#ubuntu-motu 2006-01-09
<kjcole> ajmitch, The page is taking shape... Not done yet, but look at https://wiki.ubuntu.com/MOTU/School/2005-12-10
<kjcole> ajmitch, and https://wiki.ubuntu.com/MOTU/School
<ajmitch> ok
<nalioth> what are the courtesys on packaging things that are in REVU already?
<ajmitch> nalioth: you generally don't
<kjcole> ajmitch, Everything up to the "ajmitch sets mode: -m" (public question time) is up, though some formatting required.  Lemme know what you think later.
<nalioth> next question. i'm now getting errors >>> Build dependencies/conflicts unsatisfied; aborting. <<< even though i have all the depends on the machine now (are meta-pkgs valid in teh build-depends?)
<ajmitch> it will list what packages are msising
<nalioth> ajmitch: it makes no sense to me http://paste.ubuntu-nl.org/6556     as i have all those pkgs
<ajmitch> not according to that :)
<nalioth> i've tried kde-devel in that space, but what i pasted is the components of kde-devel
<nalioth> perhaps i'm overdoing it
<Kyral> hehe nalioth
<nalioth> Kyral: i'm clueless on all this
<nalioth> i speak many human languages, but this stuff is unknown to me
<Kyral> Like I was 4 months ago
<GregorR-L> Kyral: And now you barely speak English but can speak C++ in your sleep? ;)
<Kyral> that was a bad pin
<Kyral> pun even
<Kyral> ;P
<Kyral> Soon I'll be able to speak Python in my sleep :D
<ajmitch> nalioth: you're not building it in a chroot or something?
<Kyral> nalioth, have I not explained to you the benefits of PBuilders?
<nalioth> i'm really confused now
<nalioth> i'm trying to take source tarballs and dh_make them into something usable by ubuntu/debian
<Kyral> nalioth: have you read the New Maintainers Guide?
<nalioth> Kyral: it's over my head quite a bit
<seth_k|lappy> nalioth, tip: use your @ubuntu.com address for maintainer stuff; it'll make it easier in the long run
<Kyral> and more professional!
<nalioth> seth_k|lappy: ok, i'll have to figure out how to attach it to my gpg key
<seth_k|lappy> add a 'uid'
<Kyral> Like I did
<Kyral> 3 times...
<Kyral> also set .bashrc to export DEBEMAIL=<your @ubuntu.com>
<seth_k|lappy> Any KDE-loving MOTU want to review a kde-style real fast?
* Kyral wonders if its odd that he signs packages with "Christopher Peterman (Chris)
<Kyral> seth_k|lappy: If I was MOTU I would because I owe Riddell for uploading EasyChem
<raphink> good work done in doc today :)
<Kyral> Yah I was redoing the Emacs Wiki
<Kyral> then my computer crashed and I lost all the work >_<
<raphink> real fast seth_k|lappy ?
<seth_k|lappy> raphink, the diff is like 2KB ( http://revu.tauware.de/details.py?upid=1374 )
<raphink> let's see
<Kyral> I'm not doing DocTeam work more like fixing the Wikis
<nalioth> Kyral: yes, i got all that export stuff, and just added a uid to my key and exported it to the world
<raphink> seth_k|lappy: Remove client/config/configdialog.{h,cc} from orig.tar.gz.
<raphink> why?
<seth_k|lappy> raphink, FTBFS otherwise. I'll show you (but Riddell was the one that told me to do it)
<seth_k|lappy> raphink, http://seth.pastebin.com/488266
<Kyral> Gotta wait until the Installer is done before I can work on the Install Guide for DocTeam
<raphink> FTBFS?
<seth_k|lappy> fails to build from source, sorry
<Kyral> Fail To Build From Source
<seth_k|lappy> notice the highlighted lines. It tries to moc a file that can't be found
<seth_k|lappy> but configdialog.{h,cc} are generated from configdialog.ui
<raphink> hmm ok
<raphink> ok fine then
<raphink> you could use compat 5
<Kyral> wtf is compat 5?
<raphink> I was talking to seth_k|lappy Kyral
<Kyral> yah buyt what is it lol
<raphink> debhelper >= 5 in control
<seth_k|lappy> raphink, but if it doesn't need it, should I stick to the lower compat?
<raphink> and 5 >> compat
<Kyral> ah
<ajmitch> I'm sure in your pakages Kyral you've set the compat level for debhelper
<raphink> seth_k|lappy: the policy is to now use compat 5
<seth_k|lappy> raphink, okay, thanks :) I shall change
<Kyral> ajmitch: Uhh...I let dh_make do it...
<ajmitch> Kyral: and there lies the problems in today's society
<Kyral> yah yah
<seth_k|lappy> ajmitch++
<raphink> seth_k|lappy: in debian/control long description : s/that aim/that aims/
<Kyral> dh_make defaults to compat 4
<ajmitch> for now
<seth_k|lappy> raphink, no... subject/verb agreement
<raphink> Kyral: yes and it's outdated
<seth_k|lappy> the styles aim
<raphink> hehe sorry seth_k|lappy
<raphink> mea culpa ;)
<Kyral> hmm
<Kyral> I should change EasyChem to compat 5 and have someone upload the debdiff
<ajmitch> raphink: I don't think it's mandatory to use 5, but recommended
<ajmitch> Kyral: it's not like it'll change much
<seth_k|lappy> no worries, mon franais est plus, plus pire que votre anglais :P
<raphink> ajmitch: never said it was mandatory ;)
<Kyral> ajmitch: yah but I think Riddell reccommended whenever the package gets updated
<raphink> seth_k|lappy: ;)
<Kyral> like when Upstream releases again
<ajmitch> raphink: no, you said ' the policy is to now use compat 5'
<raphink> hmm yes
<raphink> ajmitch: i'm afraid not everyone follows or even know the policy in most cases, so
<raphink> ;)
<raphink> ajmitch: talking of policy, I added a policy issue for next MOTU meeting
<raphink> in the agenda
<Kyral> when is that?
<Kyral> The next MOTUMeeting?
<ajmitch> undecided
* Kyral falls down
<raphink> no idea when it is
<Kyral> I hangout in #ubuntu-meeting anyway
<nalioth> can i run dh_make outside of a chroot and let my pbuilder make it again inside the chroot?
<Kyral> so I'll catch it
<nalioth> er, debuild, i mean
<raphink> but there's already something in the agenda ;)
<ajmitch> raphink: the thing is, there's no difference between those 2 files
<raphink> ajmitch: yes but with GPL3 coming there might be
<raphink> policy states .../GPL should be used
<raphink> but doesn't talk about .../GPL-2 at all
<raphink> and it seems GPL-2 is a static one
<Kyral> oh jeez what is that package that helps test Debpacks
<raphink> whereas GPL is to be dynamic and link to GPL3 once released
<raphink> so it should be for "GPL 2 or later" packages
<Kyral> not Linda or Lintain...
<raphink> lintian
<ajmitch> file a bug on debian-policy then :)
<raphink> ajmitch: well we can discuss it ;)
<Kyral> puiparts I think
<raphink> slomo seemed to think packaged released on GPL 2 had to be linked to GPL-2
<Kyral> or something like that
<raphink> although GPL also contains GPL v2 now
<raphink> and I don't know any app released under GPL 1
<raphink> since it's far too old
<Kyral> got it piuparts
<raphink> ajmitch: I don't think there is anything to modify in debian-policy package
<raphink> just to get clear on whether packages need to link to .../GPL or .../GPL-2
<raphink> and how to deal with GPL-3 when we'll have packages using it
<Kyral> GPL-3 is out?
<raphink> (when it's released that is )
<Kyral> lol
<raphink> nope
<raphink> it's soon to be out though
<raphink> if I understood well
<seth_k|lappy> raphink, http://revu.tauware.de/details.py?upid=1375 switched to compat 5
<seth_k|lappy> thanks for the comment
<raphink> seth_k|lappy: building now
<raphink> finishing to review
<raphink> so ar it's a nice package
<raphink> Kyral: GPL-3 is expected for the beginning of 2006, according to various sources on the NET
<Kyral> ah
<raphink> although hey we all know the FSF ;)
<raphink> and the Hurd was expected for 1994 I think ;)
<Kyral> lol
<Kyral> I actually wanna install Debian/HURD on a spare partition
<raphink> http://www.fsf.org/Members/peterb/gplv3
<lucas> http://ox.blop.info/bazaar/universe-versionslist.html.gz
<lucas> Outdated in Ubuntu (Ubuntu version < Debian version) : 105 packages
* raphink installed Debian GNU/Hurd/Mach K7 2 years ago
<lucas> arg !
<lucas> still 105 merges to do !
<Kyral> lol
* raphink will now wait for a stable of Debian GNU/Hurd/L4 to test it again
<ajmitch> hah
<ajmitch> raphink: 2010?
<Kyral> I also wanna play with LFS
<ajmitch> or 2020?
<raphink> ajmitch: ;)
<raphink> we'll see ;)
<raphink> I don't lose hope
<raphink> nor does gnubuntu imo
<raphink> they'll have to get a kernel after all ;)
<Kyral> yah, WTF is up with that
<Kyral> is GNUbuntu gonna be Ubuntu/HURD or something?
<nalioth> ajmitch: care to run at my latest folly? (scroll up)
<ajmitch> lucas:
<ajmitch> ajmitch@tiber:~/scripts$ wc -l current/merges
<ajmitch> 140 current/merges
<ajmitch> mine does count main as well
<ajmitch> nalioth: excuse me?
<nalioth> ajmitch: i asked a question above. i'll ask it again.
<ajmitch> please do
<nalioth> an i run debuild outside of a chroot and let my pbuilder make it again inside the chroot?
<ajmitch> pbuilder has its own chroot
<nalioth> also, how to add INCLUDEPACKAGE variables into my pbuilderrc? i've got INCLUDEPACKAGE=gnupg, but it's not including it
<Kyral> hey LJ
<ajmitch> why do you want to do that?
<nalioth> ajmitch: yes, but is running debuild on my own account gonna create any nastiness in the .dsc, and such?
<ajmitch> it may do
<ajmitch> depending on how the packaging is
<ajmitch> and if upstream has proper makefiles
<nalioth> ajmitch: i have no idea what i'm doing here. i want gnupg in my pbuilder so it quits complaining about 'is gnupg installed'
<ajmitch> I hate packages where you can't build them cleanly twice in a row
<ajmitch> pbuilder --save-after-login login
<ajmitch> install gnupg
<nalioth> ajmitch: ah, ok. ty
<raphink> bad crash
<raphink> seth_k|lappy: comment sent
<seth_k|lappy> haha thanks raphink
<seth_k|lappy> :)
<LaserJock> lucas: how's to wiki work going?
<Kyral> gah...anyone know what the vpenis stat for a processor means? Everytime I fire off my sysinfo script I get a wierd reaction because of that stat...
<lucas> LaserJock: I did quite a lot of rewriting/merging/removing
<lucas> nobody has complained yet, so it looks like I didn't remove too many important things by mistake ;)
<LaserJock> lucas: yeah, I saw that. I am subscribed to all the MOTU pages
<raphink> no fun, this package is too perfect ;)
<raphink> hehe
<raphink> siretart: are you there?
<ajmitch> siretart is off for a week
<LaserJock> lucas: do you think that anything on Merging is useful for MOTUMerging ?
<raphink> yes, lucas's been very busy on the wiki today :)
<lucas> ah
<lucas> didn't know of Merging
<lucas> this page is cool
<lucas> I'll add a link on MOTUMerging
<LaserJock> cool, I worked quite a bit on that page but I don't know if it is really useful
* lucas is depressed by seeing the list of packages he generated
<lucas> so many ubuntu-specific changes, so many merges to do
<raphink> lucas: :(
<raphink> :( :(
* raphink needs to get to merge soon
* raphink doesn't know how to merge really yet
<raphink> or yet really
<raphink> whatever
<lucas> :-)
<lucas> try to work on xtranslate
<lucas> it is an easy one, looking at the diffs
<raphink> lucas: would you have time to explain to me how to merge ?
<lucas> try first to read MOTUMerging and the linked pages
<lucas> if you have questions, I can answer them and improve the docs
<raphink> ok
<raphink> well looking at http://revu.tauware.de/~sistpoty/MoM/index.py?state=new
<raphink> I see only 7 packages to merge
<lucas> yeah, the list is generated from the logs
<crimsun_> list hasn't been refreshed yet
<lucas> and it's probably buggy
<raphink> ic
<lucas> use the list from http://ox.blop.info/bazaar/universe-versionslist.html.gz
<raphink> so where do I get the real list?
<lucas> look at the legend at the bottom
<raphink> ok
<lucas> oups legend is not english :-)
<LaserJock> well the revu.tauware.de list comes from the MoM logs
<raphink> argh
<crimsun_> I use the version on tiber
<raphink> so merges are to be done on the orange ones, right?
<LaserJock> is MoM working still?
<raphink> Outdated in Ubuntu (Ubuntu version < Debian version) : 105 packages
<lucas> LaserJock: it seems to miss a lot of merges
<crimsun_> yep, MoM still works
<lucas> raphink: yes
<raphink> that's what is to be synced/merged?
<raphink> ok
<lucas> try xwit and wtranslate
<lucas> xwit is a sync, xtranslate is a simple merge
<raphink> why?
<raphink> I'll work on kde ones ;)
<lucas> because they are easy :-)
<raphink> kgeography
<raphink> :)
<raphink> well I'm a packager and I already reviewed merges
<lucas> kgeograhy should be autosynced
<raphink> i just don't know the steps with the bugs an malone and so on
<raphink> but I know how to package ;)
<lucas> since there's no ubuntu changes
<crimsun_> it'd be nice if http://ox.blop.info/bazaar/universe-versionslist.html.gz could be filtered only for ones that we need to merge
<lucas> probably just lagging
<raphink> hm ok
<lucas> crimsun: I can do that
<crimsun_> lucas: great, I'd really appreciate it
<raphink> lucas: so only packages with ubuntu changes must be checked and merged/synced manually?
<lucas> well kgeography is an exception
<LaserJock> raphink: right
<lucas> it's here because it was probably uploaded today
<raphink> ok
<raphink> how about kmess then?
<lucas> ah, no, that's strange
<lucas> anyway
<lucas> yes, go with kmess :)
<raphink> hmm
<lucas> ah
<raphink> how do I merge kmess ?
<lucas> kmess is -0ubuntu2
<lucas> it was uploaded to ubuntu BEFORE debian
<lucas> through REVU probably
<raphink> it's a package that was added by Tonio_ from scratch
<LaserJock> well, it looks like revu.tauware.de has up to 12/31/05
<raphink> yes
<raphink> exactly
<lucas> so what you can do is debdiff them
<raphink> not so long ago
<lucas> see if debian improved the package
<raphink> lucas: who'll get the authoring for the package?
<lucas> by authoring, what do you mean ?
<raphink> hmm ok
<lucas> the maintainer field doesn't change
<raphink> I shall get the packages from p.d.o and p.u.c I guess
<lucas> if it's a merge, you add a changelog entry with your name
<raphink> and run the debdiff manually
<raphink> no I mean
<lucas> yes
<raphink> if I merge the Debian version in Ubuntu
<seth_k|lappy> merging is confusing; I never understood how to do it efficiently
<seth_k|lappy> I can do it, but not quickly (and probably not well)
<raphink> Tonio_ will lose the maintainership of his
<raphink> his package will disappear
<crimsun_> merging's actually really easy
<raphink> seth_k|lappy: i'm just learning
<lucas> depends on who is the maintainer in the debian version
<raphink> lucas: not Tonio_ for sure
<raphink> ;)
* lucas downloading both packages
<lucas> maybe he found a sponsor
<crimsun_> 1) read REPORT; 2) look for -dropped.patch in the MoM directory; 3) if the bits in -dropped.patch have been subsumed, it's a sync, otherwise it's a by-hand merge
<seth_k|lappy> crimsun_, in concept indeed, but it's so time-consuming to read the dropped patch and check files by hand
<lucas> usually I only use the ubuntu patch
<lucas> and see if the changes were integrated in debian
<crimsun_> if you're ever confused, take the latest Debian revision and check what changes the last Ubuntu revision had. You can always revert to the Debian packaging and apply Ubuntu bits back part by part.
<crimsun_> sometimes it's smarter to do that because MoM generates incorrect reports
<crimsun_> particularly for the -0ubuntuX ones, since it sometimes gets confused with the base version (particularly if snapshot.d.o was down)
<crimsun_> err, snapshot.d.n
<crimsun_> another case (see tiber->new) is say, kguitar, which we shouldn't merge because a decision has to be made whether to continue with the Ubuntu packaging or to drop it in favor of Debian's
<lucas> ok, for kmess, the two packages are totally different
<lucas> since Antonio didn't propose his package to debian, somebody else packaged it
<lucas> waste of time
<crimsun_> similar situation for kguitar
<lucas> raphink: if you know him, ask him to review debian's kmess and submit patches to the BTS to improve it
<lucas> so everything he did is not lost
<raphink> lucas: I don't think Tonio_ really wants to contribute to Debian
<lucas> ubuntu will probably use debian's version
<crimsun_> sometimes there's a compelling reason to keep the Ubuntu-specific version, like daniel's work with tilda
<raphink> yes I guess lucas
<raphink> which is why sometimes I wonder if REVU is really that useful
<raphink> since there are many more DDs than ubuntu packagers
<crimsun> revu is definitely helpful for _us_
<lucas> I'd personally recommend to look for sponsors in Debian
<raphink> mhm
<lucas> Debian has probably a good KDE team which could easily sponsor KDE-related packages
<lucas> I'm doing this on a regular basis for ruby packages
* ajmitch really does like to have packages in debian, rather than just in ubuntu
<lucas> http://pkg-kde.alioth.debian.org/docs/
<raphink> I'm trying to understand how good this is to use REVu
<raphink> rather than just getting packages in Debian
<raphink> if packages added through REVU are to be put to trash
<lucas> REVU is good to get comments/review
<raphink> to be replaced by Debian ones eventually
<lucas> the debian equivalent (debian-mentors) doesn't work as well as REVU
<Tonio_> hum
<raphink> yes but eventually, the Debian package, that didn't go through REVU, will replace the Ubuntu package that did go through it
<raphink> so what's the use?
<Tonio_> lucas, I can understand the need to report the packages to debian
<Tonio_> but anyway, what the need and purpose of revu in that case ?
<Tonio_> I mean, no need to package for ubuntu then
<lucas> raphink: not if, once you have a perfect package thanks to REVU, you go find a sponsor in debian
<Tonio_> let's go make mackages for debian directly...
<lucas> Tonio_: I never advocated REVU
<Tonio_> lucas: don't get me wrong, I don't mind if some or all of my packages are overrittent by debian ones
<raphink> lucas: then, for the good health of Ubuntu, there should be a team of DD among the MOTUs, who volunteer to automatically sponsor packages from REVU to Debian
<Tonio_> the only thing important to me is that applications are available on ubuntu repos
<ajmitch> raphink: automatically sponsor?
<Tonio_> that's the only important thing
<LaserJock> I personally am not inclined to try to get a Debian sponsor for anything I do because I don't use Debian and am not terribly  fond of it
<raphink> ajmitch: I mean some MOTUs are DDs, right?
<Tonio_> I just wonder what is the purpose of revu then....
<crimsun> we do have several DDs among us, but it's not right to expect them to be go-to guys
<raphink> ajmitch: so could these take the NEW packages from REVU and sponsor them in Debian ?
<ajmitch> raphink: that takes a fair bit of work, and also the maintainers have to care for their packages in debian
<raphink> so Ubuntu packagers don't have to deal with getting their packages both in Ubuntu and Debian ?
<ajmitch> there are very few of us that are DDs as well
<ajmitch> yes they have to deal with it
<ajmitch> it would never be a straight automatic process
<lucas> raphink: lack of ressources in MOTU + Debian's requirements regarding package quality are much higher than ubuntu's
<ajmitch> lucas: I prefer to keep ubuntu's package quality just as high
<LaserJock> Why can't we Ubuntu people take care of our own packages? Why do we have to have Debian look after stuff we are willing to maintain?
<Tonio_> if the goal is to have universe packages exactly like debian ones, and all work merged, it would be better to have a shared plateform with debian
<Tonio_> and just work once, no ?
<lucas> ajmitch: yes, but in reality, some packages who go through REVU are not as good as debian packages
<ajmitch> lucas: I know, some slip through
<ajmitch> and I don't like that
<raphink> lucas: we also see many Debian packages that are not good ;)
<raphink> ajmitch: so then we should try to get more MOTUs to be DDs
<lucas> Tonio_: the goal of MOTU is to manage divergence
<whiprush> raphink: are you the upstream deskbar-applet guy? Or am I mixing you up?
<ajmitch> raphink: hah, good luck
<raphink> you're mixing me up whiprush
<ajmitch> raphink: there's about 2 MOTUs in NM at the moment
<whiprush> k
<ajmitch> they might be DDs in a year or so
<raphink> ajmitch: see ? there's a pb here
<raphink> Debian refuses to take more DDs easily
<ajmitch> why?
<raphink> we want to get as close to Debian as possible
<ajmitch> I really don't feel like rehashing this tired argument again
<raphink> but it only works one way
<ajmitch> we seem to have it each month
<raphink> so if we had stuff in Ubuntu
<raphink> it doesn't get back
* ajmitch will bbl
<raphink> well i'll just like to understand
<lucas> raphink: the whole problem is that Debian is doing a HUGE work
<raphink> and understand if it's really worth it having new packages through REVU if they are to be replaced soon
<lucas> that ubuntu can't do because ubuntu doesn't have the resources
<lucas> some people think that ubuntu != debian
<raphink> yes I understand that lucas
<raphink> but reckon also that Debian hasn't been doing some work that ubuntu has been doing
<lucas> that you can contribute to ubuntu without contributing to debian, and that's fine
<raphink> otherwise Debian would be the user-friendly distro that Ubuntu is
<raphink> lucas: no I agree that we have to contribute to Debian
<raphink> I totally agree
<Tonio_> lucas: I personnaly understand the need to contribute to debian
<raphink> what I don't understand is the use of REVU in this case
<raphink> is it not a waste of time to package new stuff
<lucas> well, personally, I must admit I don't know
<raphink> that are gonna be lost in merges soon?
<lucas> except for Ubuntu-specific packages
<lucas> and to get reviews
<raphink> and why, instead, don't we make it easier to contribute to Debian directly?
<tseng> hi ogra
<lucas> raphink: contributing to debian is hard
<raphink> we should then encourage packagers to do their work in Debian and merge it afterwards, no?
<ogra> hey
<raphink> lucas: that's the pb
<lucas> look at the archives of the debian-mentors ML
<lucas> lots of RFS (request for sponsor), few answers
<LaserJock> raphink: I don't run Debian so I don't create packages for Debian
<raphink> i don't want to contribute to Ubuntu with new packages, spend tens of hours on packages, and have my work replaced because "contribution from Debian is of higher quality"
<raphink> supposedly
<lucas> LaserJock: I thought it was about Free Software
<LaserJock> raphink: I submit stuff to REVU because I want it in Ubuntu. I honestly don't care so much if it ends up in Debian
<raphink> LaserJock: that's not the issue at all
<Tonio_> I have seen many many debian packages that wouldn't been advocated on revu...
<LaserJock> raphink: isn't it
<raphink> I'm really happy if my work ends up in debian
<lucas> Tonio_: have you filed bugs ? ;)
<raphink> the issue that my work is not lost
<LaserJock> I am to but I doubt it will happen for me
<raphink> replaced by the dupplicate work of someone else in Debian
<Tonio_> lucas, they are not buggy
<raphink> who didn't even care that I did the work first
<raphink> Debian can't deny the existence of Ubuntu anymore
<Tonio_> they just leave files, leave modified content on binaries etc...
<raphink> just as we check if packages exist in Debian already before packaging them
<lucas> Tonio_: you can send wishlist bugs with a patch in the BTGS
<lucas> BTS
<raphink> why don't they check here before packaging?
<Tonio_> lucas: I agree with you that point, I can, and shouuld
<raphink> just recognizing we can package too
* seth_k|lappy hunts for a MOTU that likes KDE to give him a second review for a new KDE style
<lucas> raphink: rule #1: it's hard to force a debian developer ;)
<raphink> and not wasting manpower in duplicating work
<Tonio_> my only question is, in that case why not closing revu, and try to build a common package submitting system with debian ?
<lucas> Tonio_: buxy proposed that
<Tonio_> merging would be necessary in that case
<lucas> but nothing went out of the discussion I think
<Tonio_> because technically merging is a waste of time
<lucas> Tonio_: merging is necessary because of some choices ubuntu makes
<raphink> no Tonio_, some packages need to be merged because debian and ubuntu don't have the same libs
<lucas> for example python 2.4 instead of python 2.3
<lucas> or modular xorg
<raphink> but that shouldn't prevent to have a common REVU-like system
<Tonio_> agree, yes
<lucas> but I agree that unecessary divergence sucks
<raphink> to check the quality of packages
<raphink> quality assurance could be common
<raphink> while having packages build on different libs
<lucas> raphink: it already is to some point
<raphink> open-source allows to not waste manpower in duplicating work
<raphink> yet that's what happens with debian and ubuntu
<lucas> not really
<lucas> only with REVU ;)
<raphink> well lucas
<raphink> when I see a package added to Ubuntu through REVU
<Tonio_> well, let's stop using revu, package for debian
<lucas> more precisely: only with REVU packagers who don't seek a debian sponsor
<raphink> when the packager spent 1month working on it
<raphink> and eventually it gets replaced by a Debian package
<Tonio_> and if things go well, we'll se our packages in ubuntu for dapper +3 ^^
<raphink> whose maintainer didn't even notice there was a work done in ubuntu before
<raphink> I call that a waste or manpower
<lucas> Tonio_: upload a package today in Debian. It is in ubuntu tomorrow.
<raphink> lucas: where is it written in the ubuntu doc that we ought to find a sponsor for Debian ?
<Tonio_> lucas: I hope you're right
<LaserJock> but how are we supposed to change Debian?
<Tonio_> and I'm okay to make the test
<LaserJock> I think REVU is great and I think it is very useful
<LaserJock> if Debian wanted to use it it would be great
<Tonio_> LaserJock: don't dream
<lucas> Tonio_: checking right now ;)
<raphink> where are we told how to get our packages in debian, if it's the way to go ?
<raphink> and why are we told to use REVU if it's better to get a DD to sponsor our work ?
* raphink is just trying to understand
<lucas> Tonio_: ok, maybe more than 1 day
<raphink> lucas: the NEW queue in Debian is already more than 1 day ;)
<LaserJock> cause it is faster to get things in Ubuntu through REVU and Debian sponsorship
<lucas> if you upload a NEW package in Debian, it is reviewed by the ftp-master team (for license stuff, etc), which takes ~1 week
<lucas> then, it gets in the NEW queue in Ubuntu
<lucas> I don't know who manages it, but he seems to be in holidays :-)
<LaserJock> elmo I think
<lucas> if he takes as long as Debian, it takes 2 weeks
<Tonio_> okay, so let's close revu and resubmit everything to debian then.....
<LaserJock> it only takes 2 weeks to get a package in Debian?
<LaserJock> Tonio_: no way, I like REVU
<LaserJock> but that is just me I guess
<Tonio_> hum
<Tonio_> debian's organisation is a total mess
<lucas> it takes one week between you sponsor upload and the package shows up in debian unstable
<Tonio_> and that's to stay polite
<lucas> Tonio_: no, it works very well
<crimsun> I think Debian's situation has vastly improved since pre-Warty
<Tonio_> lucas, that's not incompatible :)
<LaserJock> how long does it take to get a sponsor in Debian
<Tonio_> a mess can be working fine, look at postfix ^_^
<lucas> LaserJock: find one who is vaguely interested in your packages
<lucas> your packages are about science. look for people packaging similar stuff.
<lucas> ask them to review your packages
<LaserJock> well, they are few and far between
<LaserJock> that is what I am saying
<seth_k|lappy> LaserJock, would you have time to do a quick MOTU review for me, or are you busy?
<LaserJock> seth_k|lappy: I'm not a MOTU :(
<lucas> LaserJock: or find a researcher who is a debian packager :-)
<lucas> (this is easy)
<seth_k|lappy> LaserJock, oops, sorry. Thought you were
<LaserJock> well, that is why I am here, because I can't find very many of those
<seth_k|lappy> LaserJock, erm... you are in the team on Launchpad, guess that's why I thought you were :)
<lucas> buxy: ping
<lucas> buxy: interesting discussion for you here, wake up ;)
<LaserJock> I package for Ubuntu because I run Ubuntu and I don't want to run Debian as well just to get my packages in Ubuntu
<lucas> LaserJock: you can just use a chroot
<rraphink> if I understand well though
<LaserJock> seth_k|lappy: yeah on launchpad motu != MOTU
<lucas> you don't need to use debian to find a sponsor
<Kyral> Yah I need to join the LP Team lol
<lucas> also, DDs are not idiots, they understand what ubuntu is about
<rraphink> we basically better tell packagers that if they want to add to Ubuntu the better way
<LaserJock> lucas: but then I have a lot more work. I just want to get my packages in Ubuntu. I know that it somwhat selfish but I just don't have time for 2 distros
<rraphink> while keep using Ubuntu
<lucas> LaserJock: it will take time to find a sponsor.
<lucas> but then, he will provide useful comments
<rraphink> also considering the way many DDs still consider Ubuntu
<rraphink> i'm sure many packagers will be happy to do so ;)
<lucas> and after a few packages, he will trust you
<lucas> it doesn't take more time
<lucas> rraphink: most DDs have a very good opinion of Ubuntu
<LaserJock> lucas: in the scientific area I think it takes much longer to get a package in Debian than in Ubuntu
<psusi> damnit... how do you get emacs to insert a hart tab again rather than spaces to the default indent level?
<Kyral> guys
<Kyral> new UniverseCanditate
<Kyral> http://ubuntuforums.org/showthread.php?t=112176
<lucas> LaserJock: maybe an interesting project to start would be to create a list of DDs willing to sponsor packages that went through REVU
* Kyral looks at ajmitch
<ajmitch> Kyral: that's great, have you added it to UniverseCandidates?
<lucas> since this mean that they have reach a minimum quality level
<Kyral> no, someone just pinged me lol
<Kyral> and I wasn't looking at you for that
<Kyral> I was looking at you for lucas thing
<ajmitch> Kyral: perhaps you could just reply to the forums telling them where to make suggestions?
<rraphink> [02:40]  * rraphink thinks he wants to go through the NM process and create a MOTUDDSponsor team
<rraphink> [02:40]  <rraphink> to get Ubuntu packages into Debian before they are dumped
<rraphink> [02:41]  * rraphink has seen what it is to depend on a sponsor at a Debian conf and doesn' tlike the idea of it though
<Kyral> The Forums Community knows I am connected to MOTU
<ajmitch> rraphink: utnubu team
<lucas> Kyral: I mean DDs which aren't already ubuntu devs
<ajmitch> Kyral: that's wonderful & all, but they still need to be told how to make requests properly
<Kyral> goodpoint
<ajmitch> so many suggestions there, none of which the developers see
<lucas> raphink: being sponsored can be very cool
<lucas> for example, I'm part of a ruby team in debian
<lucas> when I need one of my packages to be sponsored
<rraphink> ajmitch: does utnubu take packages straight from REVU to get them in debian before they are packaged ?
<rraphink> or at least inform DDs of the existence of packages in Ubuntu
<lucas> I just ping one of the members
<lucas> of the team
<rraphink> before they begin to duplicate the work
<Kyral> Personally I'll wait until 1) I actually USE Debian and 2) Until I am MOTU
<lucas> I already got sponsored by 3 different DDs like that, and I never waited
<rraphink> Kyral: being a MOTU won't give you any role on consideration in Debian
<crimsun> nor should it, really
<crimsun> (unless you've got packages in Debian)
<LaserJock> I just don't see why we should have to learn two different distros to help Ubuntu out
<lucas> rraphink: if you package something in REVU, the minimum contribution to Debian you should do is file an ITP
<ajmitch> rraphink: they take packages from ubuntu repositories, not REVU
<lucas> (intent to package)
<Kyral> rraphink: I mean by then I should have MUCH more experianced
<ajmitch> lucas: no, minimum should be RFP
<rraphink> lucas: then let's document ITPs in the ubuntu doc
<rraphink> never seen anything about ITPs in it
<ajmitch> considering that this was agreed upon about 4 months ago
<ajmitch> but whatever
* ajmitch gives up 
<LaserJock> it seems to me that there will always be duplication of work to some degree as long as the distros are seperate
<Kyral> Wait can we package Public Domain packages?
<ajmitch> Kyral: as long as you know it's public domain
<Kyral> Yah sf page says its PD :D
<ajmitch> then package it
<Kyral> I will
<Kyral> when my computer stops acting up
* Kyral adds it to his "To Package" queue
<Tonio_> rraphink: totaly agree....
<rraphink> Kyral: so having much more experience will give you ... what?
<rraphink> Kyral: Ian Murdock chose to apply for NM instead of accepting to be a DD as a matter of fact
<Kyral> rraphink: Knowing what I'm doing? Making less stupid mistakes?
<rraphink> I think he's still waiting to be accepted
<Kyral> NM?
<Tonio_> ubuntu documentations don't refer at any moment to what to do with merging, ITP or any kind of debian contribution
<rraphink> ;)
<rraphink> Kyral: NM = New Maintainer
<Kyral> ah
<Kyral> whats the difference?
<rraphink> Kyral: NM is to get to be a DD
<rraphink> meaning he's not officially a DD yet
<Kyral> ah
<rraphink> although he's the creator of Debian
<Kyral> so its like to become MOTU, you need to be a Member
<rraphink> kind of
<Kyral> To become a DD you need to be a NM
<rraphink> well you can go the NM way to be a DD
<rraphink> this is a long way
<rraphink> at last!
* Kyral considers just hanging out in #debian for a while...
<lucas> you can be Maintainer of packages without being DD
<lucas> DD means write-access to the archive, basically
<raphink> you get tested on your knownledge of licenses, techniques, etc.
<lucas> if somebody writes your packages for you, no problem :-)
<lucas> that's what sponsors are for
<Kyral> Yah, I figure if I'm MOTU I'll know that stuff better than I do now
<raphink> Kyral: then hang out in #debian-mentors instead ;)
<raphink> this is the equivalent of #ubuntu-motu
<Kyral> lol okay
<Kyral> less likely to be shot?
<raphink> haha
<Kyral> Seriously some people might remember me
<raphink> so what ?
<raphink> i'm still in Debian
<raphink> leading a project on alioth
<raphink> and that's fine
<Kyral> one of the guys in #ubuntuforums was piss drunk one night and made such a mess in #debian that one of the guys came in saying he'd go to lilo
<raphink> except I've got to have all my work sponsored
<raphink> by a DD
<Kyral> I went into #debian and apologized for him
<lucas> hey, another important point in favor of seeking a sponsor in debian
<lucas> imagine you get integrated into the debian kde team
<Kyral> Gak! One of you guys has to register me to the MOTU LP Team
<lucas> you get to know all debian kde maintainers much better
<lucas> so it's much easier to do your MOTUKDE work
<raphink> you're a MOTU Kyral ?
<raphink> ;)
<Kyral> no, but neither is LJ :P
<raphink> lol
<raphink> pff
<Kyral> Hey cool! It shows up that I am the maintainer for EasyChem on my LP profile
<raphink> lucas: that implies that Ubuntu contributor must be told once and for all that they should contribute to Debian directly, but not expect to be recognized by DDs
<raphink> yep Kyral :)
<raphink> and you can access the package options from there
<raphink> like translation
<raphink> if available
<Kyral> I'm not upstream so I don't tink I'm authorized to translate it
<lucas> raphink: why "not expect to be recognized by DDs" ?
<raphink> because I know many DDs who don't like Ubuntu
<lucas> ajmitch: you have a pointer to the discussion about RFP being the minimum level to expect ?
<lucas> raphink: give out names.
<lucas> I don't know any.
<raphink> I don't have names
<raphink> lucas: are you a DD yourself?
<lucas> no, I'm stuck in NM :)
<raphink> lucas: since ?
<lucas> mmh
<lucas> ~4 months
<raphink> hehe
<raphink> what can non-DDs do in Debian without needing someone to oversee their work?
<lucas> but it's not a problem
<lucas> everything that has to do with bugs
<lucas> for example
<Tonio_> lucas: maybe you know a patient and sympathetic DD
<Tonio_> but my personnal experience with debian's commmunity is a disaster
<lucas> Tonio_: I know a lot of them ;)
<lucas> ok, so maybe it's true it would be a good thing to start a list of DDs willing to sponsor packages from Ubuntu
<Tonio_> if you want my point of view, most of them are pretentious assholes....
<Riddell> isn't that what utnubu is?
<Tonio_> but well, I'm not objective
<raphink> lucas: utnubu, as ajmitch pointed
<lucas> Riddell: utnubu is quite dead I think
<raphink> Riddell: the point is that they're not numerous enough then
<Riddell> hmm
<lucas> and it doesn't work the good way
<raphink> or not active enough
<raphink> let us just not waste time and work
<lucas> Riddell: basically, they generate lists of packages, and select some of them
<raphink> we've got apps that exist in Ubuntu and not in Debian yet
<raphink> if we don't get them in Debian, two things will happen
<raphink> 1) Debian is missing them in a way, which is a waste for it
<lucas> it would probably be more interesting if REVU packagers could go chat with them
<raphink> 2) Debian will package them one day, and waste that time spent for this work in ubuntu
<raphink> shall it be added to the PackagingTips that non-ubuntu-specific packages should be done with an ITP ?
<ajmitch> no
<Tonio_> that's why I would suggest a unique package submitting plateform
<Riddell> ajmitch: why not?
<raphink> so _at least_ debian packagers don't begin to do it on their side
<lucas> ajmitch: you have a pointer to the discussion about RFP being the minimum level to expect ?
<ajmitch> Riddell: because an ITP says that the person will maintain it in Debian
<raphink> hmmm
<ajmitch> lucas: I had one, you can probably find it on google
<Riddell> ajmitch: you can still post to wnpp saying it's packaged, please someone put it in debian
<ajmitch> Riddell: that's an RFP
<raphink> can someone expand the abbrev a bit ?
<Riddell> yeah, they're all acronymns
<lucas> ajmitch: I understand RFP as "it's not packaged, please package and maintain it for me"
<raphink> for non-debian guys
<ajmitch> request for package, intent to package
<lucas> http://www.us.debian.org/devel/wnpp/
<ajmitch> lucas: not necessarily, we've filed RFPs that refer to the ubuntu packages before
<raphink> lucas: yes, and ITP as `I'm working on a package, please don't duplicate my work'
<lucas> but does an ITP imply that you are a DD ?
<ajmitch> no
<lucas> we could leave REVU packagers the choice
<raphink> what does it cost to file an ITP then?
<ajmitch> an ITP implies that you will maintain it, whether you're a DD or not
<lucas> RFP is they prefer to let sbody else maintain
<lucas> ITP if they want to find a sponsor
<Tonio_> why couldn't it be automatic ?
<raphink> we could at least _inform_ Ubuntu packages of the existence of WNPP and its options
<Tonio_> REVU is able to make the difference between a new or updated package....
<Tonio_> that's typically the kind of thing that could be automated between REVU and sponsor.debian.net
<psusi> I'm updating a package in universe that I believe is synced from debian... that means rather than bump the -11 to -12, I want to make it -11-0ubuntu1 right?
<Tonio_> in the plateform level
<Tonio_> and not to be done by every packager for every package
<lucas> psusi: -11ubuntu1
<psusi> ahh... ok
<Tonio_> to me, in a logic and general way
<Tonio_> the link between two trees has to be done at the top of them once
<Tonio_> and not between all branches....
<lucas> Tonio_: then what ?
<lucas> packages from REVU get to mentors.
<lucas> and they sleep there.
<raphink> hehe
<lucas> looking for a sponsor has to be a human process
<Tonio_> that's why cooperation between ubuntu and debian has to be defined at the top level
<raphink> lucas: so you need to know DDs personnaly
<Tonio_> and the conclusion could be a common working plateform
<Tonio_> something like that
<Tonio_> becasue actually, contribute to debian is long, diffcult and not very convenient
<Tonio_> if contributing to ubuntu means contributing to ubuntu + contributing to debian....
<Tonio_> well, it becomes heavy
<lucas> raphink: apt-cache show <package>
<lucas> and you start to know DDs ;)
<raphink> lol
<raphink> well I know DDs already
<raphink> but as Tonio_ says
<raphink> really
<raphink> it's a bit weird that ubuntu contributors, who are less numerous than debian ones
<raphink> have to work on both debian and ubuntu
<raphink> while debian ones don't have to worry about debian
<raphink> although historically it's totally logical I reckon
<Tonio_> well, the problem is that ubuntu contributors are not thowsands
* raphink drops just a note : we're three french guys debating in english here
<Kyral> hmm...the auto-backport thingy got EasyChem lol
<lucas> I'll write MOTUContributingToDebian and discuss the "friendly DD list" with buxy tomorrow
<Tonio_> but ubuntu has grown incredibly in a very short time
<Tonio_> more people are using ubuntu than debian actually, by far....
<lucas> Tonio_: I don't think so
<raphink> Kyral: where do you see that?
<lucas> for example, there are far less popularity-contest results for ubuntu
<Tonio_> lucas, I personnaly don't know any debian user that hasn't or isn't about to switch....
<Kyral> raphink: I got an email
<raphink> Kyral: nice :)
<lucas> Tonio_: I know lots of them
<raphink> few DDs are about to switch
<raphink> but many users are
<Tonio_> raphink: how many are DD compared to users ?
<Tonio_> 0.01% ?
<raphink> I doubt so
<raphink> lol
<raphink> there are about 1000 DDs
<raphink> that would make a bit too many Debian users imo
<raphink> ;)
<LaserJock> ok, so here's my problem. It is hard enough for me to keep track of where to go and what to do for Ubuntu but if I also have to learn Debians system and MLs then I just think I will be swamped
<raphink> I doubt there's 10M debian users ;)
<Tonio_> the problem is that ubuntu can't ignore debian
<Tonio_> for historic, technicall and ethic reasons
<raphink> Debian can less and less ignore Ubuntu
<Tonio_> BUT, debian cannot ignore ubuntu longer to me....
<raphink> but DDs can choose to ignore Ubuntu
<Tonio_> and maybe it is time to have a real work sharing program
<raphink> whereas Ubuntu devs cannot really choose to ignore Dbian
<LaserJock> I don't think Ubuntu ignores Debian
<raphink> huhu
<Tonio_> and not on ly ubuntu contributors having to asslick debian DDs....
<Tonio_> excuse my language, but that's my feeling.....
<LaserJock> Tonio_: what would a work sharing program consist of
<lucas> la plupart des DDs ont une excellente opinion d'Ubuntu
<Tonio_> LaserJock: to me ?
<LaserJock> sure
<Tonio_> a common package submitting plateform
<Tonio_> to start
<lucas> le coup des DDs qui n'aiment pas Ubuntu n'existe que sur linuxfr :-)
<raphink> lucas: mais un MOTU restera toujours moins qu'un DD pour un DD
<Tonio_> no need to have two plateforms if the common goal is to have a perfect merging
<raphink> the goal is not to have a perferct merging Tonio_
<Tonio_> lucas: je dis aps le contraire
<lucas> raphink: je sais pas s'il y a vraiment ce sentiment de scurit
<lucas> de supriorit
<lucas> pardon
<lucas> peut-tre un peu, et alors ?
<raphink> parfois on se demande ;)
<Tonio_> mais je pense aussi que hormis si on a de bonnes connaissances dans le milieu debian, on se fait facilement chier dessus, si je peux me permettre l'expression
* Kyral makes a note to make a translation script for Irssi
<Tonio_> debian, c'est trs "systeme de caste"
<LaserJock> it just seems to me that there is enough differnce between the distros that having a commmon platform wouldn't be fesible
<lucas> Debian est la distrib GNU/Linux qui apporte le plus au libre, depuis plus de 10 ans
<Ubugtu> An error has occurred.
<Kyral> lol
<Tonio_> et la norme c'est de pter du haut du dos, dans bien des cas...
<LaserJock> Ubugtu need one too Kyral
<lucas> bof
<raphink> lol
<raphink> Kyral: kopete has an automatic translation module
<raphink> it's pretty slow though
<raphink> obviously
<lucas> Debian is the GNU/Linux distribution which brought the most to Free Software, for more than 10 years now
<Kyral> raphink: yah
<seth_k|lappy> or you could just learn french, like I did :P
<lucas> seriously, what did Ubuntu bring to free software ?
<Tonio_> lucas: c'est pas parcequ'ils font des trucs ethiquement bien que tout est rose.... les guguerres de pouvoir dans le libre ca existe....
<raphink> agreed lucas
<LaserJock> I just don't see why we need to worry about Debian so much, if they want our stuff they can get it
<raphink> lucas: users ?
<Tonio_> lucas: l'humilit ? ^_^
* Tonio_ doesn't know how to say that in english
<raphink> LaserJock: it's not the issue
<lucas> LaserJock: what do you prefer:
<raphink> LaserJock: I don't mind my work ending up in Debian, on the contrary
<lucas> 1) get you packages overriden by those of a debian developer
<raphink> LaserJock: but I'd rather it not be duplicate and replaced taht's all
<lucas> 2) maintain your packages for both ubuntu and debian
<lucas> if you do (2), you get a lot of potentially new users
<lucas> which all file very good bug reports, make patchs, etc
<LaserJock> I just don't think 2 is an option for me
<raphink> lucas: you forgot 'and get those of a debian dev merged in ubuntu' in 1)
<lucas> LaserJock: why ?
<LaserJock> lucas: because I don't have time for it
<raphink> much much work lucas
<lucas> it doesn't cost much time
<raphink> you don't measure the time it takes to understand the Debian system when you're used to it
<raphink> just as it seems very easy to me to package
<raphink> but i remember having spent days learning it
<raphink> and having headaches
<raphink> with my mentor explaining me things for hours
<LaserJock> lucas: but I really don't know anything about Debian so I would have to go and figure out the way the do things
<LaserJock> I think have to keep track of 2 distros instead of the one I am using
<raphink> lucas: once you know both Debian and Ubuntu ways, it all seems logical and easy
<LaserJock> s/think/then/
<lucas> raphink: I don't think it is so different from ubuntu
<raphink> but learning them is a long process
<Tonio_> lucas third potential solution :
<Tonio_> work for debian only and let ubuntu sync....
<raphink> lucas: once you know both, it's not very differnt, that's what I say
<raphink> Tonio_: yeah work for Debian only and use Ubuntu
<raphink> ;=)
<raphink> ;)
<Tonio_> the point is that I can admin 1), 3), but 2) is to me a waste of time
<raphink> the `Do what I say not what I do' solution
<SEJeff> someone please correct me if I'm wrong... Debian is about being rock solid and Ubuntu is about being polished ontop of a rock solid core
<LaserJock> here is my solution: package for Ubuntu and then if I get stuff in try to make sure that Debian knows about it (ML probably)
<raphink> SEJeff: I agree
<LaserJock> I don't totally agree but again I don't know a whole lot about Debian
<raphink> now the issue SEJeff is why would it be hard for the polisher devs to improve the rock ?
<SEJeff> Package it for Ubuntu and try to get a DD to rebuild it for debian
<SEJeff> raphink, grep the debian changelogs with grep -i "Ubuntu"
<raphink> SEJeff: well that's option 2)
<psusi> that's what I plan on doing... fixing it for ubuntu, then letting the debian maintainer know so he can merge in the changes when he chooses
<raphink> getting it in Debian through a sponsor
<SEJeff> I guarantee you will find a TON of ubunut changes in debian
<SEJeff> Like the entire x.org packages
<Tonio_> hum
<SEJeff> Those are more or less straight from Ubuntu
<Tonio_> the problem in fact, is confidence
<Tonio_> ubuntu syncs debian
<Tonio_> why couldn't be the sync bidirectionnal ?
<LaserJock> because DD don't want that sometimes?
<raphink> yeah it's not as automatic the other way
<raphink> because many DDs son't mind
<Tonio_> because DDs would be okay to see a package comming from ubuntu without beeing checked right ?
<raphink> don't
<raphink> Tonio_: we check Debian packages
<raphink> so it's fair they'd check ours
<Tonio_> not all.......
<raphink> but it would be nice if they did
<raphink> actually
<raphink> and i think still many packages added to Ubuntu are not synced in debian
<raphink> they are repackaged
<raphink> instead
<SEJeff> There is a debian project get ubuntu changes back into debian. I can't remember the name though
<Tonio_> why isn't that possible to automate revu to post a RFP as soon as a new package is uploaded ?
<Tonio_> is that so difficult to implement ?
<raphink> that obviously get us back to filing ITPs imo
<raphink> if we filed ITPs
<Tonio_> I don't think so
<raphink> then the work wouldn't be done twice
<raphink> SEJeff: utnubu
<raphink> but there are 6 devs in it
<LaserJock> but doesn't that mean we intend to package/maintain for Debian as well
<Tonio_> raphink: my question is, why couldn't it be autopmatic ?
<SEJeff> raphink, yes, thanks
<raphink> can 6 devs do such a huge work?
<Tonio_> why should we get a sponsor, then blabla, blabla, and waste time on that ?
<lucas> LaserJock: you know about http://lists.debian.org/debian-science/ ?
<SEJeff> raphink, if they are good.
<Tonio_> imagin you have two databases
<Tonio_> what would you do ?
<raphink> LaserJock: ubuntu is nothing without debian, it's only fair we give back... but i wish we had more means to do it
<lucas> you could subscribe, describe your packages, and ask for a sponsor
<Tonio_> implement a sync script that runs in a cron
<SEJeff> raphink, Look what Federico, Mattias, Behad, and 2 or three others are doing for gnome
<Tonio_> of tell your users to do everything twice ?
<lucas> Tonio_: you are dreaming
<LaserJock> lucas: yes that is the only Debian list I am on. If I do a package for Ubuntu I will mail the debian-science list to tell them it is Ubuntu
<Tonio_> where is the logic there ?
<SEJeff> raphink, granted, they are all amazing developers... but 6 devs can do a lot if they are skilled
<LaserJock> but I will not package it for Debian
<Tonio_> lucas, just auto posting a RTP isn't a dream
<lucas> the kind of verification debian makes for their maintainers and their packages has currently nothing in common with what ubuntu does
<Tonio_> it is something that could be implemented on REVU
<Tonio_> once a package is uploaded by a motu, a RTP is sent automatically
<Tonio_> where is the dream there ?
<lucas> LaserJock: you could learn a lot by packaging for debian too
<LaserJock> lucas: sure but I don't have time for that
<Tonio_> the same that what we are asked to do, but automatically.....
<LaserJock> lucas: I am a chemist not a programmer or it guy
<lucas> ah ok I thought you were interested in learning stuff
<lucas> it is RFP
<LaserJock> lucas: I am but I only have time to devote to learning 1 distro
<LaserJock> lucas: and the distro I have chosen is Ubuntu not Debian
<lucas> and Debian probably doesn't want to get spammed by some RFPs about packages which aren't even lintian-clean
<Tonio_> lucas: RFP sorry
<LaserJock> lucas: I am not against Debian but I just can't be working on 2 different distros
<Tonio_> lucas: well, if every ubuntu contributor is posting a RFP, the rsult is exactly the same....
<Tonio_> if it is automatically done and ONLY when the package is approved, you will certainly have less RFPs sent...
<lucas> LaserJock: packaging for debian too will multiply the time you need by no more than 1.1
<lucas> you should at least discuss this on debian-science
<LaserJock> what if there was a debian ML that gets email from Ubuntu
<LaserJock> every time we add a new package
<Kyral> MOTUScience should interact with DebianScience
<LaserJock> Kyral: I agree
<Kyral> lucas: what is the channel? I'm gonna drop in
<LaserJock> Kyral: but to what extent?
<lucas> Kyral: I'm not sure if they have a channel
<lucas> they have a mailing list
<Kyral> hmm
<lucas> LaserJock: regarding syncs and merges, do you have a lot of merges in science packages ?
<lucas> or mostly syncs ?
<lucas> by working together with debian-science, you could help get more autosyncs
<lucas> and much less painfull merges
<LaserJock> lucas: hmm, hard to say. I am actually hoping to get a lot more -0ubuntu1 packages
<LaserJock> because Debian is just too slow
<lucas> that's so wrong
<LaserJock> For science the problem is that it is easier to package for Ubuntu than it is for Debian and scientists don't have a lot of time to become DDs
<lucas> you don't have to be a DD to get sponsored
<lucas> at least try to get sponsored
<lucas> and I can help you package for debian
<LaserJock> but it is easier to use REVU
<lucas> if you need it
<lucas> you can use REVU for reviews and then get sponsored
<lucas> this isn't incompatible
<LaserJock> lucas: the problem is not so much learning to package as learning the social structure, etc.
<lucas> you don't have to learn it
<lucas> you'll have to subscribe to debian-devel-announce, and that's all.
<raphink> thinking of it now
<Kyral> hmmm
<raphink> I think using REVU to get good quality packages and then getting them sponsored
<Tonio_> lucas, and another question
<Tonio_> what do you do with the rosetta kde patch ?
<Kyral> I supposed that I should just drop into #debian and ask
<lucas> please at least mail debian-science to ask if somebody want to sponsor you
<raphink> can get DDs to appreciate the work done in REVU with tim
<raphink> time
<raphink> and recognize that packages that come from REVU are good technically
<LaserJock> I feel like the best way to go is to package for Ubuntu and notify the debian-science ML.
<Tonio_> that means the package submitted to debian has to be different
<raphink> and trust then more and more
<raphink> them
<Tonio_> first patch deleted, all patched renumbered, changelog updated etc.....
<LaserJock> but I don't think reporting a ITP is something I should do
* lucas thinks of writing a spec about removal of universe packages which aren't in debian after some time if they have not reach a certain amount of users
<raphink> lucas: how do you measure the amount of users of a package?
<LaserJock> lucas: just because there aren't a lot of useres doesn't mean it's not important
<lucas> popcon.ubuntu.com
<lucas> LaserJock: if it's important, it'll be easy to find a sponsor in debian.
<LaserJock> lucas: that is scewed toward a certain population
<Tonio_> popularity doesn't mean quality......
<raphink> lucas: this is only for breezy, isn't it,
<raphink> ?
<Kyral> I'll email the Debian-Science list next week about EasyChem
<LaserJock> lucas: but I know that the Debian people are already having a problem with getting sponsors, I just don't think it's going to be terribly easy for me
<lucas> raphink: no I mean in the future
<LaserJock> but I will certainly try
<raphink> lucas: ok
* raphink was trying to find his packages on popcon
<raphink> :(
<lucas> raphink: find a sponsor, it's easier to find them in debian
<LaserJock> popcon only gives result for people who turn it on, which is not Joe User
<lucas> also, you get to appear in debian-weekly-news
<lucas> you'd be surprised to learn how many people worldwide read dwn
<Kyral> LaserJock: I'll email the Debian Science list soon
<raphink> lucas: i have a project on alioth, and at least two DDs in it, one of which was my first mentor. So I don't need to search long to find sponsors. I still think there's things to do to improve this matter of fact for all packagers of Ubuntu.
<LaserJock> Kyral: good, I need to tell them about MOTUScience although I think azeem has talked to them already
<raphink> lucas: i know that, already appeared in dwn ;)
<Kyral> LaserJock: well I am the Maintainer ;D
<marcin`> hi all
<raphink> lucas: and when I happened to appear in dwn, I was amazed at least by the number of languages in which it was translated, in such a short time.
<marcin`> sorry to interrupt - but I'm reading whis channel for few minutes...
<raphink> marcin`: yes,
<marcin`> and what are you guys talking about?
<LaserJock> but the problem with science packages is that it is easier for scientists to contribute to Ubuntu than to Debian I think
<marcin`> what is with 'sponsor' 'mentor' DD?
<Kyral> raphink: when I email how should I be?
<Kyral> like polite?
<raphink> marcin`: DD = Debian Developer
<raphink> Kyral: when you email who?
<Kyral> the Debian Science list
<lucas> ok, I'm going to bed now
<raphink> marcin`: a mentor is someone who teaches you how to package
<Kyral> oh, polite means like UBER polite
<lucas> Tonio_, raphink: what are you doing for a living ? student ?
<LaserJock> scientist are not as likely to become DDs but in Ubuntu you can just but something on REVU
<raphink> marcin`: and a sponsor is a DD who can get your package into Debian
<raphink> lucas: nope, chomeur pour l'instant
<Tonio_> lucas: I'm system administrator
<raphink> marcin`: does that help?
<marcin`> raphink: so I can think about sponsor only if I got new package that is not available in debian already?
<Tonio_> with a speciallity on ldap and MTAs
<raphink> marcin`: you want to sponsor a package when it's not in Debian yet
<raphink> yes
<marcin`> raphink: hmm yes...
<raphink> marcin`: if you have a new package that is not in Debian yet, it's a good idea to try to find a sponsor to get it in Debian
<marcin`> raphink: I just thought that 'sponsor' means something different...
<lucas> Tonio_: ok
<raphink> otherwise, sooner or later, your Ubuntu package will be dumped by the Debian version packaged in the meanwhile
<Tonio_> lucas: and ashamed to say that, "microsoft expert" ;)
<raphink> so it's better if you dump your own package with it's Debian equivalent
<raphink> so you keep being the only maintainer
<Tonio_> this is what my company writes on my cv, not what I pretend to be, of course :)
<raphink> lol
<Tonio_> expert means nothing
<lucas> heh
<lucas> ok, really off to bed now
<lucas> be back tomorrow
<raphink> ok
<Tonio_> good night
<raphink> good night
<raphink> I'll try to thikn of constructive stuff to get out of this talk
<raphink> ;)
<raphink> s/thikn/think/
<Kyral> raphink: you think I should hangout in #debian-mentors?
* ajmitch doesn't see much constructive that's not already being done at the moment
<raphink> Kyral: I haven't been there for a long tie
<raphink> time
<raphink> but you can go
<raphink> ajmitch: well it'll be constructive for my understanding of the whole thing I think
<Kyral> yah if my Ubuntu cloak doesn't scare people
<raphink> ajmitch: and maybe to write a few docs on the subject
<Tonio_> ajmitch: little question, cause I haven't seen your point of view on that point
<raphink> if thre is such a conversation coming back regularly
<raphink> then it means it's not documented enough
<raphink> imo
<Tonio_> ajmitch: except for very rare exceptions, when there is a divergence
<ajmitch> Tonio_: because I didn't want to get involved
<Kyral>  ./join #debian-mentors
<Tonio_> is REVU of any use according to you if packages have to be submitted to debian in the second place
<Kyral> oops
<raphink> lol
<ajmitch> yes
<Tonio_> okay
<LaserJock> Tonio_: what do you mean by "have to"?
<Tonio_> LaserJock: I mean, that if that's not done, they will be overwritten, giving waste job, when someone in debian will do is own package
<Tonio_> so logically, it "has to"....
<ajmitch> someone in debian is free to ignore your package anyway
<ajmitch> and do it from scratch
<LaserJock> that is assuming someone is going to package it in Debian
<Kyral> lol
<Kyral> Yah I mean I'd be lazy
<Kyral> lol we are invading lol
<raphink> haha
<seth_k|lappy> Kyral, md5deep done, so don't trouble yourself over it ( http://revu.tauware.de/details.py?upid=1378 )
<Tonio_> ajmitch: so the only way to be sure that the job isn't done twice and maybe lost one day is to do it for debian in the first place
<raphink> well notice siretart was already there Kyral
<Tonio_> and let ubuntu sync
<Kyral> seth_k|lappy: ahh
<Tonio_> that's the reason I start wondering about the purpose of REVU....
<raphink> Tonio_: no, not necessarily
<Tonio_> imagin you take time to package an app, patching etc.... get it approved on revu,
<raphink> as you package it for Ubuntu, you can file an ITP
<raphink> and once it's in Ubuntu try to get the package in Debian through a sponsor
<Tonio_> then posting an RFP in debian
<raphink> then once it's in Debian, sync the version you got in Debian in Ubuntu
<raphink> so you keep being the only maintainer
<Tonio_> to see that ignored and your package overwritten by another one....
<raphink> you get your package in Ubuntu fast
<raphink> you get it improved yet more in debian
<raphink> and it gets back into Ubuntu with your name in the end
<Tonio_> I would personnaly stop packaging for ubuntu directly in that case......
<raphink> ajmitch: is that right?
<Tonio_> well, listening to lucas, it is quicker getting the package in debian that in ubuntu so....
<Tonio_> and packages are better also....
* raphink finds it funny that there are twice as many people on #ubuntu-motu as on #debian-mentors ;)
<LaserJock> for me it is more like, package for Ubuntu and then let Debian know so that if somebody is interested then they can get it in Debian
<Kyral> Anyeone know how to reset the status bar in Irssi back to default?
<LaserJock> raphink: and a whole lot more talking
<raphink> Tonio_: while getting it into Debian, nothing prevents you from putting it on REVU at the same time
<Tonio_> raphink: waste of time.....
<Tonio_> because ubuntu syncs...
<raphink> LaserJock: typical Debian answer on #debian-mentors you got : read the doc
<raphink> ;)
<raphink> and don't ask questions ;)
<raphink> take your glasses, an aspirine and read
<raphink> no Tonio_
<raphink> your package gets improved in the process
<raphink> you get the initial version through REVu
<Tonio_> to me debian's community is the less friendly I've found on the net
<raphink> you get a good package in Ubuntu
<raphink> then you get it into Debian
<raphink> it gets improved
<raphink> then you merge it again in Ubuntu
<raphink> and it's improved again
<Tonio_> raphink: , or maybe ;
<raphink> you get very good packages this way
<raphink> and keep being the only maintainer
<Tonio_> you get it approved in ubuntu, at least one month
<Tonio_> then you submitted it the debian, but well, another one has been done, and your job is lost....
<raphink> Tonio_: find a sponsor _while_ it's still on REVU
<raphink> you package an app
<raphink> for both Ubuntu and Debian
<Tonio_> rap, in that case why not submitting it directly to debian ?
<raphink> when it's improved on REVU, you improve both
<LaserJock> Tonio_: honestly, I haven't seen Debian move fast enough for that to be much of a problem
<Tonio_> I don't understand the difference
<LaserJock> but then maybe it is just me
<raphink> Tonio_: because if you only submit it to Debian :
<raphink> 1) yo uwon't benefit from REVU
<raphink> 2) it'll end up in Ubuntu later
<raphink> ;)
<Tonio_> raphink: if DDs are that good
<Tonio_> a package submitted and approved for debian will be de facto good for revu
<raphink> Tonio_: they are mostly _numerous_
<Tonio_> another question
<raphink> Tonio_: MOTUs and mentors are humans, not machines
<Tonio_> you package an app
<Tonio_> with the patch for rosetta
<raphink> and a mistake that has not been seen by a DD can be seen by a MOTU
<Tonio_> then the package ets without it in debian
<Tonio_> ubuntu sync
<Tonio_> what happens to the pot file ?
<Tonio_> lost ?
<raphink> you keep it
<raphink> when merging
<raphink> imo
<Tonio_> you keep it or the actual version yes
<raphink> that's logical
<Tonio_> but for the next versions ?
<raphink> that's why I would submit to both Debian and Ubuntu at the same time
<Kyral> sithspit the Statusbar commands are confusing
<Tonio_> the patch won't go in debian right ?
<raphink> so when your package reaches Debian
<raphink> there is already a version with the pot patch in Ubuntu
<raphink> so it's kept when merging
<Tonio_> that's a kind of mess
<Tonio_> packaging for ubuntu, to get the pot file in it
<raphink> Tonio_: just have to find the better way for you to do
<Tonio_> then packaging for debian
<raphink> I think i'm finding mine
<Tonio_> package overwrittent
<Tonio_> no patch anymore
<Tonio_> but the pot is in rosetta
<raphink> no no
<Tonio_> and start again with the next version
<raphink> you make one package
<raphink> in the beginning
<raphink> you submit it without the pot file to Debian
<Tonio_> you have to maintain 2 packages
<raphink> and with the pot file to Ubuntu
<raphink> through REVU, the package gets into Ubuntu
<raphink> and through mentors into Debian
<raphink> when it raeches Debian, it's already in Ubuntu, very likely
<Tonio_> then ubuntu syncs
<raphink> so when it's merged afterwards
<ajmitch> hm
<raphink> the pot file is kept
<raphink> on top of the package improved through the Debian process
<ajmitch> this package is almost working..
<Tonio_> and the debian package overwrites the ubuntu one
<raphink> what do you think ajmitch ?
<Tonio_> raphink: yes, it is
<Tonio_> but with the next version, you have to do it
<ajmitch> I dunno
<Tonio_> again
* ajmitch hasn't been following
<raphink> ajmitch: ok ;)
* raphink begins to be a bit tired to follow, too
<LaserJock> Tonio_: you would have to merge it each time until Debian includes it
<raphink> ;)
<ajmitch> nearly all of my packages are maintained solely in debian & synced across
<Tonio_> LaserJock: no everytime
<raphink> brb
<Tonio_> because if someone make or updates the debian package before your one is advocated on revu
<Tonio_> the pot file will not be added to rosetta
<Tonio_> the ubuntu package doesn't have the priority
<Tonio_> that's an issue
<LaserJock> then we would just make and -ubuntu1 version
<LaserJock> s/and/an/
<Tonio_> LaserJock: and MOTUS will tell you "no, already in debian"
<Tonio_> like I've seen many times
<raphink> ubuntu patches are kept Tonio_
<raphink> if necessary
<LaserJock> why? If you are fixing bugs or really adding something I don't think it will be rejected by the MOTU
<Tonio_> raphink: not sure that can be applied to the rosetta patch
<raphink> pretty sure
<Tonio_> because the kde.mk on the building server is modified
<Tonio_> and might crash on debian servers
<raphink> the rosetta patch would never end up in Debian
<raphink> ;)
<LaserJock> heah, I just reading the debian-mentors FAQ and they suggest that if someone can't find a sponsor to user REVU and utnubnu
<LaserJock> s/user/use
<Kyral> lol
<LaserJock> so it seems to me that Debian knows what's going on
<raphink> interesting :)
<ajmitch> LaserJock: considering that womble has been in here a bit lately..
<ajmitch> womble == FAQ writer
<LaserJock> ajmitch: ah, good to know
<Kyral> So does that mean I'm already halfway there? lol
<LaserJock> so I mean it really just seems like packaging for Ubuntu and letting Debian know (either through debian-mentors or an area specifc ML) will probably be sufficent
* raphink is going to make a nice schema to explain his idea
* Tonio_ proute sur debian !!!!!
<raphink> lol
* ajmitch is probably one of the lucky few
<Tonio_> c juste pour les francophones, et j'assume :)
<LaserJock> If we feel bold enough to want to maintain the package in Debian also then we can do a itp and rfs
<Kyral> I don't mind maintaining EasyChem
<ajmitch> LaserJock: that's expected
<LaserJock> ajmitch: what is expected?
<ajmitch> that you file an ITP if you plan to maintain
<Kyral> Where is this form anyway?
<LaserJock> right
<Tonio_> ajmitch: where is it written on the packaging guides, on revu etc ???
<LaserJock> but we aren't expected to file an ITP are we?
<ajmitch> Tonio_: I'm talking about debian
<Tonio_> ajmitch: ho sorry....
<ajmitch> eg I have 2 ITPs open
<ajmitch> 1 of which has a package in Ubuntu
<ajmitch> the other one I'm working on at the moment
<LaserJock> I am willing to maintain for Ubuntu but I would have to think about maintaining for Debian as well
<LaserJock> but maybe I just need to go ahead and get further into Debian
<LaserJock> I just think that an Ubuntu contributor shouldn't have to neccessarily be an Debian contributor. It's nice but not neccessary.
<Kyral> ajmitch: how would I file an ITP?
<ajmitch> Kyral: by reading the instructions on the page
<Kyral> which page?
<ajmitch> the debian pages which give an intro to packaging & getting things in
<LaserJock> http://bugs.debian.org/wnpp
<thierry> Kyral : are you a MOTU?
<Kyral> no
<Kyral> just in Training
<thierry> k
<Kyral> but I have something in Universe
<thierry> k... I'm trying to get reviewed my package, could you help me anyway?
<Kyral> umm sure
<Kyral> brb though
<thierry> http://revu.tauware.de/details.py?upid=1371
<ajmitch> did you fix the shared lib issue?
<Burgundavia> Kyral, was I not harrasing you about galaxy-mage? ;)
<Kyral> ic
<Kyral> Burgundavia: Yah
<thierry> ajmitch : well by adding DEB_CONFIGURE_EXTRA_FLAGS := --enable-shared=yes (if that's enough)
<ajmitch> thierry: you have checked, right?
<Kyral> Burgundavia: I cannot package for a bit
<thierry> ajmitch : how can I check?
<Kyral> Its on my "To Package" Queue
<ajmitch> Kyral: why not?
<Burgundavia> Kyral, at this rate I never have to learn packaging. I can just harass others into doing it for me
<ajmitch> thierry: by checking what files are in the package
<Kyral> ajmitch: production box is internet disabled
<ajmitch> Kyral: so?
<Kyral> ajmitch: bah
<Kyral> I'm also working on my school's lab build
<ajmitch> thierry: looks like you still have to fix it
<thierry> ajmitch : yes, but wich more files should be there? its my first package :)
<ajmitch> thierry: the library package is useless as it stands, sorry.. it only has README & a changelog
<ajmitch> but --enable-shared=yes didn't get passed to configure
<Tonio_> good night all :)
<LaserJock> cya Tonio_ , thanks for the discussion
<seth_k|lappy> Would anyone care to look at md5deep ( http://revu.tauware.de/details.py?upid=1379 ) or polyester ( http://revu.tauware.de/details.py?upid=1375 [KDE, 1 advocate]  ) ?
<Tonio_> LaserJock: that's a pleasure :)
* Kyral makes a note to register on sponsors.debian.org
* ajmitch is registered on there too
<Kyral> and to file an RFS for EasyChem
<ajmitch> well, sponsors.debian.net
<ajmitch> for anyone who wants the real site :)
<Kyral> lol
<Kyral> yub yub ajmitch
<LaserJock> hmm, I will have to look into it as well
<LaserJock> but I think the main thing is I am going to email debian-science and work on the relationship between them and MOTUScience, that way all this discussion will really become irrelevent
<Kyral> yah
<Kyral> cc me on that
<LaserJock> I will probably cc ubuntu-science
<Kyral> I don't think I'm on that list...
<LaserJock> yes you are
<LaserJock> gimme a sec I will check
<raphink> Kyral, LaserJock : http://raphink.free.fr/debs/ubuntu_debian_packages.jpg
<raphink> what do you think?
<raphink> ajmitch:
<raphink> except the image quality is horrible ;)
<Kyral> lol
<raphink> this is what I get to
<Kyral> brb
<raphink> that allows being the maintainer of both
<raphink> while having the package in Ubuntu fast
<raphink> and not get someone duplicate the work
<LaserJock> Kyral: you aren't on the list :( Do you want me to add you?
<raphink> what do you think LaserJock ?
<LaserJock> raphink: just a minute, stupid dialup
<raphink> ok
<Kyral> LaserJock: yah
<Kyral> my @ubuntu
<raphink> http://raphink.free.fr/debs/ubuntu_debian_packages.png
<raphink> this is much nicer to look at ;)
<thierry> ajmitch : where could I get info of what is a shared librairy? maybe it could help me...
<Nirvana> would this be the right place to ask if a package is coming to Ubuntu?
<minghua> raphink: sorry, I think I joined in the middle, what idea is your diagram trying to say?
<Nirvana> well, I'll ask anyways, and come back in ten for the answer: when will aMSN and LimeWire (0.95 and 4.10.0 respectively) be ported to Ubuntu?
<raphink> minghua: trying to think of a way to contribute to Ubuntu without the contribution to be dumped by merge from Debian later on
<raphink> minghua: and get the best of it
<Kyral> Nirvana: check to see if its in Debian Sid
<Nirvana> link please
<raphink> packages.debian.org
<Kyral> what raphink said
<Nirvana> ahh, I usually check there too!
<raphink> Kyral: what do you think of my scheme?
<Kyral> raphink: you wrote it on a napkin?
<Kyral> ;P
<raphink> minghua: does that help you understand the scheme?
<raphink> Kyral: I'm not a graphic designer :p
<Kyral> raphink: neither am I
<raphink> and I used inkscape, even if that's painful to hear :p
<LaserJock> raphink: I think it looks reasonable
<minghua> raphink: yeah, I understand the idea, and your diagram says it well, but isn't that the way things are supposed to be? :-P
<raphink> minghua: it's surely the way it's supposed to be
<raphink> now i'm happy to know it
<raphink> it's not documented
<raphink> or official in any way it seems
<minghua> oh, I see
<raphink> so if it's the way it should be and the diagram says it well
<LaserJock> minghua: some people were suggesting that we should just try to get packages sponsored in Debian and not have REVU for new packages
<minghua> raphink: it would be nice in the documentation :-)
<raphink> then I'll try to document it
<raphink> minghua: some other people were also suggesting that it's fine to contribute through REVU and see your work demped by merges later on
<raphink> s/demped/dumped/
<raphink> which is hard to swallow
<minghua> LaserJock: I would not agree with that, my experience is that getting things sponsored is hard
<minghua> not that is necessarily a bad thing, but REVU has its place
<raphink> minghua: the idea in my scheme is that REVU is a great way to
<raphink> 1) get your package fast enough in ubuntu
<raphink> 2) get a good package so that Debian won't have much to say abou tit
<raphink> with time, DDs might be used to getting good packages from REVU
<raphink> and value it
<raphink> imo
<minghua> raphink: you probably want to emphasize the importance of filing bugs with (non-ubuntu-specific) patches to Debian BTS then, if you feel work getting dumped is a big concern
<raphink> in a way yes
<raphink> I also want to better understand the sentence you just wrote
<raphink> and no doc in ubuntu allows me to
<Nirvana> hey since you guys are MOTU (cool name btw 8-) ), would you mind pointing me into some documentation dealing with creating .deb packages? I've tried the official debian site once before, but it was unclear to me...
<raphink> only my short experience in the Debian world helps me with it
<raphink> the New Debian Maintainer's Guide is the reference Nirvana
<Kyral> Nirvana: the New Maintainers Guide is the best resouce
<raphink> https://wiki.ubuntu.com/PackagingTips
<raphink> here are the things to know
<raphink> added the NDMG to it today
<raphink> thought it could be useful somehow ;)
<Nirvana> I think that's what I read, maybe I'll re-read
<psusi> is anyoen around who can expedite my gpg key being authorized to upload to revu?
<raphink> minghua: i'd be happy to have a referent who knows Debian enough to help me with such a doc
<raphink> psusi: send a signed message to keyring@tauware.de
<Nirvana> yes, it was what I read, ah well though, maybe it'll be clearer the third time around (3rd times the charm :P)
<minghua> raphink: I would like to help, but I am not sure I know more than you
<raphink> https://wiki.ubuntu.com/REVU
<psusi> raphink, did that about an hour ago...
<raphink> also a page largely updated today psusi
<raphink> psusi: then wait
<raphink> it's night in Europe
<LaserJock> Nirvana: you might want to also look at the Ubuntu Packaging Guide at doc.ubuntu.com
<psusi> ok...
<raphink> it's 5AM
<raphink> and many MOTUs are in Europe
<raphink> reminds me I should get some sleep soon ;)
<minghua> raphink: and I don't quite understand which part of my last sentence you have difficulty to understand, maybe I can rephrase
<raphink> BTS
<raphink> I guess it's Bug Tracking System
<raphink> when you get in the Debian world
<raphink> you're surrounded with acronyms
<raphink> that everybody seems to know except you
<raphink> BTS, ITP, RFP, DD, etc.
<minghua> raphink: yes, sorry for using abbreviations you are not familiar
<raphink> that doesn't help understanding
<raphink> minghua: these acronyms, as the rest, should be documented in the ubuntu doc imo
<raphink> if we want ubuntu contributors to contribute to debian without too great an effort
<minghua> raphink: for acronyms, we have http://women.alioth.debian.org/dicts/
<raphink> this is not the ubuntu doc
<raphink> or is it reffered to in the ubuntu doc?
<LaserJock> I wish we could interact with Debian more without having to become DDs to do it
<minghua> raphink: I don't really know
<minghua> raphink: I'm all for better docs, I just don't have enough motivation to write them myself
* Burgundavia whips minghua 
<raphink> it's not easy I reckon minghua ;)
<nalioth> is there something special to do to export a gpg key for folks to grab to verify your packages?, or just export your key regular and change .asc to .gpg  ?
* raphink is heading to bed
<raphink> later
<seth_k|lappy> bye raphink|sleep
<raphink|sleep> seth_k|lappy: can you have a look at http://raphink.free.fr/debs/ubuntu_debian_packages.png and tell me what you think ?
<raphink|sleep> later on ;)
<seth_k|lappy> raphink|sleep, seems like the ideal method
<seth_k|lappy> raphink|sleep, the problem is that most ubuntu people won't want to have to file an ITP etc. Possibly REVU should be able to do that for you
<minghua> Burgundavia: that hurts....  altough I generally agree with you, more people should be writing docs
<minghua> seth_k|lappy: I don't think automatic ITP (intent to package) is a good idea, RFP (request to package), maybe
<minghua> seth_k|lappy: I don't think automatic ITP (intent to package) is a good idea, RFP (request to package), maybe
<seth_k|lappy> minghua, ah. I'm a bit shaky on the difference... ITP = you will maintain in Debian, RFP = you want somebody else to maintain?
<seth_k|lappy> do you actually have to have a package ready to file an RFP?
<LaserJock> ok, I better go too. I will try to email debian-science and try to look into Debian sponsorship
<minghua> seth_k|lappy: your understanding is correct, and you don't need a package ready for filing RFP
<seth_k|lappy> ok, thank you
<LaserJock> but you guys should really look at w.u.c/UbuntuPackagingGuide, I would really like feedback *hint*
<minghua> seth_k|lappy: but as long as such thing is filed automatically, I think RFP is more proper
<seth_k|lappy> yes, makes sense
<Kyral> hmm
<Kyral> is the planet.ubuntu.com login tied to LP and Wiki?
<seth_k|lappy> yes
<Kyral> okay
<seth_k|lappy> it appears to do nothing though
<Kyral> it should say that on the form lol
* Kyral falls down
* Kyral mehs
<Kyral> can't find the thingy to add my blog RSS feed to Planet
<lifeless> Kyral: email jdub
<Kyral> lifeless: mkay
<seth_k|lappy> erm
<seth_k|lappy> I don't suppose there is quality-of-content screening on what goes into planet
* seth_k|lappy doesn't want to see Planet have 600 blogs of Ubuntu members this time next year
<Burgundavia> seth_k|lappy, jdub approves it
<lifeless> seth_k|lappy: planet ubuntu <-> ubuntu members, makes sense to me
<Burgundavia> seth_k|lappy, it is self regulating and people can always be removed
<seth_k|lappy> that's true. I suppose I just fear 100 new articles a day coming out of the Planet RSS feed,  la planet gnome or something, and that it'll cause me to miss the important ones
<crimsun> you're free to cherry-pick the articles you read :)
<seth_k|lappy> this is true. crimsun, did you happen to figure out if you can log in with your old e-mail to REVU, so I can maybe get that second advocate for polyester?
<crimsun> seth_k|lappy: it's not my e-mail, it's something else, but I'll work on it. Thanks for poking me.
<seth_k|lappy> I appreciate it, crimsun.
<nalioth> another silly question. how do i get around this when i build packages? Depends: kdelibs4c2 (>=4:3.4.3-1) but 4:3.4.3-0ubuntu1 is to be installed
<seth_k|lappy> is your pbuilder up-to-date, nalioth ?
<nalioth> seth_k|lappy: there are no updates available for it
<nalioth> i dont understand your question
<nalioth> have i changed any configs and it is out of date that way, no.
<seth_k|lappy> sudo pbuilder update will run an apt-get update inside the pbuilder
<seth_k|lappy> if kdelibs4c2 is a new release or something
<seth_k|lappy> but it looks like a debian vs. ubuntu issue
<seth_k|lappy> is this something you're trying to install from a .deb?
<nalioth> no, this is the ksmoothdock i built with only one lintian squeak (that i have no clue how to fix)
<nalioth> i put it up on my repo and am looking at it in synaptic and it tells me that
<minghua> nalioth: what distribution is your pbuilder in?  dapper aparently renamed to kdelibs4c2a
<nalioth> breezy pbuilder
<minghua> breezy indeed only has 4:3.4.3-0ubuntu1, so probably what seth_k|lappy said, debian vs. ubuntu issue
<nalioth> how do i get the build depends to say *ubuntu1 ?
<seth_k|lappy> what does the line say right now?
<seth_k|lappy> kdelibs4-dev should be enough
<nalioth> ksmoothdock: Depends: kdelibs4c2 (>= 4:3.4.3-1) but 4:3.4.3-0ubuntu1 is to be installed.
<seth_k|lappy> you don't have like, a KDE 3.5 repo in your sources.list for pbuilder, do you?
<seth_k|lappy> if you didn't have the same one in your master sources.list, that might be it
<nalioth> i have only breezy repos in my pbuilder sources.list
<minghua> nalioth: how did you build your ksmoothdock?
<minghua> in breezy pbuilder?
<nalioth> minghua: yes. in a breezy pbuilder
<nalioth> there are no stable kde 3.5 repos for me (i'm on powerpc)
<minghua> nalioth: do a "sudo pbuilder login" then run "cat /etc/apt/sources.list" and "apt-cache policy kdelibs4-dev" in the chroot should give necessary information
<nalioth> minghua: this is my first day using pbuilder, and i have no idea what i'm looking at in the policy
<minghua> nalioth: what version did it say?
<minghua> nalioth: or you can always paste is somewhere and ask others to look
<nalioth> 4:3.5.0-0ubuntu0breezy1
<minghua> nalioth: yeah, that's the problem, the output should also say where the version is from
<nalioth> minghua: as said above, i'm a one day novice at all this
<nalioth> i guess i'm wanting to know what to put in the control file so that it looks for *ubuntu1  pkgs
<minghua> nalioth: my impression is you should just get rid of the non-breezy repository from your sources.list
<nalioth> minghua: thank you.
<minghua> nalioth: np, good luck with your package :-)
<nalioth> minghua: i'm just practicin' up atm
<nalioth> minghua: so far all the pkgs i would like to get into Ubuntu are already in REVU
<minghua> nalioth: I see, good luck with advocates then ;-)
<nalioth> minghua: but i'm sure i'll find something to adopt
<GregorR-L> When is the next freeze for Ubuntu?
<dholbach> hello everybody
<crimsun> re daniel :)
<dholbach> crimsun: i have a xubuntu test box right now - it works nicely :)
<crimsun> dholbach: cool!
<zakame> heya dholbach :)
<zakame> ooh xubuntu!
<ajmitch> hey dholbach
<dholbach> hey guys - you're already rocking Universe? :)
<ajmitch> nah
<ajmitch> hardly touched it
<zakame> haha
<zakame> lucas is, definitely :)
<ajmitch> oh?
<ajmitch> why is that?
<lucas> ?
<zakame> re the good list :)
<ajmitch> oh that
<lucas> well it's not about rocking universe, just giving a status of what is still to do
<ajmitch> like the merge page does
<lucas> (and what was done)
<zakame> still, nice overview to help rocking ;)
* ajmitch found a good way to get his script to update a merge list in about 5 seconds now :)
<ajmitch> since most of the time was spent calling dpkg
<zakame> w00t
<ajmitch> well, 15 seconds, sorry
<ajmitch> but that's not too bad compared to the 5 minutes it was
<lucas> does it include calling apt-get update to update the *Packages and *Sources files ? :-)
<zakame> hehe
<ajmitch> lucas: yes
<ajmitch> except it doesn't use apt-get
<lucas> ah
<zakame> aptitude?
<ajmitch> just fetches the sources, parses the sources
<zakame> er ECHAN
<ajmitch> no, just python
<lucas> I can do "mdt dist-apt-get dapper source plop"
<ajmitch> that's great
<lucas> if I want to run apt-get with a dapper sources.list
<lucas> I found that libapt is not that bad, and it's better to use it
<lucas> then reinvent the wheel
<GregorR-L> So, ajmitch ... mind uploading the newest rev of my pack?  PWEEEEEEEZE? *sad puppy dog face*
<pappan> Happy New Year to all !
<GregorR-L> A bit belated, but sure!
<pappan> yes but i was away and did not get much time
<pappan> dholbach: are you there
<dholbach> yeah
<GregorR-L> Hmm
<GregorR-L> Clearly he didn't need to talk to you too badly ;)
<GregorR-L> O_O
<lucas> hi raphink
<lucas> did the little discussion continue after I left ?
<lucas> I woke up at 8, was quite hard :-)
<raphink> I woke up 15 minutes ago
<raphink> lol
<raphink> quiet hard
<raphink> lucas: http://raphink.free.fr/debs/ubuntu_debian_packages.png
<raphink> this is my conclusion on it, the option I would choose
<raphink> and if this is the way to go, I'm going to document it in the wiki
<raphink> some said filing an RFP might be better
<lucas> I've started a wiki page about this
<raphink> I think I'll ask some DDs what they think of the matter ;)
<lucas> https://wiki.ubuntu.com/ContributingToDebian
<crimsun> lucas: were you able to generate a page that just has the necessary Ubuntu merges? (currently 154)
<raphink> lucas: we'll see that later I don't have much time now
<raphink> but this is really something I'd want to work on
<lucas> I'll detail the ITP/RFP debate
<lucas> crimsun: haven't worked on it yet
<raphink> lucas: you can use my scheme if you want
<lucas> raphink: we'll chat about this tonight if you prefer
<crimsun> I'll be offline (no MOTU work) today and tomorrow; driving to visit a friend who was recently diagnosed with lymphoma
* crimsun gets some rest, tata
<dholbach> crimsun: tell him our regards
<crimsun> thanks, daniel
<dholbach> the MOTU crew was thinking of him :-)
* dholbach hugs crimsun
<crimsun> :)
<lucas> is he an ubuntu user ? ;)
<raphink> lucas: there's some work to do on either merging or linking PackagingTips and UbuntuPackagingGuide
<lucas> that's a bit far from MOTU I think
<lucas> feel free to start to work on that, I won't :-)
<raphink> ok
<raphink> what is the UbuntuPackagingGuide actually?
<raphink> the page I mean
<raphink> is it just a spec ?
<lucas> I dunno
<raphink> or is it to be filled with data?
<raphink> lol
<raphink> ok we'll see abut that
<raphink> argh
<raphink> The authentication database is temporarily unavailable. Anonymous access only.
<raphink> :(
<Lathiat> whats that on?
<raphink> wiki.u.c
<zakame> gaah
<raphink> yeah
<zakame> that's why I sometimes keep cookies for that, I can still edit
<raphink> and i'm wanting to write doc
<raphink> :s
<raphink> I'll write in kate and paste later on
<raphink> lucas: tu peux jeter un coup d'oeil  a stp ? http://raphink.free.fr/debs/get_your_package_in_debian
<raphink> vu que le wiki est en panne ;)
<lucas> arg, j'ai commenc un truc trs proche
<raphink> ah
<raphink> fais voir
<raphink> on va merger ;)
<lucas> https://wiki.ubuntu.com/ContributingToDebian
<lucas> mais il manque un bout que je peux pas commiter
<lucas>  cause du probleme d'auth
<raphink> tu peux lire mon truc ?
<raphink> je pense que a peut complter ta page
<raphink> on peut mixer un peu des deux ;)
<zakame> lucas: w00t
<raphink> entre autre la partie Getting New Soft in Debian
* zakame wonders why -motu became -fr all of a sudden ;)
<raphink> zakame: wanna read them and give your opinion?
<lucas> raphink's fault ;)
<raphink> lucas: hehe, you began it last night ;)
<raphink> my turn
<raphink> that just proves open-source is still quite active in france ;)
<dholbach> lucas: cet page manque des informations sur utnubu :)
<raphink> de fait dholbach we need to add that too
<lucas> I know
<raphink> dholbach: can you have a look at http://raphink.free.fr/debs/get_your_package_in_debian ?
<lucas> buxy mentionned it too
<lucas> but I'm waiting for the wiki to come back
<raphink> dholbach: it's not on the wiki yet because the wiki auth system is broken now
<lucas> raphink: your page is very good, but maybe too detailed
<lucas> you'll see what I mean when I'll be able to commit ;)
<zakame> I really should learn fr :)
<raphink> lucas: our conversation yesterday was very detailed
<dholbach> raphink: we decided against ITPs
<raphink> on such a subject I'd rather give lots of infos
<dholbach> raphink: RFPs with a link to the package in the ubuntu archive should suffice
<raphink> dholbach: ok
<dholbach> raphink: most ubuntu guys don't run debian and you can't expect it
<raphink> of course dholbach
<dholbach> raphink: so it's better to have a debian maintainer who actually uses the package in a day-to-day basis
<raphink> then I'll document both ways
<dholbach> right
<raphink> the RFP way, which is easier
<dholbach> thanks
<raphink> and the ITP way, which is better
<raphink> no?
<dholbach> yeah and utnubu-discuss@ way :)
<lucas> my page proposes both, explain the pros and cons of each approach
<lucas> but I can't show you :)
<raphink> lucas: good :)
<raphink> hehe
<zakame> wow
<raphink> lucas: I'll wait till you can submit it
<raphink> and then i'll add my contribution
<lucas> ok
<zakame> ooh, so now I know why RFP, not just ITP
<raphink> ;)
<raphink> lucas: we need ITD (Intend To Doc)  bugs for the wiki ;)
<raphink> so we don't duplicate articles ;)
<zakame> how about existing RFPs which are not yet tagged already-in-ubuntu?
<dholbach> ouch :)
<raphink> lol
<raphink> zakame: you can tag RFPs as already-in-ubuntu?
<zakame> raphink: yes iirc, I read it at utnubu.alioth
<raphink> oh interesting :D
<raphink> that means we can file RFPs for our new packages
<buxy> rajasun: yes, that's the user of "usertags" in the Debian BTS
<raphink> and tag them as already-in-ubuntu as soon as they get in dapper
<buxy> it allows you to create such page :
<buxy> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=already-in-ubuntu;users=utnubu-discuss@lists.alioth.debian.org
<buxy> sorry rajasun, I meant raphink
<raphink> very interesting buxy :)
<raphink> that's something that really deserves to be documented
<buxy> this link is on http://utnubu.alioth.debian.org
<zakame> buxy: rocking
<raphink> :)
<Tonio_> hi all
<raphink> salut Tonio_
<Tonio_> lut
<zakame> heya Tonio_ :)
<Tonio_> yop zakame
<Tonio_> raphink: did last night debate starte again ?
<Tonio_> ;)
<Tonio_> s/starte/started
<raphink> Tonio_: lucas and I are working on documenting this
<raphink> although the wiki is down now
<Tonio_> and what is the recommended method at the end ?
<raphink> Tonio_: http://raphink.free.fr/debs/get_your_package_in_debian
<raphink> that's what I've written so far
<Tonio_> RFP, ITP or so ?
<raphink> and lucas wrote https://wiki.ubuntu.com/ContributingToDebian so far
<raphink> Tonio_: RFP
<raphink> although ITP is better
<raphink> so we'll document both and leave the choice to packagers
<raphink> Tonio_: buxy pointed out that RFPs can be labeled already-in-ubuntu
<raphink> so that you can file an RFP, get your package in Ubuntu and label the RFP this way
<raphink> so a Debian maintainer can pick up your Ubuntu package and maintain it
<raphink> Tonio_: we also discussed the fact that DDs think to be thinking about how to import Ubuntu packages and benefit from REVU aswell
<raphink> s/think/seem/
<Tonio_> to be honnest, if the final goal is to gethum
<ogra> err, thats what the utnubu team is for ...
<Tonio_> oups
<raphink> Tonio_: if there are efforts on both sides, it can be quite interesting
<Tonio_> hum
<raphink> Tonio_: this is the way I see it http://raphink.free.fr/debs/ubuntu_debian_packages.png
<Tonio_> the label "already in ubuntu" seems convenient
<ogra> just send them a mail to the list, they care for ITP or RFP
<raphink> ogra: yes, and we're trying to document the way to help it
<ogra> at least thats what we agreed on ages ago
<Tonio_> what I don't want is to have to disturb a DD al the day
<raphink> ogra: then we need to document it
<ogra> it will be totally obsolete once debian and utnubu join revu
<raphink> no one is going to guess a mail has to be sent to utnubu list if it's not said anywhere
<raphink> ogra: when will debian join REVU?
<ogra> nobody has to
<ogra> its up to you if you want to notify debian or not
<raphink> ogra: we don't have to, but if we don't, then our packages are dumped by debian ones after a short time and this is a waste of time and manpower
<Tonio_> ogra: that is my point of view... same plateform for both distribs....
<ogra> ask siretart, they are working on alioth/revu compatibility
<ogra> Tonio_, that cant work
<raphink> mhm
<Tonio_> ogra: for most packages it can
<Tonio_> I admit that there are differencies that can cause issues
<Tonio_> and make it impossible in some cases
<ogra> since all our stuff will be on launchpad eventually and thus it will all be bzr ... as long as debian doesnt switch to bzr, they are always apart
<zakame> ooh, debian + ubuntu + revu = w00t
<ogra> but you can build interaction layers
<buxy> ogra: "they are working" on alioth/revu compatibility ?
<buxy> you mean I proposed something but we didn't do anything yet ...
<ogra> on the mentioned interaction layer, yes
<ogra> siretart is working with you guys, isnt he ?
<ogra> (as time permits aside revu2 development)
<buxy> sirestart was very positive on this idea, but IIRC he didn't do anything yet or he did something without telling me about it ...
* tseng points at the planet debian flamewars of "use subversion or kindly die"
<ogra> nah, he's surely busy with revu2 stuff
<zakame> tseng: hehe
<raphink> ogra: or he's busy with his vacation ;)
<ogra> or this, yes :)
<raphink> I doubt he's snowboarding with is laptop
<Tonio_> anyway, that's very interesting and pleasure to ear :)
<Tonio_> it will clarify many questions...
<raphink> this is dangerous for both the laptop and himself
<ogra> Tonio_, its been discussed on the ML
<raphink> ogra: thre are many MLs
<raphink> and most users don't read them
<raphink> they read the wiki instead
<raphink> which is the main source for docs
<zakame> yeah I distinctly remember him saying `don't break tiber'
<Tonio_> exactly, hard to read all of them ;)
<ogra> if i dont say the name in #ubuntu-motu, guess which one i mean
<raphink> so we need to document this in the wiki
<ogra> :)
<raphink> ogra: ;)
<raphink> still
<buxy> ogra: I can't blame sirestart however, I didn't do anything more on my side neither ...
<raphink> ogra: as the manager of the MOTU team and employee (iirc) of canonical, it is only fair that you know the ML and read it
<raphink> but this is not everybody's case
<ogra> just write down that you have the option to notify utnubu-devel if you want to see your package in debian and that revu2/alioth integration is planned
<raphink> ogra: lucas and I are writing a doc on contributing to Debian when packaging for Ubuntu. This is gonna be written for sure
<raphink> now that we know about it ;)
<ogra> fine
<raphink> :)
<zakame> raphink: w00t
<ogra> i didnt attend the latest motu meeting, so it might have been considered differently ... but that was the consensus i know about ..
<raphink> mhm
<ogra> to not annoy debian with RFPs and ITPs
<raphink> huh?
<raphink> then I don't understand anymore
<Tonio_> LOL
<ogra> and since ubuntu package integration for universe is exactly what utnubu does, thats the right way
<raphink> ogra: so when we have a package uploaded from REVU
<raphink> we shall notify the utnubu team about it
<ogra> nope
<raphink> so THEY file the RFP with a already-in-ubuntu tag
<ogra> its not mandantory
<raphink> right?
<raphink> IF I want to do it, that's the way to go, right?
<ogra> we always said its optional if or if you dont want your package in debian
<ogra> so its up to you, but the right way is to notify utnubu
<ogra> they care for ITP and RFP stuff then
<raphink> ok thanks
<raphink> so IF I want my package in Debian
<raphink> I get it on REVU
<raphink> and once it's accepted I notify utnubu through the list
<ogra> yup
<raphink> correct?
<raphink> ok
<raphink> now I don't want to sound annoying or so
<raphink> but we've been told in the last hours
<ogra> by whom ?
<raphink> that it has been discussed lots of times and agreed
<Tonio_> lucas
<raphink> yet we got tons of different answers from different people
<Tonio_> Riddell, and a few more
<ogra> he wasnt even in motu when we discussed it last time
<Tonio_> nobody has the same vision
<raphink> lucas thinks it's better to get the package sponsored
<raphink> Riddell says it's better to file RFPs ourselves
<raphink> you think we shall not do anything
<raphink> it'd be a great thing if everybody could agreee ;)
<ogra> raphink, i can only tell what policys we decided upon in the meetings
<raphink> ok
<ogra> lucas wanst in motu back then
<raphink> is it in the MOTU Minutes?
<ogra> i dont know if or why Riddell handles it differently for KDE packages
<Riddell> I've had debian people moan that they've dupliated work beacuse they didn't know it was in ubuntu
<ogra> and i'm not even sure he was in the meetings back then
<tseng> Riddell: it couldnt be much easier to look
<ogra> Riddell, exactly, thats why we have utnubu
<tseng> you have to draw a line in the sand somewhere
<raphink> I think everybody would benefit from a standard way notifying ubtnubu each time
<Tonio_> Riddell: You've been pocken with one of my packages, I remember
<raphink> imo
<buxy> ogra: a meeting decision may be changed ...
<ogra> raphink, yes, it must be in the minutes sent to the mailing lists
<raphink> both Debian and Ubuntu would benefit from it
<ogra> buxy, thats what i said above
<Riddell> shrug, like I say I've had debian people complain and an RFP is their way of working with them
<tseng> utnubu makes reports of packages in ubuntu not in debian automatically iirc
<ogra> buxy, but we had reasons not to put more work on us back then ...
<Riddell> tseng: pocken?
<buxy> ogra: you can't defer completely on utnubu, you must incite Motu to upload via sponsor if possible, adn give utnubu as an alternative
<Riddell> s/tseng/tonio/
<ogra> buxy, why ?
<tseng> Riddell: if we rolled over to every DD that posted a shot at us on his blog we'd never do anything
<Tonio_> Riddell: emailed, a bit agressively ;)
<tseng> :/
<buxy> ogra: because that's the way to get your package integrated in Debian
<ogra> buxy, utnubu has announced itself as *the* path for packages going from ubuntu to debian
<buxy> look, utnubu integrated only 2 or 3 packages in Debian
<tseng> the mono team tends to get sponsors for packages
<ogra> buxy, we agreed on it
<ogra> why should we change it now ?
<buxy> ogra: right, utnubu can be the "central coordination stuff"
<buxy> but utnubu guys should only be sponsors for packages created by Ubuntu MOTU
<ogra> buxy, if a technical base for another solution (revu2) exists, thats fine, but for now its putting a lot of workj on our sholders
<buxy> and not "maintainers"
<ogra> why ?
<buxy> because you create the package, it's your job to keep it on shape
<ogra> i absolutely dont care whats written in the maintiner field in a ubuntu package ...
<Tonio_> are utnubu members DD ?
<ogra> since everybody can work on it here
<ogra> Tonio_, yes
<Tonio_> ogra: k
<buxy> ogra: but you should care for "new packages"
<ogra> buxy, the maintainer field is irrelevant in ubuntu
<ogra> buxy, but its important for debian
<buxy> otherwise you will never manager to integrate them in Debian, and you obviously want that for long term maintenance
<zakame> hm so how will that go?
<buxy> ogra: my position is that MOTUs and wannabe MOTU must be trained to do the best for Ubuntu and Debian cooperation
<buxy> after that, if they decide to ignore the recommendation, it's their choice, but the good behaviour should be documented anyway
<zakame> buxy: hm will this be credited for NM?
<raphink> buxy: totally agree
<raphink> buxy: we can't ask the MOTUs and MOTU wanabee to behave properly if they ignore the way to go
<raphink> zakame: haha I doubt so
<raphink> lol
<buxy> zakame: if a MOTU goes in NM later, he can certainly show the work he has done within Utnubu to progress quickly in the process
<Tonio_> will the package version freeze this month also concern universe and REVu ?
<raphink> zakame: although it would be only fair that just as being a DD is counted as experience and contribution for Ubuntu membership, being an Ubuntu member should be taken in consideration for NM
<raphink> logically
* lucas back, reading the log
<zakame> raphink, buxy : ooh
<raphink> zakame: aah
<raphink> lucas: wiki up again
<zakame> w00t
<raphink> lucas: i'll let you work on ContributingToDebian again before I work on it
<ogra> but you cant account that on maintainer fields in ubuntu
<raphink> so we don't mix our work like yesterday
<ogra> only on changes
<raphink> ogra: ubuntu packagers are not to be maintainers ?
<ogra> raphink, maintainer fields are totally irrelevant in ubuntu, as i said above
<buxy> ogra: a "new package" created for Ubuntu is done by someone who is proud to have created this package
<ogra> the only thing you can count are uploads and chack changes
<raphink> that means nobody minds whether I maintain my packages in ubuntu ?
<buxy> the person is certainly interested to have his package in Debian
<raphink> +1 buxy
<raphink> buxy: and to keep his name on his work, somehow
<ogra> buxy, i dont care who is in the maintainer field if i judge someones packaging skills, i chack the changes he made to packages regardless who is listed as maintainer
<buxy> and with the help of sponsors (coming from Utnubu or for somewhere else), this is possible
<raphink> buxy: and to be sure his work is not going to be dumped soon
<ogra> and if debian doesnt take that into account for judging NM but look at maintainer fields, they dont understand ubuntu maitenance
<buxy> ogra: I speak of "new packages", I don't care what updates you do to the Ubuntu package later on :)
<zakame> buxy: I'm certainly proud to have libmemcache go into Sid :)
<raphink> zakame: :D
<ogra> buxy, and i dont even care for new packages if i judge someone for motuness
<ogra> buxy, i'm intrested in packaging skills, not in cdbs or deb-make knowledge
<raphink> ogra: it doesn't help people volunteer for contribution if their name is removed from their work
<buxy> ogra: you diverge from the discussion then, you recruit MOTU how you want
<ogra> i.e. how does someone solve a ftbfs on amd64 in a transition is far more intresting than what did he uncomment in the deb-make template
<zakame> still, ogra has a point, packaging skills are indeed a plus
<buxy> we're speaking of how MOTU should treat new packages created for Ubuntu, nothing more
* jsgotangco observes
<lucas> raphink: commited, but I'll do some minor changes and let you know when it's free
<raphink> lucas: ok
<ogra> raphink, if its their work, thats true, but then we have a communication issue on debians side
<ogra> if a DD packaged it new and totally different, then this doesnt apply
<raphink> and issues are to be fixed imo, not hidden
<ogra> but not through burdening it on MOTU
<raphink> ogra: that's why bugs should be filed to Debian, so a DD doens't begin to duplicate the work
<ogra> nope
<ogra> a DD should also read our bugtracker as we have to do it with the debian bts if we want fixes
<raphink> does the Debian policy states so?
<zakame> RFP/ITPs with already-in-ubuntu
<ogra> if i care for a package, i check the different bts and places where i can fnd patches ...
<raphink> does Debian want a minimal diff with Ubuntu? or just Ubuntu with Debian?
<ogra> i expect the same from every DD
<zakame> perhaps something in the debian bts linking to LP...
<ogra> debian doesnt notify me about a new package, i have to find out myself about it ...
<ogra> redhat does tis neither
<zakame> ogra: true
<raphink> but Ubuntu policy is to keep close to Debian
<buxy> ogra: Debian developers have enough work to know everything inside Debian to not have time to look after Ubuntu side of things
<ogra> so why should i start notifying other distros about my stuff, if i have to look, they should look too
<raphink> this is not the case of debian policy
<ogra> thats a core part of being a maintainer
<tseng> ogra++
<buxy> ogra: that's why Utnubu is useful, but Utnubu can't solve it alone
<zakame> ogra: hm doesn't packages.qa.d.o allow subscriptions?
<ogra> <buxy> ogra: Debian developers have enough work to know everything inside Debian to not have time to look after Ubuntu side of things
<ogra> ??
<ogra> why doesnt this apply to ubuntu as well ?
<ogra> we have not even 10% of the manpower debian has
<ogra> for a bigger amount of packages ...
<jsgotangco> ubuntu is relatively small in the os space...
<jsgotangco> but its improving
<ogra> exactly
<buxy> ogra: and ?
<ogra> and its not the time to force policys like: if you have a new package do an itp and care for getting it sponsored
<raphink> jsgotangco: ubuntu is gaining lost of end users, but not lost of devs
<raphink> Debian has more than 10% devs in its community
<buxy> it's now that Ubuntu is still small that we must set the good precedent so that Ubuntu/Debian cooperates
<raphink> and Ubuntu will never have as many
<tseng> buxy: we do cooperate in many places
<jsgotangco> raphink, that's why main is only a small subset of what debian has to offer
<jsgotangco> universe is an entirely different ballgame
<ogra> buxy, and a connection pathg between revu2 and alioth is a fine start for that
<ogra> beyond the cooperation thats going on already
<buxy> ogra: it's not about "forcing", it's about telling " TRY to do this, this is the best thing, if you can't, then do at least that".
<ogra> but making up policys for such stuff that force you to ITP or RFP a package is wrong imho
<ogra> and you dotn gain much ...
<tseng> ogra: thats not true
<tseng> you gain someone not doing stupid stuff with your package in Debian
<tseng> it happened to me at least 3 times
<ogra> worst case you gain more headdaches because the DD caring for your packag disagrees in a way that incompatible in ubuntu
<lucas> I'm done with https://wiki.ubuntu.com/ContributingToDebian
<lucas> please read and comment here
<ogra> tseng, sure, but this knifa has two cutting edges ;)
<ogra> it can be fine it can be worse ...
<raphink> lucas: ok will do
<ogra> so the current way of notifying utnubu and letting them take over the package as a team is fine ... (or notifying the mono team in tsengs case)
<ogra> yo dont loose anything in ubuntu thriugh that ...
<tseng> we work on alioth svn for mono stuff
<tseng> but i certainly cant expect everyone to do that
<ogra> exactly ...
<ogra> and still your name isnt in the maintainer field :)
<tseng> people took all my packages
<ogra> even if the packages come from ubuntu only ...
<tseng> f-spot, tomboy, beagle..
<ogra> yup
<tseng> they all have maintainers
<tseng> (now)
<ogra> isnt it mono-team ?
<ogra> lie the gnome-team ...
<tseng> sortof
<tseng> mono-team has group and non-group packages
<tseng> in the same svn.. but non-group has one maintainer
<tseng> group = core and libraries
<buxy> ogra: if the creator of the package chooses not to join the Debian team, then that's fine, but Ubuntu should inform the creator of how he can reintegrate his work into Debian and explain advantages of that
<tseng> non-group = most apps
<buxy> in that sense, I hope you will promote the wiki page that lucas redacted
<ogra> buxy, again, why ?
<raphink> buxy: +1
<buxy> ogra: because you're creating a distribution that you want "rock solid" and "maintained in the long term"
<ogra> buxy, i dont see a reason to put work that should be done in debian on MOTUs sholders
<buxy> that's why you're based on Debian
<tseng> eh look at banshee and beagle
<buxy> and to make you work sustainable, in the long term, you want to avoid divergence between Debian and Ubuntu
<tseng> we had them in universe as YMMV for *months* before they went in debian
<tseng> for a reason
<tseng> i got burnt on beagle, someone else decided it was "ready" for debian
<ogra> buxy, but thats a DDs job ... not a MOTU job, we have enough in the pipe
<tseng> banshee we got in when it was ready
<buxy> ogra: it's not about FORCING to do the work, but about telling them "this is better, if you can please do it"
<ogra> buxy, i dont think its *better*
<raphink> buxy: +1
<buxy> ogra: DD and MOTU share the same goal of creating a high-quality distribution
<ogra> buxy, its an option you have
<ogra> yup
<raphink> I don't think we want to end up with merges between totally different -1 and -0ubuntu1
<raphink> that's wasting time and work
<ogra> raphink, you cant avoid it
<raphink> ogra: I don't know about "never | can't"
<buxy> ogra: the "wannabe MOTU" don't know about this option unless you tell them
<ogra> especially not if we all take oer the jobs of the DDs
<raphink> I know issues, I'm sure there are solutions
<tseng> raphink: when it happens I drop my package and do whatever i need to to the DD package
<tseng> raphink: and send him fixes
<tseng> its not that big a deal
<buxy> ogra: don't exagerate, we're speaking on "new pacakges", it's a minority right now
<buxy> and it's not necessarily MOTU's work... it's the work of the creator of the package
<buxy> whihc may be sponsored by a MOTU
<zakame> hm
<raphink> tseng: to me it is, in the sense that two people have been working on the same thing separately, to end up with only one product. One of them could have worked on something else instead. This is Microsoft way of working :p
<zakame> which right now we do REVU
<raphink> REVU sponsors for Ubuntu only
<zakame> yeah, that's what I mean
<ogra> raphink, yes, thats what its written for
<raphink> yes ogra
<ogra> as packages.ubuntu.com shows you ubuntu and not debian packages
<raphink> yes
<raphink> but when you make new packages for ubuntu, you check p.d.o and p.u.c
<ogra> so buxy's way of having the same tool for debian and interaction between the two is a gret effort :)
<raphink> and we expect DDs to do the same
<zakame> hm isn't that what lucas' list does now? :)
<raphink> couldn't there be an interface that would gather both p.d.o and p.u.c to check for the existence of packages in either?
<ogra> thats what utnubus tools do since ages
<raphink> so it could be used by both DDs and MOTUs
<ogra> raphink, write it if youre interested ;)
<buxy> raphink: that's the launchpad too
<zakame> yes
<raphink> then we need to document it
<ogra> yes, launchpad wil once offer such stuff
<raphink> let packagers know about it
<buxy> maybe I could add a link from the Package Tracking System to the Launchpad
<lucas> the problem here is that debian is the root of the tree, and ubuntu is a leaf
<raphink> both in Ubuntu and in Debian
<raphink> what's the use of a tool if people who need it don't know about it?
<zakame> buxy: that would be neat
<lucas> ubuntu is not the only debian derivative
<ogra> lucas, wrong view
<raphink> lucas: tell me what Linspire or Xandros bring to Debian ?
<lucas> you can't expect the root to look at all leafs.
<Tonio_> raphink: I don't agree, Linspire brings unstability and bad spirit
<raphink> <lucas> ubuntu is not the only debian derivative <--- ubuntu is the only debian derivative that aims to bringing back to Debian
<lucas> I dunno, because they are doing the idiot thing of not contributing much to debian
<ogra> lucas, and with smart in dapper+1 debian wont be the only root
<Tonio_> which is a great effort in a certain way ;)
<raphink> Tonio_: LOL
<lucas> ogra: s/wont/might not/
<lucas> smart is still vaporware
<dholbach> what exactly are you trying to discuss?
<ogra> we offer all our patches and changes public
<dholbach> lucas: smart works nicely
<ogra> its the DDs job to dig them
<Gloubiboulga> hi
<ogra> lucas, smart is in dapper
<lucas> dholbach: we are not really discussing, just trolling
<zakame> heya Gloubiboulga
<ogra> and will be the default in dapper+1
<buxy> ogra: what is smart ?
<ogra> lucas, not really
<dholbach> lucas: nice
<zakame> ogra: smart?
<dholbach> buxy: apt-cache show smartpm
<zakame> ah
<dholbach> ogra: we're "aiming for smart" for dapper+1 :)
<raphink> dholbach: this is an interesting question. I find it interesting that after hours discussing this subject we haven't reached the Godwin point yet.
<dholbach> raphink: you're a nazi? ;)
<raphink> dholbach: ;)
<ogra> dholbach, then gustavo would be payd for nothing
<raphink> nooo
<raphink> you ruined it all
<raphink> two days of constant discussions on here
<dholbach> raphink: i wanted to speed it up :)
<raphink> ;)
<ogra> raphink, useless discussion
<raphink> dholbach: :
<ogra> raphink, we had a dedcision about thet topic months ago
<lucas> well, please at least comment on https://wiki.ubuntu.com/ContributingToDebian
<raphink> ogra: many of us weren't there
<dholbach> let's all calm down and be focused on what's directly ahead of us :)
<ogra> raphink, feel free to bring it up on the next MOTU meeting then
<buxy> ogra: you're really not friendly to make things go forward
<raphink> and it seems the conclusoins of this talk wasn't documented enough
<raphink> since we had to talk about it again
<ogra> but dont discuss it just randomly in he channel
<buxy> "shut up, we decided it this way, come on later"
<raphink> ogra: we're not talking randomly
<raphink> ogra: at least lucas and I have been taking notes and trying to document the way it is
<raphink> so that's not talking randomly without a support
<ogra> buxy, i'm only careful and we already discussed this topic over several meetings
* buxy appreciates the work of raphink and lucas
<raphink> there's no need for official meetings to make things go forward
<ogra> raphink, but just making a desicion over the head of others isnt either
<raphink> otherwise it wouldn't go forward often ;)
<raphink> sure ogra
<raphink> we're just trying to
<raphink> 1) understand the way it is now
<buxy> ogra: when I read what you write, it looks like you'd be happy to go away with Debian and continue alone, ie you don't really care on what Ubuntu is based
<raphink> 2) understand the existing options today
<raphink> 3) document this all
<ogra> raphink, there are minutes of every MOTU meeting we ever had on the MLs
<ogra> buxy, thats not true
<raphink> ogra: I'm not paid to read the minutes when I search for an info, sorry
<raphink> and I don't expect new packagers to read the MOTU minutes when the want an info
<raphink> a great thing about Ubuntu is its doc
<raphink> and the Ubuntu community can be proud of it
<spacey_ki> ogra, ldm (dapper chroot) doesn't log in.
<spacey_ki> oh
<raphink> eventually, we might document Debian better than Debian itself
<spacey_ki> wrong channel
<raphink> ;)
<ogra> buxy, i just see that we have ~30 MOTUs and probably 20 wannabes that still have to care for ~100 packages before UVF and debian has about 1000 maintainers for a lesser amount and you guys want to put work into MOTU that doesnt belong here
<lucas> ogra: doing a little more work on our side now is a big win in the future
<lucas> we can't keep diverging
<raphink> ogra: we guys want to be sure we're not working on REVU stuff only to get to work on merging totally different versions of the package in a week
<lucas> there are 150 packages waiting manual action from MOTUs
<ogra> lucas, the workload is wrong weigthed
<lucas> and 900 with are different from the debian version
<buxy> ogra: you're too involved in the daily work, you need to see the whole picture
<jsgotangco> (there's only 1 guy doing syncs for starters)
<ogra> buxy, i see the picture of a DD who cares for lets say 5 packages in a whole
<ogra> buxy, and a isee 50 ppl caring for ~17000 packages
<lucas> jsgotangco: note that syncs are probably handled by a script ;)
<ogra> buxy, so where is my pic wrong ?
<lucas> ogra: we just can't care for 17000 packages
<lucas> that's why we must avoid divergence
<ogra> lucas, thats what MOTU does
<buxy> ogra: it's wrong, because you don't take care of 17000 packages, you mainly take care of what diverges
<buxy> and the more you diverge, the more you have work
<buxy> and thus you should aim at not diverging
<ogra> buxy, if a package ftbfs's MOTU has to care
<buxy> and thus you should aim to reintegrate your work into Debian
<zakame> re: merging, can I help my fellow MOTUs on their assigned merges (even is it is now so)
<zakame> ?
<ogra> no matter if its in the "selected set"
<lucas> zakame: what do you mean ?
<ogra> buxy, if fixing the ftbfs of an important library pulls a transition in, MOTU has to care too
<ogra> buxy, we have to care for 17000 packages, even if we ont touch them all
<buxy> ogra: yes but again, the FTFS can come from the divergence you create, or from a bug oif the Debian package, in both cases, working with Debian is avoiding unneeded work in the future
<dholbach> it'd be nice, if we had more interaction between ubuntu and debian, but we should aim to not let this eat up our time or distract our focus - those processes should be light-headed and we shouldn't have to 'rely' on the outcome of them
<ogra> dholbach+++
<dholbach> and i see the problem of merging, etc too
<buxy> dholbach: agreed, this is completely understandable
<lucas> ogra: necessary divergence != divergence caused by missing actions on the MOTU side
<ogra> i see the revu2 attempt of buxy and siretart as the right way
<zakame> lucas: still, syncs are checked I think
<zakame> lucas: elmo does the syncing, and he does check it ;)
<zakame> I did a sync request once for a pkg already synced, and he knows :)
<dholbach> i see one good solution: more teams who work/talk with their debian counterparts
<zakame> dholbach: indeed
<jsgotangco> resistance is futile!
<buxy> dholbach, ogra: you're paid by Canonical to keep universe in a good shape and organize the MOTU stuff ?
<ogra> buxy, nope
<zakame> I <3 Ubuntu and I <3 Debian, so I cry when they clash :P
<tseng> buxy: they are paid to do so much else that they barely have time for universe.
<ogra> buxy, canonical doesnt pay anybody for universe stuff
<dholbach> buxy: i mainly work on Desktop and community stuff
<jsgotangco> dholbach is our gnome crack master
<dholbach> buxy: but i do care about MOTU
<ogra> me as well
<zakame> dholbach: which reminds me, I should get in touch with pkg-java
<dholbach> i'd love to have more teams
<ogra> we were both MOTUs *before* we got hired
<dholbach> i think else we can't cope with the rising pile of bugs :)
<buxy> dholbach, ogra: OK, but please don't handle MOTU volunteers like you're handled by Canonical
<ogra> buxy, i handle MOTU voluteers as i always did, and i dont think i handle them wrong
<dholbach> buxy: i'm not quite sure, what you mean, but I treat them as Ubuntu-loving volunteers. is that ok? :-)
<buxy> I mean MOTU volunteers are like DD, they're working for the ubuntu and the free software, and telling them to cooperate with Debian will not reduce their capacity to do Ubuntu work
<raphink> on the contrary maybe buxy
<ogra> sure, i always tell wannabees that there is the opportunity to get your stuff into debian
<dholbach> buxy: i won't tell people what they have to do - but if we are to write down policies, i try to keep some different things in mind
<buxy> they make their own choice, but they need to be told the various possible choices, with the advantages and disadvantages of each side
<raphink> cooperate with Debian might be a way to better understand Ubuntu
<dholbach> buxy: i agree
<raphink> buxy: +1
<tseng> raphink: -1, thats tired
<raphink> tseng: ?
<ogra> buxy, sure but you wont see me telling anybody you *have to* or *you should* file an ITP
<tseng> its sort of like watching a DD blow up when you tell them they need to use a new RCS
<ogra> buxy, surely i'll tell wannabes of the advantages and disadvantages, but i still see it as a job of a DD to care for his package
* dholbach -> dogwalk + lunch
<buxy> ogra: you don't need to tell them directly, just point the them to the wiki page that lucas wrote
<buxy> it's there for that purpose
<hub> hi a;ll
<dholbach> we have to be careful with making things "requirements", but documentation is absolutely good to have
<buxy> ogra: we're speaking of new packages without DD ... :-))
<ogra> buxy, so for dapper+1 you guys will also document this for redhat and suse ?
<zakame> heya hub
<ogra> since we wont strictly be bound to debian anymore then ?
<jsgotangco> brb
<lucas> ogra: this won't happen.
<ogra> lucas, its planned
<lucas> it is not what smartpm is about
<Tonio_> buxy, couldn't that be considered like DD's job to come and look for packages that could be included into debian ?
<ogra> npe, but launchpad
<Tonio_> making a diff between the two package list and have a look
<lucas> ubuntu is far from having the workpower to maintain everything on their own
<lucas> if ubuntu does this, it will just become as crappy as Mandriva
<buxy> ogra: sorry I dodn't know enough about smartpm but I have seen similar projects in the past, and nothing ever come out of them, so wait & see is my opinion on this one
<ogra> lucas, exactly ... thats why we will be able to pull from different other roots in the future
<ogra> buxy, smartpm will only be the frontend ...
<lucas> Tonio_: you can't consider Debian and Ubuntu at the same level
<ogra> the tool is launchpad ...
<lucas> Tonio_: Ubuntu is not the only debian-based distribution
<Tonio_> lucas, I absolutly don't
<buxy> Tonio_: DD who are part of Utnubu made this choice, yes, but DD are volunteers and you can't force anything on DD :-)
<Tonio_> buxy: I don't about forcing
<ogra> buxy, as MOTU are voluneers ;)
<zakame> ogra: cool! :)
<Tonio_> but couldn't things be organised like this :
<Tonio_> debian -> ubuntu done by motus
<buxy> ogra: I know, there's nothing impossible between volunteers ... they can nevertheless cooperate
<ogra> buxy, sure
<Tonio_> ubuntu (REVU) -> debian done by volontary DDs
<buxy> but both sides must do some steps in each other's direction
<Tonio_> with the best level of automation tomake things quick and clean ?
<ogra> buxy, and i see it happen with yours and siretarts initiative
<ogra> but i also see that valuable worktime goes into pointless discussions since two days
<ogra> wile there are lots of packages that wont get upgraded in 3 yers after UVF
<buxy> Tonio_: that's already how things are, but the bordeline will never be so clean. Some MOTU are DD. Some MOTU are Debian maintainers (without being official DD).
<buxy> And we're trying to document/formalize the various cases that can exist at the borderline
<ogra> with the cost of packages being left behind ...
<ogra> thats a task for a motu meeting where everybody is notified before and can tell his opinion
<buxy> ogra: on my side, the time spent here is time that I should have spent working for money, so it's a money-loss for me ... (I'm my own boss in my own company)
<ogra> its not a thing that should just be done in the channel at a random time
<zakame> so when is the motu-meeting? :)
<ogra> buxy, thats your decision :)
<buxy> ogra: volunteers discuss thing when they want, you're free to not join the discussion
<ogra> buxy, yes, but we once haldled it less unfair
<ogra> there are many people not been around the last two days, they might have an opinion to tell thats why we have meetings
<buxy> sure, but the meeting can also acknowledge work done by interested parties
<ogra> after its done ?
<buxy> yes
<buxy> that's how free software works
<ogra> thats not how we worked the last 18 months, but feel free to change it
<buxy> people do things, other people tell this is great, go look at it, things become eventually official at the end
<buxy> seomtime things are done and lost, because it wasn't terribly good, that's the life
<ogra> i.e. we made decisions as a whole and talked about stuff  instead of providing undiuscussed finished work
<ogra> it worked quite well the last releases ...
* raphink thinks about the cathedral and the bazaar
<buxy> ogra: for developing Ubuntu it's great to organize the work of paid guys
<ogra> buxy, dont mix up this stuff please
<buxy> ogra: no attack in my sentence
<ogra> my work for canonical has nothing to do with my MOTU work
<ogra> and i didnt change my attitude to MOTU since i was hired ...
<zakame> well regular meetings should really work, since it brings everyone up-to-date and threshes out the bits, just like this one ;)
<buxy> ogra: anyway, meeting are good, but they are not a reason to close discussion between meetings
<ogra> buxy, thats not what i said
<ogra> but just doing stuff in a team without notifying the others that might want to contribute to this discussion isnt really team friendly
<raphink> hmm
<ogra> at least if its stuff that applies for everyone in the team
<raphink> we're talking, trying to understand some things, document stuff, etc.
<raphink> we're not taking any decision so far
<raphink> the result of this talk is documentation
<raphink> that might, if well done, be the base of meetings later on
<raphink> if required
<buxy> ogra: no need to have a meeting, to decide to create some new content in the wiki :-)
<ogra> yes, but putting on a meetin before this would be nice to make others know that you will do it ... if someone disagrees, he has at least the opportunity to do so
<raphink> hmm ogra
<raphink> should be a meeting be held when we want to document a difficult point?
<raphink> just to write a wiki page on a sensible point?
<ogra> for a point that applies to everyone, that would be nice ...
<raphink> ok
<buxy> ogra: the meeting would have brought nothing, as the discussion would have taken much longer than the meeting itself
<raphink> yes
<raphink> this discussion has been going on for about 15 hours now
<raphink> and hasn't really been telling the same things oever and over, but adding to it
<raphink> this is a vast subject
<ogra> if you write some docs like PbuilderHowto thats something different, but something that might become our policy later is different
<zakame> WHOA
<ogra> buxy, you can dicuss later on ... its just that the meeting brings it to the attention of everyone
<raphink> it'll be easier to be discussed in a meeting if there's already a wiki page summing up the issue and the existing options
<buxy> ogra: check https://wiki.ubuntu.com/ContributingToDebian
<buxy> this is "information", it's not "policy"
<zakame> raphink: well, like a spec ;)
<raphink> zakame: kinda maybe
<buxy> however making that page known & accepted in the Ubuntu community benefits both Debian and Ubuntu
<ogra> buxy, but it applies to everybody "tell newbies there is this opportunity" and might become policy later
<Kyral> Morning MOTU
<raphink> if it is found out that this opportunity benefits to everybody, then it's good that it becomes policy later
<raphink> hi Kyral
<raphink> ogra: but the current goal is not to make it policy at all
<raphink> just to list the options for newbies to be informed
<zakame> heya Kyral
<Gloubiboulga> someone has some time to review this: http://revu.tauware.de/details.py?upid=1362 ?
<Gloubiboulga> Riddell has advocated it :) (thanks Riddell)
<ajmitch> hm, plenty of hot air in here today
<ogra_ibook> nahh
<ogra_ibook> just valuable discussion
<raphink> hehe
<ajmitch> I'm sure..
<ogra_ibook> but we should have a motu-meeting soon i guess :)
<raphink> ajmitch, ogra_ibook https://wiki.ubuntu.com/ContributingToDebian
<ajmitch> yes I saw it
<ajmitch> you've given that url at least 3 times :)
<raphink> hehe
<raphink> not me, lucas did I think ;)
<zakame> heya ajmitch :)
<ajmitch> hi zakame
<ajmitch> raphink: it has some good points
<raphink> haha
<ajmitch> that's funny?
<ajmitch> hm
<raphink> yes, the way you said it ;)
<raphink> `it has some good point' implies you have to search for them among the other stuff ;)
<raphink> to me
<ajmitch> there are some things there that are wrong
<raphink> ajmitch: i'd be happy that you tell us which ones :)
<ajmitch> "Contributing your work to Debian is just what you should do ethically speaking. If you don't understand that, you probably shouldn't be developing Free Software."
<ajmitch> ie, contribute to debian or you're just a loser..
<zakame> ooh my pbuilder updating is almost complete, on dialup :)
<lucas> I'll make it softer
<ajmitch> the tone of that sentence is aggravating to put it mildly
<ajmitch> assuming that a debian maintainer will adopt whatever you put up as an RFP
<raphink> ajmitch: yes agreed on this part
<zakame> gaah
<ogra_ibook> lucas, why not having a meeting and work out the fine tuning there ...
<ajmitch> and it really really is a good idea to be running debian to file bugs on it
<raphink> ajmitch: yes, with a chroot for ex
* ajmitch should hopefully get a new laptop in the next day or two
<zakame> ajmitch: indeed
<lucas> ajmitch: buxy read it and didn't objected to that
<ajmitch> I think I'll have a proper debian install on there
<ajmitch> lucas: that's wonderful, but I'm objecting to it now :)
<ajmitch> then again it is 6AM here
<raphink> lucas: maybe we can add a link to the chroot WikiPage to install a sid chroot and report bugs from within
<lucas> ajmitch: buxy has been part of Debian QA for years. I'd say that if he doesn't mind, it's ok, don't you think ?
<lucas> raphink: what's the exact name of the page ?
<lucas> [17:59:48]  <ajmitch> assuming that a debian maintainer will adopt whatever you put up as an RFP <= fixed
<zakame> ajmitch: w00t!
<raphink> lucas: DebootstrapChroot
<ajmitch> zakame: ?
<buxy> ajmitch: I'm running Ubuntu on my laptop, but I still do Debian work in a chroot :)
<ajmitch> lucas: sure, feel free to ignore anything I say
<zakame> ajmitch: re: new laptop
<ajmitch> buxy: that's how I've been working lately too
<buxy> lucas: I would rewrite the sentence to me more clear anyway, the idea is "forward bugs that also apply" to Debian.
<lucas> ajmitch: aren't we allowed to sometimes disagree ?
<ajmitch> lucas: oh we do
<buxy> Forwarding bugs that "might apply" should be done with care.
* ajmitch freely disagrees with ogra on some things, for example :)
<ogra_ibook> :)
<ogra_ibook> the bugs part should take malone into account, its not mentianed at all and will (for most it already does) obsolete most of the steps you describe there
<ogra_ibook> *mentioned
<ogra_ibook> i.e. bugs should always be reported to malone and get an upstream link to debian bts
<ajmitch> I'm not sure if malone will file bugs in debian's BTS or not
<ajmitch> It may do, one day
<ogra_ibook> it will
<lucas> Some things to keep in mind:
<lucas>  * Forwarding bugs that ''might apply'' to Debian should be done with care. If you haven't checked throughtly that Debian was affected, don't file the bug or mention it in the bug report. The Debian maintainer will probably be very angry if you report a bug impossible to reproduce on Debian ! If unsure, ask a Debian user to try to reproduce it, or set up a Debian chroot on your computer (see DebootstrapChroot).
<lucas> ajmitch: you prefer it this way ?
<ogra_ibook> i think the mail interface already does since ubz
<buxy> lucas: it's better
<ajmitch> lucas: probably not a good idea to write about the maintainer being very angry though :)
<lucas> ok, i'll drop that
<ajmitch> it's just that there are often bugs that appear to be in one package that end up being the fault of another
<lucas> Some things to keep in mind:
<lucas>  * Always mention that you are running Ubuntu, not Debian.
<lucas>  * Forwarding bugs that ''might apply'' to Debian should be done with care. If you haven't checked throughtly that Debian was affected, don't file the bug or mention it in the bug report. If unsure, ask a Debian user to try to reproduce it, or set up a Debian chroot on your computer (see DebootstrapChroot).
<ajmitch> throughtly->thoroughly
<ajmitch> looks better though
<lucas> so you see, I'm not always ignoring what you says :-)
<ogra_ibook> "Debian has a lot of users who will be interested in your package. Your package will get good press (Debian Weekly News for example), and also good bug reports, because the Debian user community is very well educated."
<ogra_ibook> hmm, ubuntu users are not well educated ??
<ajmitch> heh
<ajmitch> no, we're all slack-jawed yokels round these parts
<ogra_ibook> damn, we do a distro from idiots for idiots ...
<zakame> gahh
<lucas> ogra: would you describe the ubuntu user community as "very well educated" ?
<hub> ogra_ibook: that is dcc
* hub apologize for the bad joke
<ogra_ibook> lucas, parts of it, yes, as i would do it for *parts* of the debian community
<ogra_ibook> hub, haha
<zakame> heh we service our users better :P
<buxy> lucas: s/,because .*/ from the big Debian user community/
<lucas> ok
<lucas> for example, I think that the percentage of users able to understand "s/,because .*/ from the big Debian user community/" is much higher in debian than in ubuntu ;)
<buxy> :)
<ogra_ibook> and that is a inidicator for a good bug report ?
* ogra_ibook shakes his head
<lucas> you first complain was about "very well educated"
<ogra_ibook> good boog reports because debian users are better educated ...
<buxy> lucas: ogra meant that knowing regexp doesn't help writing good bug reports :)
<ogra_ibook> thats why i should push my package to debian ?
<lucas> </troll>
<lucas> I fixed it as buxy suggested
<buxy> ogra_ibook: would you please calm down ? you're constantly trying to increase the flame level in the discussion
<ogra_ibook> between the lines i read: why do you package for ubuntu at all ? if its ethically incorrect not to push it up all the time, you get better bugreports in debian because ubuntu users are dumb ...
<ogra_ibook> i dont
<lucas> I do think it is 'ethically incorrect not to push it up'
<buxy> ogra_ibook: that's why you review is important, now the text is better suited to be read & understood by both parties
<ogra_ibook> but this whole page is pretty unpolite worded please look it over
<lucas> but I might be a bit pedantic about ethics ;)
<buxy> ogra_ibook: you're exagerating, what else do you see ?
<lucas> ogra: sorry to be being such a good english writer as you are
<lucas> please enlight me
<ajmitch> ogra_ibook: why else do you think I've made some suggestions? :)
<ogra_ibook> ajmitch, i'm trying too
<lucas> s/sorry to be being/sorry to not being/
<ajmitch> I know
<ogra_ibook> just try to formulate it that i dont feel i'm an evil guy if i dont push my stuff back to debian
<ajmitch> but you are evil! you're using an ibook! :)
<ogra_ibook> ... or that i feel i'm a dumb user if i use ubuntu instead of debian...
<lucas> please try to suggest changes then
<lucas> I'm open to suggestions :-)
<zakame> lol
<ogra_ibook> lucas, i dont want to rewrite it
<lucas> then what do you want ,
<lucas> ?
<ogra_ibook> i wouldnt have started this page at all without a broader discussion first ...
<ogra_ibook> either in a meeting or through the ML ...
<lucas> without support, the discussion would have turned out as a flamewar
<ajmitch> why do you assume we'd have to resort to flames?
<lucas> because that's what has been going on today here ? ;)
<zakame> there's no need for fire
<ajmitch> you think this was flames? :)
<ogra_ibook> i didnt see any flame here, sorry
<lucas> from the beginning to "Forwarding bug reports", do you still see something impolite/untrue/unsuited/etc ?
<raphink> lucas: I have not really seen a flamewar here today... an animated discussion for sure... but no flameware
<raphink> war
<lucas> I reread carefully and didn't find anything to change
<zakame> nothing here, move along, just agitated discussion, nothing fancy ;)
<ogra_ibook> the "how to do it part looks ok"
<ogra_ibook> i'd put REVU to the top though
<lucas> <ogra_ibook> i'd put REVU to the top though <= I'm not sure I understand what you mean
<lucas> I added to the part of the developers reference documenting bug severities
<ogra_ibook> grmbl
<lucas> [18:30:06]  <lucas> <ogra_ibook> i'd put REVU to the top though <= I'm not sure I understand what you mean
<ogra_ibook> "After reading this page, you might think that REVU is useless, and should not be used." thats a very negative introduction for the paragraph
<ogra_ibook> i'd put the whole paragraph to the top and rather point out that revu is a nice thing without negative sentences :)
<ogra_ibook> top == top of the section
<ogra_ibook> as a motu i have used revu a lot, why should i think its bad after reading this page, i know its good ...
<ogra_ibook> probably just leave it out completely
<raphink> this page is not for MOTUs who know REVU well already
<ogra_ibook> err, for whom is it ?
<raphink> rather for new packagers who might not see the use of REVU really after seeing that it's good to contribute to Debian directly
<lucas> well, the page might lead some people to thinking "what's the point in packaging with ubuntu in mind then ? I could just package for debian using debian-mentors"
<ogra_ibook> new packagers are busy with learning packging, this giving back part should come if you know about it
<ogra_ibook> s/it/packaging/
<jeld> hello all
<ogra_ibook> lucas, yes, it looks a bit like an advertisement for debian-mentors
<ajmitch> buxy: what cooperation has siretart discussed with you about revu?
<ogra_ibook> ajmitch, its on the ML ...
<zakame> true
<ajmitch> ogra_ibook: yes, but which list?
<ajmitch> motu? mentors? utnubu? :)
<ogra_ibook> ajmitch, a project that interconnects alioth with revu2
<ogra_ibook> ajmitch, motu ...
<ogra_ibook> and utnubu
<ajmitch> alioth itself?
<ogra_ibook> nah, not the whole of alioth indeed
<ogra_ibook> :)
<jeld> I was browsing the UniverseCandidates list and found that crafty is on the list. I have created the packages for crafty and books and uploaded to my site. What next?
<ajmitch> see wiki.ubuntu.com/REVU to submit it for review
<lfittl> jeld: upload them to REVU (http://wiki.ubuntu.com/REVU) ;)
<segfault> should i use dchroot or pbuilder?
<zakame> segfault: for?
<segfault> build packages in a separated environment
<ogra_ibook> for building use pbuilder
<ogra_ibook> for testing use dchroot if you dont want to run dapper on your main system
<dholbach> can somebody give me the link for the announce of the revu mails?
<zakame> for both use pbuilder in a dchroot
<ogra_ibook> zakame, why ?
<ogra_ibook> i mean, why should i run pbuilder in a chroot ...
<segfault> i'm using dapper atm.
<segfault> should i build the package for breezy or dapper?
<ajmitch> dholbach: http://lists.ubuntu.com/archives/ubuntu-motu/2005-December/000057.html
<ogra_ibook> so if you dont care to clutter your system with libs you only need for testing the package, you can test it directly
<ogra_ibook> for dapper
<ogra_ibook> unless you aim to go for the backports team
<dholbach> ajmitch: merci beaucoup
<zakame> ogra_ibook: in my case, its convenient, since the inside pbuilder can use the dchroot's cache, as I want to save bandwidth, on dialup ;)
<ajmitch> de rien
<segfault> but every time i build a package with pbuilder, it'll uncompress the tarball, make it... its kinda slow to do this every time
<ogra_ibook> zakame, ah, you didnt talk about caching :)
<ajmitch> zakame: apt-proxy, or using the aptcache that pbuilder has
<ogra_ibook> segfault, you can use a chroot for building, but its more work to keep it clean
<ogra_ibook> segfault, i prefer the patient any lazy way ...
<ogra_ibook> but its up to you
<segfault> hehe, ok
<zakame> ajmitch: aptcache
<segfault> if i make a new package, which is lsted in UniverseCandidates, it'll go for breezy or dapper?
<ajmitch> dapper
<ajmitch> dapper is in development, so it's the only one that gets new packages
<segfault> after dapper release, it'll recieve only updates on those packages?
<ajmitch> only really critical updates
<ogra_ibook> s7updates/fixes/
<ogra_ibook> ;)
<ajmitch> I meant that :)
<segfault> hum, ok, thanks
<dholbach> Could everybody who'd like to be a MOTU soon, play a question-and-answer game with me in a query please?
<ajmitch> dholbach: do I count?
<dholbach> sure
<zakame> dholbach: _o/
<dholbach> that's all? just ajmitch and zakame?
<ajmitch> and we're already MOTUs
<ajmitch> sigh
<ajmitch> does that mean we're not eligible for the prizes?
<dholbach> you definitely are
<segfault> i can
<ajmitch> ok
<zakame> hehe
<ogra_ibook> prizes ????
<ogra_ibook> what can one win ?
<segfault> a hug.
<zakame> w00t
<jamessan> dholbach's gonna fly out here and give me a hug if I win? cool!
<ajmitch> a round of drinks?
<dholbach> jamessan: where do I have to land to hug you?
<jamessan> Boston
<ogra_ibook> jamessan, nope, you have to come to the next conference to pick it up :)
<jamessan> aww
<dholbach> jamessan: you fancy to answer some questions too? :)
<jamessan> sure, although I don't plan on doing the MOTU thing anytime soon.
<zakame> W00T! pbuilder create done, in 2 1/2 hours :P
<ajmitch> ouch
<segfault> do you guys use cdbs?
<zakame> indeed, and 'tis 2 in the morning here :P
<zakame> segfault: I'm giving it a try tomorrow :)
<ajmitch> segfault: I do
* dholbach hugs zakame and ajmitch - thanks a lot to the both of you.
* ajmitch hugs dholbach 
<segfault> lintian doesn'tt like me.
<segfault> whiprush: roundcube: unknown-section universe/web
<segfault>  W: roundcube: unknown-section universe/web
<segfault> why there is no section universe/web?
<ajmitch> drop the universe part
<segfault> hum, ok
<zakame> np :)
* zakame hugs dholbach 
<dholbach> ajmitch, zakame: you rock - thanks!
<dholbach> anybody else?
<dholbach> anybody wants to review http://wiki.ubuntu.com/MOTUReportDraft - it's just a quick sketch yet
<ajmitch> heh
<segfault> usin cdbs, how do i put (the cdbs way) the package files under debian/package/?
<ajmitch> man dh_install
<ajmitch> you need to have packagename.install files
<segfault> k
<Q-FUNK> hi
<dholbach> please add some more stuff to the MOTUReportDraft - all the new people in here :)
<Q-FUNK> could someone sync rus-ispell from debian/unstable please?
<ogra_ibook> did you testbuild it on ubuntu ?
<Q-FUNK> it should build just fine.
<ogra_ibook> it should or it does ?
<Q-FUNK> I don't hav eenough hard-disk space for a dapper chroot.
<Q-FUNK> but basically, the diff on the old ubuntu version was strictly about going ahead with packaging an newer version that what debian had.
<segfault> hehe, i guess i'll show up in the next MOTUReport
<lucas> is UVF still Jan 14th ?
<Q-FUNK> since then, I have taken over rus-ispell maintenance, packaged a newer upstream release and cleaned up the packaging. there should not be any reason to diff anything for dapper, at this point.
<dholbach> ogra_ibook, Q-FUNK: shouldn't it be autosynced?
<Q-FUNK> dholbach: my understanding is that if ubuntu had any own diff, then it needs to be manually synced?
<ogra_ibook> might be, i would have asked for a sync if it would have been tested...
<ogra_ibook> Q-FUNK, if a package has a -XubuntuX in the version it needs manual syncing, else it goes through the autosync
<zakame> er I though Jan 19
<ogra_ibook> yup
<ogra_ibook> jan 19 afaik
<zakame> *thought
<ogra_ibook> should be on the release schadule in the wiki
<Q-FUNK> ogra_ibook: indeed so, which is why I'm here today asking for someone to do that manual sync.
<ogra_ibook> ah
<ogra_ibook> Q-FUNK, then it will be on the manual syncs list anyway
<lucas> going back home
<lucas> 8pm
<Q-FUNK> ogragiven how we're less than 2 weeks away from the freeze, I would rather know ASAP if there's still any delta, so that i can perhaps do something about it.
<lucas> what a day
<jpatrick> hey \sh
<ajmitch> hey \sh
<ogra_ibook> Q-FUNK, thats a question of manpower
<segfault> woohoo, my first package is done.
<\sh> moins
<ogra_ibook> hey \sh
<\sh> moins ogra
<zakame> hi \sh :)
<Q-FUNK> dholbach: that reminds me, pitti suggested I should talke to you about preapring a language pack for Estonian for Dapper.
<Amaranth> segfault: awesome, what package?
<dholbach> Q-FUNK: to me? i wonder why :)
<segfault> roundcube
<segfault> webmail from roundcube.net
<ogra_ibook> dholbach, oh, you do langpacks now ?
<dholbach> ogra_ibook: i surely don't
<Amaranth> segfault: never heard of it ;)
<ogra_ibook> *g*
<Q-FUNK> hm
<\sh> dholbach: fixing istanbul....sorry for the *censored* eye sight of me
<dholbach> \sh: don't worry
<ajmitch> \sh: there are others if you want them ;)
<Amaranth> So when a MOTU makes a new package just for Ubuntu, does something poke Debian and let them know?
<segfault> amaranth: it's new, ajax-powered. it's kinda cool
<Q-FUNK> dholbach: I'm probably mixing issues then.  I remember him telling me to talk to you about something related to one of my packages, though.
<Amaranth> Or should hte packager do that?
<ogra_ibook> Amaranth, the packager
<Amaranth> file a ITP bug?
<ogra_ibook> Amaranth, revu2 might change that
<ogra_ibook> Amaranth, nope, an RFP
<segfault> there's some problem with php5-imap
<dholbach> Q-FUNK: If you remember, I'm happy to help out, where I can. language-packs is unfortunately not my area of expertise.
<zakame> gn8 all
<\sh> Amaranth: make it a rfp...you don't want to be responsible for the package your lifetime :)
<Amaranth> heh
<ogra_ibook> Amaranth, unless you want to take it over in debian
<Amaranth> segfault: ok, do what they said
<ogra_ibook> dholbach, might be pitti thought your expertise lies in estonian if you read HP in four langs ;)
<segfault> how do you guys take care of upstream packages?
<dholbach> ogra_ibook: estonian is not on my list of languages to learn yet. :)
<Amaranth> HP?
<segfault> subscribe to their -announce list when there's one?
<dholbach> segfault: what do you mean?
<dholbach> segfault: gnome has RSS feeds - sourceforge.net has too
<Amaranth> segfault: You mean tell the developers of the software you're packaging that there is a package in Ubuntu?
<dholbach> segfault: but else: announce mailing lists - irc channels of upstream developers, ...
<segfault> i mean, you take care of tons of packages, there's no way you can check their sites, one by one
<ogra_ibook> Amaranth, yes, he reads hewlett packards business reports in four languages for fun :)
<segfault> RSS is nice, though
<Amaranth> oh
<dholbach> Amaranth: I don't. Don't listen to ogra.
<Amaranth> isn't that what debian.watch is for?
<ogra_ibook> *giggle*
* dholbach confiscates ogra_ibook's crack pipe for today.
<segfault> well, dunno, heh.
<\sh> ajmitch: well..I leave it up to you now with the merges...right now I'm somehow not in the mood of doing hardcore merging stuff..i'm learning more python and be prepared for python .net
<ogra_ibook> dholbach, meeeeeh meeeeeh
<ogra_ibook> dholbach, give it back, i need to stay up until 2am for the meeting
<Amaranth> \sh: IronPython?
<\sh> Amaranth: yepp
<dholbach> Amaranth: Harry Potter :)
<Amaranth> heh, those books are awesome
<Amaranth> each one is longer than the last
<\sh> I wonder when HP is fighting for this abbreviation in front of a court against J.K. Rowling
<Amaranth> and is meant for an older audience
<\sh> Amaranth: no...harry potter is growing up...so the audience as well
<Amaranth> yeah, that's what i mean
<dholbach> \sh: I still refuse to grow up.
<Amaranth> i'm only a couple of years off his age, so i've been following along ;)
<ajmitch> \sh: python .net?
<\sh> dholbach: you shouldn't have smoke in your early years ,)
<ajmitch> \sh: like ironpython?
<Amaranth> most recent book sucked though
<\sh> ajmitch: yep
* ajmitch sees you already answered that
<ajmitch> are you packaging ironpython?
<dholbach> Amaranth: the 6th sucked?
<\sh> ajmitch: no :)
<Amaranth> Python.NET was some weird bridge, wasn't it?
<ajmitch> \sh: good, because I've started doing so ;)
<Amaranth> dholbach: Yeah.
<\sh> Amaranth: the last one was the best...you can see now snapes real personality..he is a spy..*oops*
<dholbach> \sh: a spy... leaves it all open ;)
<Amaranth> hey, while we're giving away details...dumbledore dies
<Amaranth> which sucks
<ajmitch> shhh
<Amaranth> i think the 6th book was just setup so she can do more than 7 books
<ajmitch> probably
<dholbach> Amaranth: i thought it made the whole books an epos instead of a kids' boarding school book. :)
<dholbach> Amaranth: You're harsh with her. :)
<\sh> dholbach: well...the logic behind dumbledores death is obvious...because think about the first part what dumbledore said, when harry defeated squirrel
<Amaranth> yeah, but if he doesn't go back to school in book 7 she can drag it on longer ;)
<\sh> Amaranth: the 7th is the last..harry will die
<dholbach> Amaranth: and we'll get an 8th book and a 9th.
* dholbach beams.
<Amaranth> \sh:quirrel
<\sh> Amaranth: right....squirrel was the web application ,
<\sh> ;)
<Amaranth> heh
<Amaranth> that was book 1, no?
<\sh> Amaranth: yepp philosophers stone
<Amaranth> sorcerer's stone ;)
<jpatrick> whatever
<Amaranth> anyway, there is no way she was planning the whole thing from book 1 on
<\sh> Amaranth: the original is philosophers stone, right? let me check the title of the first video ,)
<Amaranth> if anything from book 1 suddenly seems like foreshadowing it's because she did it on accident or warped the story around it
<Amaranth> \sh: not in the US
<\sh> Amaranth: well...yes..the US .. every time a bit extra ,)
<\sh> Amaranth: but it's surprising to read the translations of the name "Lord Voldemort" ,)
<Amaranth> ?
<segfault> package-contains-upstream-install-documentation
<segfault> is this warning too bad?
<\sh> Amaranth: Harry Potter and the Philosophers Stone (2001) [ENG] 
<tseng> if you get a warning, its probably something wrong
<Amaranth> you don't need the upstream install documentation, you're installing it
<tseng> it doesnt break anything, but its not less wrong
<Amaranth> the INSTALL file
<Amaranth> \sh: that's when the movie came out?
<\sh> Amaranth: yepp
<segfault> so i must do a post-install script to auto configure it
<raphink> hi slomo
<slomo> hi raphink :)
<raphink> how are you slomo?
<slomo> hm, tired and busy now ;) i'm currently learning maths
<raphink> hehe ok
* raphink is happy to have stopped his studied
<raphink> studies
* lucas is happy to still be studying
<jpatrick> i'm still at friggin' school
* raphink is afraid to have a hard time finding a job though
<lucas> raphink: where in france are you ?
<raphink> lucas: Poitiers
<raphink> currently
<lucas> ok
<raphink> but there's nohting keeping me there if I need to move
<lucas> what are you qualifications ?
<raphink> http://raphink.multiply.com/profile/resume/resume.pdf
<raphink> this was a year ago
<raphink> since then I have studied pedagogy and how to create a company for 4 months
<raphink> and gained experience in linux stuff, too ;)
<raphink> lucas: I don't have my engineer diploma since I stopped my school in the middle of the second year
<raphink> lucas: j'ai un parcours zarbi, hein? ;)
<lucas> effectivement :)
<raphink> what do you think I could do with that?
<raphink> lately i'm thinking of trying to work as a Linux technologies teacher
<raphink> teaching people in companies how to use Linux
<raphink> since more and more companies use it
<lucas> that's a good idea
<raphink> and working on a new way to teach computer science, using my knowledge in pedagogy
<raphink> ty lucas
<raphink> unfortunately, ideas don't pay ;)
<tseng> raphink: when you figure it out let me know
<segfault> why lintian complains about changelog-file-not-compressed when dh_compress says it'll only compress files bigger than 4K? The upstream changelog has 2.2K. Lintian is on drugs.
<raphink> as long as it's only an idea, it doesn't help me to eat ;)
<tseng> atm i seem to need a unix guy to push a power button on a linux box
<raphink> tseng: when I figure out what?
<tseng> raphink: cluing in people to linux
<raphink> tseng: you mean about a course to teach linux ?
<tseng> eh
<raphink> ;)
<raphink> tseng: I have my ideas on this ;)
<raphink> began to work on the hard drive and filesystem so far
<raphink> maybe I should begin with simpler stuff
<segfault> hehe
<raphink> but I found this part interesting
<raphink> tseng: the pedagogy i'm learning is quite innovative, and based on cognitive psychology
<raphink> tseng: and my point is that most computer science courses fail because computer science it taught without ever removing the perception from learners
<tseng> what perception
<raphink> you learn to use a computer facing a computer and you don't try to check that you know how do it when the comp is off
<tseng> and yes i dropped out of computer science after a few weeks
<tseng> what do i win
<raphink> tseng: PM this is offtopic
<tseng> hah
<Amaranth> This channel has no topic to get off of. :)
<jpatrick> Amaranth: haha
<raphink> hehe
<raphink> indeed
<lucas> who can create accounts on a *.tauware.de box ?
<jpatrick> siretart I think...
<chninkel> hi
<Kyral> hmm
* Kyral feels paranoid
<psusi> is siretart around?  I sent in my email last night with my new gpg key to get upload access to revu... not heard back yet
<Kyral> Guy with a Gentoo Dev cloak just walked into #ubuntu
<ogra> psusi, i think he's on holiday
* psusi hopes gentoo makes their cloaks out of fancloth
<psusi> ogra: ahh... can anyone else hook up the key?
<ogra> i dont think so
<psusi> darn
<jpatrick> Kyral: I can't see him/her
<ogra> probably sistpoty
<Kyral> jpatrick: its spb-
<Kyral> or something like that
<ogra> Kyral, whats wrong with gentoo devs ?
<Kyral> ogra: nothing
<Kyral> just...unusual
<ogra> we steam a lot of their patches ;)
<ogra> *steal
<tseng> their mono maintainer is my main man
<Kyral> and I tend to pick up on things that don't fit in with what I'm used to
* Kyral shrugs
<jpatrick> Kyral: negative, can't find him :/
<ogra> so they might steam some community feeling in #ubuntu in turn ;)
<tseng> and yea i happily steal patches from him
<ogra> *steal
<ogra> grmbl
<tseng> (and share back)
<Kyral> spb-
<psusi> gentoo does come up with a lot of nifty stuff
<Kyral> yah
<psusi> I just don't like waiting 3 days for things to compile ;)
<Kyral> Ain't Portage all in Python?
<tseng> Kyral: yes.
<ogra> mostly to hackish to be used in public :)
* Kyral wistles
<ogra> but often great with a little tweakage :)
<Kyral> jpatrick: he just quit out
<tseng> well
<tseng> ebuilds are pseudo-bash
<chninkel> could someone help me with bug https://launchpad.net/distros/ubuntu/+source/mysql-query-browser/+bug/6390 ?
<Ubugtu> Malone bug 6390: "query-browser (Ubuntu) - mysql-query-browser: merge new debian version" Fix req. for: mysql-query-browser (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: PendingUpload http://launchpad.net/bugs/6390
<jpatrick> Kyral: oh damn I was looking at #ubuntu-devel
<Kyral> hehe
<chninkel> the mysql-query-browser binary crashes on ubuntu but works perfectly on debian sid
<lucas> ok, let's work on some merges before UVF.
<seth_k|lappy> Any motu that likes KDE that would like to review polyester? http://revu.tauware.de/details.py?upid=1375 [New, 1 advocate] 
<raphink> I would if I could seth_k|lappy ;)
<seth_k|lappy> you and me both, raphink :P
<seth_k|lappy> you reviewed it last night, but it's advocates I need
<raphink> hehe :)
<raphink> yes I know
<seth_k|lappy> Let me know when you apply for MOTU, because I'll probably apply the same meeting. I know Riddell said he wanted both of us working on KDE goodies
<raphink> seth_k|lappy: I'll apply for membership first ;)
<seth_k|lappy> ohh, you're not a member yet?
<raphink> step by step ;)
<seth_k|lappy> I've got that one out of the way, at least
<raphink> nope
<raphink> i'm applying for the second time next tuesday
<raphink> last time they said my contribution was nice but not long enough
<raphink> and asked me to come back in 4 weeks
<raphink> so I will ;)
<seth_k|lappy> yep :)
<raphink> will you wait for me ?
<raphink> ;)
<raphink> I'll need to work on merges and bugs anyway
<raphink> the work I do is not enough to apply for MOTU imo
<seth_k|lappy> I don't plan to apply in the near near future, so probably :P
<seth_k|lappy> I need to do more work as well.
<seth_k|lappy> but my list of packages in Ubuntu is steadily growing :) I'm maintaining 3 (soon 4) and have quite a few uploads
<segfault> do i need to change anything to get postinst exec'ed after install a package?
<raphink> segfault: no
<raphink> apart from programming postinst properly
<segfault> k
<segfault> i've just uploaded roundcube. can anyone please review it when it appears?
<raphink> segfault: url?
<raphink> please
<segfault> looks like it take some minutes to show up
<raphink> yes segfault
<raphink> up to 10 minutes sometimes
<lfittl> raphink: the cron script should run every 5 minutes as far as I know
<segfault> raphink: http://revu.tauware.de/details.py?upid=1383
<segfault> woo!
<raphink> lfittl: ah ok
<raphink> Internal Server Error
<raphink> cool
<raphink> i love that
<segfault> heh
<raphink> I'll look at it soon
<segfault> thanks
<minghua> good afternoon
<raphink> hi minghua
<lfittl> segfault: you did a native upload, rename the upstream tar.gz to roundcube_0.1.orig.tar.gz and create the sourcepackage again
<raphink> segfault: you miss the orig.tar.gz file
<raphink> segfault: rebuild your package with the -sa option
<segfault> oops
<raphink> debuild -S -sa
<raphink> or dpkg-buildpackage -rfakeroot -S -sa
<raphink> and upload it again
<segfault>  dpkg-buildpackage -S -sa -rfakeroot
<segfault> i did this
<raphink> you missed the -sa surely
<raphink> cause you miss the orig.tar.gz
#ubuntu-motu 2006-01-10
<raphink> do it again
<raphink> and give me the new url when it's done
<lfittl> raphink: he did a native upload, that also happens if you don't have a orig.tar.gz
<raphink> (check it's created the orig.tar.gz before uploading again)
<raphink> hmmm
<lfittl> segfault: make sure there is a file named roundcue_0.1.orig.tar.gz
<raphink> what do you mean by native upload lfittl ?
<raphink> :s
<raphink> oki
<segfault> roundcube_webmail_0.1-20051021.tar.gz
<lfittl> raphink: upload without using an upstream source ;)
<raphink> segfault: you should either rename the original tar.gz to orig.tar.gz
<segfault> that was the name of the upstrem package
<segfault> heh
<raphink> segfault: rename it
<raphink> lfittl: ok :)
<raphink> segfault: mv it to roundcube_webmail_0.1.orig.tar.gz
<segfault> k
<lfittl> segfault: name of the upstream package is not important, important is the name and version of your sourcepackage
<raphink> actually
<raphink> is the version really 0.1 ?
<lfittl> raphink: his sourcepackage name is roundcube without webmail ;)
<raphink> isn't it 0.1-20051021 ?
<raphink> yes
<segfault> is it wrong? should i include the date?
<raphink> why not keep webmail in the sourcepackage name segfault ,
<raphink> segfault: depends if the date is part of the version number
<segfault> too big? the project name itself is just roundcube
<raphink> segfault: if the date is used as a sub-version of 0.1 then yes
<raphink> segfault: roundcube-webmail would be fine for a name, too
<segfault> ok, i'll change it
<lfittl> upstream released other 0.1 versions, make sure to change the version number to 0.1-20051021
<raphink> lfittl: that's what i'd think too
<raphink> :)
<segfault> roundcube-webmail_0.1-20051021
<raphink> yes
<lfittl> :)
<raphink> so the upstream tarball will be renamed to (or linked from) roundcube-webmail_0.1-20051021.orig.tar.gz
<segfault> iirc, i didn't use it too because of dh_make complained about it
<raphink> then you change your debian/control aswell ;)
<segfault> but its ok now
<raphink> and the source package dir name
<raphink> and you run dpkg-buildpackage again ;)
<raphink> segfault: dh_make might complain about things and still be wrong ;)
<raphink> dh_make is helpful but we still package manually
<raphink> :)
<raphink> for good reasons
<segfault> i see
<raphink> wb Kyral
<Kyral> ty
<segfault> the directory must have package-version, while orig.tar.gz uses package_version
<segfault> why?
<raphink> that's policy ;)
<segfault> right
<segfault> http://revu.tauware.de/details.py?upid=1385
<raphink> lets see
<segfault> i haven't made a nice postinst script, i'm still fighting with debconf.
<segfault> most of its parts i got from phpldapadmin's source
<raphink> E: roundcube-webmail source: declares-possibly-conflicting-debhelper-compat-versions 4 4
<lfittl> segfault: You could change the apache in "Depends: apache | httpd" to apache2, since that is our default webserver now ;)
<raphink> remove the debhelper compat declaration from debian/rules
<raphink> and use only debian/compat and debian/control for it
<segfault> ok
<raphink> distribution is dapper, not unstable
<lfittl> maybe changing the debhelper compat level to 5 would be good
<raphink> yes, too
<segfault> ok, changed
<segfault> uploading again..
<lfittl> :)
<segfault> how do i remove with dcut? i pressed ctrl+c.
<raphink> segfault: no
<segfault> heh
<raphink> I'm still commenting
<raphink> its not done yet
<segfault> raphink: ah, right, sorry
<minghua> segfault: the reason orig.tar.gz must be named package_version is that there can be character "-" in the package name, such as your case
<minghua> segfault: the directory name is based on the debian/changelog, so it knows exactly which part is package name, which part is version number
<minghua> as for why such inconsistency exists, I don't really know :-(
<segfault> humm, thanks for the explanation
<raphink> is this your first package segfault ?
<raphink> if so, you didn't choose the easiest one to begin with ;)
<raphink> segfault: give me a good reason why your package would modify the apache config
<raphink> wb seth_k|lappy
<raphink> segfault: first comments sent ;)
<lfittl> segfault: building the package in my pbuilder fails
<lfittl> cp: cannot create regular file `debian/roundcube/usr/share/doc/roundcube/INSTALL.roundcube': No such file or directory
<raphink> I'll test the build once the first comments are taken in consideration :)
<lfittl> good idea :)
<lfittl> although this should be a missing mkdir, and easy to fix
<raphink> and I'd first like to know if postinstall and prerm are necessary
<raphink> and why they'd modify apache.conf
<segfault> i'll read now, wait
<segfault> well, it was in case the user is using apache-1.3
<segfault> in case of apache2, it uses "apache.conf", which stays in /etc/roundcube
<segfault> and creates a link inside /etc/apache2/conf.d
<lfittl> then drop the apache-1.3 part
<segfault> but since it now depends only on apache2, i'll remove the httpd entries
<segfault> in the postrm
<segfault> err, postinst.
<raphink> what's the use of the postrm and postinst otherwise?
<raphink> I see it activates some modules
<raphink> but these modules are already activated by the postinst of the libapach2-mod-* packages
<raphink> corresponding
<raphink> so you don't need to do that
<raphink> I don't see a reason why your package should touch apache.conf at all so far
<segfault> well, i got it from phpldapadmin
<segfault> all it does is append conf.d as a modular directory if it doesn't exist in the conf file
<segfault> in the case of apache2, it does exist by default, so its not necessary to create it
<segfault> i'll change it
<segfault> for some reason, debconf questions are not showing up after install
<raphink> segfault: i'd like it if you could keep only what's necessary, or even remove the postinst and prerm
<raphink> segfault: how about when you run dpkg-reconfigure ?
<raphink> talking about debconf
<raphink> according to policy
<raphink> debconf questions should be ask in config, not in postints
<raphink> postinst should ask no question
<raphink> only apply the actions required by choices made in config with debconf
<sistpoty> hi folks
<segfault> i'll clean it up now, removing the apache1 stuff
<raphink> hi sistpoty :)
<raphink> ok
<raphink> how are you sistpoty ?
<sistpoty> raphink: I'm fine, thx... how are you?
<raphink> I'm fine too :)
<raphink> sistpoty: trying to think of a job to do ;)
<raphink> and bugging everybody about it ;)
<sistpoty> hehe
<raphink> lol
<lfittl> hi sistpoty, could you archive 1 package, and delete another one on revu?
<raphink> just so you're prepared ;)
<sistpoty> hi lfittl
<sistpoty> lfittl: sure, which ones?
<raphink> lfittl: which ones?
<raphink> ;)
<sistpoty> :)
<lfittl> sistpoty: delete http://revu.tauware.de/details.py?upid=1384, because we decided to change source package name 5min ago
<lfittl> and archive http://revu.tauware.de/details.py?upid=1148 as its uploaded ;)
<raphink> :)
<raphink> http://revu.tauware.de/details.py?upid=1384, archived :)
<lfittl> right, as a reviewer you could archive too :)
<raphink> yep
<raphink> but I can't delete
<lfittl> yep i know that only admins are allowed to do this
<sistpoty> raphink: lol, I guess I unarchived it again
<raphink> haha
<seth_k|lappy> raphink, you can archive? oh you're in trouble now, I"ll be giving you things to archive all day :P
<sistpoty> no, old problem... there were more then one uploads
<raphink> playing ping pong with packages sistpoty ?
<raphink> seth_k|lappy: I can archive packages on REVU
<raphink> I doubt there's packages to archive everyday ;)
<seth_k|lappy> sistpoty, want to review a KDE style for me (already has one advocate and 2 positive reviews) http://revu.tauware.de/details.py?upid=1375
<sistpoty> seth_k|lappy: ok... will take a look
<seth_k|lappy> thanks sistpoty :)
<raphink> seth_k|lappy: funnily enough, we're both halfway to MOTU
<raphink> seth_k|lappy: you've got the membership part, i've got the reviewer one
<raphink> seth_k|lappy: we could merge ;)
<raphink> lol
<seth_k|lappy> raphink, http://revu.tauware.de/details.py?upid=1257 http://revu.tauware.de/details.py?upid=1365 http://revu.tauware.de/details.py?upid=1230
<raphink> j/k
<seth_k|lappy> archive those :P
<raphink> k
<seth_k|lappy> thanks :)
<raphink> please ;)
<lfittl> raphink: could you delete one of the advocates on http://revu.tauware.de/details.py?upid=1284 for me? :)
<lfittl> the package is not yet ready for upload
<raphink> ok
<sistpoty> raphink: only admins can delete advocates iirc
<lfittl> k, then sistpoty: could you do it for me? :)
<raphink> sistpoty: oh yes
<raphink> i can only remove mine if I ever put any huhu
<sistpoty> lfittl: I guess it would be good to keep the advocates (further checking will be easier)... but I can delete them and write some comment bout it ;)
<raphink> seth_k|lappy: packages archived
<lfittl> sistpoty: I will just make a minor change and upload again
<segfault> must the "copyright holder" be dated?
<lfittl> segfault: yes
<seth_k|lappy> segfault, make sure and date each year the person holds copyright
<raphink> a copyright is "(C) YYYY Author Name"
<seth_k|lappy> e.g. (c) 2003, 2004, 2005 Foo Bar
<raphink> a copyright is "(C) YYYY Author Name author@mail.ext"
<seth_k|lappy> ah right, and e-mail address
<segfault> ok
<raphink> seth_k|lappy: 2003-2005 is fine too
<raphink> imo
<seth_k|lappy> yep
<raphink> although the FSF likes to write the whole list of years ;)
<segfault> Uploading via ftp roundcube-webmail_0.1-20051021-0ubuntu1.dsc: Error '553 Could not create file.'
<segfault> can anyone erase it?
<raphink> use -f
<raphink> dput -f
<raphink> to force the upload
<segfault> i did
<raphink> hmm
<raphink> ok
<raphink> let's see
<segfault> i pressed ctrl+c some time ago while uploading
<raphink> hmm
<raphink> sistpoty: any idea,
<raphink> ?
<segfault> Note: This problem might be caused by files already existent on the server.
<segfault>       For the official Debian upload queues, the dcut(1) utility can be used
<segfault>       to remove stale files from unsuccessful uploads.
<raphink> I don't think you can use dcut with REVU
<raphink> not sure
<seth_k|lappy> you can't
<seth_k|lappy> I tried once
<seth_k|lappy> sistpoty will have to remove the files
<seth_k|lappy> (or another admin)
<raphink> yep
<sistpoty> I'm on it ;)
<segfault> thanks
<raphink> :)
<sistpoty> segfault: files should be gone
<segfault> yeap, thanks again
<raphink> sistpoty: could you have a look at kalcul please while you're there?
<raphink> http://revu.tauware.de/details.py?upid=1310
<sistpoty> raphink: I'll add it to the q... I'm still on the kde style ;)
<seth_k|lappy> get in line, raphink ;)
<raphink> it's ready to go ;)
<raphink> oh ok :)
* raphink gets in line after seth_k|lappy 
<seth_k|lappy> hehehe
* raphink gets back and takes a ticket with a number, then gets back in line shortly
<sistpoty> hehe
<raphink> hey I'm number 2 :D
* raphink raphink dances around with his ticket :)
<segfault> http://revu.tauware.de/details.py?upid=1386
<segfault> anyone?
<segfault> :)
<raphink> yep
<raphink> you still miss the / in debian/dirs segfault
<raphink> I don't know that you need to use .../roundcube-webmail dirs
<raphink> but I'm pretty sure you need to have absolute paths
<segfault> where?
<raphink> debian/dirs
<raphink> you use usr/share/ etc...
<segfault> are those / in debian/dirs really necessary? i haven't seen one debian/dirs using it
<raphink> I think it should be /usr/share/etc.
<raphink> not sure
<raphink> hmm I'l have a look at policy
<segfault> so far i read phpldapadmin and snort sources
<segfault> what do you mean with /usr/share/etc?
<segfault> put the roundcube configs there?
<raphink> cant' find it
<raphink> keep it so
<raphink> no, no nevermind
<lucas> on http://ox.blop.info/bazaar/universe-versionslist.html.gz, packages are now sorted according to popcon results
<raphink> great lucas :)
<lucas> it makes it easier to determine on which merges/syncs you should work first
<lfittl> :)
<raphink> rock
<lucas> it took me 4 hours
<raphink> wow
<raphink> :)
<lucas> I had to understand how python-apt worked to write a script that convert binary package names to source package names efficiently
<lucas> and libapt-pkg really is evil ;)
<raphink> ;)
<lucas> wesnoth	1.1-1	1.0.2-1ubuntu1
<lucas> this one should be high priority :-)
<raphink> oh yeah :D
<raphink> I could do it :)
<raphink> as my first merge :)
<raphink> segfault: you miss the Homepage: at the end of the long description in debian/control
<lucas> raphink: go ahead with wesnoth
<lfittl> lucas: dholbach might be interested in adding news about that to the motu report :)
<lucas> lfittl: I first have to move the list elsewhere
<raphink> lucas: I'll go as soon as i'm done reviewing
<lucas> I have a brand new account on tiber
<raphink> :)
<lfittl> always nice to have :)
<segfault> done
<raphink> segfault: I believe you don't need debian/conf anymore
<lfittl> we only have 2 weeks left for merges, right?
<lucas> yes
<raphink> segfault: both?
<raphink> now let's see if it builds ;)
<lfittl> maybe I should work on some :)
<segfault> yes i do, it has the conf file which will be linked to /etc/apache2/conf.d
<segfault> but i still dont get asked if i want to restart my web server, which should be done in debian/config
<raphink> segfault: ok
<raphink> wait
<raphink> builds fine on my chroot
<raphink> now let's update pbuilder and try :)
<segfault> i'll update my pbuilder now
<raphink> oh, an important point segfault
<raphink> this is not compiled code
<raphink> so architecture is all, not any
<raphink> segfault: in debian/control : architecture: all
<segfault> what's the difference?
<raphink> segfault: any means it builds on any architecture
<raphink> all means it doesn't need to be compiled
<slomo> all is one package for all arches, any one package for each arch
<sistpoty> hi slomo
<segfault> humm, rock
<raphink> since this is a php package, you don't need to compile the source, so it's all
<raphink> hi slomo :)
<slomo> raphink: well, in the case of mono for example it is compiled... but arch indep anyway ;)
<slomo> hi sistpoty, raphink :)
* seth_k|lappy will wait for crimsun and then ask him to walk me through a merge. I still don't quite get them in some cases
<raphink> segfault: you'll get a lintian output about Build-Depends-Indep once you change this
<sistpoty> slomo: you have main upload rights? could you review a package for me please?
<raphink> ignore it, since debhelper is not to be put in Build-Depends-Indep
<segfault> ok
<raphink> good idea seth_k|lappy
<slomo> sistpoty: sure
<raphink> I'll do the same then
<seth_k|lappy> raphink, maybe we should do it together instead of making him do it twice :P
<raphink> that's my idea seth_k|lappy ;)
<raphink> I'll do wesnoth
<raphink> which one will you do seth_k|lappy ?
<seth_k|lappy> http://people.ubuntu.com/~scott/ongoing-merge/superkaramba/
<lucas> sistpoty: can you install 'ruby' on tiber ?
<sistpoty> slomo: http://revu.tauware.de/details.py?upid=1381 (0.0.8 was uploaded by siretart already)
<raphink> ok
<lfittl> I think I will join the party and also do a merge :)
<sistpoty> lucas: mom...
<raphink> wait till I finish to review this package
<seth_k|lappy> It's extremely trivial, yet I don't know what the correct way to go is
<slomo> sistpoty: ok... will do :)
<raphink> sistpoty: you call lucas mom? ;)
<seth_k|lappy> so I think I just need some rules-of-thumb and guidelines
<raphink> i'l surprised sistpoty ;)
<sistpoty> no, mom for moment please ;)
<raphink> haha
<sistpoty> I guess that's a stupid german shortcut
<raphink> ;)
<sistpoty> lucas: done
<raphink> segfault: ok change the architecture and it's fine for me
<lucas> thanks
<raphink> :)
<segfault> woo, nice
<segfault> you checked that debconf stuff?
<raphink> segfault: have it reviewed by MOTUs now ;)
<raphink> oh no
<raphink> I will
<raphink> thanks for reminding me
<raphink> I will, now
<segfault> thanks
<raphink> doesnt work
<raphink> it asks questions when I run dpkg-reconfigure though
<raphink> segfault: just a note on the config/postinst : you could echo a "Restarting roundcube-webmail server..." in postinst
<raphink> postinst should not be verbose, but this is nice to read ;)
<sistpoty> seth_k|lappy: polyester is nice... looks just like plastik :)
<seth_k|lappy> sistpoty, it's shinier :P
<sistpoty> yeah
* sistpoty has already switched
<slomo> sistpoty: this new file... you don't do anything with it... is this intentional?
<raphink> segfault: on `dpkg --purge roundcube-webmail' : rmdir: /etc/roundcube-webmail: No such file or directory
<sistpoty> slomo: what new file?
<raphink> check that segfault
<slomo> sistpoty: this ppd thing
<sistpoty> slomo: no, since it's by far not a good ppd for the 1400W, just s.th. to have a start... (see README.debian)
<raphink> well actually no
<sistpoty> seth_k|lappy: just a small note: don't install an empty TODO file (actually you might bring this to upstream, that they shouldn't provide a 2-byte empty TODO file ;)
<sistpoty> seth_k|lappy: but it's fine as it is
<raphink> segfault: you there?
<segfault> yes
<raphink> ok
<segfault> should i remove the rm on purge?
<slomo> sistpoty: ok, uploaded :)
<raphink> don't both with the --purge stuff segfault
<seth_k|lappy> sistpoty, cool :) I'll tell upstream (I have a few other things to tell them too... notice that I had to change orig.tar.gz)
<sistpoty> thx slomo
<seth_k|lappy> sistpoty, thanks a lot for reviewing it for me :)
<lucas> http://tiber.tauware.de/~lucas/versions/universe.html
<lucas> new, stable, location
<sistpoty> seth_k|lappy: you did? damn I didn't see this... for what reason did you have to change it?
<raphink> graet
<lucas> I haven't set up the cron yet
<lucas> will do tomorrow
<seth_k|lappy> sistpoty, it FTBFS'd otherwise. I had to remove configdialog.{h,cc} or the build bombed
<seth_k|lappy> sistpoty, that was Riddell's recommended solution.
<seth_k|lappy> sistpoty, please see http://seth.pastebin.com/488266
<sistpoty> seth_k|lappy: but that's no reason to change the orig-tarball... you can remove them during clean
<raphink> segfault: add the echo in postinst though please
<seth_k|lappy> sistpoty, hmm
<segfault> no problem if it will show 2 messages? the echo one, and the other from the apache2 init script
<sistpoty> seth_k|lappy: deletion of files doesn't go into .diff.gz... so it's safe to remove files during clean, that shouldn't be there when the package is built
<raphink> segfault: two messages is fine. It just should not be verbose. Two messages for a good reason is fine imo.
<seth_k|lappy> sistpoty, okay. Hold off on the upload and I'll look at how to do that with a cdbs rules file (I could do it with a normal one but don't know how with cdbs)
<sistpoty> seth_k|lappy: ok... hehe I've got no real clue bout how to do it with cdbs either
* seth_k|lappy thinks it would just be easier to remove from orig for this release and poke upstream for next release :P
<sistpoty> seth_k|lappy: no... the orig is called orig because it *is* the upstream tarball. It may only be changed if s.th. in it cannnot be distributed (or repacked if wrong format)
<raphink> segfault: give me the new url when its uploaded
<segfault> sure, just a minute
<raphink> seth_k|lappy: are you doing your merge tonight or shall we do it tomorrow?
<raphink> or just wait for crimsun to be there
<slomo___> hmm... network troubles :)
<slomo___> sistpoty: but it's uploaded now ;)
<seth_k|lappy> raphink, just waiting on crimsun
<sistpoty> slomo___: cool, thx :)
<seth_k|lappy> sistpoty, okay, I found how to change stuff in the clean rule... will fix and reupload
<raphink> ok seth_k|lappy
<raphink> will do too
* sistpoty is out for a smoke
<slomo___> sistpoty: have fun :)
<raphink> segfault: once installed, how are we supposed to access the webmail ?
<raphink> ;)
<segfault> it must be configured, in /usr/share/roundcube-webmail/config
<segfault> tomorrow i'll try to put those stuff in the postinst script
<segfault> http://revu.tauware.de/details.py?upid=1392
<raphink> segfault: the default system-wide dir for apache is /var/www
<raphink> so it might be nice to make a link from /var/www/roundcube-webmail to /usr/share/roundcube-webmail maybe
<raphink> so users can access the webmail on http://localhost/roundcube-webmail by default
<segfault> that's included in /etc/roundcube-webmail/apache.conf
<raphink> I don't seem to see anything in /var/www after the install though
<segfault> it won't
<segfault> it creates an alias in apache.conf
<raphink> why?
<ajmitch> morning :)
<segfault> which is not updated, by the way
<segfault> hehe
<raphink> I mean, phpmyadmin creates a link in /var/www
<raphink> why wouldn't your package do the same?
<raphink> morning ajmitch
<segfault> they're different approaches
<segfault> with the same result, though
<raphink> sure
<raphink> as long as they work ;)
<segfault> yeah, hehe
<raphink> you could add an echo in postrm too, when you restart apache2
<raphink> there, commented :)
<segfault> done
<raphink> ok
<raphink> now ask a MOTU to review it :)
<segfault> any MOTU around?
<segfault> :P
<raphink> hehe
<segfault> thanks for the help raphink
<raphink> you're welcome
<raphink> sistpoty: did you get up to my package?
<seth_k|lappy> he had to go out for a smoke because my package was so scary :P
<raphink> oh yeah right
<raphink> LOL
<sistpoty> re ;)
<sistpoty> raphink: I'm just about it
<raphink> re sistpoty
* raphink holds his ticket :)
<raphink> me me !
* sistpoty takes the ticke
<sistpoty> +t
<seth_k|lappy> haha
<raphink> :)
<raphink> ok well
<raphink> I think I'll go to bed
<raphink> seth_k|lappy: merges tomorrow evening ?
<sistpoty> raphink: got a minute for kalcul review?
<seth_k|lappy> raphink, sure thing
<raphink> sure sistpoty
<raphink> hopefully wesnoth will still be available for my merge tomorrow :)
<sistpoty> raphink: automake1.6 is no longer in the archives, so it ftbfs
<raphink> really?
<raphink> hmm
<raphink> I've got other packages that entered dapper with automake1.6
<seth_k|lappy> yeah, 1.{5,7,8,9} are there, but not 1.6
<raphink> when was it removed?
<sistpoty> raphink: iirc a bug to remove it was filed some time ago in debian
<raphink> oh ok
<raphink> hmm then let's use 1.9
<raphink> by default
<raphink> does it build with 1.9?
<sistpoty> raphink: the orig-tarball is changed... (some autotools-stuff)... would be good to just do bunzip2 tarball gzip -9 tarball
<raphink> seth_k|lappy: 1.5 was removed too it seems
<sistpoty> raphink: haven't tried with 1.9 yet
<raphink> sistpoty: yeah I removed these stuff from orig tarball because lintian was screaming I think
<sistpoty> raphink: and to be picky: in debian/copyright the fsf-address is missing
<raphink> hmm
<sistpoty> raphink: please just unpack/repack the orig... (without untarring it)... lintian wouldn't complain about autotools-stuff iirc, eventually about cvs or s.th.
<raphink> right
<raphink> yes maybe cvs
<raphink> isn't it in the changelog?
<raphink> hmm no
<raphink> weird
<sistpoty> nope
<raphink> i'll repackage ok
<seth_k|lappy> sistpoty, I patched it. I am reuploading... mind looking once more in a second?
* seth_k|lappy takes ticket :P
<sistpoty> raphink: if lintian complains about cvs... just ignore it (and complain at upstream) or make lintian quiet
<sistpoty> seth_k|lappy: not at all... I guess this will be a trivial change only?
<seth_k|lappy> yep, two lines
<sistpoty> :)
<seth_k|lappy> clean::
<rbelem> hello folks
<seth_k|lappy> rm -f client/config/configdialog.{h,cc}
<seth_k|lappy> :)
<seth_k|lappy> sistpoty, I built it again in a pbuilder to make sure my fix worked. It did fine, so reuploading to REVU :)
<sistpoty> :)
<raphink> sistpoty: argh just remembered I don't have my key here ;)
<raphink> shall I give you a diff?
<raphink> :s
<raphink> or just wait til I get to a comp with my key?
<sistpoty> raphink: if you don't mind, just wait till you get to your key... I promise to take a look tomorrow ;)
<raphink> ok
<raphink> thanks
<raphink> I'll work on it tomorrow then
<raphink> :)
<raphink> good inght
<raphink> night
<sistpoty> gn8 raphink
<raphink> bubbye
<seth_k|lappy> sistpoty, http://revu.tauware.de/details.py?upid=1394 :)
<sistpoty> seth_k|lappy: k
<seth_k|lappy> ty
<raphink|sleep> seth_k|lappy: i thought the builddialog stuff would prevent it from building?
<raphink|sleep> configdialog stuff sorry
<seth_k|lappy> raphink|sleep, correct, but sistpoty had me remove it in the clean:: target instead of from .orig
<seth_k|lappy> Riddell said that he and the debian qt/kde maintainers like to change .orig, but MOTUs don't like that :P
<raphink|sleep> yes
<raphink|sleep> if you remove it in the clean
<raphink|sleep> it'll be remove _after_ it's built
<raphink|sleep> so it won't build imo
<raphink|sleep> it should be removed in a step before building
<raphink|sleep> imho
<sistpoty> raphink|sleep: iirc clean is called before actual building, but I would have to look at the policy to be sure ;)
<raphink|sleep> sistpoty: ok
<raphink|sleep> I'm not really sure of it
<Riddell> seth_k|lappy: does that work, it'll need to redo the make -f Makefile.cvs
<seth_k|lappy> sistpoty, it is
<seth_k|lappy> Riddell, it built for me
<seth_k|lappy> in a pbuilder
* Riddell tests
* raphink|sleep is going for real ;)
<raphink|sleep> bye
<seth_k|lappy> bye raphink|sleep :)
<seth_k|lappy> that's kinda what I thought Riddell, which is why I built it myself once to make sure
<seth_k|lappy> Riddell, did it bomb out?
<Riddell> seth_k|lappy: hmm, my chroot has gone weird
<sistpoty> seth_k|lappy: built for me, good to upload
<sistpoty> Riddell: do you want to review again or can I upload polyester?
<Riddell> sistpoty: give me 1 minute
<sistpoty> Riddell: sure
<Riddell> sistpoty: go for it
<sistpoty> Riddell: ok ;)
<sistpoty> seth_k|lappy: polyester uploaded
<seth_k|lappy> cheers sistpoty, I'll stop bugging you for today
<seth_k|lappy> I appreciate it
<seth_k|lappy> (stop bugging unless of course you want more stuff to review :P)
<sistpoty> you're welcome... thx. for your contribution ;)
<sistpoty> well, I guess I'll do one or two merges... and if my girlfriend hasn't come home till then, I'll go for another review ;)
<seth_k|lappy> haha
<seth_k|lappy> it's a deal
<sistpoty> *g*
<seth_k|lappy> sistpoty, if she hasn't come home, http://revu.tauware.de/details.py?upid=1378 ;)
<sistpoty> seth_k|lappy: k
* sistpoty slaps sistpoty that revu allows that /me can advocate the same package twice
<seth_k|lappy> while you're at it, make it so uploaders can archive their own uploads ;)
<sistpoty> seth_k|lappy: will do for revu2 ;)
<seth_k|lappy> yay ;)
<sistpoty> damn, I should write on it again, otherwise it will never get finished
<seth_k|lappy> sistpoty, hum, I think you uploaded polyester twice
<seth_k|lappy> I got 2 emails exactly the same
<sistpoty> erm... no I uploaded only once
<seth_k|lappy> oh well, weird :)
<sistpoty> seth_k|lappy: mails from revu or from katie?
<hub> can someone unarchive and/or explain the latest comments of http://revu.tauware.de/details.py?upid=840
<seth_k|lappy> sistpoty, from katie
<sistpoty> seth_k|lappy: that's strange... did she accept or refuse the upload then?
<seth_k|lappy> sistpoty, it is NEW so I just got two e-mails with the subject "polyester_0.6.5-0ubuntu1_source.changes is NEW"
<sistpoty> seth_k|lappy: no idea really *g*
<seth_k|lappy> np :)
<at1as> Stupid noob question...  Is anyone else having issues with transcode/libdvdcss2 on ubuntu?
<at1as> I'm no longer able to successfully rip and encode my DVDs.
<at1as> on Breezy.
<hub> at1as: mpaa is watching your back
<sistpoty> hub: what's unclear about libiptcdata?
<hub> well what is wrong?my latest comment explain all my "observations"
<hub> like what is against the policy
<at1as> thanks
<at1as> At least someone is ;)
<sistpoty> hub: for the -doc: usual place would be to install to /usr/share/doc/<packagename>... not quite sure whether gtk-doc might be ok here as well
<hub> well, upstream seems to put it there, and don't see obviously how
<hub> looks like what gtk-doc generates
<hub> sistpoty: there is already a lot of things in my /usr/share/gtk-doc
<hub> including rhythmbox
<sistpoty> hub: I have no such dir, since I'm using kde... and I have no clue, what would reside in gtk-doc
<hub> http://www.gtk.org/gtk-doc/
<sistpoty> hub: so devhelp will look in .../gtk-doc? and inside your doc-package is html?
<hub> it is
<hub> it is generated by gtk-doc
<hub> that's why
<sistpoty> ah, k... then this seems the right place
<sistpoty> (maybe you could add a link into /usr/share/doc, but that would only give extra points for polishing)
<sistpoty> for the -dbg package this feels the right place to be... but according to the bug report, you are right ;)
<hub> the .so are not .so just symbols
<sistpoty> ah, /me learned another lesson :)
<dholbach> Lathiat: are you there?
<hub> hey dholbach
<dholbach> hey hub :)
<at1as> hub: Is there actually something that breaks dvdcss in breezy?
<at1as> I had no troubles viewing or encoding dvds in warty
<hub> at1as: no idea. I have a DVD player under my TV
<hub> at1as: so I don't use the DVD on the laptop
<hub> at1as: sorry
<sistpoty> hub: libiptcdata is fine for me... since the debdiff is small, I'll upload
<hub> ok thanks
* Kyral pokes anyone
* sistpoty hides very fast
* sistpoty is out for another cigarette
<Kyral> Umm, guys, there is a guy saying he got an email from  K-Concepts Communications Consultants co., LTD saying they contact(contracted?) with Ubuntu
<ajmitch> that's interesting
<ajmitch> why tell us? ;)
<Kyral> because I was hoping someone would know? Because I don't?
<ajmitch> what difference would it make?
<ajmitch> I've never heard of them
<Kyral> dunno, guy is concerne
<Kyral> d
<ajmitch> about?
<Kyral> if its legit
<ajmitch> probably not
<ajmitch> they probably just use ubuntu
* Kyral nods
<at1as> hub: thanks anyway.  I also have a dvd player, but I also use mythtv, and it is so much easier to view videos if they're on the hd :)
<ajmitch> looks to be a taiwanese outfit
<Kyral> so I should tell him its prolly sketchy?
<hub> at1as: yeah I get that
<ajmitch> the last news on their site is from 2002 (at least in the english section)
<Kyral> so busted?
<minghua> Kyral: who is that guy? BlueT_ on freenode?
<ajmitch> who knows?
<Kyral> minghua: yah
<Kyral> why?
<Lathiat> dholbach: yep
<hub> dholbach: is there a time I'll get the keys of the universe>
<hub> ?
<dholbach> Lathiat: could you please join #ubuntu-meeting?
<dholbach> hub: keys? universe?
<hub> dholbach: to upload :-0
<minghua> well, then no big deal, the K-concepts company basically said they _probably_will_ be responsible for the Ubuntu events in Taiwan in the future
<hub> dholbach: just wondering:-)
<ajmitch> minghua: right
<dholbach> hub: talk to elmo about that. write a mail.
<ajmitch> minghua: which is quite reasonable
<hub> okay
<Kyral> minghua: you wanna handle it?
<Kyral> minghua: I'm just a programmer lol
<ajmitch> considering that there's this asian business tour happening :)
<ajmitch> Kyral: as are most people here :P
<minghua> Kyral: I don't see them claiming they have contracted from ubuntu, contacted with, maybe, but they are not claiming that either
<Kyral> yah but I no good with business things :D
<Kyral> minghua: mind PMSGing him?
<Lathiat> dholbach: yep
<minghua> the letter is at http://bluet.org/~matthew/priv/email-Vicky-kconcepts.txt for those who can read traditional Chinese (I doubt many here :-P)
<dholbach> Lathiat: merci, it's a meeting about Dapper Status.
<hub> can someone archive this http://revu.tauware.de/details.py?upid=1339
<hub> dholbach beat me to upload
<dholbach> hub: will do.
<minghua> Kyral: I can't handle that either, as I don't know the ubuntu PR department either
* hub should release a newer version to give him a chance to upload it :-)(
<dholbach> arg... somebody else archive it please - I don't have my password here.
<Kyral> minghua: I just pasted your answer ;P
<dholbach> hub: feel free. :-)
<hub> dholbach: neither :-/
<hub> dholbach: I have to fix something upstream first :-)
<minghua> ...
<minghua> I can talk with BlueT_, I suppose
<sistpoty> hub: archived
<hub> sistpoty: thankds
<dholbach> thanks Lathiat
<psusi> can someone help me figure out how to manage my patch to the udftools package?  it doesn't appear to be using either dbs or dpatch.. it just has patch-n-description.diff files in the debian dir
<whiprush> \sh_away: motu transcript story is fridged, I appreciate the CC.
<ajmitch> eek
<ajmitch> it needed a lot of tidyup
<Kyral> lol
* sistpoty is off to bed
<sistpoty> gn8 everyone
<ajmitch> night
<psusi> can someone help me figure out how to manage my patch to the udftools package?  it doesn't appear to be using either dbs or dpatch.. it just has patch-n-description.diff files in the debian dir
<psusi> is there another patch management tool I should read up on, or is this just done by hand with diff?
<hub> crap
<hub> libsane do no install
<SEJeff> I just downloaded the source of a program and changed ${packagename}/debian/control and would like to rebuild a binary package from that. How do I do that?
<SEJeff> I am very familar with redhat packaging and the equivalent redhat command would be rpmbuild -bb packagename.spec
* psusi waves at SEJeff 
<psusi> SEJeff, I'm in the middle of learning that myself...
<psusi> cd ${packagename} and debuild -S
<psusi> that will make a new source .deb in ..
<psusi> then pebuilder build the_new_source.deb
<psusi> err, actually, it is pebuilder build ${packagename}.dsc
<psusi> the debuild -S sets up what you would get if you extract a source .deb.. which is the .orig.tar.gz, the .dsc, and so on
<psusi> damnit... I keep typing pEbuilder... it's just pbuilder
<SEJeff> psusi, pebuilder is for windows live cds :)
<SEJeff> psusi, I'll try that out, thanks
<psusi> right now I'm trying to figure out how to get it to actually assemble the other files into the .deb ;)
<psusi> since I'm satisfied with my changes and the resulting binary package pbuilder generates looks good
<SEJeff> psusi, '/usr/bin/dpkg-buildpackage: debian/rules: /usr/bin/make: bad interpreter: Permission denied' I got this problem yesterday with a perl script, any ideas?
<psusi> ls -al /usr/bin/make
<SEJeff> psusi, -rwxr-xr-x 1 root root 139920 2005-12-16 22:01 /usr/bin/make those are correct
<psusi> hrm.... odd
<psusi> looks like it is saying it could not execute /usr/bin/make in response to the shbang in debian/rules
<psusi> try doing this as root
<SEJeff> I had #!/usr/bin/perl -w in a script I wrote and it gave the same thing
<SEJeff> psusi, that was the first thing I tried after I got that error... same message
<psusi> wonky
<psusi> strace it? ;)
<SEJeff> psusi, I'm just trying to fix the broken gnome-schedule in dapper as I want to use it. I will try to fix it tomorrow
<SEJeff> night
<psusi> night
<minghua> SEJeff: the simplest way is dpkg-source -b package-version
<minghua> SEJeff: package-version being the directory of the whole source tree
<minghua> SEJeff: your "bad interpreter" error still look strange though and may be unrelated
<zakame> afternoon MOTUs :)
<minghua> hi zakame, I have a question for you
<minghua> zakame: do you remember requesting a sync on octave2.1 for me?
<minghua> it doesn't seem to arrive (yet)
<zakame> minghua: no, I haven't requested that, iirc, I was hesitant 'coz someone else may had requested it already ;)
<minghua> oh okay
<zakame> minghua: if it's not, then I'll do it now :)
<minghua> zakame: it is not, so please do, thanks :-)
<zakame> minghua: hm last build was on Dec 24
<Gloubiboulga> morning
<zakame> but 'tis a ubuntu version, so I'll request then :)
<minghua> zakame: that's doko's libstdc++ transition rebuild upload
<zakame> morning Gloubiboulga
<zakame> yep
<segfault> any MOTU around?
<segfault> http://revu.tauware.de/details.py?upid=1396
<segfault> any MOTU around?
<jpatrick> segfault: maybe ajmitch ?
<segfault> dunno if he's around
<zakame> segfault: why? :)
<segfault> http://revu.tauware.de/details.py?upid=1396
<segfault> :)
<segfault> to review it
<dholbach> hellas
<lfittl> morning dholbach :)
<dholbach> hey lfittl
<segfault> dholbach: are you busy?
<dholbach> segfault: why do you ask? :)
<lfittl> he needs a motu for reviewing his package ;)
<segfault> dholbach: can you review one package? http://revu.tauware.de/details.py?upid=1396
<segfault> its kinda simple
<dholbach> segfault: will do in a sec and tell you what i find
<dholbach> segfault: need to get up to scratch with mails and the like first
<segfault> dholbach: sure, no prob
<jpatrick> dholbach: noone has taken a peek at my lmms: http://revu.tauware.de/details.py?upid=1280 :(
<dholbach> jpatrick: will do
<jpatrick> thanks
<Nafallo> wow
<Nafallo> 10 packages left for merging. good job guys! :-)
<lfittl> Nafallo: don't forget the 190 assigned merges ;)
<Nafallo> those are assigned and handled already, no?
<lfittl> they are assigned but not fixed, meaning the merge is not done yet
<dholbach> who would like to proofread/add-stuff to http://wiki.ubuntu.com/MOTUReportDraft?
<jpatrick> dholbach: new MOTU hopefuls: Me
<Nafallo> hmm, that means people are working on them atleast :-P
<Nafallo> (and what I meant)
<lfittl> k, then you are right :)
<dholbach> jpatrick: would you care enough to add it?
<jpatrick> dholbach: I have to be a member first
<dholbach> jpatrick: to the MOTUReportDraft page?
<dholbach> segfault: wouldnt you have to depend on *debconf?
<segfault> dholbach: humm, i think so... i forgot it. can you tell me why after installing the deb, i dont get asked by debconf if i want to restart the browser?
<segfault> err, the web server.
<segfault> config seems to be ok
<dholbach> segfault: not really, i'd have to compare with other packages to do that
<lucas> dholbach: I'd like to add something
<lucas> about the fact that lists of package versions are available
<lucas> but I still have to do some work on them
<lucas> what's your deadline ?
<tseng> Ubugtu: seen crimsun
<lucas> tseng: he said he was gone for 2 days, been visiting a friend who is ill
<dholbach> lucas: just go ahead and add it - i'd like to get the news out, but it's not mission-critical or something
<tseng> lucas: thanks.
<lucas> can I work on that tonight ? does that fit ?
<lucas> I have to do some real-world work sometimes ;)
<zakame> hm why is robotour in multiverse?
<dholbach> lucas: it's ok :)
<Nafallo> hmm, could someone remove pessulus from "new merges" on our mom-interface? :-)
<Nafallo> we are newer than debian already :-)
<jpatrick> morning raphink
<raphink> hi jpatrick
<jpatrick> raphink: might want to add yourself here: https://wiki.kubuntu.org/MOTUReportDraft
<raphink> what's that for?
<jpatrick> next MOTU report
<raphink> oh yeah
<jpatrick> under "new MOTU hopefuls"
<raphink> and seth too
<raphink> but i'm not even a member yet
<raphink> but ok
<jpatrick> just a hopeful
<raphink> hop
<jpatrick> someone care to poke lmms? : http://dot.kde.org/1113428593/
<jpatrick> damn wrong link
<jpatrick> http://revu.tauware.de/details.py?upid=1280
<segfault> http://revu.tauware.de/details.py?upid=1397
<rtcm> hi, is there an RCS where the source packages in ubuntu are maintained?
<lucas> it depends on the package
<lucas> some of them are just debian's
<lucas> some are maintained somewhere in bzr
<lucas> etc
<lucas> you can get the source for a package by running apt-get source <package name>
<lucas> if you have sources lists in your /etc/apt/sources.list
<rtcm> lucas: and where can I find the ones that are maintained in a RCS?
<azeem> rtcm: there is no easy way to find out, I think
<nomed> how can i check if my request to join a team has been sent ?
<tepsipakki> nafallo: is there hope to get aac/m4a-support for gtkpod, because otherwise it can't read the metadata from those and syncing fails
<tepsipakki> I know about the license..
<rtcm> azeem: hmm, ok then, thanks
<Nafallo> tepsipakki: I have no idea, I just merged it.
<Nafallo> tepsipakki: you should ask MOTUMedia (i.e. slomo ;-)).
<Nafallo> what shall we do with linux-kernel-di-*-2.6? merge them?
<slomo> tepsipakki: this would mean moving gtkpod to multiverse as the faad/faac is located there...
<tepsipakki> slomo: so it's a no-go? would it be ugly to have a "gtkpod-aac" or similar in multiverse?
<tseng> it would
<tseng> but there isnt another way
<slomo> tepsipakki: would be possible if someone does it :)
<tseng> if you google a few people have already rolled gtkpod-aac
<tepsipakki> i've tried to compile it on breezy, but didn't succeed
<tepsipakki> slomo: :)
<slomo> what was the problem?
<tepsipakki> funny that rhythmbox which is in main, can play stuff from my ipod quite happily
<slomo> because it uses gstreamer... and there is a gstreamer plugin for aac/m4a in multiverse which you have installed ;)
<tepsipakki> slomo: yeah of course
<tepsipakki> slomo: would gtkpod-aac need to have it's own source-package, if it was in multiverse?
<slomo> yes
<slomo> i.e. a copy of the gtkpod sourcepackage with that very small change...
<slomo> ugly duplication but the only way :/
<tepsipakki> yes. heck, I might do it after I've upgraded my home computer (not until fglrx works with dapper completely)
<tepsipakki> I believe here are plenty of people to push the (source) package once it is done? I'm still just an ubuntero
<tepsipakki> or would it mean that the uploader is the maintainer, or can a non-member be?
<slomo> you can be the maintainer... and it will be fairly easy to find someone to upload it once it's done and good :) if you have any questions on what changes need to be done etc feel free to ask here ;)
<tepsipakki> yes, sure. thanks!
<tepsipakki> I've done some packaging before, so it's not completely foreign
<slomo> damn, istanbul segfaults :(
<tepsipakki> which reminds me that I promised to package libgssapi and librpcsecgss this week..
<segfault> slomo: can you review http://revu.tauware.de/details.py?upid=1397?
<lucas> segfault: please stop bugging MOTUs about reviews. your priority should be to fix existing software currently, and work on merges and syncs
<zakame> evening MOTUs :)
<Nafallo> hmm
<Nafallo> ajmitch: hi!? :-)
<zakame> heya Nafallo
<Nafallo> zakame: hi there :-)
<Nafallo> anyone knows if we should merge linux-kernel-di-*-2.6 or not? :-)
<zakame> hm I remember ajmitch saying not, iirc
<Nafallo> why is it still on the mergelist then? :-P
<Nafallo> and for pessulus, kmess and kguitar we are already newer than Debian ;-)
<Nafallo> so nothing to do :-P
<zakame> pretty unsure of it myself... I can't recall what reason was there not to do a merge/sync test on those :)
<zakame> indeed, that's why I'm working on my Debian pkgs for a change :P
<Nafallo> :-)
<Nafallo> I better help my girls clean my computerparts :-P
<Nafallo> later all :-)
<zakame> and learning cdbs too :)
<zakame> cya Nafallo :)
<zakame> wow, why didn't I learn cdbs in the first place? :P
<ajmitch> because cdbs is evil
<zakame> buwahaha voodoo
<tseng> <3 voodoo
<jamessan> zakame: because it's better to know how things work behind the scenes first :)
<tseng> thats why i use ruby on rails
<zakame> jamessan: yup :)
<ajmitch> tseng: zope 3 all the way
<ajmitch> don't you want your apps to turn out like launchpad?
<tseng> ajmitch: sigh
<tseng> no
<tseng> at least use django
<tseng> ORM for the win
<zakame> jamessan: now I know why Manoj's debian-dir was a bit like cdbs, except for the verbosity
<jamessan> zakame: I don't think I've heard of debian-dir before
<zakame> jamessan: http://arch.debian.org/arch/private/srivasta
<tseng> ajmitch is so advantgard he uses debian-dir with bzr
<zakame> w00t
<zakame> I've yet to play with bzr :(
<tseng> bzr is magic crack
<psusi> diff/patch rule all! ;)
<ajmitch> tseng: I do?
<tseng> ajmitch: something like that, no?"
* ajmitch usually uses cdbs for packages
<Yagisan> \sh_away: When you get back I'd like to talk to you about Ubuntu's wine package for dapper. I saw you were the last to touch it, and I'd like to discuss some (future) packaging issues with it. Alternatively, point me in the direction of someone more appropriate.
<Yagisan> \sh_away: I'm logged in ATM, but I'll most likely be in bed soon. feel free to msg me.
<zakame> gn8 all
<greenpenguin13> n8 zakame
<zakame> :)
<jpatrick> can someone look at http://revu.tauware.de/details.py?upid=1380 ?
<\sh> moins
<Nafallo> \sh: you have bzr-trees all aspects of gajim? :-)
<\sh> Nafallo: sure :)
<Nafallo> urls? :-)
* Nafallo better get up-to-date with bzr again :-P
<\sh> Nafallo: right now it's local only...but I will push them during the weekend on tiber
<Nafallo> ah, oki :-)
<\sh> drwxr-xr-x   7 shermann shermann 4096 2006-01-05 18:18 gajim-0.9.1
<\sh> drwxr-xr-x   7 shermann shermann 4096 2006-01-05 18:28 gajim-0.9.1-debian-copying
<\sh> drwxr-xr-x   4 shermann shermann 4096 2006-01-05 18:45 gajim-0.9.1-debian-dir
<\sh> drwxr-xr-x   7 shermann shermann 4096 2006-01-05 18:31 gajim-0.9.1-debian-group-patch
<\sh> drwxr-xr-x   7 shermann shermann 4096 2006-01-05 18:46 gajim-0.9.1-package
<\sh> drwxr-xr-x   7 shermann shermann 4096 2006-01-05 18:24 gajim-0.9.1-ubuntu-human
<\sh> drwxr-xr-x   7 shermann shermann 4096 2006-01-05 18:25 gajim-0.9.1-ubuntu-launchpad-integration
<\sh> this is my repos :)
<\sh> where gajim-0.9.1-package is the merged gajim-0.9.1 tree with all other branches and a nested debian dir branch
<\sh> I played before only with diffs between revisions just like svn...
<Nafallo> ahh, looks like some stuff isn't in the current uploaded package :-P
<\sh> but now I remembered siretarts way of doing things and HCT as well, and this way it's more easier for me to keep track
<\sh> what?
<Nafallo> gajim-0.9.1-debian-*? :-)
<\sh> ah ... I just got rid of the patch system :)
<Nafallo> ehm, copying and group patch :-P
<\sh> everything is now in the debdiff
<\sh> it's in :)
<Nafallo> hehe, nice :-)
<Nafallo> I never really liked the patchsystem :-)
<\sh> the only patch I dropped is the debian xpm stuff
* Nafallo does debian/ubuntu-patches.diff and applies it now :-P
<\sh> well...I try to change everything to diff.gz for the packages I brought in :)
<Nafallo> hmm, is it really in? it's not in our current debian/patches :-P
<\sh> Nafallo: there is no debian/patches anymore I merged the new 0.9.1-2 rev
<Nafallo> is that uploaded?
<\sh> Nafallo: yes just now
<Nafallo> oh
<\sh> Accepted gajim 0.9.1-2ubuntu1 (source)
<Nafallo> sources is not in the archive yet :-P
<\sh> Date:
<\sh> 2006-01-05 19:00
<\sh> just 10 minutes ago
<jpat|away> \sh: can you look at my lmms?: http://revu.tauware.de/details.py?upid=1280
<Nafallo> yea, should go in with the :03 run :-)
<\sh> Nafallo: it has to compile first :)
<Nafallo> no, the source have to go in before it can compile :-)
<\sh> jpat|away: sure one moment :) I have to close my bugs first :)
<\sh> Nafallo: sure
<Nafallo> so I can apt-get source anytime now :-)
<\sh> Nafallo: but it takes some time ever :)
<slomo> Nafallo: not online in jabber? :P
<Nafallo> slomo: ehm, yes I am?
<slomo> not for me... hmm
<Nafallo> I just sent you "test"
<slomo> hmm... nothing happened here... \sh, your server is broken ;P
<\sh> slomo: what?
<\sh> you mean jabber?
<\sh> i'm on :)
* Nafallo restarts gajim
<slomo> yes... i was connected since 2 hours and now nafallo's messages don't get here ;)
* slomo restarts
<\sh> slomo is offline :)
<\sh> nafallo is now online
<\sh> slomo is now online
<slomo> ah, now it's better
<Nafallo> slomo: you got "test :-)"
<Nafallo> ?
<slomo> no
<slomo> Nafallo: did you get my message?
<\sh> Nafallo: you got my test it message?
<Nafallo> \sh, slomo: nope
<\sh> slomo: and my hello message?
<slomo> nope
<\sh> i'm with kopete now
<\sh> and I can see you online
<slomo> i see you all online now... but no messages ;)
<Nafallo> \sh: you got "test"?
<\sh> write something to me pls
<\sh> Nafallo: no
<slomo> \sh: done... did you get something?
<Nafallo> something is wrong somewhere then...
<\sh> also not
<\sh> but I'm talking to another guy
<Nafallo> hmm
<Nafallo> so client-server-client broken? :-P
<\sh> gajim?
<slomo> yes
<Nafallo> yes
<Gloubiboulga> slomo, do you have some time for a review?
<slomo> Gloubiboulga: no... i must leave in -1 minute =)
<\sh> try hmm...gaim or psi or kopete to be sure that it's not the server
<slomo> Gloubiboulga: but i could add it to my todo list... just give me the url
<Gloubiboulga> ok
<Gloubiboulga> http://revu.tauware.de/details.py?upid=1362
<Gloubiboulga> thanks slomo
<slomo> bbl
<Nafallo> \sh: did you get the last three messages after "nice..file a bug" ?
<\sh> no
<Nafallo> xml-console says you didn't :-P
<Nafallo> http://paste.ubuntu-nl.org/6656
<\sh> what is this shit? ,)
<Nafallo> console output :-P
<\sh> yes...but Byte has no attribute encoding?
<\sh> what they are doing
<\sh> it's dbus magic
<Nafallo> nice that this gajim is in breezy-backports ;-)
<\sh> damn
<\sh> are u using the backports version?
<Nafallo> nope
<Nafallo> my girlfriend is :-)
<\sh> and this message is from your gf?
<Nafallo> nope, my dapper laptop :-)
<\sh> hmmm...
<Nafallo> haven't tried to reproduce it on breezy yet.
<Nafallo> when did gajim start to use dbus? :-P
<\sh> since 0.9?
<\sh> and since gajim-remote?
<Nafallo> ah
<Nafallo> hmm
<Nafallo> libnotify is dbus, no?
<\sh> no.
<\sh> it's libnotify
<Nafallo> damn :-P
<\sh> it has to do something with gamin bla....
<Nafallo> I wonder why it tries to use dbus then... since I have never even touched gajim-remote :-P
<\sh> libnotify is messaging dbus for triggering some things..like notifying the taskbar
<\sh> IMHO :)
<\sh> Need to buy some cigarettes
<Nafallo> gaah
<Nafallo> this started after the new notify thingie :-P
<Nafallo> baah. food now anyway :-P
<flujan> hi guys.
<flujan> I send a e-mail to the list
<flujan> I want to help the motu project
<flujan> daniel holbach point me this channel
<flujan> i'm not a active irc user, but... let it go!!!
<flujan> ;)
<flujan> hello
<Gloubiboulga> hi flujan
<Gloubiboulga> it's very quiet tonight
<flujan> hum... i'm in Brazil so here is about 6 pm
<flujan> ;)
<Gloubiboulga> maybe you should ping dholbach...
<flujan> how can I do that?
<Gloubiboulga> I just did :)
<flujan> ping dholbach
<Gloubiboulga> you just have to write his nick
<flujan> dholbach
<Gloubiboulga> I guess he's away from computer
<flujan> hum... ok
<dholbach> pong
<dholbach> i was on the phone
<flujan> hi daniel
<flujan> I join the channel but there's no living here. ;)
<flujan> so, who is the project leadr?
<tseng> there isnt a "leader"
<dholbach> sabdfl (Mark Shuttleworth) is the project leader :)
<dholbach> flujan: we're trying to do everything as a big family :)
<flujan> ok, but someone take the decisions for instance... what package one should maintain
<dholbach> everybody decides that in consensus
<dholbach> and we do team maintenance
<dholbach> but surely respect the area of expertise of others
<dholbach> i wouldn't meddle with mono packages, if i didn't have to :)
<dholbach> i let tseng and slomo do the dirty work there
<flujan> so... i'm not need anything special... I only use postgresql and zope
<flujan> ahuaha understood...
<dholbach> :)
<tseng> yay mono
<flujan> So, the multiuniverse packages... Which packages is in the wishlist and are "aproved" to be merged?
<flujan> I can take one of this packages and try my best
<flujan> ;)
<dholbach> there are merges to do, i hope somebody else can introduce you to this
<dholbach> there are a *lot* of bugs in launchpad assigned to the 'motu' team, which need cleaning up and triaging
<Kyral> ack
<dholbach> and if you'd like to package something new, you'd better hurry - dapper has a *very* early upstream version freeze atm
<Nafallo> dholbach: are there? only 5 that seems not to be merges on the mom-list-thingie :-)
<tseng> dholbach: (how soon again?)
<Kyral> I need to complain to hwdata upstream
<Kyral> tseng: I was just about to ask that :D
<dholbach> tseng: main is definitely 19th of January
<tseng> damn
<dholbach> tseng: and for Universe we have to ask for 1-2 weeks of delay
<Kyral> Universe?
<dholbach> tseng: because it'd be unfair
* Kyral whews
<dholbach> i'll try to raise the point
<tseng> so we'll get mono 1.1.13.1 maybe
<Kyral> Okay I should be able to get yamysqlfront in
<dholbach> Dapper wil be rocking stable, so we better hurry, if we want upstream stuff to get in (as well as NEW packages)
<dholbach> we will concentrate on fixing up whatever we can after UVF
<dholbach> and we'll do well
<flujan> is ther orphan packages? With orphan I mean a package without a maintainer
<tseng> packages dont have maintainers here
<dholbach> flujan: we inherit packages from Debian
* Kyral throws dholbach a military salute
<Kyral> you got it sir
<dholbach> woohoo!
<ogra_ibook> flujan, you just grab what you like and work on it :)
<ogra_ibook> flujan, no bureaucracy
<dholbach> the last two weeks everything will be fixed and we just have to organize the Release Parties - i know it
<Kyral> lol
<ogra_ibook> haha
<Kyral> PARTY!! WOHOO!
<segfault> hallo
<flujan> ok so... where can i grab something?
<Kyral> I can hear Jeff's voice (AGAIN) going "we do NOT have a drinking problem in this project!"
<flujan> i like to work with bugfixes
<Kyral> then you can complain to hwdata upstream lol
<ogra_ibook> just dig through the bugtracker on launchpad.net ... if you find some intresting bugs, grab them and attach a patch to the bug with a fix
<flujan> ok
<flujan> another thing..
<flujan> I worked with slackware since 7.0
<Kyral> Actually could we check to see if we could use the hwdata package from Breezy?
<flujan> now, I need some help creating packages to ubuntu
<ogra_ibook> there are some pages on the wiki that are packaging related ... mainly you should take a look at the debian new maintainers guide
<ogra_ibook> thats good for a starting point
<Kyral> upstream changed something that borked Kickstart
<flujan> ok, so I will check it and will keep an eye in the mailing list
<ogra_ibook> yup
<ogra_ibook> and hang around here, this is where the main work happens ...
<Kyral> Oh if anyone has a sec, archive EasyChem
<Kyral> ty
<segfault> any MOTU with spare time to review one package?
<jpatrick> \sh: I'm here now :)
<flujan> hum... there is a lot of bugs that already have a debian patchs ...
<Kyral> then ask them to be synced from Debian
<jpatrick> dholbach: do you have time for http://revu.tauware.de/details.py?upid=1280 ?
<\sh> jpatrick: checking right now
<jpatrick> thanks
<Nafallo> \sh: #ubuntu-im ? :-)
<dholbach> jpatrick: i'm just doing an libxml update and wanted to look in gnome-system-tools and gthumb next
<jpatrick> okay
<dholbach> hey jdahlin
<jdahlin> hi dholbach
<dholbach> jdahlin: new kiwi version, or what? ;-p
* dholbach hugs jdahlin
<jdahlin> dholbach: oh, not at the moment :-)
* dholbach is in a good mood. :-)
<jdahlin> I did release a new gazpacho release a few moments ago thou
<jdahlin> however, I was mainly here trying to figure out why dosemu is broken in breezy
<dholbach> jdahlin: i asked in #ubuntu-desktop already, who wanted to package it
<dholbach> jdahlin: nobody stepped up yet and if nobody does, after i fixed the other updates, i'll do it myself
<dholbach> no idea about dosemu though
<jdahlin> dholbach: it's in debian, so maybe I should push the debian maintainer
<dholbach> i was just having a look into debbugs
<dholbach> maybe it's fixed in dapper already and you'd just have to backport the fix
<jdahlin> rebuilding dosemu using gcc 2.95 seems to work (it doesn't build with a recent version)
<Ubugtu> GCC bug 2: "ICE on template with aggregates" Product: gcc, Component: c++, Severity: normal, Assigned to: unassigned@gcc.gnu.org, Status: RESOLVED, Resolution: FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
<dholbach> argargarg
<\sh> how do someone burn mdf images?
<lfittl> \sh: convert it to iso by using mdf2iso
<\sh> lfittl: which package is this in?
<lfittl> mdf2iso ;)
<raphink> ;)
<\sh> not in breezy
<raphink> it's in dapper at least ;)
<lfittl> oh sry thought you were on dapper
<lfittl> yep it's only in dapper
<\sh> ah is it in dapper?
<\sh> ok...trying to backport
<Gloubiboulga> dholbach, I'm having a look at malone #6437 , should I also change stuff like debhelper version (it's >=4.0.0) ?
<Ubugtu> Malone bug 6437: "schedule (Ubuntu) - wrong dependencies" Fix req. for: gnome-schedule (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: New http://launchpad.net/bugs/6437
<dholbach> Gloubiboulga: if we require it, yes - else: not really, because we'll have to merge it next time too
<Gloubiboulga> ok, I just change the dependencies, and produce a debdiff then
<\sh> jpatrick: done
<jpatrick> woohoo
<jpatrick> next one i have is: http://revu.tauware.de/details.py?upid=1380
<LaserJock> hi everybody!
<jpatrick> hi LaserJock
<Gloubiboulga> hello LaserJock :)
<LaserJock> I'm back from the dialup land so hopefully I can get some work done ;-)
<Kyral> Yea LJ
* \sh has to go now...laters
<LaserJock> wow, I have over 500 packages to upgrade
<raphink> LaserJock: same here
<raphink> just upgraded 495 packages
<raphink> ;)
<raphink> wb Kyral
<Amaranth> anyone know if python compiled with gcc 3.3 would work with pyqt4 compiled with gcc 4?
<Ubugtu> GCC bug 3: "Nested types sometimes not visible" Product: gcc, Component: c++, Severity: normal, Assigned to: nathan@gcc.gnu.org, Status: RESOLVED, Resolution: FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
<Ubugtu> GCC bug 4: "Test PR" Product: gcc, Component: other, Severity: normal, Assigned to: unassigned@gcc.gnu.org, Status: RESOLVED, Resolution: FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
<Amaranth> *boggle*
<Nafallo> LOL
<Nafallo> Seveas: !!! ^
<Seveas> hehe
<Seveas> I added some more zillas :)
<Amaranth> gccbug, perhaps?
<Seveas> @bugtracker remove gcc
<Ubugtu> The operation succeeded.
<Nafallo> could it be smartar about 3.3 (dots) ? :-P
<raphink> seth_k|lappy: are you around?
<seth_k|lappy> raphink, indeed
<seth_k|lappy> but I'm about to leave for work
<raphink> oh ok
<raphink> :)
<raphink> I'll see if I can merge wesnoth :)
<seth_k|lappy> yeah, go ahead and go for it ;) I won't be back until late
<raphink> ok
<raphink> ouch
<raphink> 32MB debdiff!
<jpatrick> ouch
<raphink> lol
<raphink> big changes in wesnoth :)
<raphink> so let's see
<seth_k|lappy> well it is a new upstream version, so nurr
<raphink> first thing to do is to file a bug, right?
<seth_k|lappy> they change a lot of stuff
<seth_k|lappy> yes, first file an LP bug with the title 'wesnoth: merge new debian version'
<raphink> yes, thankfully ;)
<seth_k|lappy> and mark it Accepted and assign it to you
<raphink> ok
<raphink> manually?
<seth_k|lappy> there's no automatic way to do it
<raphink> ok
<raphink> I'll do my first merge manually
<seth_k|lappy> you can use the LPEmailInterface crack to do it all at once though
<seth_k|lappy> good luck :P
<raphink> this is better to understand how the automatic tool work
<raphink> haha
<raphink> thanks ;)
<raphink> grr spamassassin eats all my CPU
<raphink> :s
<seth_k|lappy> oh, raphink, I hear the best way is to start with the debian package and the ubuntu patch, and then look at the differences between those two
<seth_k|lappy> instead of the other way around
<raphink> hmm ok
<raphink> so I extract the debian package
<raphink> and I look at the ubuntu patch?
<raphink> or what?
<raphink> do I put MOTU: my name
<raphink> even if I'm no MOTU?
<Gloubiboulga> good night
<raphink> hi glou
<raphink> bi
<raphink> :s
<raphink> hi lucas
<jpatrick> raphink: have to get to that meeting :/
<raphink> ok
<lucas> hi :)
<raphink> what meeting?
<jpatrick> CC
<raphink> jpatrick: CC is not today
<jpatrick> I know
<raphink> ;)
<raphink> I'm sure you'll manage to be there don't worry ;)
<jpatrick> if I run...
<raphink> anyone knows where I can find a tarball of motu-tools ?
<raphink> instead of downloading the files one by one
<lucas> raphink: where do you download them from ?
<raphink> lucas: I see http://tiber.tauware.de/~shermann/motu-tools/
<raphink> but that's not very convenient to download
<raphink> a tarball would be nicer
<lucas> then bzr branch http://tiber.tauware.de/~shermann/motu-tools/
<raphink> ;)
<raphink> hmm that's the link I gave
<lucas> yeah and I added bzr branch ;)
<jpatrick> raphink: http://revu.tauware.de/details.py?upid=1160
<raphink> which means?
<lucas> do you know what bzr means ?
<raphink> jpatrick: not sure this is the same
<raphink> yes lucas but I don't know how to use it yet
<lucas> ok
<raphink> ;)
<lucas> install it, and type bzr branch http://tiber.tauware.de/~shermann/motu-tools/
<lucas> that's everything you need to know for now
<raphink> bzr is a new equivalent to cvs/svn right?
<raphink> oh ok
<raphink> :)
<raphink> thanks
<lucas> there's a good bzr tutorial somewhere on the web
<lucas> I don't remember exactly
<raphink> :)
<raphink> I'll look at it later on
<raphink> right now I'm wanting to merge wesnoth :)
<lucas> ok
<lucas> regarding wesnoth, it seems the patch was caused by the -t version not working
<raphink> hmm ok
<lucas> s/version/option/
<raphink> I'll have a look
<lucas> looking at the changelog
<lucas> so, you just have to download and build the debian version, and see if -t works fine
<raphink> bzr branch http://tiber.tauware.de/~shermann/motu-tools/ doesn't seem to work
<lucas> erm, it's supposed to
<raphink>  $ bzr branch http://tiber.tauware.de/~shermann/motu-tools/
<raphink> bzr: ERROR: URLError instance has no attribute 'code'
<raphink>   command: '/usr/bin/bzr' 'branch' 'http://tiber.tauware.de/~shermann/motu-tools/'
<raphink>       pwd: u'/home/raphink/debs/merges'
<raphink>     error: exceptions.AttributeError
<raphink>   at /usr/lib/python2.4/site-packages/bzrlib/transport/http.py line 146, in get()
<raphink>   see ~/.bzr.log for debug information
<raphink> sorry can't acess the pastebin so ;)
<raphink> lucas: http://ubuntu.pastebin.com/492353
<lucas> it works for me
<lucas> ***lucas@blop:/tmp% bzr --version                                           (2)
<lucas> bzr (bazaar-ng) 0.6
<raphink> ok good
<raphink> I'll see about that later on
<raphink> I got all the files manually ;)
<raphink> [MAIL] 
<raphink> method=SMTP or sendmail
<raphink> what shall I take ?
<dholbach> Have a nice evening - I'm off.
<raphink> bye dholbach
<lucas> SMTP
<raphink> ok
<raphink> that seems easier
<lucas> sendmail might produce problems if your local mail server is not correctly set up
<lucas> raphink: wget -r -np -nH http://tiber.tauware.de/~shermann/motu-tools/
<lucas> would have worked too
<raphink> ok
<raphink> thanks
<raphink> :)
<raphink> hmm
<raphink> I'm using gmail as my mailbox
<raphink> can I set that for merges?
<raphink> smtp uses a weird port
<raphink> oh yes I can set it
<raphink> hehe
<raphink> sorry
<raphink> stupid question
<raphink> hop :)
<raphink> hmm
<raphink> it seems lpbugs.py failed to send
<raphink> http://ubuntu.pastebin.com/492373
<raphink> :(
<raphink> any idea
<raphink> ?
<raphink> Kyral: did you ever get something like this ? http://ubuntu.pastebin.com/492373
<LaserJock> Kyral_: are you testing your irssi+screen or something?
<Kyral> no...
<Kyral> Yanno how DNS hated my laptop?
<Kyral> err
<Kyral> Desktop?
<Kyral> .....
<raphink> :s
<Kyral> DIE IMPOSTER!
<LaserJock> raphink: you have updated your motu-tools?
<raphink> I have just downloaded the last version LaserJock
<raphink> and just set it up
<Kyral> brb
<Kyral> ...I'm gonna restart my machine...
<Kyral> this is odd
<raphink> LaserJock: any idea?
<Kyral> or...
<LaserJock> raphink: I used to get stuff like that but I don't anymore, I don't think
<raphink> LaserJock: http://ubuntu.pastebin.com/492382
<Kyral> Rogue Irssi Session
<raphink> these are my settings, if ever there's something wrong in them
<LaserJock> raphink: you need auth?
<raphink> LaserJock: for gmail yes
* Kyral is VERY confused
<LaserJock> raphink: that could be the problem
<raphink> why?
<LaserJock> raphink: cause I don't need auth and it works for me ;-)
<raphink> hehe
<raphink> well I have to use the email I use to log to LP right?
<Kyral> Yanno how my DNS hated me for a while?
<LaserJock> yes, I believe so
<lucas> raphink: can you use your provider's SMTP server ?
<raphink> lucas: to send from my gmail add ?
<raphink> not sure
<lucas> you should be able to
<raphink> I could try
<raphink> ok
<raphink> seems to work lucas thanks
<raphink> :)
<raphink> at least I got no error (yet)
<raphink> where do I see if it worked?
<lucas> if a bug gets created on LP
<raphink> for the wesnoth package ?
<lucas> yup
<raphink> oh yes I see it :)
<raphink> hehe
<raphink> hehe
<ajmitch> morning
<LaserJock> hi ajmitch
<raphink> hi ajmitch
<LaserJock> ajmitch: do you have a minute to review plotdrop?
<ajmitch> nope
<LaserJock> oh well ;-)
* ajmitch has a laptop to install breezy (and then dapper) on
<hub> ajmitch: I went dapper directly
<ajmitch> hub: I'll put up some info on the laptop testing pages
<hub> canonical laptop?
<ajmitch> no, that was nicked in montreal
<hub> ah
<ajmitch> this is a new one I got about 30 min ago
<hub> yeah I got that
* ajmitch is still in windows, getting the essential bits (ff, ooo, putty)
<hub> ajmitch: ah. I wiped windows
<hub> to claim my refund
<ajmitch> heh
<raphink> can anyone take me through my merge so I do it properly?
<raphink> :s
<raphink> lucas: from extracting the source and look at the files, it seems the -t stuff has been restored in Debian, too
<raphink> lucas: and there's no patch to be checked
<raphink> lucas: so I should sync?
<lucas> you tested ?
<lucas> please describe 'it seems' :-)
<raphink> hehe
<raphink> well
<raphink> ok
<raphink> in the _ubuntu.debdiff
<lucas> also, remember that you have to check that the package builds on dapper
<lucas> ideally using pbuilder, or within a quite clean chroot
<raphink> I see that the diff described in changelog was on wesnoth-1.0.2/debian/wesnoth-data.install
<raphink> the ubuntu package had restored a line in this
<raphink> I extracted the new debian package
<raphink> and checked that this line is there
<lucas> ok
<raphink> :)
<lucas> build, install, test :-)
<raphink> now I should just check if it build in my dapper pbuilder
<raphink> :)
<raphink> so updating it :)
<raphink> that's all that is to do, right?
<lucas> yes
* lucas admits he doesn't use pbuilder
<raphink> ok :)
<raphink> I use pbuilder for all my reviews
<raphink> in addition to using dchroot to test debuild && debuild -S -sa
<raphink> :)
<hub> ajmitch: what kind of laptop is it?
<ajmitch> hub: acer travelmate
<ajmitch> P-M 2GHz, 1GB RAM, 100GB HDD
<ajmitch> should be good enough to compile a bit of stuff
<hub> I don't have that big
<hub> still way better than my old and desktop
<raphink> ooh nice laptop
<raphink> :)
<raphink> checking for Py_Finalize in -lpython2.4... no
<raphink> checking for Py_Finalize in -lpython2.4... (cached) no
<raphink> checking for Py_Finalize in -lpython2.4... (cached) no
<raphink> configure: error: Python development libraries required
<raphink> make: *** [config.status]  Error 1
<raphink> pbuilder: Failed autobuilding of package
<raphink> :( :(
<raphink> what's that ?
<raphink> the package depends on python-dev (>=2.3)
<raphink> and I saw it install
<raphink> :s
<Kyral> Damn there are a lot of updates
<Kyral> This prelink is gonna HURT
<raphink> grrr FTBFS
<raphink> and I don't get why!
<Kyral> it tells you
<raphink> yes it tells me
<raphink> Python development libraries required
<Kyral> yah
<raphink> but they are installed
<raphink> so it doesn't help
<Kyral> dlocate -S Py-Finalize?
<raphink> nothing
<raphink> :
<raphink> :s
<raphink> do you think this is a bug with python dev ?
<lucas> wow
<lucas> apt-cache is sooooo broken
<lucas> I mean apt-cache depends and apt-cache rdepends
<Kyral> broken in a good way or?
* lucas has to read the code
<lucas> it's not believable
* lucas must be missing sthing
<Kyral> lucas calm down
<Kyral> breath
<Kyral> broken good or broken bad
<lucas> apt-cache --important --recurse depends amavisd-new |less
<Kyral> ...?
<lucas> see how it ends up listing ruby as a recursive dependancy
<Kyral> on?
<lucas> amavisd-new suggests apt-listchanges
<lucas> apt-listchanges depends on ruby
<lucas> so amavisd-new "recursively-depends" on ruby
<lucas> even if there's a suggest in between
<raphink> I don't get what's wrong with this python stuff :s
<ajmitch> raphink: it is in python2.4-dev, really
<raphink> ajmitch: ok so python2.4-dev is broken?
<lucas> [22:55:47]  <raphink> the package depends on python-dev (>=2.3)
<lucas> does it build-dep or dep on it ?
<raphink> build-dep lucas
<raphink> and I checked pbuilder was installing it
<ajmitch> raphink: no it's not broken
<ajmitch> raphink: your package is the one that is broken
<raphink> hmm
<raphink> ajmitch: does that mean I have to patch configure?
<lucas> somebody good at perl here ?
<ajmitch> raphink: you do what is needed to fix it cleanly
<raphink> ok
<lucas> I'd need a very small patch to apt-rdepends
<lucas> but my perl really sucks
<lucas> nobody knowing even basic perl here ?
<hyakuhei> how basic?
<LaserJock> man, I wish there was a #ubuntu-advanced or something
<raphink> hmm
<lucas> for my $opt (@configoptions) {
<lucas>   my $o;
<lucas>   my $v;
<lucas>   ($o, $v) = split(/\=/,$opt,2);
<raphink> my pb seems to come from the transition python2.3 -> python2.4
<lucas> how can I write this in a cleaner way ? :)
<raphink> debian hasn't gone through the python2.4 transition yet?
<hyakuhei> 2.4.2 in ubuntu breezy
<raphink> hmm
<raphink> FTBFS on sid too
<raphink> :s
<lucas> seems strange that a package that FTBFS is in debian
<raphink> well the merged one from MoM
<raphink> is FTBFS on sid
<raphink> checking for Py_Finalize in -lpython2.3... no
<raphink> checking for Py_Finalize in -lpython2.3... (cached) no
<raphink> checking for Py_Finalize in -lpython2.3... (cached) no
<raphink> configure: error: Python development libraries required
<raphink> make: *** [config.status]  Erreur 1
<raphink> debuild: fatal error at line 768:
<raphink> dpkg-buildpackage failed!
<raphink> (sid)
<raphink> ;)
<raphink> in my sid chroot
* lucas double-checking (no offense)
<raphink> that I just updated
<raphink> sure
<raphink> :)
<raphink> I'll try with the debian source
<raphink> and if it works I'll check the diff
<lucas> ah
<lucas> which source did you tried ?
<lucas> the MoM one ?
<raphink> yes
<lucas> never trust the MoM sources
<raphink> since the MoM source doesn't build in dapper
<raphink> I tried to build it in sid
<raphink> and it doesn't build either
<raphink> so I'll try to build the debian source in sid
<lucas> syncing means overriding local changes by using the debian source instead
<raphink> and if it works (it shoudl work) try to find where in the diff it fails
<lucas> the sources on MoM are often broken
<raphink> lucas: so what do I do?
<lucas> use the debian sources
<raphink> oh ok
<lucas> do you know how to get them ?
<raphink> I try to build the package in dapper from the debian sources?
<lucas> yup
<raphink> well I apt-get source in my sid chroot ;)
<raphink> hehe
<lucas> heh
<raphink> that works ;)
* lucas prefers to 'mdt dist-apt-get sid source wesnoth'
<raphink> and now I just have to leave the chroot and build in dapper
<raphink> hmm interesting
<lucas> (just a little advertisement for mdt)
<raphink> ;)
<raphink> not sure I'll remember it though
<raphink> :)
<lucas> syntax is 'mdt <command>'
<raphink> ok
<raphink> :)
<lucas> command here is 'dist-apt-get <distrib> <subcommand>'
<lucas> dist-apt-get means running apt-get with the apt database from <distrib>
<raphink> lucas: so if the debian source builds in dapper
<raphink> and I checked the change made in ubuntu previously was in the debian source
<raphink> it goes for sync
<raphink> right?
<lucas> exactly
<raphink> just geting sure I understand everything
<raphink> what's the use of the MoM source?
<raphink> if it's broken most of the time
<ajmitch> it's not broken most of the time
<raphink> it's just a merge suggestion?
<lucas> I use MoM because it's the easiest way to get the diffs
<ajmitch> and yes it's a merge suggestion
<raphink> hmm
<ajmitch> blindly trusting it is bad
<raphink> what exactly is the -1ubuntu1 source provided by MoM
<ajmitch> but so is ignoring it
<raphink> ?
<raphink> and how is it gotten?
<ajmitch> it's the debian & ubuntu changes merged automatically
<raphink> ok
<lucas> yup, debian source + merge patch
<raphink> ok
<raphink> where does the merge patch come?
<lucas> probably from interdiff between ubuntu and debian patches
<lucas> but not sure at all
<raphink> hmm
<ajmitch> plus some more magic
<raphink> so the easiest thing is to check first if the Debian source builds in dapper
<raphink> without a change?
<ajmitch> it's more than just a simple diff call
<raphink> and then check if the previous patches from ubuntu were merged
<raphink> ?
<ajmitch> I'd check the source first
<lucas> raphink: no, the first check the changelogs
<lucas> to know what happened
<lucas> then, the source, to know exactly what happened :)
<raphink> ajmitch: what source?
<raphink> ajmitch: the debian one? the ubuntu one? the mom one?
<ajmitch> I go for the ubuntu debdiff first
<ajmitch> looking at the changelog
<ajmitch> and see what is in the merge debdiff
<lucas> ah, /me prefers to go second for the debian debdiff
<ajmitch> I look at that last :)
* raphink is confused
<lucas> or directly the debian source, depending on the complexity of the changes
<lucas> raphink: both are corrects, and you might prefer a third solution
<ajmitch> sigh, this laptop doesn't go into native resolution on a breezy install
<ajmitch> what a pain
<raphink> I guess I just have to find my way
<raphink> the thing is that I really have to understand all the steps anyway
<raphink> to not forget one
<lucas> well, when you have understood everything, just add/improve MOTUMerging
<raphink> sure
<raphink> :)
<raphink> lucas: ok now looking in the _real_ debian source (instead of mom) and understanding a bit better (hopefully) what's going on, I see that the -t stuff in wesnoth-data.install was NOT merged in Debian
<raphink> ;)
<lucas> :-)
<raphink>  $ grep scenario  wesnoth-data.install
<raphink> debian/tmp/usr/share/games/wesnoth/data/scenarios/multiplayer
<raphink> debian/tmp/usr/share/games/wesnoth/data/scenarios/tutorial
<lucas> then check if you can reproduce the bug
<raphink> so that means we need to apply it again
<raphink> ;)
<raphink> I guess
<lucas> (maybe it was fixed in another way)
<lucas> if it isn't, prepare the merge
<raphink> hmm
<raphink> you mean compiling the package and checking if -t works?
<lucas> yes
<raphink> ok
<raphink> it's building in my pbuilder rightnow
<raphink> long build ;)
<raphink> 43MB sources
<raphink> so I'll go prepare a tea while it's building
<lucas> and don't forget to read https://wiki.ubuntu.com/ContributingToDebian to know how to report the bug to debian (if not already reported)
<raphink> :)
<lucas> so next time, you can do a sync instead of a merge
<raphink> mhm
<raphink> lucas: I wrote this page with you, so I read it several times already ;)
<lucas> yep I know, but I'm just playing a personal game of mentioning as often as possible here :)
<lucas> also, make sure to put as much info as possible in the changelog (launchpad bug number, debian bug number). So next time it's much easier to understand what was the bug, and check if it was fixed in debian.
<raphink> ok
<raphink> pfiew huge work ;)
* lucas did his first patch to apt-rdepends today
<raphink> :)
<Kyral> gah....beagled is still busted
<raphink> lucas: faster way : installing wesnoth in my sid chroot and testing -> unknown scenario 'test'
<lucas> works too, but what if the bug was caused by ubuntu, not debian ?
<raphink> I don't think so
<raphink> it's just linking to a campaign named root
<lucas> (a bug which only shows up on ubuntu, not on debian)
<raphink> or so
<raphink> and if it doesnt work in the sid chroot
<raphink> I doubt it works in a real sid
<lucas> yeah I know, it was just to mention that
<lucas> it's just better to check on dapper
<lucas> depending on the fixes, it might not be necessary
<raphink> yes but while it's compiling in dapper
<lucas> ah ok
<raphink> at least I can check that it doesn't work in sid
<lucas> yes, true
<lucas> so it allows you to file a better bug in debian too :-)
<lucas> what's the LP bug id of the missing scenario bug ?
<lucas> (or URL)
#ubuntu-motu 2006-01-11
<raphink> lucas: ok finished building the debian source in dapper
<raphink> it builds but still has the -t issue
<raphink> so going for a merge?
<lucas> yep
<raphink> ;)
<raphink> what do I do?
<lucas> file the bug in debian now, so you can include its number in the changelog without waiting
<raphink> hmm ok
<raphink> I shall first see if there's a but in LP ?
<lucas> in the BTS
<raphink> yes but I should first find the ubuntu bug, no?
<lucas> (and LP, too, but the bug number in LP was probably mentionned in the ubuntu patch)
<lucas> yes
<lucas> also, when you have a debian bug number, attach it to the LP bug
<lucas> (if you find one)
<raphink> malone #1213
<Ubugtu> Malone bug 1213: "wesnoth option -t does not work (error: "Unknown scenario: 'test'")" Fix req. for: wesnoth (Ubuntu), Severity: Minor, Assigned to: MOTU, Status: Fixed http://launchpad.net/bugs/1213
<raphink> thank you Ubugtu
<raphink> :)
<lucas> so you see, if Benjamin Montgomery had reported the bug to debian, it would have saved you a lot of time
<lucas> oops
<lucas> the bug was reported to debian
<lucas> shame on the DD
<raphink> I don't see it on the Debian BTS
<raphink> :s
<raphink> I'm on http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=wesnoth&archive=no&version=&dist=unstable
<lucas> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337834
<Ubugtu> Debian bug 337834: "missing test scenario file" Package: wesnoth-data, Version: wesnoth-data/1.0.1-1., Severity: minor, Maintainer: Isaac Clerencia  http://bugs.debian.org/337834
<lucas> filed against wesnoth-data
<raphink> oh it's on wesnoth-data that's why
<raphink> ;)
<lucas> the BTS makes a distinction between binary packages and source packages
<raphink> hehe
<raphink> ok
<raphink> so what do I do if it was reported already?
<raphink> shout on isaac on IRC ? ;)
<lucas> http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=wesnoth for the src package
<raphink> ok
<lucas> you can try that
<raphink> haha ok
<lucas> I'm wondering
<raphink> what?
<lucas> it would probably better to use a wildcard, no ?
<lucas> debian/tmp/usr/share/games/wesnoth/data/*
<lucas> or something
<raphink> hmm maybe
* lucas has to check the .install file syntax
<raphink> unless there are things not to be installed
<raphink> * is fine in a .install
<raphink> it works
<raphink> it could be debian/tmp/usr/share/games/wesnoth/data/*.cfg
<raphink> unless isaac meant to not install all of them
<raphink> willingly
<lucas> worth checking
<lucas> listing the files like that is very error-prone
<raphink> yes
<raphink> very likely to miss one
<raphink> hmm
<raphink> he's not answering
<raphink> :s
<raphink> lucas: ok, since this was reported on both LP and D BTS already I guess I shall just go on with merging?
<lucas> yes
<lucas> but in the changelog, mention as much info as possible
<lucas> :-)
<lucas> very important
<raphink> note that I'll be the second mergers reactivating this bug
<raphink> the bug was reported in Debian by benjamin
<lucas> yes, this sucks
<raphink> so its an old bug we have to merge each time
<lucas> the debian maintainer is not helpful
<lucas> buxy wouldn't be happy ;)
<raphink> he's not helpful to debian users either ;)
<raphink> I talked with buxy yesterday
<raphink> that was funny
<lucas> funny ?
<raphink> because I thought I wanted to talk to Raphael Hertzog
<raphink> because he's a french guy involved in Debian and I thought he could advice me about some stuff
<lucas> ah :)
<raphink> so I searched for his nick on freenode
<raphink> and found out that he was buxy
<lucas> hehe
<raphink> and that we had just had a conversation 2 hours before
<lucas> where do you know him from ?
<raphink> ;)
<raphink> that's funny ;)
<raphink> we had a conversation with him here yesterday
<raphink> you were here
<raphink> ;)
<lucas> yeah, but I mean, before
<raphink> iirc
<raphink> apart from that well he's quite famous
<lucas> you were at RMLL last year ?
<lucas> he gave a good talk about Debian QA
<raphink> I have a project on alioth that had to go through him
<raphink> no
<raphink> the only deb conf I went to was in spain, in may
<raphink> a debian-custom conf
<lucas> go this year :-)
<raphink> where I met mark, presenting edubuntu
<azeem> lucas: where is it this year?
<raphink> well
<raphink> I haven't got money lucas
<lucas> RMLL is Rencontres Mondiales du Logiciel Libre
<raphink> if I had a job I would go maybe
<lucas> azeem: Nancy
<lucas> east of france
<azeem> ah, Dijon was PITA to get at
<raphink> ok
<raphink> will you be there lucas ?
<raphink> lucas: are you going to Paris in the end of the month?
<lucas> Nancy shouldn't be much better ;)
<raphink> to the Solution Linux salon ?
<lucas> I'll be in RMLL
<azeem> bah
<lucas> (probably)
<raphink> not in SL ?
<lucas> I won't go to solutions linux
<raphink> when is RMLL?
<lucas> I might go to FOSDEM
<raphink> FOSDEM?
<lucas> beginning of july, probably
<raphink> ok
<raphink> I'll see then
<raphink> now to merge this #@ bug
<raphink> ;)
<raphink> what shall I do ?
<raphink> merge the debian/changelog first ?
<lucas> yes
<raphink> lucas: shall I take the debian/changelog from MoM, put my name on it and describe my merge ?
<lucas> and add an entry
<lucas> yes
<raphink> this is what I'll do
<lucas> take the ubuntu one
<lucas> then use dch to add an entry
<raphink> I'll take the debian source, put the MoM debian/changelog in it, change the last entry to add my changes
<raphink> and make the changes
<raphink> is that fine?
<lucas> no, you have to add an entry, not change it
<raphink> the result is the same as ubuntu changelog + dch I guess
<raphink> I'm pretty sure its' the same but ok
<raphink> so I take the debian source
<lucas> no, you need to keep the old ubuntu entry
<raphink> put the ubuntu debian/changelog in it
<raphink> and dch
<lucas> basically, at the end, you get a changelog with 2 ubuntuX entries
<raphink> lucas: the MoM changelog has the ubuntu entries
<raphink> huh?
<lucas> yup I know
<lucas> (and the rest of it)
<lucas> well, do it
<raphink> why?
<lucas> I'm sure it'll be fine
<lucas> do what you think ;)
<raphink> no no wait
<lucas> you get:
<lucas> 1.1-1ubuntu1
<lucas> 1.1-1
<lucas> ...
<raphink> yes
<lucas> 1.0.2-1ubuntu1
<raphink> so there's just one ubuntu entry
<lucas> 1.0.2-1
<lucas> etc
<raphink> in the end
<lucas> to add
<lucas> well
<lucas> :()
<lucas> :-)
<raphink> I mean
<raphink> if I take the ubuntu changelog, it'll miss the new debian version
<raphink> which is required
<raphink> since I'm merging
<lucas> just cook something that works ;)
<raphink> the mom changelog on the other hand has both debian and ubuntu changes
<raphink> ok
<raphink> I'll do that :)
<raphink> I'll get the source again, since I built it and don't want to check if it's very very clean ;)
<lucas> when you say "mom changelog", I don't know which one you mean
<raphink> I mean the one I get when I extract the mom source package
<lucas> oh
<raphink> dpkg-source -x package-1ubuntu1.dsc
<lucas> I never use it
<raphink> provided by mom
<raphink> there's a changelog in this one
<raphink> made by mom
<raphink> why?
<lucas> ok, you can do that
<raphink> it contains both debian and ubuntu changes
<raphink> merged
<lucas> well I dunno ;)
<raphink> so it's complete
<raphink> I'll show you
<lucas> there's probably a lot of ways to reach the same point, anyway
<raphink> this is what it contains : http://ubuntu.pastebin.com/492591
<raphink> (the changelog generated by mom)
<raphink> seems to me that I just have to either replace the mom entry by mine manually
<raphink> or remove it and dch
<raphink> no?
<lucas> isn't dch able to update it instead ?
<lucas> I'm not a dch guru
<raphink> hmm
<LaserJock> raphink: just use MoM's changelog and edit it
<raphink> hehe
<raphink> nm
<raphink> LaserJock: ok that's what I thought :)
<LaserJock> but use dch
<LaserJock> I think dch -a or dch -e does what you want
<LaserJock> dch -a is right
* ajmitch never uses dch
<raphink> why use dch ?
<raphink> I can change it manually
<LaserJock> ajmitch: why not?
<raphink> putting my name, email add and date is not that hard ;)
<ajmitch> LaserJock: because I never have the need?
<LaserJock> raphink: dch -a is easier for me
<raphink> for you ;)
<LaserJock> ajmitch: you do it all by hand?
<ajmitch> no, I use emacs with its debian-changelog-mode
<ajmitch> which may use dch behind the scenes
<raphink> oh ok
<raphink> I do it all by hand :)
<LaserJock> ajmitch: ahh, ok. I don't use emacs that much anymore
<raphink> and I'm happy so far:)
<ajmitch> it's faster for me to use emacs than dch
<LaserJock> I wonder if vim has something similar?
<ajmitch> possibly
<tseng> dch uses vim properly
<tseng> it opens a new line starting with * after the heading and before the byline thingy
<raphink> lucas:
<raphink>   * Resynchronise with Debian.
<raphink>     - Restore scenario-test.cfg for -t switch
<raphink>       (Closes: Malone #1213)
<Ubugtu> Malone bug 1213: "wesnoth option -t does not work (error: "Unknown scenario: 'test'")" Fix req. for: wesnoth (Ubuntu), Severity: Minor, Assigned to: MOTU, Status: Fixed http://launchpad.net/bugs/1213
<raphink> I just put it again
<lucas> add the debian bug #
<raphink> ok
<raphink> how do I name it ?
<raphink> Debian bug: # ...
<raphink> ?
<lucas> yes, for example
<lucas> also, I would add
<Kyral> whee bug reporting time
<raphink> ok
<Kyral> gnome-schedule
<lucas> "in debian/wesnoth-data.install"
<lucas> somewhere
<raphink>  * Resynchronise with Debian.
<lucas> the more info you put now
<raphink>     - Restore scenario-test.cfg for -t switch
<raphink>       (Closes: Malone #1213 & Debian bug #337834)
<Ubugtu> Malone bug 1213: "wesnoth option -t does not work (error: "Unknown scenario: 'test'")" Fix req. for: wesnoth (Ubuntu), Severity: Minor, Assigned to: MOTU, Status: Fixed http://launchpad.net/bugs/1213
<Ubugtu> Debian bug 337834: "missing test scenario file" Package: wesnoth-data, Version: wesnoth-data/1.0.1-1., Severity: minor, Maintainer: Isaac Clerencia  http://bugs.debian.org/337834
<raphink> like that?
<raphink> ok
<lucas> the less time you spend next time
<raphink> yes
<lucas> - Restore scenario-test.cfg for -t switch in debian/wesnoth-data.install
<lucas> actually it doesn't really closes the debian bug
<lucas> just add "see debian bug #337834"
<Ubugtu> Debian bug 337834: "missing test scenario file" Package: wesnoth-data, Version: wesnoth-data/1.0.1-1., Severity: minor, Maintainer: Isaac Clerencia  http://bugs.debian.org/337834
<raphink> ok
<raphink>   * Resynchronise with Debian.
<raphink>     - Restore scenario-test.cfg in debian/wesnoth-data.install so that -t switch
<raphink>       will work.
<raphink>       (Closes: Malone #1213 ; see Debian bug #337834)
<Ubugtu> Malone bug 1213: "wesnoth option -t does not work (error: "Unknown scenario: 'test'")" Fix req. for: wesnoth (Ubuntu), Severity: Minor, Assigned to: MOTU, Status: Fixed http://launchpad.net/bugs/1213
<Ubugtu> Debian bug 337834: "missing test scenario file" Package: wesnoth-data, Version: wesnoth-data/1.0.1-1., Severity: minor, Maintainer: Isaac Clerencia  http://bugs.debian.org/337834
<raphink> lucas: fine for you?
<lucas> perfect
<raphink> ;)
<raphink> now do I patch or change manually?
<lucas> now, don't forget to change debian/wesnoth-data.install
<raphink> it's just one line to patch so I guess I can do it manually ;)
<lucas> you can change manually I'd say ;)
<raphink> hehe
<lucas> then rebuild, then test
<raphink> done
<raphink> ok rebuilding then :)
<raphink> debuild -S -sa
<raphink> then with the pbuilder
<raphink> I guess ;)
* raphink prefers to ask stupid questions the first time to not ask them too late ;)
<lucas> no problem :-)
<lucas> yes, both, or just pbuilder
<raphink> just pbuilder is enough imo
<lucas> what we are doing here is the canonical way
<raphink> if it builds in pbuilder, it builds in my trashy system
<raphink> ;)
<lucas> there might be some shortcuts you can take for some packages
<lucas> when you are very sure about your changes
<raphink> yes I guess
<raphink> well I always prefer to check my work
<raphink> I check the work of others on REVU through these steps
<raphink> so I wouldn't be honest not checking it the same way for my own packages ;)
<lucas> :-)
<raphink> + this is quality assurance
<raphink> and I prefer to spend time checking before uploading
<raphink> than correcting bugs afterwards, when you don't remember what you did
<raphink> ;)
<raphink> because I'm lazy ;)
<seth_k|lappy> hi raphink, how is your merge coming?
<raphink> and lazy people work better to not have to work again
<raphink> seth_k|lappy: almost done I think
<raphink> it's rebuilding
<raphink> seth_k|lappy: but it's a 43MB source so it takes some time to build ;)
<seth_k|lappy> haha yes
<raphink> my flat is freezing
<raphink> :s
<raphink> or well I'm freezing in my flat rather
<raphink> :s
<seth_k|lappy> hehe
* seth_k|lappy hugs nafallo for merging in the new mysql-query-browser
<seth_k|lappy> now my life can continue
<raphink> hehe
* raphink needs to upgrade his shelf 
<raphink> Error : shelf too small for all trousers and pull-overs
<seth_k|lappy> is that a stack overflow error?
<seth_k|lappy> :P
<raphink> yes it seems
<raphink> :(
<raphink> I shall not use extended pull-overs
* raphink suspected his new trousers are floating points ones
* raphink thinks he should go to bed soon 
* raphink is still waiting for wesnoth to build
<raphink> lucas: package built in pbuilder, installed, tested
<raphink> working :)
<raphink> now to find a MOTU to upload it?
<lucas> no, put the debdiff in the bug report, and assign to motureviewers
<lucas> maybe lpbugs does that for you
<raphink>  $ debdiff wesnoth_1.1-1.dsc wesnoth_1.1-1ubuntu1.dsc
<raphink> ?
* lucas never remembers exactly what lpbugs does
<slomo> yes
<lucas> ues
<lucas> yes
<raphink> :)
<psusi> is there anyone around who can fix up my gpg key to have access to upload to revu?
<raphink> so I just
<raphink> ./lpbugs.py -u -b <bugid> -p
<raphink> and it will ask me to join the debdiff ?
<lucas> psusi: siretart or sistpoty, but they are both away
<lucas> never used that ;)
<lucas> maybe you must attach the debdiff manually
<raphink> ok
<psusi> blast...
<raphink> I'll see what it tells me
<slomo> psusi: ajmitch can do it too
<lucas> http://tiber.tauware.de/~lucas/versions/
<lucas> finished
* ajmitch can?
<psusi> slomo, is he around?
<psusi> that answered my question, but made it pointless ;)
<slomo> ajmitch: i thought you were in the tiber admin team? ;)
<ajmitch> yeah I am
<ajmitch> I can add users to revu
<ajmitch> if needed
* psusi sent in his gpg key for revu access the other day... could use some help
<psusi> ok... I sent in the email the other day like the wiki said to... do you need me to send it to you now?
<ajmitch> sure, I'll take a look
<ajmitch> psusi: please upload your key to a keyserver
<raphink> do I check the patch box if I attach a debdiff ?
<ajmitch> yes
<raphink> ok :)
<raphink> logical, but yet I prefer to ask
<ajmitch> well that dapper upgrade was successful
<psusi> ok... I think I just uploaded it to ubuntu's keyserver
<ajmitch> not there yet
<raphink> lucas: merge done ? :)
<psusi> gpg --send-keys --keyserver keyserver.ubuntu.com < that's all I need to do right?
<psusi> it seems to complete really fast
<psusi> with no output
<psusi> returned 0 though
<lucas> raphink: looks like :) congratulations :-)
<raphink> lucas: I have to mark it as pending upload now?
<lucas> yes, and assign it to motureviewers
<raphink> manually?
<raphink> done :)
<lucas> if lpbugs didn't do it for you, yes
<raphink> and now I need to try it really
<raphink> anybody wants to test wesnoth on a 1vs1 with me ?
<raphink> hehe
<lucas> I never played
<lucas> and it's a bit late
<raphink> it's a nice game :)
<raphink> don't you want a short game ? ;)
<raphink> hehe
<lucas> ah, you aren't finished yet
<lucas> put the merge on your wiki homepage
<lucas> (see mine)
<raphink> done lucas ;)
<lucas> ah
<raphink> 10 minutes ago
<ajmitch> psusi: gpg --keyserver keyserver.ubuntu.com --send-keys 8b3e5ee2
<lucas> I didn't check
<raphink> http://wiki.ubuntu.com/RaphaelPinson
<raphink> I always keep my wikipage up-to-date
<psusi> ajmitch, aha... that looks like it did something
<raphink> et wesnoth a dchire lucas :)
<lucas> I should try some day
<raphink> ok
<raphink> haha
<raphink> we're 7 players on the wesnoth 1.1 server
<raphink> bad thing about updating ;)
<seth_k|lappy> raphink, did lucas walk you through merging in this channel?
* seth_k|lappy will read the log if so to find out best way to do it
<raphink> yes seth_k|lappy
<raphink> :)
<seth_k|lappy> grood
<raphink> very grood
<raphink> sorry
<raphink> I meant vey grood ;)
<lucas> raphink: please update MOTUMerging or write a new page about what you understood
<psusi> ajmitch, can you see the key yet?
<lucas> MOTUMerging doesn't look very good currently
<raphink> lucas: ok
<raphink> you're saving me from testing the changes in wesnoth ;)
<lucas> hehe
<ajmitch> psusi: yes, done
<psusi> awesome... thanks
<LaserJock> when is a control file created from a control.in ?
<psusi> hrm... looks like the dput worked... does it usually take a few for it to show up on the web site?
<ajmitch> yes
<ajmitch> make sure you only upload source packages
<psusi> aye
* StevenK ponders requesting moin be synced.
<StevenK> Ubuntu's changes mostly change what packages are built for some reason.
<slomo> StevenK: do you have some time for sponsoring now? :)
<StevenK> Probably.
<LaserJock> do I have to change both debian/control and debian/control.in ?
<StevenK> slomo: Point me at the URL?
<slomo> StevenK: http://slomosnail.de/~slomo/debian/unstable/fatsort/
<slomo> StevenK: nothing too great... but well ;)
<psusi> ahh, sweet: http://revu.tauware.de/details.py?upid=1400
<Amaranth> LaserJock: just control.in, then regenerate the control file
<LaserJock> Amaranth: how do I do that?
<Amaranth> LaserJock: ./debian/rules
<raphink> lucas: what's your command to get the debian source again?
<LaserJock> Amaranth: so shouldn't debuild do it?
<lucas> mdt dist-apt-get sid source wesnoth
<Amaranth> i don't think so
<lucas> after creating 'sid' with mdt dist-create
<Amaranth> LaserJock: cdbs, right?
<raphink> thanks
<LaserJock> Amaranth: I didn't think so
<Amaranth> good luck then :P
<Amaranth> i thought only cdbs did the control.in stuff
<LaserJock> man this sucks
<LaserJock> I just wanted to get one more merge in
<LaserJock> and then I see that the Debian source that the ubuntu1 version comes from isn't around so MoM used a previous version
<LaserJock> so the debdiffs are ~ 1.5 Mb
<LaserJock> and now I gotta change control
<seth_k|lappy> If upstream author ships debian/ inside their source package, is it acceptable to change the orig tarball to remove it (so I don't build a native package)?
<raphink> seth_k|lappy: states so in debian/changelog
<seth_k|lappy> of course :)
<raphink> lucas: are you following my changes on MOTUMerging?
<lucas> no
<lucas> I'll read them tomorrow
<raphink> ok
<lucas> too tired now, I have to go to bed
<lucas> gnight
<raphink> ;)
<raphink> just to know ;)
<raphink> night
<LaserJock> ok, I found a debian/control rule ind debian/rules but I don't know what to do with it
<slomo> it updates debian/control for you... just call make -f debian/rules debian/control to update debian/control
<LaserJock> slomo: ok, thanks
<slomo> it gets it's informations from debian/control.in most of the time... but better look at it more closely ;)
<LaserJock> hmm, now it says that it is up to date but it's not
<LaserJock> I really wish I hadn't started this merge :(
<psusi> god damnit, why can I never get xargs to work right with {} substitution?  xargs echo {} bar ; then entering foo gives "{} bar foo" instead of "foo bar"
<psusi> what am I doing wrong?  it should work according to the man page
<raphink> pfff
<raphink> ajmitch: could you review my doc and tell if anything is wrong please?
<raphink> thanks \sh_away
<raphink> \sh: would you mind reviewing my changes to MOTUMerging?
<\sh> right now I'm trying to figure out some buildd bugs...
<raphink> ok
<jsgotangco> nice new wesnoth
<raphink> yes :)
<raphink> after building it, I went online to test it
<raphink> but only 7 people were using this version ;)
<raphink> so far
<jsgotangco> ohhh
<jsgotangco> i'll grab it when it hits the archives
<raphink> :)
<raphink> soon enough, it was just uploaded :)
<\sh> hehe :)
<Burgundavia> watch productivity wall
<Burgundavia> s/wall/fall
<raphink> :)
<StevenK> Maybe sbuild needs to be configured to only build wesnoth if we are 2 days from release. :-P
<raphink> StevenK: heh I was asked to do this merge :p
<raphink> StevenK: be happy this merge was not done 2 days from release ;)
<\sh> gnarf i'll fix wesnoth for amd64
<\sh> whereever the patches went...it's failing
<SEJeff> psusi, are you using xargs with find?
<psusi> nope... just like I showed it... xargs echo {} bar <enter>
<psusi> type in foo <enter> then a ctrl-d and it comes out "{} bar foo"
<psusi> why is it that packages on revu don't appear to contain the .orig.tar.gz?
<\sh> psusi: what?
<\sh> if i have a look e.g. on http://revu.tauware.de/details.py?upid=925 i see the orig.tar.gz
<psusi> hrm... it isn't there in mine for some reason: http://revu.tauware.de/details.py?upid=1400
<seth_k|lappy> psusi, eek, you uploaded a debian-native package
<\sh> well u uploaded a native package
<psusi> what's that mean?
<seth_k|lappy> it means that it isn't split into orig and diff, the debian/ dir is inside the tarball
<\sh> psusi: see seth_k|lappy
<seth_k|lappy> psusi, name your original tarball foo_X.Y-Z.orig.tar.gz
<psusi> how did it get like that?  I did a debuild -S from inside the modified source dir, then dput on the .changes
<\sh> psusi: further more...the numbering is not correct
<psusi> I have the .orig.tar.gz
<psusi> what is wrong with the numbering?
<\sh> psusi: first of all fix the numbering it must be 1.0.0b3-11ubuntu1
<seth_k|lappy> psusi, it probably isn't numbered exactly like the version number (should be 11ubuntu1, not 11-ubuntu1)
<\sh> psusi: secondly check that the orig.tar.gz is named udftools_1.0.0.b3.orig.tar.gz
<psusi> ohh... don't put the - between the old rev and the ubuntu1?
<\sh> psusi: and the name of the source dir has to be udftools_1.0.0b3
<\sh> psusi: and the name of the source dir has to be udftools-1.0.0b3
<\sh> sorry
<psusi> \sh, that's it's name
<psusi> yep... that's all how it is
<\sh> psusi: change the numbering :)
<psusi> I guess I'll remove the - before ubuntu1
<Burgundavia> Riddell, is our first female motu? should we start celebrating now?
<seth_k|lappy> Burgundavia, yeah, Hobbsee's the first one to ever upload to Ubuntu I think :P
<Burgundavia> nice
<psusi> ok, uploaded
<psusi> hrm... I think I confused revu
<seth_k|lappy> psusi, hehe.
<\sh> psusi: http://revu.tauware.de/details.py?upid=1401
<seth_k|lappy> I would say so... no orig, and two diff's
<\sh> what?
<\sh> a female motu?
<psusi> it's very confused
<\sh> a she-ra?
<psusi> is there any way to nuke the entry and start over from scratch?
<\sh> Version: 1.0.0b3-11ubuntu1
<\sh> Binary: udftools
<\sh> Maintainer: Richard Atterer <atterer@debian.org>
<\sh> hmm?
<psusi> it's a source upload, not binary
<seth_k|lappy> not an MOTU \sh, but an uploader at least. Hobbsee just uploaded a patch for ksudoku, and Burgundavia commented that she was perhaps the first female ever
<\sh> psusi: well..the package is already in ubuntu...
<psusi> \sh, right... I fixed some bugs
<\sh> psusi: what you want is not uploading to revu, you want to merge :)
<psusi> I got the existing source package and patched it, now I'm trying to package that as a new ubuntu specific version ( since the old one was synced directly from debian )
<\sh> psusi: well..it will be synced automagically during the next round
<\sh> all packages which are synced from debian and never touched by ubuntu people will be synced again automatically by elmos auto-sync script
<\sh> which runs at least 2-4 times a week
<psusi> no no... I don't want it to be sycned
<psusi> I have made changes
<\sh> psusi: so file a merge bug with lpbugs (see https://wiki.ubuntu.com/MOTUMerging)
<psusi> I did an apt-get source, entered the directory, fixed some bugs in the source, bumped the rev with dch, then did debuild -S
<\sh> well...then file a bug on udftools in malone and send a debdiff as attachment and ping me when you are done :)
<\sh> psusi: and give me the malone bugnumber
<psusi> hrm... I wanted to put it on revu first to make sure I did it right ;)
<\sh> revu should only be a tool for really "NEW" packages :)
<\sh> psusi: well...I'll check it anyways :)
<psusi> ohh
<\sh> what you do is: apt-get source udftools
<psusi> ok, I thought it was just a place for motu's to put up their packages to be reviewd before they were ready for prime time
<\sh> change your things
<\sh> psusi: if you do some fixes or changes which are important but concerning a package which is already in the archives, we file bugs :)
<\sh> and attaching debdiffs
<\sh> put a changelog entry in debian/changelog
<\sh> debuild -S
<\sh> and then
<\sh> debdiff debian-version.dsc ubuntu-version.dsc > debian_to_ubuntu.debdiff
<\sh> i wonder now, why gnuradio-core wants to install all libs into /usr/lib64 and not in /usr/lib on amd64
<psusi> ok... so who will review the bug since it doesn't have an ubuntu maintainer?
<\sh> -ESTRANGE
<\sh> psusi: file it under udftools in malone...and give me the bug number
<\sh> psusi: I'll take care as soon as you are ready :)
<psusi> hrm... ok... if you want to look at it now to let me know if I packaged it right, I'll do that... otherwise, I think I want to do some more work on it... get it integrated with hal so you don't have to manually configure it
<psusi> should be as automagic as possible
<\sh> psusi: did you do a debuild -S -sa or only debuild -S when you uploaded to revu the second time?
<psusi> unfotunately, I can't figure out why hal won't call my callout script to play with the cdrom device
<psusi> debuild -S every time
<\sh> psusi: please do a source upload with debuild -S -sa (-S is sign only and it will only the .dsc and .diff.gz uploaded not the orig.tar.gz)
<nalioth> howdy
<psusi> hrm... what's debuild -sa do with the .orig.tar.gz? it exists already from when I did an apt-get source on the original package
<ajmitch> hi nalioth
<seth_k|lappy> \sh, after that if you aren't busy, would you mind looking at kde-style-klearlook for me? :) http://revu.tauware.de/details.py?upid=1395
<LaserJock> would there be a way to send emails to MOTUs who have advocated a package on REVU when the package has been updated? Or is that just stupid
<LaserJock> I guess maybe that the revu ML does that already
<\sh> seth_k|lappy: on it
<seth_k|lappy> \sh, thanks a lot!
<nalioth> 'nother newbie question: i'm running "dpkg-scanpackages binary /dev/null | gzip -9c > binary/Packages.gz" in my repo dir, but now i have powerpc and i386 packages in it. and only one or the other is showing up in Packages.gz
<\sh> seth_k|lappy: is it klearlook or klearlooks? because the gtk engine is named clearlooks:)
<nalioth> it works fine with just one arch pkg
<seth_k|lappy> \sh, http://kde-look.org/content/show.php?content=31717 says Klearlook :)
<seth_k|lappy> nalioth, you need to put them in separate places methinks... I think the trivial repo only works with one arch
<nalioth> seth_k|lappy: i tried it with binary/x86 and binary/powerpc, but still only got one listed in Packages.gz
<nalioth> but not a problem at all, i'll go fix it
<seth_k|lappy> nalioth, checking
<seth_k|lappy> nalioth, http://www.us.debian.org/doc/manuals/repository-howto/repository-howto.en.html
<seth_k|lappy> the first example is the one you want, I think. It has binary-arch stuff
* Hobbsee waves at psusi and \sh - hello!
<nalioth> seth_k|lappy: thanks
* psusi dances
<ajmitch> psusi: it worked?
<seth_k|lappy> nalioth, man dpkg-scanpackages suggests making "binary-i386" "binary-ppc" etc., then calling dpkg-scanpackages for each one.
<\sh> good morning Hobbsee
<ajmitch> hello Hobbsee, \sh, et al :)
<Hobbsee> hey ajmitch
<psusi> ajmitch, eh?
<psusi> I was dancing with Hobbsee
<ajmitch> psusi: the dancing?
<ajmitch> oh right
<seth_k|lappy> he couldn't do that before, because we didn't have any girls
<Hobbsee> hehe
<\sh> seth_k|lappy: you got my vote
<psusi> I'm still trying to figure out hall callouts to get udftools to automagically detect and configure your cdrw
<seth_k|lappy> \sh, thanks a lot for your review :)
<\sh> very very strange
<\sh> why does configure find the GL lib in a chroot but not in a pbuilder...but it's there
<Hobbsee> psusi: only one problem with that - i dont dance :P
<psusi> you can dance if you want to, you can leave your friends behind...
<psusi> ok... now I've got davie bowie on the brain
<\sh> dancing is evil...
<psusi> not according to david bowie
<GURT> not david bowie
* psusi is brain washed by david bowie
<psusi> heheh
<GURT> unless im missing something
<GURT> which i probably am
<psusi> ahhh, here's an mp3 I've not listened to in ages.... little Davie Bowie and Trent Reznor... I'm afraid of Americans...
<LaserJock> anybody feel like helping me with a wxwindows2.4 merge?
<\sh> LaserJock: what's wrong..despite the fact that i'm busy
<LaserJock> well, the Debian source that the ubuntu1 version was based on is gone so the MoM diffs are confusing
<LaserJock> I got the control.in file done but I think I might have to change stuff in debian/rules
<ajmitch> what do the changelogs say?
<LaserJock> the lates ubuntu entry was a merge + some build dep stuff (which I did) + not building wx-common, python-wxversion and python-wxtools which I'm not sure if that is done or not
<LaserJock> s/lates/latest
<LaserJock> but before that there is quite a bit of stuff as well
<LaserJock> I'm just having a hard time with figuring out what exactly was changed in the -ubuntuX versions
<LaserJock> I can find the obvious stuff in control.in but I can't seem to get control generated and rules is huge (at least for me)
<ajmitch> if you're relying on MoM's debdiff for ubuntu changes it might not be accurate
<LaserJock> right
<LaserJock> but I'm trying to figure out how to get the info
<minghua> LaserJock: it should be easy to figure out if MoM is using the correct Debian base version
<LaserJock> minghua: I know it's not
<LaserJock> minghua: but the correct Debian base version doesn't exist anymore
<nalioth> <mumble> it's all in the syntax </mumble>
<LaserJock> so MoM used the previous version to diff with
<minghua> LaserJock: not even at snapshot.debian.net?
<ajmitch> s.d.n lost a fair chunk of their archive
<LaserJock> not there either
<LaserJock> cool site though, never heard of it
<minghua> Hmm, tough luck
<minghua> what about pinging the debian maintainer to see if he has a local copy of the old version :-P
<LaserJock> I know, I am regretting starting it but somebody has to do it I guess
<LaserJock> I suppose that is a possibility but I was thinking of doing a debdiff of the current Ubuntu version and the new Debian version
<LaserJock> that might give a smaller debdiff anyway
<LaserJock> well, that got it down to 18Kb
<\sh> grmpf
<LaserJock> and it looks like except for changelog and control{.in} the 18K is from rules
<\sh> hum?
<LaserJock> \sh: are huming at me?
<\sh> LaserJock: no at me
<StevenK> Right, zakame didn't like my debdiff for linkchecker, so can someone request a sync?
<LaserJock> ok well that's ok then ;-)
<ajmitch> StevenK: why didn't he like it?
<StevenK> "Do we really need to include the translations diffs? The only Ubuntu change recorded in the changelog was about updating B-Ds on debhelper and cdbs, I think the translations are just adjustments made at buildtime which should be done automatically iirc."
<ajmitch> right..
<\sh> ajmitch: tell me, what can it be, if a configure tool finds libs properly in a chroot or on a normal system, but not in a pbuilder login or pbuilder build env?
<\sh> s/if/when/
<ajmitch> extra files, like .la, etc?
<StevenK> Missing packages in Build-Depends.
<\sh> nope
<ajmitch> what was missing?
<\sh> ajmitch: libSDL_mixer libSDL_sound and GL and GLU libs..but they are installed I checked...
<ajmitch> the -dev packages are all there?
<\sh> and on the same machine but in a chroot env it builds with the same build-deps
<\sh> ajmitch: jepp
<ajmitch> strange
* ajmitch was just heading out, too
<ajmitch> testing out the build speed of the new laptop while I'm gone :)
<\sh> new laptop?
<\sh> from canonical?
<ajmitch> no
<ajmitch> one that I got, which arrived this morning
<\sh> what new toy did you buy?
<ajmitch> it has some issues to solve for dapper
<ajmitch> acer travelmate
<\sh> ah acer..and nice?
<ajmitch> p-m 2GHz, 100GB HDD, 1GB RAM
<ajmitch> wireless is flaky, sound is broken
<\sh> oergs...half of a traveling workstation
<\sh> how many KGs?
<ajmitch> faster than my desktop box :)
<ajmitch> about 3?
<ajmitch> might be 2
<\sh> phew
<ajmitch> fairly hefty, 15.4" widescreen
<ajmitch> if I'm in a dark alley it'll make a good weapon
<\sh> my workstation doesn't even have a monitor
<\sh> dark alleys in NZ?
<ajmitch> not many here :)
<\sh> well...the hobbit dungeons ok :)
<ajmitch> haha
<ajmitch> disk is big enough to hold a few merges or unmet deps
<ajmitch> I've got britney on there to setup & calculate unmet deps
<\sh> ajmitch: give me an output for source packages this time...the last time it was more a list of binary packages ,)
<ajmitch> a list of binary packages only takes a minute to convert to source names :)
<ajmitch> it should be easy enough
<ajmitch> same tool that is used for main installibilty reports
<ajmitch> ok, I've got to go & get some food now
* ajmitch will return later :)
<\sh> have fun..I'm stopping as well now
<\sh> see you later guys and gals :)
<chillywilly> bah, I always miss ajmitchie
<seth_k|lappy> he probably leaves just before you come, because he knows you'll call him "widdle ajmitchie"
<chillywilly> that's a term of endearment dagnabbit
<BlackJudas> mythgame?  How can I get it to install?
<seth_k|lappy> Package mythgame version 0.17-1 has an unmet dep: Depends: libqt3c102-mt (>= 3:3.3.3)
<seth_k|lappy> needs patched.
<seth_k|lappy> BlackJudas, I'll try to get to it tonight
<BlackJudas> Can I do anything to help?
<BlackJudas> I've packaged for debian before :P
<BlackJudas> Well sorta.
<BlackJudas> Anyway, I'd supar appreciate that, it made me so sad... and this is my first ubuntu install.
<seth_k|lappy> hehe
<seth_k|lappy> just apt-get source foo && nano debian/control, fix the depends, pdebuild, debdiff
<seth_k|lappy> I'm looking at it now :)
<BlackJudas> Oh hot.
<BlackJudas> I'm new to ubuntu, sorry, I don't much understand official versus motu etc.
<BlackJudas> Well, from what I see, it's the wrong version that's packaged.
<BlackJudas> Needs to be 18.1
<seth_k|lappy> you're using dapper?
<seth_k|lappy> or breezy
<BlackJudas> Breezy
<seth_k|lappy> ahh
<BlackJudas> Don't know how to use dapper (no idea where the sources are)
<seth_k|lappy> we shipped it broken then, and I don't have a breezy chroot on hand
<seth_k|lappy> one sec
<BlackJudas> Fun ;)
<minghua> we shipped it broken?
<seth_k|lappy> minghua, well, if it doesn't work, I call broken :P
<BlackJudas> Yeah I saw the bug reported on the launchpad site.  Said it would be fixed in dapper a month ago, and I've been killin' myself trying to find dapper sources.
<LaserJock> BlackJudas: just replace breezy with dapper in sources.list
<minghua> seth_k|lappy: yeah, I understand the meaning.  I was just surprised
<BlackJudas> Oh, :/
<seth_k|lappy> but you don't want to upgrade to dapper right now, BlackJudas. It's unstable
<BlackJudas> Thought it was closed for some reason.
<BlackJudas> So dapper is the equivalent to sid in deb?
<BlackJudas> Ok.
<Burgundavia> BlackJudas, not really
<Burgundavia> BlackJudas, similar to etch
<minghua> BlackJudas: I would call it experimental + unstable + testing
<minghua> and at this time it's more like experimental, IMHO
<seth_k|lappy> all in one happy distro
<BlackJudas> Heh nice.
<BlackJudas> And confusing for a debian "lifer"
<BlackJudas> I feel like such a noob all over again, I can't berate people in #debian anymore :)
<LaserJock> but I use it for day-to-day use so it isn't all that bad
<Burgundavia> BlackJudas, in terms of actual code, closer to sid. In terms of process, closer to etch
<BlackJudas> Nice.
<BlackJudas> Hrrm, maybe the wrong channel to ask, but if I throw the dapper tag as another source in my sources list, can I get the linux-2.6.14 kernel image or sources?  And does ubuntu use the kernel-package utility when one wants to build their own kernel?
<Burgundavia> BlackJudas, 2.6.15 and yes
<BlackJudas> So... Would I be able to throw a 'sudo apt-get install linux-2.6.15/dapper' at the command line?
<BlackJudas> oh heh nice.
<Burgundavia> BlackJudas, Ubuntu, the DCC and Debian have very very similar kernels
<Burgundavia> and likely to get closer in terms of creation and actual code
<BlackJudas> Great, so ubuntu pulls the debian patches to the kernel as well?
<BlackJudas> This is good news for me.
<Burgundavia> http://lists.dccalliance.org/pipermail/dcc-devel/2006-January/000487.html
<BlackJudas> Kinda exciting actually.  Anyway I won't continue fouling up the airwaves in this channel.  I'll gently await seth_k|lappy to make my day even better.
<seth_k|lappy> BlackJudas, I'm getting nalioth to build it, I don't have a breezy chroot on my laptop
<seth_k|lappy> I'm at home on vacation
<BlackJudas> So forgive my ignorance (I'm too lazy for google), but what's DCC?
<BlackJudas> seth_k|lappy, Ahh, thank-you!
<nalioth> Direct Computer Connection (bypasses the ircd), if you're talking about irc BlackJudas
<BlackJudas> nalioth, :P heh
<BlackJudas> nalioth, nah, I found the definition: http://lists.dccalliance.org/mailman/listinfo/dcc-devel
<Burgundavia> D****n Common Core Alliance
<BlackJudas> Very cool idea imho, I've been out of the debian 'politics' loop for quite a while now.
<BlackJudas> I'm sure there's flaming on the debian lists about it.
* Burgundavia just laughs
<BlackJudas> =D
<seth_k|lappy> BlackJudas, building now
<BlackJudas> <o/ \o/ \o>  :) (sorry had to, cuz I am really dancing)
<seth_k|lappy> erm, BlackJudas, not to cut your dance short, but libmyth isn't even in the repos
<seth_k|lappy> I have no clue how it built the first time, let me go check buildlogs
<BlackJudas> :/
<BlackJudas> Hmm let me check.
<seth_k|lappy> blast it, it's a hoary lib
<seth_k|lappy> rebuilding that too
<seth_k|lappy> mythgame is in the repos, but it build-deps libmyth-0.17, which hasn't been in the repos since Hoary.
<BlackJudas> Gotcha.
<BlackJudas> Fun times
<seth_k|lappy> libmyth-0.18.1 is in breezy, but naliot.h is trying a 0.17 build for breezy, just in case it works
<seth_k|lappy> yeah BlackJudas, sorry, but you're outta luck. We start getting a huge dependency string
<seth_k|lappy> it'll be fixed in Dapper, which will be released in April. Or you can compile it yourself from source
<BlackJudas> seth_k|lappy, ok, I'll get it from source.
<BlackJudas> Thanks for trying.
<seth_k|lappy> sorry BlackJudas :(
<BlackJudas> Though :/ I don't understand how all the other stuff made it in :)
<seth_k|lappy> (although that way you'll get the shiny new 0.18 instead of the 0.17 in breezy)
<BlackJudas> No worries.  You tried, and I very much appreciate it.
<BlackJudas> apt-cache show mythtv (and the other fun stuff associated to it) as version 0.18.1-5
<BlackJudas> So I've got it, it's just mythgame being lame.
<ejofee> in breezy, there's flashplugin-nonfree (22.6 kb) and flashplayer-mozilla (980 kb), which i heard have similar functionality. why so huge a package file-size difference between them?!
<crimsun> ejofee: the latter is illegal and will be removed from the repo
<crimsun> ejofee: the former is a ruby-based installer that downloads the flash plugin from a macromedia-sanctioned Web site
<crimsun> (whereas the former actually violates macromedia's eula by distributing the binary plugin)
<crimsun> err, the latter^ violates[..] 
<ejofee> crimsun: but... in opera, it's only the latter that works :(
<ejofee> crimsun: that is, flash didn't work in opera until i installed flashplayer-mozilla.
<crimsun> ejofee: then it's a packaging difference. Look at debian/rules and debian/*.postinst in both packages.
<ejofee> crimsun: will this be fixed in dapper?
<crimsun> ejofee: we haven't exactly identified "the" -- if any -- problem.
<crimsun> (you need to inspect the packaging differences first)
<ejofee> crimsun: shouldn't it install automatically in such a way that it works in opera?
<ejofee> crimsun: i see
<ejofee> crimsun: that is, "(i see)"
<minghua> ejofee: if you can't identify the problem, please at least file a bug
<crimsun> ejofee: we don't even distribute Opera -- how can we anticipate its plugin path? Afaik, it's supposed to use netscape's/mozilla's/firefox's
<minghua> ejofee: just asking on IRC usually don't get problem fixed
<crimsun> note that flashplugin-nonfree and flashplayer-mozilla have different dependencies/recommends
<dholbach> good morning
<hub> morning
<dholbach> does somebody know the ircnick of PatrickDavies?
<dholbach> hey hub
<dholbach> is that jpatrick?
<whiprush> IRC: jpatrick on Freenode (#kubuntu, #kubuntu-devel and #ubuntu-motu)
<whiprush> according to the wiki
<dholbach> whiprush: merci beaucoup
<dholbach> arg, i could have looked it up myself
<whiprush> np
<dholbach> but anyway... it's nicer chatting with you ;)
<whiprush> I finally felt useful. :)
<LaserJock> hi dholbach
<dholbach> i'm just writing up the MOTU report (or adding the last bits
<dholbach> ) - hey LaserJock
<whiprush> oh cool cool
<dholbach> hub: when will you be a MOTU?
<whiprush> I will stick around for the fridge post then
<hub> dholbach: what do I need to do now?
<dholbach> hub: show up on a TB meeting?
<hub> ah
<hub> when is the next?
<dholbach> propose yourself to the ubuntu-dev team on launchpad
<hub> ok
<dholbach> and add yourself to TechnicalBoardAgenda
<dholbach> http://fridge.ubuntu.com/event should know
<hub> ok
<hub> done for the join
<raphink|sleep> dholbach: talking about the technical board, I don't think it would be a good idea for me to apply this time, only 7 days after I might be a member
<raphink> what do you think ?
<hub> dholbach: apparently the agenda link to the list on launchpad
<dholbach> raphink: yeah, maybe you better wait 2 weeks or something
<hub> dholbach: so I don't need to add myself
<raphink> mhm
<dholbach> hub: or was it MaintainerCandidates
<LaserJock> when will we start working on unmet deps? after UVF?
<raphink> dholbach: I guess I should be accepted as member on next tuesday though ;)
<dholbach> *blush* it's been a while since I became MOTU :)
<dholbach> raphink: i'll speak for you
<Burgundavia> dholbach, delivering the smackdown to Patrick MacFarland?
<raphink> dholbach: on tuesday?
<hub> dholbach: the say to not add yourself there
<hub> dholbach: so I'm good
<dholbach> Burgundavia: this is not the first time
<dholbach> raphink: http://fridge.ubuntu.com/event
<dholbach> could you all have another look at http://wiki.ubuntu.com/MOTUReportDraft and add whatever I forgot *PLEASE*
<hub> dholbach: it must be noted that I work for a "comptetitor": Xandros
<dholbach> ... while I prepare some coffee :)
<Burgundavia> dholbach, that reminds me, we need to wrestle -laptop away from him
<dholbach> hub: oh nice
<dholbach> hub: how is work there?
<hub> dholbach: it is ok. I just do proprietary stuff satm
<Mithrandir> selling your soul to the devil, are you? ;-P
<hub> Mithrandir: well it pays
* dholbach hugs hub
<Burgundavia> Mithrandir, some of us even sell non-free stuff
<crimsun> LaserJock: now's as good a time as any.
<Mithrandir> Burgundavia: hence my ;-P
<hub> Mithrandir: and I still have hope to move forward
<Mithrandir> hub: yeah, I was joking.
<Burgundavia> I can tell you this, as of tomorrow, a lot of things might change around the cool multiseat work my company is doing
<LaserJock> has ajmitch gotten an updated unmet deps list?
<hub> Burgundavia: like using ubuntu? :-)
<Burgundavia> hub, not that radical
<hub> ah
<raphink> dholbach: you can correct the report with the fact that I didn't help sistpoty modifying REVU
<ejofee> crimsun: thank you.
<raphink> dholbach: I just reported his work to the list
<ejofee> minghua: right, thanks.
<hub> Expression, the zero admin desktop from my former company moved quickly from a RH9 to a Xandros (debian based) at that time
<hub> from GNOME to KDE
<dholbach> raphink: please change it yourself - you're all free to change whatever you like.
<raphink> sure
<dholbach> thanks
<raphink> there
<LaserJock> maybe we should put something about how many merges have been done
<LaserJock> 594 according to http://revu.tauware.de/~sistpoty/MoM/index.py?state=fixed
<hub> dholbach: once I become a MOTU, do I still upload stuff on REVU or do I upload direclty and review on REVU?
<dholbach> NEW stuff should still go to REVU
<dholbach> LaserJock: yeah, cool - could you add that?
<dholbach> argl
<Burgundavia> dholbach, to avoid double packaging, ala the deskbar applet?
<dholbach> Burgundavia: no that doesnt work, Mithrandir packaged it, who is no MOTU :-)     but rather to get a bunch of bugs out of the first uploaded version and to make sure it's not completely crackful :)
<Burgundavia> dholbach, but everything going through REVU also avoids the double packaging problem
<Burgundavia> a problem that might increase as the size of MOTU increases
<dholbach> Burgundavia: only for MOTUs
<nalioth> o
<Mez> hub - /query
<dholbach> Burgundavia: there are people in Debian packaging too and people in main - but for motu, you're right
<nalioth> i've got a package that says to "cd kio-msits && make install" after the main package has been built. where in the debian/rules would that go?
<Mez> nalioth, after the make command
<nalioth> ok, ty Mez
<Mez> oh
<Mez> no
<Mez> in the install bit
<Mez> sorry
<Mez> didnt read that
<nalioth> install bit?
<crimsun> what I said in -offtopic. debian/rules (non-cdbs, too, under normal circumstances) has an install target.
<Mez> what crimsun said :d
<hub> what is Jorge nick?
<crimsun> hub: whiprush.
<whiprush> am I the right jorge you're looking for?
<hub> whiprush: I have PULSE... but the LED does no longer work, I never tried to replace the battery
<whiprush> hub: heh, join the club.
<nalioth> well, Mez, crimsun i'm totally lost on "install target"
<Mez> nalioth : are you suing cdbs ?
<whiprush> apparently in some editions you could just pull out the battery and replace it
<crimsun> nalioth: pastebin your current debian/rules
<Mez> usind *
<nalioth> but i'll figure it out
<whiprush> I don't have that one.
<hub> whiprush: I think I can. it is cardboard
<hub> the one sold in France
<whiprush> ah
<whiprush> good for you, mine is all glued in.
<whiprush> it pulses no longer. :(
<hub> I didn't try
<hub> so I can't tell
* hub should go to bed
<Mez> so should i
<Mez>  but gotta wait for uniform to be washed so i can put it to dry then go bed
<nalioth> http://paste.ubuntu-nl.org/6679   Mez crimsun
<nalioth> Mez: i'm using pbuilder
<Mez> nalioth: see the bit that says # Add here commands to install the package into debian/kchmviewer.
<Mez> add it in that bit :D
<nalioth> Mez: ty
* raphink thinks he should write some CDBS docs
<Amaranth> export DEITY="cdbs"
<nalioth> i haven't even met cdbs yet, i'm having such fun with pbuilder now
<Amaranth> yeah, yeah, no quotes, i learned it that way and it works most of the time :P
<raphink> nalioth: cdbs makes it much easier for most packages
<Amaranth> cdbs does everything for you
<Amaranth> and if it does something wrong, you just have to bug the cdbs devs :P
<raphink> lol
<Amaranth> of course while figuring out how to use cdbs you'll probably learn a lot about packaging anyway...
<raphink> nalioth: the main point with cdbs is that you can end up with debian/rules files long as 1 line sometimes
<raphink> so much easier to maintain and read
<Amaranth> raphink: 1?!? mine is 3 :(
<raphink> Amaranth: ;)
<dholbach> ok, I'll send the report now
<raphink> Amaranth: depends if you count the make line ;)
<Amaranth> i don't
<raphink> Amaranth: but sometimes only debhelper.mk is sufficient
<raphink> if you don't need to compile anything
<Amaranth> i include the distutils and debhelper files and have it handle the config file
<Amaranth> err, control
<raphink> ouch
<raphink> I wouldn't let it handle the control file ;)
<Amaranth> meh
<raphink> from what I heard this is dirty
<raphink> but heh if it works for you ;)
<Amaranth> it just adds proper build-deps for cdbs and debhelper
<raphink> mhm
<Amaranth> i could probably do it manually, but i'll wait to see if it breaks
<raphink> Amaranth: http://revu.tauware.de/revu1-incoming/kubuntu-grub-splashimages-0512141415/kubuntu-grub-splashimages-1.0/debian/rules
<raphink> one line :)
<Amaranth> no fair! there's no code in that package :P
<raphink> that's what I say
<raphink> if there is nothing to compile, you need only one line
<Amaranth> i actually could probably do it in 1 line
<raphink> now mind you, there's some bit of script in postinst and prerm ;)
<Amaranth> ditch the control handling and debbuilder
<Amaranth> i think i just need the distutils include
<raphink> why?
<raphink> what is it for ?
* raphink never used the distutils include
<Amaranth> python
<Amaranth> my app already handles all the install stuff with distutils instead of autoconf
<raphink> oh yeah
<Amaranth> so it's just a matter of giving the install script a prefix and rolling that into a deb
<raphink> ic
<raphink> mhm
<nalioth> thanks guys
<nalioth> what i'd like to know is why my pbuilder won't find "kde-devel" and other pkgs that are in the repos
<trappist> is there some dapper repository known only to the developers where the updates go?  the folks in #ubuntu-devel swears there's a newer, fixed version of iptables than the one broken in bug 16831 but I'm not seeing it.
<Mez> g'night all
<Mez> trappist - sudo apt-get update; sudo apt-get upgrade; sudo apt-get dist-upgrade
<trappist> Mez: did that of course.
<nalioth> i'm beginning to see why the kubuntu wish list is there
<raphink> nalioth: never used it actually ;)
<raphink> nalioth: when you want to add to kubuntu, you can also go to kde-apps.org and grab the good apps there
<nalioth> raphink: the things that interest me on the wish list don't seem to be 'right' (i.e. calling for libqt3 of a version that is in the repos, but not building cuz it can't find them)
<cyle> hi my name is cyle, i'm looking to get involved with ubuntu as a package maintainer/developer
<raphink> cyle: welcome here ;)
<raphink> cyle: since you got here, I guess you know about the MOTUs
<raphink> cyle: did you read https://wiki.ubuntu.com/MOTU and related pages?
<cyle> i'm currently crawling around in there
<raphink> hehe ;)
<raphink> well we're working on reorganizing this doc
<raphink> but it's a lot of work ;)
<raphink> do you have specific questions cyle ?
<raphink> do you already have packages to get in Ubuntu?
<raphink> or do you want to work as a merger?
<cyle> well i was wondering what kind of things need worked on right now, wondering how i could help best with my skillset
<cyle> i built myself a firefox-1.5 package lastnight out of frustration :)
<raphink> hehe
<raphink> well I think FF1.5 is already up there
<raphink> and has been for quite a long time
<nalioth> cyle: frustration at firefox? or your dog ran away with your wallet?
<Burgundavia> raphink, only 1.5rc3
<Burgundavia> raphink, there are a lot of issue with FF
<raphink> oh ok
<cyle> i'm currently in breezy
<cyle> don't wanna move up to dapper on my desktop for another month or two
* raphink hasn't used FF in a loooooooong time
<raphink> cyle: you'll need a dapper stuff somehow to work on packages
<raphink> I'd say at least a chroot
<raphink> minimum would be a dapper pbuilder imo ;)
<cyle> i have um, a few spare machines lying around here :)
<raphink> haha ok
<raphink> ;)
* raphink has one machine, with 1 dapper pbuilder, 1 dapper chroot and 1 sid chroot
<cyle> a few my girlfriend would love for me to throw out as well
<raphink> 1 machine is enough ;)
<raphink> cyle: hehe
<cyle> i've been running linux for about 3.5 years now
<raphink> the thing with FF is that it's not in universe cyle
<raphink> it's a main package
<cyle> i'm not looking to do anything specifically with firefox
<cyle> but somebody asked if i had built any packages specifically
<raphink> oooh
<raphink> yes I asked so ;)
<raphink> meaning if you wanted some new packages in Ubuntu
<raphink> I guess you know how to package cyle
<raphink> and you've been through NDMG
<raphink> and read quite a bit of Policy too
<cyle> for about the last year and a half i've been compiling all of my applications, including kernel, kde on my own so i'm very comfortable with that kind of thing
<cyle> i've been through the debian policy
<cyle> is ubuntu much different?
<raphink> good
<raphink> :)
<raphink> no cyle
<raphink> the policy in universe is generally to stay as close to Debian as possible when it comes to package sources
<raphink> (now we differ on the libs though, so the binaries are different)
<raphink> cyle: Ubuntu has not any close as manpower as Debian has
<raphink> so we need to constantly sync/merge packages from Debian into Universe
<raphink> cyle: Ubuntu is not based once and for all on sid, but constantly, that is an important point
<nalioth> if i find something on the kubuntu wish list that exists, can i dump from the list?
<raphink> so one of the main works in universe is to grab packages from sid and get them in Ubuntu, either by synchronizing them (simple rebuild in Ubuntu) or merging them (if changes are required)
<raphink> nalioth: if you package it, sure
<raphink> nalioth: imo
<cyle> myself i'd prefer to run/help debian, but having dealt with ubuntu for a few months, i realize it's better for the less-geeky, and there's no need to help geeks get comfortable with linux, it's the non-geeky people that linux needs to continue to capture
<nalioth> it's in the repos now.
<raphink> nalioth: well then you can remove it, sure :)
<nalioth> it's an ancient program and i'm actually boggling that it's on the kubuntu wish list page
<raphink> nalioth: cleaning the wiki is a good thing
<raphink> :)=
<raphink> and useful
<raphink> :)
<raphink> cyle: helping Debian is already helping Ubuntu
<raphink> cyle: although there are obviously Ubuntu-specific work to be done
<cyle> well, directly helping is more what i mean
<raphink> mhm
<cyle> as you said, debian has an army of maintainers/developers
<raphink> do you have an account on LP already cyle ?
<cyle> LP?
<raphink> yes
<raphink> Debian has about 1000 DDs, MOTUs are around 30
<raphink> cyle: launchpad.net
<raphink> you need an LP account for most things
<cyle> i'm not familiar with it
<raphink> and to create a WikiPage for you on wiki.ubuntu.com and document your work there
<cyle> ah, i see, i've never actually officially joined an opensource project before so no
<raphink> cyle: just go to launchpad.net and create yourself an account :)
<raphink> cyle: do you have a GPG/PGP key, too?
<raphink> (just trying to list the basic tools needed to help with packages)
<cyle> okay, CyleRiggs
<raphink> sure
<cyle> (gpg) no i don't, which utility do i use to create it?
<raphink> :)
<raphink> cyle: mine is https://wiki.ubuntu.com/RaphaelPinson if you need inspiration to put things on it
<raphink> cyle: you use gnupg
<raphink> look at https://wiki.ubuntu.com/GPGKey to create one
<cyle> i see in the manpage gpg and gpgv, which one is preferred?
<raphink> this is what will let you sign your work
<nalioth> raphink: is packaging a perl thing the same as any other?
<raphink> cyle: just follow the link I gave you
<cyle> raphink: yeah sorry i didn't see that url before i sent it
<raphink> nalioth: well iirc perl is interpreted so it doesn't need to be compiled
<raphink> nalioth: so you only need to put the stuff in the right place and apply the right perms iirc
<trappist> perl itself needs to be compiled - your perl code is interpreted
<raphink> yes
<raphink> ;)
<raphink> thanks trappist
* nalioth 's head is fixin to go into orbit.
<raphink> cyle: your GPG key is what will identify you in the open-source world (and more)
<trappist> also not all perl modules are pure perl... many need to be compiled
<raphink> cyle: it will be what testifies that a work has been done by you and not anyone else
<raphink> trappist: ic
<nalioth> no more kubuntu wish list for me
<nalioth> i'll stick with things i like
<raphink> haha
<raphink> nalioth: you can work on merges too ;)
<trappist> I have a question.  we're including a small chunk of some old kernel source in the iptables package to get it built.  we patch that kernel source and the iptables source with patch-o-matic in a vain attempt to add some nifty features... those features aren't in the kernel we use and therefore aren't really in iptables...
<raphink> nalioth: there are many apps waiting to be reviewed on REVU right now, so I'd say if you don't have an app in particular that you want to get in, merges are more useful
<trappist> iptables wants to be built against the source of the kernel we actually use.  I'd love to fix this, but I'd need cooperation from kernel people.  what to do?
<nalioth> i do have apps i'd like to get in, but don't see them on REVU. where is a list of accepted pkgs?
<raphink> trappist: go ask on #ubuntu-kernel ?
<trappist> didn't know there was such a place.  awesome.
<raphink> nalioth: on the repos for most of them ;)
<nalioth> trappist: there is probably #ubuntu-kansas, too
<trappist> heh.
<raphink> nalioth: haha
<nalioth> raphink: so if i can't find it on REVU or in the repos i can put it on revu?
<raphink> yes nalioth
<nalioth> cool.
<raphink> nalioth: but don't expect to have it in dapper though
<raphink> nalioth: the UVF is in a few days, and there are many packages to be reviewed on REVU
<raphink> nalioth: so you're lucky if you get your new apps in dapper now
<raphink> unless you get to be a good packager soon ;)
<cyle> okay, is this key signing a necessary step?
<Amaranth> UVF always gets pushed back a couple of days
<Amaranth> cyle: yep
<raphink> cyle: very necessary
<cyle> okay, i'll have a buddy do it at work tomorrow
<raphink> cyle: for most things you might do in open-source
<raphink> cyle: you can't do it now ?
<nalioth> cyle: it proves your packages havent collected any nastiness 'tween there and yon
<raphink> cyle: its' better if you create the key yourself. Get used to using gnupg, you'll need it quite often.
<raphink> cyle: even to sign your email or encrypt stuff.
<raphink> s/email/emails/
<cyle> i can't get it signed right now
<cyle> i have it and uploaded it
<raphink> oh sure cyle you need to meet people to get it signed :)
<raphink> good
<cyle> it's 2:30 in the am, strangley enough it's pretty quiet right now
<raphink> cyle: getting your key signed by influent people makes your identity fully trusted by many
<raphink> pretty quiet where cyle ?
<cyle> kansas city, missouri, usa
<raphink> ok ;)
<raphink> I thought you meant here
<Amaranth> cyle: your friend is in the PGP strong set?
<raphink> it's 9:43AM here but I'm not fully awake I guess
<raphink> lol
<nalioth> another whimsical question. how does one package icons?
<cyle> no but he has a gpg key as well
<Amaranth> that won't help
<raphink> cyle: what matters is not to get your key signed by anyone
<Amaranth> you need to have it signed by someone in the strong set
<raphink> cyle: you need your key signed by people in the strong set
<raphink> Amaranth: ;)
<cyle> ahhh
<nalioth> cyle: visit biglumber.com and find some gpg carrying friends
<raphink> cyle: this is a matter of web of trust
<raphink> if you want to be trusted in the strong set, you have to get known in it
<Amaranth> you physically meet the person and show them your id
<raphink> cyle: anyway, getting your key generated is mandatory to work ; getting it signed is not urgent.
<raphink> cyle: you can begin to work in Ubuntu without having your key signed yet
<raphink> cyle: but it's nicer if you get it signed by at least one person in the strong set soon :)
<cyle> okay
<raphink> (preferably 3)
<cyle> what exactly should i be looking for on biglumber.com
<raphink> :)
<cyle> i see top cities
<raphink> biglumper.com ??
<Amaranth> put in kansas city
<cyle> nm
<cyle> typo in my city search
<cyle> as well in the url
<Amaranth> one person in kc
<cyle> it happens often
<raphink> oh nice
<raphink> I didn't know this website
<cyle> Kenneth Root
<cyle> coincidential last name
<Amaranth> heh
<Amaranth> look him up in the phone book
<Amaranth> and call him tomorrow
<Amaranth> go out for lunch or a beer or something
<raphink> Amaranth: are they volunteers there?
<raphink> Amaranth: is there a way to register to help this project?
<Amaranth> help what project?
<raphink> biglumper.com Amaranth
<Amaranth> didn't know they needed help
<raphink> I am in the strongset and there's no one in my region
<raphink> from what I see on that site
<Amaranth> you need to add yourself
<nalioth> raphink: go sign up there, is all it takes
<raphink> let's see
<cyle> amaranth: a beer, don't think that'd go over well with the authorities
<Amaranth> heh
* raphink is registering on biglumb
<raphink> biglump
<raphink> lol
<nalioth> packageing icons is a matter of having the debian/rules put the individual icons in their proper place?
* nalioth is so new at this he's lighting the room green
<raphink> nalioth: with cdbs, packaging icons is a matter of one line in debian/rules
<raphink> and install file listing where they go
<nalioth> so i should learn cdbs, eh?
<raphink> nalioth: it won't take you long
<raphink> I can get you through in a few minutes if it' about packaging icons ;)
<raphink> ;)
<nalioth> raphink: only if you need a break from your einsteinian tasks, lol
<raphink> hahaha
<raphink> my einsteinian tasks so far are to list what I have to do today
<raphink> in real life
<raphink> i.e. mostly finding a job
<raphink> lol
<nalioth> raphink: how old are you?
<nalioth> raphink: and your geographical location?
<raphink> nalioth: 23
<cyle> i emailed the only guy available in kc to arrange a meeting, what should i do next?
<raphink> poitiers nalioth
<nalioth> cyle: wait for a response
<cyle> :)
<nalioth> cyle: have a copy of your whole fingerprint and 2 forms of official ID to take with you
<raphink> what's your ID cyle ?
<cyle> my email address?
<nalioth> some folks i've met have their fingerprint printed off and they've photocopied their ID onto the same paper (but you still need to see the hard plastic originals)
<raphink> cyle: no, your key ID
<raphink> gpg --list-keys
<raphink> will give it to you
<cyle> gpg: key FD237A16 marked as ultimately trusted
<raphink> in the form 1024D/blahblah
<raphink> ok
<cyle> 1024D/FD237A16
<raphink> cyle: did you export your key to a public server?
<cyle> gpg --send-keys --keyserver keyserver.ubuntu.com
<raphink> such as mit.edu
<nalioth> cyle: now type "gpg --keyserver keyserver.ubuntu.com --send-keys FD237A16"
<raphink> ok
<cyle> yep
<cyle> i didn't specify a key id
<cyle> i figured it send them all
<raphink> yes cyle
<raphink> you could send it to a more general server, too
<nalioth> i suggest you send to ubuntu, if you didnt specifically choose a keyserver
<raphink> such as pgpkeys.mit.edu
<nalioth> the default on mine goes to europe, lol
<raphink> well it's all interconnected anyway ;)
<cyle> i did keyserver.ubuntu.com
<raphink> my default is mit.edu somehow
<cyle> will it hurt to submit to another?
<nalioth> cyle: not at all, have fun
<raphink> cyle: you can submit to as many as you want
<raphink> :;)
<raphink> the more you do, the fastest it'll be available imo
<nalioth> cyle: they are all supposed to sync regularly
<raphink> and it won't hurt anyone
<cyle> so i need a printoff of my gpg key when i meet this guy?
<nalioth> cyle: yes. or handwritten or w/e
<cyle> handwritten, is that a joke, this thing is huge
<nalioth> cyle: it should only be 30-odd characters
<nalioth> cyle: gpg --fingerprint FD237A16
<cyle> okay
<cyle> lol
<cyle> i opened the gpg key file
<cyle> that's why i thought you were joking
<nalioth> and make a revocation certificate, too
<cyle> well what's my next step past the gpg process?
<cyle> do i need to pick a project to focus on?
<raphink> nalioth: let me know when you want to learn cdbs with your package
<raphink> I'm going out for now
<raphink> ++
<nalioth> i was fixin to bump ya on that, raphink
<nalioth> lol
<raphink> nalioth: I'll bb soon so you can read a bit on cdbs so far, study a few packages such as kubuntu-grub-splashimages or konq-kim and we'll see after that
<raphink> (you can find them on REVU so it's easier to fetch)
<Yagisan> evening all. I'd like to request a revu of http://revu.tauware.de/details.py?upid=1399
<lucas> heya
<StevenK> Can a MOTU look at Malone 5267 and Malone 5314 and tell me if they agree with Zak?
<Ubugtu> Malone bug 5267: "linkchecker: merge new debian version" Fix req. for: linkchecker (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: New http://launchpad.net/bugs/5267
<Ubugtu> Malone bug 5314: "moin: merge new debian version" Fix req. for: moin (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: New http://launchpad.net/bugs/5314
<minghua> StevenK: I only looked at 5267 and I am not a MOTU, but yes, I agree with Zak completely
<minghua> StevenK: IMO this is also a bug in the upstream tarball (either they prepare translations poorly, or they have something missing in their "make dist" target)
<StevenK> The updated stuff was for hoary, so that in case, I'll just get a sync requested.
* raphink got a nice box with about 100 Breezy CDs inside :D
<minghua> StevenK: what about the diff for _linkchecker_configdata.py then?  it looks strange to me
<StevenK> minghua: That seems to be dependant on what machine it builds on, which is stupid.
<minghua> StevenK: yeah, that's what I thought
<raphink> nalioth_zZz: I guess you're not available for cdbs ;)
<jpatrick> raphink: he is now
<raphink> hehe yes ;)
<raphink> I know thanks jpatrick
<jpatrick> seems noones interested in my kcontrol-kdmtheme...
<jpatrick> raphink: * New Upstream release : kio-sword (if you don't know :) )
<segfault> hallo
<viviersf> ok raaaait
<viviersf> im having some really WEIRD
<viviersf> Xorg issues
<ajmitch> hey viviersf
<viviersf> elo ajmitch
<viviersf> howz you
<ajmitch> alright :)
<viviersf> kewl dude
<ajmitch> had a good break?
<viviersf> ya\
<viviersf> been back for a week
<viviersf> but was moving to new offices
<jpatrick> raphink: can you check my Kleansweep? http://revu.tauware.de/details.py?upid=1404
<raphink> hm not right now
<raphink> soon
<janimo> hello
<janimo> is there some delay in getting .debs in the pool?
<janimo> I see thunar built fine yesterday but it's still not in the archive
<Nafallo> janimo: new?
<janimo> synced from debian
<lucas> raphink: hi
<lucas> what's your email address ?
<lucas> ok I know
<lucas> it's on LP
<janimo> but indeed NEW to ubuntu
<janimo> so it's in lamonts build logs as successful but not in the pool
<Nafallo> janimo: if it's binary-new it's dep-wait elmo :-)
<raphink> lucas: don't use raphink [at ]  raphink [dot]  net
<raphink> my account is blocked ... it should be better tonight since I called my domain provider this morning :s
<lucas> hehe you have an @jabber.fr JID
<raphink> raphink ;)
<raphink> easy
<raphink> I think I hold at least 95% of the raphink accounts on the internet ;)
* raphink looks happily at his 45 ubuntu CD boxes :)
* jpatrick can't wait for his Kubuntu CD boxes
<raphink> :)
<raphink> I had to reorder
<raphink> since the first ones didn't arrive
<jpatrick> I got my Ubuntu ones ages ago
<raphink> there are not Kubuntu shipit CDs yet, are there?
<jpatrick> there will be for Dapper
<zakame> evening all
<lucas> raphink: mail sent
<lucas> (to gmail)
<raphink> lucas: what for?
<raphink> ah oui
<lucas> review of you changes to MOTUMerging
<raphink> lucas: there is Merging too
<raphink> it's still a mess with MOTUMerging, Merging, MergingTips and so on
<lucas> yes, maybe it's worth merging them
<raphink> these should be reorganized/merged
<lucas> yup
<lucas> you did such a good job on MOTUMerging, I think you should be the one doing that ;)
<raphink> haha
<raphink> :p
<jpatrick> oh dear
<slomo_> StevenK: thanks :)
* jpatrick can't get a correct debian/rules for cdbs
<raphink> what's the pb jpatrick ?
<jpatrick> it just fails
<raphink> :(
<raphink> what does it say?
<jpatrick> lemme pastebin i
<jpatrick> it*
<StevenK> slomo_: Took you long enough to notice. :-P
<StevenK> slomo_: I uploaded it like 12 hours ago. :-)
<slomo_> StevenK: i was asleep :P
<StevenK> slomo_: No excuse! :-P
<jpatrick> raphink: I think it's kubuntu_01_kdepot.diff's fault
<jpatrick> http://kubuntu.pastebin.com/493145
<raphink> jpatrick: did you remake this patch or did you use it as such?
<jpatrick> I grabbed it from kubuntu.org
<raphink> then make your own
<raphink> read what it does
<raphink> and make a patch of your own that does the same thing
<jpatrick> the problem is there is no admin/cvs.sh
<raphink> this patch doesn't always apply
<raphink> if admin/cvs.sh was modified by upstream it won't work
<raphink> oh?N
<raphink> if there's no admin/cvs.sh then you need no patch
<raphink> it's pointless
<jpatrick> No it uses scons-mini
<raphink> see with Riddell
<raphink> but don't use the patch if there's no admin/cvs.sh that's for sure
<raphink> lucas: quelques modis
<raphink> s/modis/modifs
<raphink> jpatrick: does it work without the patch?
<jpatrick> it's building
<jpatrick> still setting up stuff
<raphink> ok
<jpatrick> make[1] : Entering directory `/tmp/buildd/kleansweep-0.2.4/obj-i486-linux-gnu'
<jpatrick> make[1] : *** No targets specified and no makefile found.  Stop.
<lucas> raphink: ?
<jpatrick> first time I've used cdbs
<raphink> lucas: the page
<jpatrick> raphink: http://kubuntu.pastebin.com/493162
<lucas> raphink:
<lucas> impec, je fais juste une modif mineure
<raphink> ok
<raphink> lucas: pour le debuild -S -sa
<raphink> c'est volontaire de ne pas utiliser pbuilder
<raphink> a ne sert  rien vu que c'est juste pour builder les sources sans compiler
<lucas> ah oui
* lucas boulet
<raphink> ;)
<raphink> mais non mais non lucas ;)
<raphink> lucas: le fait de dtailler le howto fait aussi qu'il y a des trucs en trop avant
<lucas> ouep
<raphink> dans Some reasons for divergence between Debian and Ubuntu
<lucas> hack hack hack
<raphink> y'a des trucs qui n'ont pas leur place
<lucas> to make it perfect
<raphink> devraient tre mergs plus bas
<raphink> lucas: yep
<lucas> if you delete too much, somebody will complain
<lucas> and you always has the history to restore
<raphink> sure
<raphink> most of the time I don't delete, I reorganize ;)
<raphink> if infos have been put there it's often for a good reason
<raphink> but sometimes not in a good way
<jpatrick> is there anyway I can use debhelper+scons
<Riddell> jpatrick: yes, see kdissert or skim
<rikai> later all , to bed with me o/
<jpatrick> yes!!
<raphink> rikai: ??
<sistpoty> hi folks
<jpatrick> hello sistpoty
<sistpoty> hi jpatrick
<Hobbsee> hey sistpoty
<sistpoty> hi Hobbsee
<sistpoty> ping raphink
<raphink> pong sistpoty
<raphink> \sh_away: ping
<sistpoty> raphink: I'm just looking at kalcul
<raphink> yes?
<sistpoty> raphink: you still changed upstream tarball... just repack it
<raphink> there's no dir in it
<sistpoty> raphink: dpkg-source is quite flexible with directories and get's it right
<raphink> the files are directly in the tarball as I said
<sistpoty> raphink: yes. but that's not a problem at all... dpkg-source does some deeper checking of directory structure and get's it right
<raphink> hmm
<raphink> I tried to just change the orig.tar.gz by repacking it
<raphink> and debuild was not happy with it
<sistpoty> raphink: basically I just tried to take your orig-tarball away and put the repacked bz2 there... works fine (after adjusting md5sum/size in dsc-file)
<raphink> pretending the size was wrong and whatnot
<raphink> adjusting md5sum might be what I missed ;)
<Yagisan> G'day All
<sistpoty> raphink: and please use gzip -9 for packing... will save 150k ;)
<raphink> sure
<raphink> I'll try that
<sistpoty> ok, in the meantime I'll take a look at the rest of it ;)
<raphink> ok
<raphink> :)
<Yagisan> siretart: still around ?
<sistpoty> Yagisan: do you mean siretart or /me?
<raphink> sistpoty: uploading again
<sistpoty> raphink: k
<Yagisan> sistpoty: either if you'd care to revu http://revu.tauware.de/details.py?upid=1399 I know siretart was interested in it.
<segfault> in a case of a source that has mysql and postgres support, but it's not really _necessary_ since it has its own internal database, should i at least compile with pg/mysql support?
<sistpoty> Yagisan: if you don't mind, I won't review this... since I only have an i386 here
<Mithrandir> segfault: generally, turn on all such features.
<Yagisan> segfault: I'd most likely add support
<segfault> but the binary will then depend on mysql/pgsql client libraries, is that acceptable?
<Yagisan> sistpoty: Thanks anyway sistpoty :)
<Mithrandir> segfault: yes, sure.
<sistpoty> ;)
<segfault> but isn't there any way to avoid installing those 2 libs, if i just want to use mysql?
<raphink> lucas: I'm having a talk with isaac. He's preparing a new package for wesnoth, merging the -t stuff
<Mithrandir> segfault: to save ~700k disk space?
<lucas> great
<lucas> have you mentioned using wildcards ?
<segfault> mithrandir: hehe, right
<raphink> lucas: what do you mean?
<lucas> '*' instead of listing each scenario
<raphink> oh yeah
<raphink> :)
<raphink> he will do that
<raphink> he said I could do it this way
<raphink> I said I knew that but my goal was to have as few changes as possible
<raphink> so I'd be happy if he did it instead ;)
<lucas> ok, perfect :-)
<lucas> excellent QA work.
<raphink> lucas: I can't find a bug for the new version \sh uploaded yesterday
<raphink> :s
<raphink> so I don't know where to find his patch for the amd64 build
* lucas doesn't know what you are talking about
<raphink> sorry ;)
<raphink> \sh made a new version of wesnoth yesterday
<raphink> -1ubuntu2
<raphink> because it wouldn't build on amd64 it seems
<raphink> isaac wants to merge that, too
<raphink> but he says the patch provided by the wesnoth website makes it build, but there's still segfault
<lucas> you can fetch the source and debdiff
<raphink> anyway I found where the -1ubuntu2 package was and gave him the link
<raphink> yes
* lucas thinks of implementing mdt fetch-source :-)
<lucas> => TODO list
<sistpoty> lucas: fetch source as in fetch a source package by dsc?
<lucas> mdt fetch-source <dist> <package name> => displays the available version
<lucas> mdt fetch-source <dist> <package name> <version> => downloads it
<sistpoty> lucas: you might want to look at madison-lite, and see if this can do parts of what you want ;)
<raphink> what would be the difference between fetch-source <dist> <package> <version> and dist-apt-get <dist> source <package> <version> then?
<sistpoty> lucas: and siretart did some similar stuff for revu2, which is basically some wrapper around apt-get
<sistpoty> (if you need inspiration and/or code) ;)
<raphink> sistpoty: http://revu.tauware.de/details.py?upid=1411
<lucas> well it doesn't use a local APT-tree
<lucas> sistpoty: doesn't look that hard to code :)
<raphink> lucas: oh ic
<sistpoty> lucas: I guess it isn't ;)
<raphink> :)
<raphink> sistpoty: should be fine now imo
<sistpoty> raphink: don't change always while i'm reviewing :P
<raphink> huh?
<raphink> I just changed the tarball as you requested
<raphink> :s
<sistpoty> raphink: oh, then maybe I'm already reviewing the latest one (cause the orig is fine)
<sistpoty> :)
<raphink> :)
<raphink> hehe
<sistpoty> raphink: kalcul is fine, maybe you could get rid of libtool in diff.gz. as well?
<sistpoty> raphink: (probably just deleting it during clean or s.th.)
<raphink> sure
<raphink> I'll do that
<sistpoty> btw.: did I mention that I updated the new merges again?
<raphink> sistpoty: how many ?
<sistpoty> raphink: total 28
<sistpoty> (unassigned)
<raphink> ok
<j^> hi, has someone looked if its possible to add gizmo to ubuntu?
<j^> would love to see a version using avahi and part of ubuntu
<j^> or is there a better VoIP solution
<lucas> sistpoty: the merge list doesn't work well
<lucas> mmh
* lucas double-checking :-)
<sistpoty> lucas: what's wrong?
<lucas> ok no it seems to be ok
<sistpoty> phew :)
<lucas> ok
<lucas> I'm investigating the difference between http://tiber.tauware.de/~lucas/versions/unimultiverse.html and http://revu.tauware.de/~sistpoty/MoM/index.py?state=new
<lucas> 124 >> 28
<sistpoty> lucas: it can never match... packages which are assigned may be newer in debian _or_ newer in ubuntu (in case source package was already uploaded)
<lucas> and 124 << (176 (accepted) + 28 (unassigned))
<raphink> sistpoty: http://revu.tauware.de/details.py?upid=1412
<raphink> no libtool anymore
<sistpoty> raphink: k
<raphink> double checked, built, etc.
<sistpoty> lucas: problem is that merge bugs should only be closed if the package built on all arches (which means a package from assigned on the merge list will move to fixed quite some time after the updated sourcepackage is available)
<lucas> yup, probably
<sistpoty> but still the difference seems a little bit big
* sistpoty is off again
<sistpoty> cya
<Tonio_> hello
<Riddell> any MOTU who want kubuntu breezy install CDs please e-mail jriddell@ubuntu.com with your postal address and how many you want
<jsgotangco> dholbach, happy 2nd birthday!
<jsgotangco> i hope you can understand me...
<tseng> jsgotangco++
<hub> it is dholbach birthday?
<jsgotangco> yes his 2nd
<hub> 2nd?
<jsgotangco> hub, planet.ubuntu.com
<tseng> 26
<jsgotangco> a child prodigy indeed
<jsgotangco> "My 2nd birthday and how I celebrated it"
<jsgotangco> =)
<hub> ah
<hub> I didn't read that at first
<hub> btw, is it me or the CSS is messed-up?
<jsgotangco> hub, yep website movements
<jsgotangco> planet wasn't too happy about the move to moin
<hub> oh
<thierry_> if my application name is geg, what should be the GenericName ? Also geg?
<thierry_> forget that, found by myself :)
<thierry_> ajmitch : could you point me somewhere or someone who could explain me what are shared librairy, what are their use and where to install them?
<janimo> anybody else having probs accessing wiki with firefox?
<janimo> since todays update it does not connect
<janimo> Firefox doesn't know how to communicate with the server.
<janimo> it sez
<thierry_> janimo : no problem here
<janimo> thanks
<janimo> latest ff right?
<janimo> all other sites work but wiki.u.com
<janimo> is there a list of packages proposed for removal form the archives?
<janimo> I'd like to add 2 packages
<thierry_> janimo : yes
<thierry_> janimo : can't find it right now but I know it exists
<janimo> in #tango they told me there's a desktop icon and the same is used for show-desktop
<janimo> thierry, sorry got deadlocked on the old thread :)
<janimo> in another channel even
<janimo> gotta close some tabs, following 3 channels is too much for my brain it seems
<janimo> ciao
<Goshawk> hi
<Goshawk> what if i wanna add a package to the MOTU repo?
<Goshawk> (universe)
<Gloubiboulga> hello :)
<thierry_> Goshawk : you have to send your package to REVU. Check https://wiki.ubuntu.com/REVU?highlight=%28revu%29
<thierry_> Gloubiboulga : hi
<thierry_> Goshawk : once sent to REVU, your package as to be advocated (accepted) by two MOTU
<Goshawk> thierry_, thx
<thierry_> :)
<dholbach> jsgotangco: thanks a lot :)
<jsgotangco> dholbach, i hope you had fun on your 2nd birthday
<thierry_> dholbach : are you a MOTU?
<Gloubiboulga> dholbach is only 2 years old? ;)
<dholbach> thierry_: yes, i am
<thierry_> dholbach :  could you point me somewhere or someone who could explain me what are shared librairy, what are their use and where to install them?<
<dholbach> thierry_: i'd suggest to apt-get source <some library> and inspect the debian/ dir - that should be the easiest
<tseng> thierry_: one second
<thierry_> that's the only point that fails in my package, I don't install the shared librairy
<thierry_> k thanks
<dholbach> thierry_: i did libsexy recently, it's pretty easy
<thierry_> k
<tseng> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
<tseng> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
<tseng> if you really wanted details about shared objects, http://www.google.com/url?sa=t&ct=res&cd=8&url=http%3A//people.redhat.com/drepper/dsohowto.pdf&ei=6Z6-Q-aGLomkaYGH1d0O&sig2=UC_yh-3OceJ3nYnJpHaU5g
<thierry_> dholbach : I'm going to resend to REVU, after that could you check it, only for the shared librairy thing?
<dholbach> thierry_: i make a note to have a look at it
<thierry_> dholbach : k , my package is libfxscintilla1.6
<dholbach> ok
<thierry_> dholbach : resent
<dholbach> thierry_: take your time, i have some other stuff to do first
<thierry_> dholbach : k
<jsgotangco> wow whiprush got mentioned in an o'reilley book what a star
<slomo_> tseng: interesting text :)
<slomo_> tseng: (the one by ulrich drepper)
<thierry_> could someone point me a librairy packaged with debhelper?
<dholbach> thierry_: the interesting part is the *.install stuff
<thierry_> ok... but is it right or do I still have problems?
<dholbach> didnt look at it yet
<thierry_> ho ok
<dholbach> just answered, because nobody else did ;)
<thierry_> dholbach : ok but in another package I get this from a reviewer : * Check your install rules, none of the binaries are being added to the packages. They only contain files in /usr/share/applications/.
<dholbach> copy over the *.install files from libsexy
<dholbach> they should be a good start
<dholbach> just build with debuild and see what is "left to install" in debian/tmp
<thierry_> dholbach : how do I see what is "left to install" ? should debian/tmp be empty if everything installs corectly?
<dholbach> no, but you can compare
<dholbach> a simple   find .    in there should give you an idea
<thierry_> k...
<azeem> there's a switch to dh_install to check whether everything got installed
<azeem> doesn't work with the way CDBS calls dh_install, though
<\sh> moins
<Gloubiboulga> hi \sh
<LaserJock> tseng: ping?
<Gloubiboulga> dholbach, I had a look at thierry_away's package
<Gloubiboulga> the Makefile seems bugged
<dholbach> Gloubiboulga: ah ok
<Gloubiboulga> it doesn't install the .so file
<dholbach> oh nice :)
<Gloubiboulga> but I can't help him solving this, as I don't know anything about cdbs
<thierry_away> I could always switch to debhelper to fix the issue
<dholbach> it's a matter of either fixing the upstream build system or the .install file
<dholbach> this has nothing to do with cdbs
<thierry_away> ho ok
<Tonio_> hi all
<Tonio_> hello dholbach ;)
<dholbach> hey Tonio_
<Tonio_> dholbach: any info on the freeze date for revu ?
<Tonio_> is it 19/01 too ?
<dholbach> it'll be Feature Freeze
<dholbach> it's on DapperReleaseSchedule on the wiki
<Tonio_> okay
<Tonio_> not versionfreeze ?
<dholbach> not for NEW packages
<Tonio_> dholbach: nice
<dholbach> tseng, slomo_, ajmitch: what do you think of http://sourceforge.net/projects/openvpnadmin/? Seems to be Mono Open VPN stuff.
<dholbach> I'll call it the day - have a nice evening.
<LaserJock> cya dholbach
<dholbach> tseng, slomo_, ajmitch: http://sourceforge.net/forum/forum.php?forum_id=524350 seems they have '.deb's
<GNULinuxer> how do I do an ITP for Ubuntu?
<tseng> you put your source package on revu
<tseng> revu.tauware.de
<GNULinuxer> tseng: my package was uploaded to debian main recently ... so will it come into ubuntu automatically?
<tseng> yes
<GNULinuxer> tseng: but who will maintain the ubuntu version of it?
<GNULinuxer> i would like to do that myself
<tseng> no one has to if the debian version works fine
<tseng> it will just keep syncing over
<GNULinuxer> tseng: I see
<tseng> until upstream version freeze
<tseng> when the next release opens we will start syncing again
<tseng> manual work is only needed if someone made an ubuntu specific version
<tseng> they need to be merged by hand
<GNULinuxer> hmm
<GNULinuxer> tseng: where do I register for a login it revu?
<tseng> see the wiki page linked at the top
<tseng> and read all notes
<GNULinuxer> ok
<tseng> its there if you only look :)
<GNULinuxer> tseng: is there any list where requested packages for Ubuntu are listed?
<tseng> erm
<tseng> can you be more specific
<tseng> UniverseCanidates on the wiki?
<GNULinuxer> yes, I guess UniverseCandidates
<pvh> I am having linking trouble trying to build Audacity 1.3beta which requires wxWidgets 2.6.1. Is there anything strange and amiss with wx2.6?
<\sh> if someone sees seth please tell him speedcrunch is already packaged :)
<\sh> would be good if he can nuke it :)
<raphink> hmmm
<raphink> I was to merge xosview
<raphink> but it doensn't exist on scott's repo
<raphink> :s
<ajmitch> morning
<rikai> brb, installing memory <.<;
<raphink> now wait a minute ...
* raphink stops and thinks ...
<raphink> how can I be merging a package from main ? :s
<raphink> ajmitch: I can't merge packages from merge, right?
<crimsun> you can, you just can't upload it.
<raphink> :s
<raphink> oh ok
<raphink> so I can keep working on the merge?
<ajmitch> only if it's not assigned to someone
<crimsun> right
<raphink> where do I see that?
<ajmitch> they use bugzilla for main
<raphink> ok
<ajmitch> search for the source package name
<ajmitch> what is it, btw?
* ajmitch did a merge in main last week, for example
<raphink> k3b
<raphink> this is a messy merge
<raphink> no ubuntu patch was taken to debian
<raphink> so all of them have to be applied again
#ubuntu-motu 2006-01-12
<raphink> ajmitch: I can't see a merge bug on bugzilla bout it
<raphink> ajmitch: what do you think? shall I keep merging ?
<crimsun> (I'd stick w/ universe myself)
<crimsun> the main ones will be done regardless; universe ones aren't necessarily so
<raphink> crimsun: well its' just because I filed the merging bug and began to work on it
<raphink> but then I filed the bug in malone, so I guess it's pointless and I can just close the bug as rejecte
<raphink> rejected
<raphink> crimsun: this merge is not even important. It's not a newer version really. Just Debian being 15 days later on the latest k3b version, packaged in December in ubuntu
<raphink> so I might just close the bug I mistakenly opened on malone and give it up ;)
<ajmitch> I doubt that it's a merge candidate, things like kde & gnome are maintained seperately from debian
<raphink> hmmm
<raphink> well it was on lucas's list of Debian packages newer than Ubuntu ones
<raphink> :s
<raphink> I don't really get yet where to get merges
<raphink> the 'official' list seems empty or with erratic links to scotts dir
<raphink> and the lucas list lists files that are not to be merged
<raphink> so I'm wondering where is the list of the real merges to be done ;)
<raphink> maybe that's something to report to lucas, btw : removing main apps from his list ;)
<ajmitch> I thought his list was meant to be universe only
<raphink> thought so too
<raphink> but I found k3b there
<raphink> http://revu.tauware.de/~lucas/versions/all-packages.html
<raphink> ;)
<raphink> and I guess other main apps could be found if one can be
<raphink> logically
<ajmitch> good to see that my lists are obsolete now
<raphink> just picking one randomly : koffice
<lfittl> http://revu.tauware.de/~lucas/versions/unimultiverse.html is for uni/multiverse
<raphink> oh ok
<raphink> thanks lfittl
* ajmitch shouldn't have bothered spending time coding up something that did the same
<raphink> good to know :)
<lfittl> np, just found that one myself :)
<raphink> could have guessed though :s
<raphink> I should add this link to MOTUMerging on the wiki
<raphink> I also want to write a howto for cdbs
<raphink> there is no howto for that
<raphink> it's a real lack
<marcin`> hello
<marcin`> I would like to register and upload some packages to REVU
<marcin`> but got a little problem with keys...
<marcin`> could someone tell me what should I put into <KEYID> section of this command
<ajmitch> what problem?
<marcin`> gpg --send-keys -keyserver blabla <KEYID>
<marcin`> wtf is KEYID?
<crimsun> um, that's your id for your gpg key
<marcin`> sure but which part of gpg --list-keys output is keyid?
<crimsun> normally it's the first id listed with --list-keys
<crimsun> pub   1024D/C88ABDA3 2003-06-23 [expires: 2006-06-27] 
<crimsun> mine's 0xC88ABDA3
<marcin`> how did you get this 0xC.... value?
<crimsun> gpg --list-keys
<marcin`> ahh so this is this part after 1024D/ ?
<crimsun> yes
<marcin`> crimsun: ok done
<marcin`> thanks very much...
<crimsun> np
<marcin`> I did all this gpg thing about a year ago and I forgot most of it ;>
<desrt> do the motu plan to pacakge a version of emacs that uses gtk2?
<desrt> er.  xemacs, i mean
<ajmitch> desrt: doubtful, why?
<desrt> because gtk1 is ugly? :)
<ajmitch> hm, *maybe* with xemacs if you found someone gullible enough
<desrt> uhm
<desrt> incidentally 'emacs' already has a gtk2 version in the archive
<desrt> and xemacs does not
<desrt> your intuition is backwards :)
<ajmitch> how so? :)
<ajmitch> ah, xemacs21, 238 bugs in debian
<slomo_> uh... i would die if i had 238 bugs for one of my packages ;)
<marcin`> desrt: where is emacs 22 gtk2 version - I mean which ubuntu repo?
<desrt> marcin`; dapper  universe
<ajmitch> weird network issues with this laptop..
<seth_k|lappy> Theoretical question: If I'm doing a new package, when do I just make changes outside debian/, and when do I decide the extra overhead of a patchsystem is worth it? If there's just a one-line change, is it worth it? Ten lines?
<ajmitch> seth_k|lappy: you decide ;)
<seth_k|lappy> bah
<seth_k|lappy> what sort of answer is that :)
<seth_k|lappy> hehe
<ajmitch> seth_k|lappy: I often prefer to throw in a patch system anyway
<ajmitch> some people don't
<ajmitch> there's no real rule about it
<ajmitch> but as soon as you make multiple changes you need to be able to sort them somehow
<seth_k|lappy> It's my personal preference to throw it in, because I figure I might need it later for bigger patches.
<seth_k|lappy> So alright, if it's a preference thing
<ajmitch> sure, if it's your own package :)
<ajmitch> I'd had simple-patchsys in for a 2-line patch
<ajmitch> hey Arrogance
<Arrogance> hi aj
<azeem> Arrogance: hey, did Jeff ask you where the flock svn is these days, or whether you have a copy of it?
<ajmitch> morning azeem :)
<azeem> heya
<Arrogance> azeem, he hasn't asked, no.  svn should be the same as always
<azeem> can you remind me? *g* (in a /msg if you want)
<Arrogance> azeem, remind you?  Sure.  svn stands for subversion
<Arrogance> *g*
<azeem> I was looking for Jeff's automake patches and he said they would be in the flock repo
<ajmitch> looks like I need to get python-bazaar in debian
<ajmitch> crimsun: do you know what alsa drivers are in the dapper kernel?
* ajmitch is another laptop user with no sound ;)
<crimsun> 1.0.10rc
<ajmitch> right
<crimsun> it's a bit past rc3
<crimsun> if you need, try rc2 from experimental
<crimsun> 1.0.11rc2, that is
<ajmitch> it was a little annoying to not have sound with this
<ajmitch> then I found that others with very similar models have the same issue
<crimsun> which laptop?
<ajmitch> acer travelmate 4064WLMi
<crimsun> ajmitch: so you have an ALC260 as the codec?
<ajmitch> yes
<ajmitch> not sure if that is support yet or not
<crimsun> it is.
<crimsun> Try 1.0.11rc2 from exp. http://http.us.debian.org/debian/pool/main/a/alsa-driver/alsa-source_1.0.10+1.0.11rc2-1_all.deb
<ajmitch> yes, I've grabbed that
<ajmitch> just trying to fetch the right linux-headers now
<ajmitch> as wireless is also giving some issues :)
<desrt> there appears to be an error on the archive
<desrt> clisp_2.36 isn't built for 386
<desrt> (it is for ppc and amd64)
<ajmitch> crimsun: surprisingly I get a lot of unknown symbols with an alsa-modules deb, against the current kernel headers
* crimsun downloads
* ajmitch did the usual make-kpkg routine, installed, watched it all fall apart
<tseng> crimsun: ping
<crimsun> tseng: pong
<tseng> crimsun: alt+1-0 doesnt work any longer in urxvt (works in gnome-termina)?
<tseng> im rather depended on them in irssi
<crimsun> from rxvt-unicode 6.2?
<tseng> yes
<crimsun> 6.3's out, just haven't had a chance to push it in yet
<crimsun> confirmed, will look in a sec. Gotta straighten out aj's alsa issue
<tseng> rock on dude
<crimsun> ajmitch: hmm, seems to build ok for me
<crimsun> ajmitch: I used module-assistant
<crimsun> ajmitch: what's the dmesg spew regarding symbols?
<ajmitch> crimsun: oh it built fine for me
<ajmitch> Jan  7 14:20:13 localhost kernel: [4384556.939000]  snd_timer: Unknown symbol snd_info_register
<ajmitch> Jan  7 14:20:13 localhost kernel: [4384556.939000]  snd_timer: Unknown symbol snd_info_create_module_entry
<ajmitch> just a few hundred lines like that
<ajmitch> terribly exciting stuff
<tseng> i just got an ad for "american idol - underground"
<tseng> (you must be shitting me)
<crimsun> ajmitch: when you dpkg -i'd the new 1.0.10+1.0.11rc2 deb, it should have done an alsa force-reload
<crimsun> tseng: 6.3-0ubuntu1 uploaded, see second changelog item
<ajmitch> yes, and a force-reload is what breaks
* ajmitch is going to reboot & see what damage has been done :)
<ajmitch> bbiab
<crimsun> ok, thanks
<ajmitch> crimsun: they installed, but I have no sound (everything unmuted & volume at max)
<crimsun> ajmitch: ok, please pastebin amixer output
<ajmitch> http://paste.ubuntu-nl.org/6717
<ajmitch> might be worth me following up with the alsa bugreport
<crimsun> yes, you will need to.
<crimsun> Does force-unload, rm -f /var/lib/alsa/asound.state, and modprobe snd-hda-intel work?
<crimsun> "work" -> result in audible sound
<ajmitch> looks like I'm getting timeouts trying to reload the snd-hda-intel drive now
<crimsun> drat.
<ajmitch> yep
<crimsun> ajmitch: does it hang the machine, or does it just fail to modprobe?
<ajmitch> just fails to modprobe, spews in dmesg
<zakame> hi all
<ajmitch> hey zakame
<zakame> hi ajmitch :) 'tis a blackout here :(
<crimsun> ajmitch: please pastebin the spew
<nalioth> is there a need for ppc packagers for backports ?
<ajmitch> crimsun: sure, once wireless is cooperative also :)
<crimsun> ajmitch: ok. :)
<crimsun> nalioth: sure; you'll probably want to coordinate w/ Mez
<nalioth> crimsun: ty
<ajmitch> http://paste.ubuntu-nl.org/6718
<slomo> nalioth: not for packagers... but for testers... packaging happens in dapper, the backports use the dapper packages and build them in breezy
<nalioth> slomo: ok. thanks
<nalioth> when is the dapper freeze?
<desrt> which freeze?
<tseng> Jan 19th main UVF
<tseng> universe soon after
<ajmitch> universe UVF on the 19th, actually
<ajmitch> possibility of other new packages until feature freeze
<nalioth> i'm tryin to resolve easyubuntu (since i'm on the EU team)
* StevenK waves to people.
<crimsun> ajmitch: does passing "model=foo" (where foo == {basic,hp,fujitsu}) to ``modprobe snd-hda-intel'' result in working audio?
<tseng> crimsun: my hero, alt+1 works
<crimsun> tseng: excellent.
<tseng> thanks.
<crimsun> np
<raphink> \sh: you around?
<\sh> somehow..but not productive
<raphink> ok ;)
<raphink> there's a bug in wesnoth
<raphink> doesnt show team colors on units and villages
<raphink> which is not very convenient
<raphink> I've tracked it down and it's a .cfg missing in wesnoth-data.install
<raphink> again ;)
<\sh> debdiff?
<raphink> isaac knows about it
<raphink> and will release the next version with *.cfg
<raphink> which will prevent this kind of mistakes in the future
<raphink> shall I release a fixed version for ubuntu?
<raphink> or just wait for the updated package in debian?
<\sh> sure
<raphink> sure for which one?
<\sh> fixed version for ubuntu :)
<raphink> hehe
<raphink> oh ok :)
<raphink> I'll take your latest version and make a debdiff
<raphink> :)
<raphink> I'm checking if it works first
<raphink> do I need to file a bug to do that ?
<raphink> or just giving you the debdiff is fine?
<\sh> raphink: send me the debdiff to sh@sourcecode.de
<raphink> ok
<raphink> :)
<minghua> wesnoth 1.1.0-2 is in debian incoming
<minghua> I assume you guys know that
<raphink> so it'll be up soon I guess
<\sh> he fixed all the bugs now/
<\sh> ?
<crimsun> just merge it from 1.1.0-2
<crimsun> as I recall we still have libgl{u}1-dev differences
<raphink> \sh: I had a talk with isaac so he should have fixed all the .cfg related bugs
<raphink> and the amd64 one, too
<raphink> if he worked on 1.1.0-2 well, a sync should be sufficient for the new package
<raphink> :)
<\sh> when i would find the source packages
<\sh> in incoming is no source of wesnoth
<crimsun> wouldn't be, it's -2
<\sh> ah yes
<\sh> but then there should be a dsc and a diff.gz even in debian, right?
<crimsun> yep, probably already processed
<raphink> hmm
<raphink> already processed I'd say
<\sh>    * Install missing .cfg files which caused a problem with team colors and
<\sh>      also closes: #337834 (missing test scenario file)
<\sh>    * Apply patch from upstream to fix build in amd64, according to patch
<\sh>      submitter the game might segfault later but it's an improvement anyway,
<\sh>      closes: #345960
<\sh>    * Enable fribidi support (--with-fribidi flag and libfribidi-dev b-d)
<\sh> lol
<raphink> since there are still the sparc and arm changes and deb in incoming
<\sh> so the amd64 patch is not worth it somehow
<raphink> hehe
<raphink> yes it seems
<minghua> \sh: sorry, the source is already in archive, I think
<raphink> your patch was different than his \sh it seems
<\sh> raphink: did you play on amd64?
<raphink> you used long integers in it, instead of normal integeres
<raphink> nope \sh I have a K7
<\sh> raphink: sure...because when he tries to typecast pointers to int he is fucked on amd64
<\sh> or on all 64bit archs
<raphink> yes
<desrt> \sh; only LP64 arches
<raphink> but he kept (int) instead of (long) and says it won't change much to the segfault anyway
<\sh> on i386 it is right that int and long are the same size (32bit) so as the pointer..but on amd64/ia64/and other archs the 64bit pointers are 64bit length and int is on 64bit only 32bit
<\sh> hahaha
<\sh> ftbfs again with gcc4?
<raphink> \sh: ?
<\sh> the problem with the int and long is a complaint from the gcc4
<raphink> if you're talking about wesnoth, the patch doesn't cause ftbfs
<\sh> that's why it ftbfs on our buildd
<raphink> it causes segfault
<raphink> but fixes ftbfs
<raphink> ok
<raphink> isaac told me the patch fixes the ftbfs, but causes segfault
<raphink> it's just a bit better ;)
<raphink> hehe
<raphink> at least it builds
<\sh> let me see how he did it
<raphink> ok
<raphink> :)
* raphink is getting a bit tired
<raphink> maybe 5AM will be a good time to go to sleep
<raphink> once this package is built
<\sh> + static int unittype_internal_compare(wesnoth_unittype* left, wesnoth_unittype* right)
<\sh> + {
<\sh> +-      return (int)left->unit_type_ - (int)right->unit_type_;
<\sh> ++      return (int)(left->unit_type_ - right->unit_type_);
<\sh> + }
<raphink> yep
<raphink> he said you used (long) instead of (int)
<\sh> that means...that he is doing a pointer substraction and casting it to int..
<\sh> the question is what is unit_type_ for a type :)
<raphink> no idea
<raphink> I'm no dev
<raphink> never studied c++
<raphink> I stopped my school before this courese
<raphink> course
<raphink> and I know that the people who stayed didn't understand it anyway
<raphink> lol
<raphink> a friend told me that after a few months studying c++, he finally understood that all he had understood was that he couldn't understand c++
<raphink> ;)
<\sh> well..it's a pointer
<raphink> argh
<raphink> someone needs to explain me pointers sometime
<\sh> typedef struct {
<\sh>         PyObject_HEAD
<\sh>         const unit_type* unit_type_;
<\sh> } wesnoth_unittype;
<raphink> I still don't get what a pointer is
<crimsun> a pointer is a data type that "points" to another data type
<crimsun> we recognise it as a memory location when it is dereferenced
<\sh> which means he assumes that the difference between left->unit_type_ and right->unit_type_ is smaller then 64bit
<raphink> mhm
<\sh> which means he can be wrong
<crimsun> (int) is the wrong cast
<\sh> or better he could be wrong
<raphink> crimsun: this is nice of you, although I doubt I can undrstand it at 4:42AM if I didn't understand it in the middle of the day before
<\sh> crimsun: what I did was typecasting to long
<crimsun> yeah, that's the standard procedure when porting to 64-bit arches
<\sh> which is, reading the porting to 64bit arch documents, the right way
<raphink> well if you think this is better, then I can merge it with this change
<\sh> so I think our version won't segfault anyhow
<Lathiat> tseng: http://www.djangoproject.com/snakesandrubies/
<\sh> well I think it will segfault somewhere..but not for the typecast I introduced
<raphink> ok
<\sh> raphink: lets fix the bug you told me in our package and leave the ai_python patch from ubuntu like it is now :)
<raphink> how do you mean?
<\sh> raphink: this calculation method I don't trust
<raphink> you mean not merging the new debian package?
<\sh> raphink: the assume that 64bit mem address - 64but mem address == 32bit length
<\sh> raphink: yes
<raphink> hmm ok then
<\sh> raphink: don't merge it :) fix the bug you mentioned and send the debdiff
<\sh> if debian asks why, tell him he is wrong
<raphink> well actually if we do that I'd very much like to use *.cfg to fix the colors bug
<raphink> and thus prevent another mistake maybe
<raphink> but that will make a bigger debdiff
<\sh> raphink: yeah..that's why you should fix the .cfg issue...but leave the amd64 bit patch like it is now :)
<raphink> since it will remove all the *.cfg files in .install
<raphink> and replace them by .cfg
<raphink> it will fix both -t switch and colors bug though
<raphink> at once
<\sh> lemme check how he did it (the cfg issue)
<raphink> and maybe more to come in the future will be prevented
<raphink> as .cfg file are added
<raphink> had he use *.cfg from the beginning, there would never have been a -t switch & a colors bugs
<\sh> debian/tmp/usr/share/games/wesnoth/data/*.cfg
<\sh> you mean this?
<raphink> yes
<raphink> did he use this?
<\sh> yes
<\sh> in his new package
<raphink> very good so
<raphink> at last I'd say ;)
<raphink> using it in a debdiff in ubuntu would generate a big diff though
<raphink> so that's why I asked him to do it himself so we could merge it
<raphink> and thus prevent a big debdiff from Debian on our side
<\sh> hum? well it removed all the .cfg entries in .install
<raphink> yes
<raphink> exactly
<raphink> so that's quite big, isn't it?
<\sh> so i don't mind...what about the -t switch?
<\sh> no
<raphink> ok I tried to add the .cfg manually and rebuild and it works
<raphink> that was it
<\sh> only 10 lines
<raphink> the -t switch is exactly the same
<raphink> the -t switch is a test_stuff.cfg file missing in .install
<raphink> and the colors is a team_colors.cfg file missing in .install
<raphink> so using *.cfg fixes both
<\sh> ok..I changed now the .cfg entries to a single *.cfg
<raphink> although so far we have fixed the -t issue by adding this line only to .install
<raphink> ok
<raphink> that should fix everything :)
<raphink> well I mean the -t switch and the colors
<raphink> the colors being quite useful to play somehow ;)
* raphink played two games without the team colors tonight
<raphink> it's confusing ;)
<raphink> \sh: so you're fixing this in -1ubuntu3 ?
<\sh> yes
<\sh> moment
<raphink> ok :)
<\sh> what is frigidi?
* raphink needs to go to bed before falling on the keyboard
<raphink> \sh: no idea
<\sh> fribidi
<raphink>  $ grep fribidi src/*
<\sh> ok..i'll enable this as well
<raphink> src/font.cpp:#include <fribidi/fribidi.h>
<crimsun> unicode bidirectional support
<raphink> src/font.cpp:   char            *c_str = const_cast<char *>(str_.c_str());      // fribidi forgot const...
<raphink> src/font.cpp:   n = fribidi_utf8_to_unicode (c_str, len, bidi_logical);
<raphink> src/font.cpp:   fribidi_log2vis(bidi_logical, n, &base_dir, bidi_visual, NULL, NULL, NULL);
<raphink> src/font.cpp:   fribidi_unicode_to_utf8 (bidi_visual, n, utf8str);
<crimsun> Build-Depends += libfribidi-dev
* raphink is off to bed
<raphink> thanks for your work \sh, I'll try to do it entirely myself next time :)
<\sh> raphink|bigsleep: no problem...
<\sh> crimsun: ok..I'll added this as well
<\sh> uploaded
<\sh> ok..now for some movies :)
<\sh> laters
<LaserJock> any MOTUs up for a quick REVU review about?
<nalioth> what can be done when the pbuilder environment can't find packages that ARE in the repos ?
<crimsun> such as?
<Burgundavia> nalioth, you got universe enabled in the pbuilder too?
<Yagisan> nalioth: sudo pbuilder update ???
<nalioth> i have universe and multiverse in my pbuilder sources.list, yes
<nalioth> it's been updated
<crimsun> did you have them in there when the base.tgz was created originally?
<nalioth> yes i have, crimsun
<crimsun> and you updated, as Yagisan mentioned?
<nalioth> i started this out with a full dapper sources.list (when i created the original base.tgz)
<nalioth> except for backports, of course
<crimsun> I generally update the pbuilders daily
<crimsun> which package is pbuilder not finding?
<Yagisan> nalioth: sometimes when updating *dapper* you don't get all the sources. try again after a few hours
<Burgundavia> nalioth, which mirror are you using?
<nalioth> archive.ubuntu.com
<nalioth> it doesnt do it with my breezy pbuilder, either, tho
<nalioth> er, it cant find the same pkg in the breezy pbuilder
<crimsun> which package?
<nalioth> libgtkglextmm1-dev   libgtkglext1-dev    neither one of these can be found with my breezy or dapper pbuilder
<crimsun> the former exists for ppc for certain
<crimsun> the latter, too
<crimsun> ``pbuilder login''
<crimsun> ``apt-cache policy libgtkglextmm1-dev''
<nalioth> ok
<nalioth> unable to locate
<crimsun> ``cat /etc/apt/sources.list''  (from within the pbuilder login)
<nalioth> i know it exists for ppc because i've compiled this program locally for myself
<nalioth> bingo
<nalioth> what i want to know is: are /etc/pbuilder/apt.config/sources.list  connected to the actual pbuilder ?
<nalioth> because i've got a full ubuntu sources.list there
<crimsun> if that's the path you provided in ~/.pbuilderrc, yes
<crimsun> I normally stash it in ~/porting/builder/apt.conf/  or something
<nalioth> path in pbuilderrc?
<nalioth> this has nothign to do with OTHERMIRROR ?
<crimsun> APTCONFDIR="/home/crimsun/porting/builder/apt.config/"
<crimsun> nope, not OTHERMIRROR
<nalioth> i just adjusted the sources.list, created a new base.tgz and it still doesnt find it
<crimsun> did you ``sudo pbuilder update --override-config'' ?
<nalioth> if i create a base.tgz, do i still need to update it?
<crimsun> yes, each day is a good refresh rate
<Yagisan> nalioth: I update mine before using them
<nalioth> ok. so even a freshly made base.tgz isn't updated
<crimsun> nope, not unless you update it manually using the above
<nalioth> ok. ty
<nalioth> my INCLUDEPACKAGE=gnupg  doesnt seem to work in my pbuilderrc
<nalioth> i've updated my pbuilder sources and updated it and it still can't find the package(s)
<crimsun> is it using the correct sources.list?
<nalioth> i have no idea where it is getting it's sources.list, i just logged into it and it has a sources.list that is not in my /etc/pbuilder/apt.config/
<crimsun> but does your ~/.pbuilderrc use a different APTCONFDIR?
<nalioth> this is really pissin me off
<nalioth> the ~/.pbuilderrc points to the above dir
<crimsun> and what are the contents of that dir?
<nalioth> i just did a save-after-login to install gnupg (cuz the INCLUDEPACKAGE=gnupg DOEASNT WORK
<nalioth> the same things in /etc/apt/ are in the above directory
<crimsun> of course INCLUDEPACKAGE wouldn't work. It's not a valid directive. You're supposed to use EXTRAPACKAGES.
<nalioth> ok
<ajmitch> evening all
<nalioth> is it common for pbuilder to eat ~2gb of space
<zakame> whoa ~2gb?!?
<ajmitch> nalioth: it can be
<ajmitch> for what part though?
<nalioth> yes, it locked me out of my box cuz it ran me out of space
<ajmitch> the aptcache? results dir?
<ajmitch> base tarballs shouldn't be too big
<nalioth> i had several things in /etc/pbuilder/build/X  mounted in /proc
<ajmitch> some projects can take 2-4GB to build
<Lathiat> sound slike you have build directories left ove
<Lathiat> that werent cleaned up
<ajmitch> like OOo is a disk hog
* ajmitch has a pbuilder dir taking 2.9GB
<ajmitch> and that's after I cleaned stale build dirs :)
<nalioth> well, now i'm locked out of my box, so am gonna wipe all vestiges of osx off of it
<seth_k|lappy> hey ajmitch, want to make history by approving REVU rights for the first female ubuntu uploader? ;) Hobbsee e-mailed her key to the keyring address awhile ago
<ajmitch> oh right
<ajmitch> I think I saw a keyid & nothing else ;)
<ajmitch> no 'please add me' or even 'heres my key' ;)
<seth_k|lappy> haha
<Hobbsee> hehe sorry about that!
<seth_k|lappy> the wiki should say that then :P
* seth_k|lappy adjusts wiki ;)
* LaserJock started to put link /var/cache/pbuilder to his 60GB backup partition so / wouldn't get full ;-)
<Hobbsee> hi ajmitch - please add me to revu
<Hobbsee> how's that?
<ajmitch> A good improvement
<seth_k|lappy> wiki updated, editnote "asking nicely works wonders" :P
<ajmitch> heh
<Hobbsee> hehe
* ajmitch just has to find sistpoty's standard reply to cut & paste
<nalioth> i'm screwed
<nalioth> now it won't load a breezy livecd
<ajmitch> heh
<minghua> nalioth: do you use APTCACHE for your pbuilder?
<Hobbsee> ajmitch: standard reply?  you could just give me the shortened version here
<seth_k|lappy> I added you to the keyring, you may proceed with uploading now. Please get your key signed by someone in the strong set, you'll need a signed key anyway  ;)
<seth_k|lappy> </standard siretart reply>
<Hobbsee> hehe ok
* Hobbsee thinks that will be difficult - i live in australia
<seth_k|lappy> um
<seth_k|lappy> ajmitch is practically next door! :P
<Hobbsee> ajmitch: where are you?
* seth_k|lappy is in the oklahoma desert, where crimsun is about his closest bet
<LaserJock> it think there are quite a few Australians running around
<ajmitch> Hobbsee: New Zealand
<Hobbsee> hehe, yeah, right, real close then
<ajmitch> Hobbsee: short answer is that it's added, login with your email address as used on that key on REVU & use the lost pw option there
<seth_k|lappy> see! practically next door! :P
<ajmitch> short trip across the ditch ;)
* LaserJock waves to seth_k|lappy across the Rockies from NV :-)
<seth_k|lappy> :)
<ajmitch> Hobbsee: where in .au? there are plenty of strange geeks around for keysignings
<Hobbsee> ajmitch: sydney
<ajmitch> no problem then
<ajmitch> there's at least a couple of people in this channel from sydney
<ajmitch> I'm sure SLUG probably run keysignings every now & then
<Hobbsee> true
<Hobbsee> i'll look into it - may end up waiting till march though, not sure yet
<ajmitch> right
<ajmitch> got something happening then?
<Hobbsee> i start university then
* ajmitch guesses you're not making the trip to .nz for LCA
<ajmitch> ah
<Hobbsee> hehe - i wish!
<Hobbsee> although, kamping_kaiser's going there, and then coming back via sydney - still workign all that out
<LaserJock> Hobbsee: what will you be studying at university?
<Hobbsee> LaserJock: a bachelor of technology in optoelectronics
<Hobbsee> ajmitch: no passport either - wouldnt help
<LaserJock> Hobbsee: cool, are/would you interested in scienctific packages?
<Hobbsee> ajmitch: hehe thanks...but...where do i log in?
<Hobbsee> LaserJock: possibly, i'm more working on the kde packages at the moment
<ajmitch> revu.tauware.de :)
<ajmitch> you don't need to login to upload
* Hobbsee bookmarks yet another link
<ajmitch> all the comments go there, and to the motu-reviewers list now
<LaserJock> Hobbsee: I started a MOTU Science team (wiki.ubuntu.com/MOTUScience) if you are interested
<Hobbsee> ok
* Hobbsee uploads her first package to revu
<LaserJock> Hobbsee: I'm a physical chemistry student that works with lasers so I know enough optoelectronics to be dangerous ;-)
<Hobbsee> hehe!
<Hobbsee> fun!
<ajmitch> LaserJock: nice :)
<seth_k|lappy> microbiology here, I'll infect you before you can shoot me with your lasers :)
* ajmitch is going back & doing electronics, possibly some optoelectronics :)
<LaserJock> seth_k|lappy: but I can shoot you from a large distance
<seth_k|lappy> hmm
<seth_k|lappy> I'll ponder this
* seth_k|lappy joins the MOTUScience team anyways
<seth_k|lappy> LaserJock's being on the MOTU team is confusing since he's not a MOTU :P
<ajmitch> you don't have to be a MOTU to be on the team :)
<LaserJock> I don't worry so much about the laser itself, we have ~6 50,000 V capacitors in the power supply
<ajmitch> ouch
<seth_k|lappy> ajmitch, I'll join both at once then ;)
<ajmitch> f?
<LaserJock> seth_k|lappy: yeah, we only have 1 MOTU on the team
<seth_k|lappy> LaserJock, no, I meant the MOTU team proper, not MOTUScience
<seth_k|lappy> remember I asked you once to review something because I saw you on the MOTU list?
<LaserJock> oh, yeah. I get confused about that too
<LaserJock> motu != MOTU
<LaserJock> ubuntu-dev == MOTU, right?
<ajmitch> LaserJock: yeah, not sure why you're on the motu group there :)
<ajmitch> ubuntu-dev == approved by TB
<seth_k|lappy> yeah
<ajmitch> and will be used to control upload rights once we move to soyuz (I can dream)
<LaserJock> ajmitch: some MOTU told me too, can't remember who though
<seth_k|lappy> ajmitch, how much stuff, in your opinion, should I have under my belt before I consider applying for MOTU? I've had nearly two dozen uploads into dapper, and am maintaining five packages.
<ajmitch> seth_k|lappy: that might just about be sufficient
<ajmitch> depending on what other MOTUs say
<ajmitch> since we have to vouch for the quality of your packaging, that you won't break stuff, etc
<seth_k|lappy> right
<seth_k|lappy> Riddell wanted me to hurry up and apply so we could have more KDE-oriented MOTUs :P that's what I really am focused towards.
<ajmitch> hehe
<seth_k|lappy> so I'm pretty sure he'd vouch for me
<ajmitch> but nobody uses KDE ;)
<seth_k|lappy> rawr
* Burgundavia notes that Ubuntu has lost Lathiat 
<Burgundavia> he has gone to the dark side, Kubuntu
<Hobbsee> haha sure they dont!
<ajmitch> Burgundavia: what?
<ajmitch> Burgundavia: oh man, no wonder he doesn't show up here anymore
<ajmitch> how will I be able to talk to him when I see him at LCA?
<Burgundavia> I am sure you can talk him out of it
* Burgundavia blames temporary insanity
<LaserJock> ajmitch: better bring a surgical mask, it can be contagious
<ajmitch> no, a large hammer will be better
<seth_k|lappy> haha
<seth_k|lappy> and then hm, sistpoty (who also happens to be my favorite MOTU) has reviewed a ton of my packages, so I'll bet he could note that my package quality is acceptable.
* seth_k|lappy ponders
<ajmitch> why talk someone out of something when you can beat it out? ;)
<LaserJock> lol
<Hobbsee> hehe
<Hobbsee> i rather like that idea - just dont beat me - i'll break!
<seth_k|lappy> now that we have a lady in our midst you will have to be gentler, ajmitch :P
<ajmitch> oh I am, don't worry
* ajmitch confesses to using KDE at times also
<ajmitch> seth_k|lappy: I'll try & be just as strict when reviewing packages though :)
<LaserJock> so now I wonder why I am a member of motu
<Hobbsee> i'll be fine :)
<ajmitch> LaserJock: not sure, it used to be so we all got the bug mails
<ajmitch> but then we set the contact address as a mailing list
<ajmitch> Hobbsee: just wait
<LaserJock> ajmitch: that could be, I vaguely remember somebody saying "why not"
<Hobbsee> oh dear, sounds ominous.  But hey, i've just realised, in the uploaders group, i'd never have to wear a nametag :P
<LaserJock> I guess I will just have to become a MOTU some time to fix the situation ;-)
<ajmitch> Hobbsee: why do you have a bunch of debdiff files in debian/ ?
<seth_k|lappy> ajmitch, I'm working with her on it
<seth_k|lappy> first upload, first time uupdate'ing :)
<Hobbsee> ajmitch: cos i screwed up, we're working on it
<ajmitch> right..
<LaserJock> ok, gotta get to bed. cya all
<ajmitch> m, debian/ as symlink..
<seth_k|lappy> g'night LaserJock, it's earlier for you than for me ;)
<ajmitch> just after 9PM here, hardly bed time
<seth_k|lappy> just after 9PM... tomorrow
<seth_k|lappy> 2:10am here, but saturday
<ajmitch> heh
<Hobbsee> you didnt want sleep anyway seth_k|lappy
<seth_k|lappy> did too, but who am I to resist the charms of a girl who needs packaging help
<ajmitch> I don't think I've ever actually used uupdate :)
<Hobbsee> hehehe
<ajmitch> sigh, geeks when there's a girl around
<Hobbsee> lol
<Hobbsee> it's more laughable from this side
<nalioth> pbuilder ate my hard driver
<ajmitch> I can imagine
<nalioth> how do you get it to clean up after itself?
<ajmitch> nalioth: APTCACHE="" will make it run a lot slower but it won't cache build-depends
<ajmitch> in the pbuilderrc
<Burgundavia> ajmitch, you read that piece "10 reasons to marry a geek"?
<ajmitch> and you can periodically clean the results dir
<ajmitch> Burgundavia: maybe
<nalioth> ajmitch: it wasnt the aptcache that locked me out
<nalioth> ajmitch: it was the build dir
* seth_k|lappy uses --buildresult ../ and builds each package's stuff in the dir right above, so I can remove everything at once when I'm done with that package
<Burgundavia> ajmitch, one of them was about worshiping the ground that the women walks on
<ajmitch> nalioth: no, but aptcache takes up a fair bit of space after awhile
<nalioth> ajmitch: i had 4 folders in /build that were mounted in /proc
<ajmitch> nalioth: pbuilder ought to remove build dirs once it finishes a build, whether success or failure
<Lathiat> nalioth: its the other wy around
<ajmitch> mounted in /proc?
<Lathiat> proc is mounted inside the build dirs
<Lathiat> ajmitch: sometimes it screws up
<Lathiat> i had a few lying around
<Lathiat> esp fi you ^C it
<ajmitch> Lathiat: sure, I have about 15 dirs still lying around
<nalioth> Lathiat: thank you, the point is: it ate my space
<ajmitch> ^C multiple times would do it
<Lathiat> nalioth: what you need to do, is umount all those procs
<Lathiat> nalioth: then rm -rf the build dir
<ajmitch> ^C once usually lets it clean up
<nalioth> too late, Lathiat i've used a fedore core 4 ppc64 install cd to take care of things
<nalioth> since the breezy liveCD wouldnt boot on my powermac
<Lathiat> wtf
<Lathiat> thats a bit darastic lol
<ajmitch> I'd say
* ajmitch has pbuilder running all on /home anyway
<nalioth> well, the thing wouldnt log in (ppc doesnt offer a 'rescue' option with yaboot)
<ajmitch> except on this laptop :)
<ajmitch> people in #ubuntu irritate me sometimes
<ajmitch> really
<Burgundavia> ajmitch, I gave up on that channel a few weeks back
* seth_k|lappy plugs along in #kubuntu, they need *somebody* to help them
<seth_k|lappy> the forums are a joke
<Burgundavia> seth_k|lappy, they are simply misinformed
<Burgundavia> especially the development one
<ajmitch> I'm about ready to give up on #ubuntu, except they like to have *someone* to keep order
<nalioth> seth_k|lappy: read "lost"
* Hobbsee isnt watching #kubuntu at all
<Burgundavia> geez ubuntu-devel is filled with long and useless threads recently
<seth_k|lappy> multitask! women are supposed to be good at it, Hobbsee !
<ajmitch> ubuntu-devel is getting steadily more useless also
<Hobbsee> ok, we here this time?
<Burgundavia> ajmitch, fedora-devel is quite bad. Look at debian-devel and d-d-l
<Burgundavia> Hobbsee, check
<Hobbsee> Burgundavia: excellent - connection just died for some reason
<ajmitch> oh debian-devel is quite noisy
<seth_k|lappy> nalioth, graah
<Burgundavia> I have noticed lots of aussies tend to do that
<seth_k|lappy> nalioth, as soon as you leave u-offtopic, people start pasting whole screens
* Burgundavia hugs his Canadian ADSL connection
<ajmitch> Burgundavia: and those of us in NZ
<Burgundavia> ajmitch, well, it is either old cable or flaky sats
* ajmitch has given up on u-offtopic
* nalioth is currently on his ibook G3 since he's making space on his regular box
<Yagisan> G'day all.
<Yagisan> Hi Hobbsee, nice to see someone else from sydney
<Hobbsee> hey Yagisan - definetly nice
<ajmitch> hi Yagisan
<ajmitch> how's it going?
<Yagisan> G'day ajmitch - not bad - I did a new ia32libs-universe upload to revu
<ajmitch> nice
* ajmitch hasn't tried to review it yet, sorry
<Yagisan> discovered that wine64 can't run 32bit win apps
<ajmitch> sadly
<Yagisan> and that to do that we need both wine, and a wine64 installed
<Yagisan> #winehq told me it was impossible - so I'll try to have something done by this weekend :)
<ajmitch> the usual way is in chroots
<ajmitch> but I know biarch stuff has been landing recently
<Yagisan> need to make a wrapper that can tell the difference between win64 and win32 apps
<ajmitch> there is a simple way, right?
<ajmitch> does 'file' give that info?
* ajmitch has no amd64 box to try it on?
<Yagisan> ajmitch: maybe, I'd have to look up PE header info and see if it changed much
<ajmitch> s/?//
<Yagisan> ajmitch: were is this biarch stuff you speak of ?
<ajmitch> ask jbailey, I think he was doing stuff :)
<Yagisan> ajmitch: also got word back that my mother-in-law survived her cancer surgery, and is still in ICU
<crimsun> Yagisan: send my regards. One of my good friends was just diagnosed with Hodgkin's and began chemo last night.
<ajmitch> Yagisan: oh, good to hear she's through that part
<Yagisan> crimsun: thanks.
<Yagisan> M-I-L had are large chunk of lung removed
<Yagisan> but they think they got it all
<ajmitch> so it hasn't progressed further? that's good to hear
<Yagisan> crimsun: I do hope your friend gets better.
<Yagisan> ajmitch: yep - all we can do now is wait. just in case I've started preparing the kids passports though
<ajmitch> they're solely australian citizens?
<Yagisan> ajmitch: nope - dual until 21, when Japan makes them choose
<Yagisan> ajmitch: it's just a *lot* of paperwork
<ajmitch> not too bad
<ajmitch> I thought they might have been stricter than that
<Yagisan> ajmitch: yep - the standard thing is say to Japan - yep I'm Japanese, but not tell any other country that :-D
<crimsun> Yagisan: thanks
<Yagisan> ajmitch: then no real changes
<ajmitch> heh
<seth_k|lappy> ajmitch, how much voodoo does it take to get marked as reviewer for REVU?
* seth_k|lappy thinks that might be a nice additional padding for his MOTU app
<Yagisan> seth_k|lappy: well, you need to be a full motu
<seth_k|lappy> Yagisan, no, you don't. raphink reviews, and he's not motu
<seth_k|lappy> you just can't advocate
<seth_k|lappy> from my understanding
<Yagisan> seth_k|lappy: I can't review and leave comments, as I'm not a motu yet. that's what siretart said, he said in revu2 that would be fixed
<ajmitch> seth_k|lappy: you need to convince others that your reviewing is worthwhile :)
<seth_k|lappy> hehe
<seth_k|lappy> sounds like it'd be better to concentrate on packaging for now, then
<seth_k|lappy> than to get diverted
<ajmitch> I'll talk to others & see
<Yagisan> ajmitch: you familiar with plone stuff ?? I'm looking for a plone on ubuntu for dummies, but google isn't helping much
<ajmitch> Yagisan: yes, I am
<ajmitch> apt-get install plone-site
<ajmitch> to get the basics
<ajmitch> iirc that'll setup a zope instance with plone loaded in it
<Yagisan> ajmitch: ok - that's all I need for a basic installation ?
<ajmitch> pretty much
<Yagisan> ajmitch: thanks - I was wondering why just installing plone didn't seem to do anything
<ajmitch> because plone has to live in a zope instance
<Yagisan> ajmitch: my website looks like shit, so I thought I'd try something new, pity they never really taught this stuff when I did my web stuff
<nalioth> where do i report flight bugs? bugzilla or malone?
<ajmitch> setting up & skinning a plone site does take a bit of effort
<Yagisan> nalioth: is the package main or universe ? if main bugzilla else malone
<Yagisan> ajmitch: that's fine - I have plenty of time - my main concern is CJK support
<ajmitch> ah
<ajmitch> I think most of the linguaplone code has been merged into plone 2.1
<nalioth> the liveCD won't boot in my powermac
<nalioth> if i have 2 partitions, can i have them both mounted on / or do i need to choose a dir in / ?
<Yagisan> ajmitch: I will be making a web-based presentation for the potential Japanese partner companies, and my poor wife needs to translate
<nalioth> i would like to merge my free space, but i can't get any liveCDs to load
<ajmitch> Yagisan: plone generally has excellent i18n capabilities compared to others
* Mez finally finds out how to let the backports bugs go straight to the mailing list from launchpad without having to accept them all or have the person on the list
<Mez> X-Launchpad-Bug: product=breezy-backports; .*
<Mez> yay!
<ajmitch> Mez: useful
<Mez> made a filter rule for it :D
<Yagisan> ajmitch: thanks - may I bother you if I hit any snags on the way ?
<ajmitch> how do you automatically approve those in mailman?
<ajmitch> sure
<ajmitch> that's what the zope team is for :)
<Yagisan> nalioth: You can't have two partitions mounted as / . You'd lose access to the first one, when you mount the second
<Mez> ajmitch - > in privacy options - > spam filters
<ajmitch> right
<Mez> you can set a regexp on headers to auto-accept
* Mez adds
<Mez> X-Launchpad-Bug: .*product=breezy-backports;.*
<Mez> X-Launchpad-Bug: .*assignee=ubuntu-backports@lists.ubuntu.com;.*
<ajmitch> ah, I didn't see that on the list I wanted
<ajmitch> (ubuntu-mono)
<Mez> :D
<Mez> for bugs to be accpted I take ?
<Mez> It's a good thing
* ajmitch was impressed to see https://launchpad.net/people/ajmitch/+packages now
* Mez finally doesnt have the darn thing buggging him everytime someone files a bug
<ajmitch> the main thing is that we can't subscibe the team to those packages
<ajmitch> although each of us can subscribe to them now
<Mez> subscribe ?
<minghua> ajmitch: like debian's PTS?
* minghua probably should subscribe to scim stuff
<ajmitch> minghua: not nearly as good
<ajmitch> Mez: subcribe, get bug reports, etc
<Mez> oh
<Mez> I thought you could subsciribe teams
<Mez> they count as people don't they ?
<ajmitch> they should
<Mez> but dont?
<ajmitch> but I don't think it worked - I didn't try myself
<Mez> try ;) :P
<ajmitch> hm, seemed to work now
<ajmitch> maybe they fixed it
<ajmitch> as often happens
<minghua> when you close a bug, the bug that is labeled as duplicate doesn't get closed automatically?
<seth_k|lappy> marking a duplicate is a form of closing
<minghua> seth_k|lappy: it still shows as [Accepted]  in the "lastest bugs" window, which looks bad
<minghua> seth_k|lappy: not that I have a big complaint though
<seth_k|lappy> minghua, ahh, in LP
<seth_k|lappy> sorry, thought you meant bugzilla
<seth_k|lappy> file a malone bug or yell at #launchpad, I hear they love that stuff ;)
<nalioth> does anyone know a bootable livecd that works on a dual proc powermac  G5?
<minghua> I'll yell in #lauchpad I think
<minghua> not in the mood of filing bug
* minghua has at least two debian bugs that he should file
<seth_k|lappy> ajmitch, I think Hobbsee is ready for you now ;) the package isn't as clean as a new one would be, but for sticking with upstream and not deviating too drastically it should be fine.
* Hobbsee is scared now
<Hobbsee> :P
* seth_k|lappy is DEFINITELY going to bed, 3:30 am
<Hobbsee> hehe nah - i'll keep you up even longer seth_k|lappy!
<seth_k|lappy> tch
<seth_k|lappy> you're not a real girl
<seth_k|lappy> I can turn you off by clicking...
<ajmitch> silly people
<Hobbsee> hehe
<nalioth> i can't believe i'm having to use a &#@#*$@*@ redhat install cd to rescue myself
<Yagisan> nalioth: you must have broken it really good. All this for pbuilder ?
<ajmitch> I'm quite impressed
<zakame> nalioth w00t
<nalioth> pbuilder ate all my space
<ajmitch> you must have a small drive
<nalioth> i'm fixing the problem
<nalioth> what gets me, is that breezy and flight-2 liveCDs won't boot in the machine
<ajmitch> Hobbsee_away: bad news is that it didn't build in pbuilder
<ajmitch> more correctly, the source didn't even unpack
* Mez goes to bed for a couple of hours
* ajmitch goes to bed for ~8hrs :)
<ajmitch> bbl
<Mithrandir> enjoy. :-)
<Hobbsee_away> ajmitch: what???
<Hobbsee_away> built on my pbuilder!
<Hobbsee> ok, now i'm confused - i'll look at this again after more sleep
<crimsun> Hobbsee: url?
<Hobbsee> crimsun: http://revu.tauware.de/details.py?upid=1419
<Hobbsee> ok, it's not building on my pbuilder anymore - it screwed up somehow
<crimsun> Hobbsee: k, sec
<Gloubiboulga> hello
<Hobbsee> hey Gloubiboulga
<Gloubiboulga> hi Hobbsee
<crimsun> Hobbsee: since my revu login isn't working, I'll comment here: You might consider versioning the package along the lines of what Debian experimental uses: http://packages.qa.debian.org/k/kradio.html
<crimsun> Hobbsee: you don't necessarily have to use Debian's infrastructure, but it's easier maintenance-wise
<crimsun> Hobbsee: if you decide to keep your packaging infrastructure, I recommend you version yours as 0.9+1.0beta3b, that way an official 1.0-0ubuntu1 (or 1.0-1 from Debian) will replace it cleanly
<Hobbsee> ok
<Hobbsee> crimsun: ok
<crimsun> Hobbsee: I recommend you actually start with http://kradio.sourceforge.net/download/kradio-snapshot_2005_12_04.tar.bz2
* Hobbsee mutters darkly about how the package screwing up on her machine now, as well
<Hobbsee> ok
* Hobbsee is thinking of starting from scratch
<crimsun> that can be versioned as 0.1+snapshot20051204-0ubuntu1
<Hobbsee_away> yep
<Hobbsee_away> crimsun: even though the other versions started with 0.3?
<StevenK> Dates usually appear first.
<crimsun> Hobbsee_away: it's up to you, really. I would just avoid use 1.0* as the base, since eventually you'll want an official, final 1.0
<StevenK> 2005.12.04-snapshot-0ubuntu1
<StevenK> Wait. Let me find a package that actually uses a date. :-)
<StevenK> 0.2004090900-1.1build1
<StevenK> That's what I was thinking of.
<crimsun> right, like wine has used all these years.
<StevenK> The problem is, if you include a date, dpkg may require you to add an epoch.
<StevenK> (When you hit 1.0)
<Hobbsee_away> true
<Yagisan> StevenK: why might you need to add an epoch ?
<StevenK> Because 1.0-1 < 0.200409090-1
<StevenK> (Possibly)
<Yagisan> StevenK: if the version is <1lessthenreal>+<real>+date+ubuntu
<Yagisan> StevenK: ah - I see - slight misunderstanding
<StevenK> Oooer, that's false.
<crimsun> just try dpkg --compare-versions 0.2004090900-1.1build1 lt 1.0-1 && echo "1.0-1 is greater"
<StevenK> steven@broken:~% dpkg --compare-versions 1.0-1 gt 0.200409090-1 && echo 'Yay'
<StevenK> Yay
<tseng> Lathiat: yep, on the rails blog
<Lathiat> tseng: :)
<tseng> DHH is always too "dapper" to be a geek
* StevenK smacks \sh.
<StevenK> \sh_away: xterm is not a native package!
<crimsun> it wasn't packaged as a native one
<minghua> I think xterm is now
<minghua> at least in debian
<StevenK> xterm 208-0ubuntu1 isn't native either.
<crimsun> I can't see where he did anything wrong.
<crimsun> dnusinow did pretty much the same thing
<crimsun> oh, I see
<minghua> scratch that
<crimsun> there's no .orig.tar.gz to correspond to his -0ubuntu1
<minghua> xterm 208-1 in debian still has .orig.tar.gz
<crimsun> right
* minghua goes to bed
<minghua> see you guys
<crimsun> k, merges continue.
<jpatrick> is someone merging smb4k?
<chninkel> I need a package to be rebuilt to correct a dependancy
<chninkel> how do I request this ?
<chninkel> see https://launchpad.net/distros/ubuntu/+source/mercator/+bug/6528
<Ubugtu> Malone bug 6528: "libmercator-0.2-4c2a can't be installed (libstdc++ new allocator build)" Fix req. for: mercator (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/bugs/6528
<Hobbsee> ajmitch: http://revu.tauware.de/details.py?upid=1419 - done a new version, hope it works, off to sleep now
<Hobbsee> hmmm...new version isnt showing yet, but it's the one that has snapshot in the version name
<zakame> evening MOTUs
<jpatrick> zakame: (Not a MOTU): evening
<zakame> heya jpatrick :)
<zakame> jpatrick: but I think you'll soon be ;)
<jpatrick> have to wait for the CoC meeting :0
<zakame> ooh, that's just around the corner :)
<jpatrick> can someone look at http://revu.tauware.de/details.py?upid=1420 ?
<zakame> checking
<jpatrick> new upstream release
<jpatrick> that's all
<zakame> hm version should be 0.6.5-0ubuntu1 to avoid conflicting with the (eventual) Debian release of 0.6.5-1
<zakame> and yes, lintian says source-contains-CVS-dir
<jpatrick> zakame: reuploading
<zakame> jpatrick: w00t
<StevenK> zakame: Okay, I accept what you say about linkchecker, so can you request a sync?
<StevenK> zakame: Also, in regards to moin, I noticed Debian has a newer version, so I have prepared a new debdiff.
<Yagisan> G'day mhz
<StevenK> -rw-r--r--  1 steven users 16K 2006-01-08 01:00 moin_1.4.99+1.5.0rc1-1ubuntu1.debdiff
<zakame> heya Yagisan , mhz , StevenK :)
<mhz> G'day (as in good duy), Yagisan
<mhz> zakame: nice to greet ya
* StevenK waves to zakame after throwing multiple questions at him.
<zakame> hehe
<StevenK> zakame: I can upload the new moin debdiff to LP, or I can throw it on the web?
<Yagisan> G'day zakame,
<Yagisan> mhz - have you used plone ?
<mhz> Yagisan: 3 duys only
<mhz> Yagisan: what d'u need?
<zakame> StevenK: sync requested :) yeah, just upload the moin debdiff :)
<zakame> brb
<Yagisan> mhz: I've just installed a test version, and made a simple page in english. I now want to make a translated version of the same page
<Yagisan> mhz: I ended up with 2 visible pages, when what I want is 1 for english, and 1 for japanese - depending on browser language
<Yagisan> mhz: and perhaps latter, 1 spanish ;)
<mhz> heheh
<mhz> Yagisan: Plone looks nice for it, indeed
<mhz> Yagisan: have you tried Trac ?
<Yagisan> mhz: no, I'm making my way through universe
<mhz> okis
* mhz thought trac was in universe
<Mithrandir> it's in trac in breezy at least
<Mithrandir> s/trac/universe/
<tseng> its a nice package
<StevenK> Depends: python (<< 2.5), python (>= 2.4), python2.3
* StevenK slaps forehead.
* Yagisan may have missed it - how well does trac support CJK ?
<StevenK> *Stupid* ${python:Depends}!
<StevenK> zakame: Right, I will need to debug that problem, I will upload a new, fixed debdiff after I wake up.
* StevenK staggers off to bed.
<mhz> Yagisan: no idea about CJK, but I do know it has nice features you'll just love to have around
<chninkel> I have a package that depends on lesstif2 which is in debian but not in ubuntu
<mhz> and yet, it's made simple
<chninkel> how to I request this package to be synced ?
<Yagisan> mhz: CJK is an essential requirement for me, for obvious reasons :)
<mhz> Yagisan: CJK is for japaneese stuff, right/
<mhz> ?
<Yagisan> mhz: Chinese Japanese Korean
<mhz> Yagisan: Trac uses MoinMoin wiki as its wiki (CMS) and I have seen Japaneese/Chineese people happily working with Moin, so I guess you should have no trouble at all
<mhz> Yagisan: and if moin is no good for you... you can always slap me or pour lemmon juice in my eyes
<Yagisan> mhz: I'll also test it too, although it's not really for a "development" site
<zakame> back
<mhz> Yagisan: just ping me if you need anything
<mhz> Yagisan: but on a second thought, if you feel already confident with Plone...
<lifeless> so, pbuilder
<Yagisan> mhz: I wouldn't say confident - I've only had it running for about 30minutes or so
<lifeless> how are you meant to combine the _source changes and the pbuilder output ?
<mhz> Yagisan: my whole life has passed thruogh my eyes in less than that :D
* mhz in a meeting at #edubuntu-es
<Yagisan> lifeless: still up, shouldn't you be in bed at this hour
<Yagisan> ?
<lifeless> yes
<Yagisan> lifeless: raining up there at epping ? just finished down here
<lifeless> I dont think so
<lifeless> cant hear it
<zakame> hmmm
<thierry_> I need to fix a makefile so that it installs the .so file (for shared librairy), and I know nothing about makefiles, could you point me some doc or people who could help me?
<thierry_> zakame : are you in the science team?
<thierry_> zakame : are you in the science team?
<zakame> thierry_: heya, no, at least not yet :)
<thierry_> anyone on science team here?
<zakame> hm LaserJock isn't around :(
<azeem> thierry_: because of the .so file?
<thierry_> no no it's something else
<azeem> ah
<zakame> heya azeem :)
<azeem> hi
<thierry_> I just want to get my patch at https://launchpad.net/distros/ubuntu/+source/geg/+bug/5399 reviewed faster and I was wondering if I should add the science team in CC since geg is math app
<Ubugtu> Malone bug 5399: "[PATCH]  adding a .desktop file to geg" Fix req. for: geg (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: New http://launchpad.net/bugs/5399
<zakame> ah
<chninkel> i am working on the xmakemol package which needs the GLwMDrawA.h file
<chninkel> it doesn't seem to be available: http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=GLwMDrawA.h&searchmode=searchfiles&case=insensitive&version=breezy&arch=i386
<chninkel> is this normal ?
<azeem> chninkel: why are you working on it?
<chninkel> azeem: merging
<azeem> chninkel: that search you cite is for breezy, packages.u.c does not have dapper for file searching it seems
<chninkel> azeem: i also try auto-apt search -f GLwMDrawA.h
<azeem> bah, does this mean Ubuntu and Debian have different names for the GL libraries now?
<chninkel> azeem: GLwMDrawA.h was present in hoary but not in breezy, I supposed the file disappeared after GLUTransition
<chninkel> azeem: do you know someone who can answer me on this problem ?
<zakame> chninkel: re: lesstif2, it seems src:lesstif1-1 dropped building the binary lesstif2
<azeem> chninkel: which version of the package are you trying to compile?  The breezy one, or something merged?
<zakame> chninkel: Debian already has a separate src lesstif2 package
<chninkel> zakame: yes I opened a bug for this: https://launchpad.net/distros/ubuntu/+source/lesstif1-1/+bug/6536
<Ubugtu> Malone bug 6536: "1 (Ubuntu) - new package lesstif2 " Fix req. for: lesstif1-1 (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: New http://launchpad.net/bugs/6536
<chninkel> zakame: can't we sync this package ?
<chninkel> zakame: I thought the lesstif1 has still lesstif2 support
<chninkel> azeem: I am working on dapper on merging lastest xmakemol package
<zakame> chninkel: prolly, but I think this is autosynced
<chninkel> zakame: the changelog date is 11 Nov 2005
<chninkel> zakame: on debian
<chninkel> zakame: but it's maybe not the date of arrival of the package in debian
<chninkel> zakame: how frequently are packages synced ?
<zakame> hm
<azeem> if [  -r $indir/$FILE.out.orig ] ; then
<azeem>         cp -u $indir/$FILE.out.orig $indir/$FILE.out;
<azeem> else
<azeem>         molpro < $indir/$FILE.com > $indir/$FILE.out;
<azeem> fi
<azeem> argh
<azeem> sorry
<reaper1> anybody there?
<zakame> heya reaper1 :)
<reaper1> nice to meet you zakame
<zakame> what's up, reaper1 ?
<reaper1> do you know where i can find eoisodes of the 2002 masters of the universe tv series
<Yagisan> reaper1: well, they aren't here
<zakame> whoa, ubuntu-motu has a TV series?!?
<reaper1> been looking everywhere with no luck
<Yagisan> reaper1: this isn't a downloads channel - it's a development channel
<reaper1> sorry can someone suggest a download channel that might have what im looking for im new to this
<azeem> reaper1: google just announced such a service, maybe iTunes Video store?
<reaper1> thank for your help
<jpatrick> zakame: lol
<zakame> chninkel: seems you'll have a blast with xmakemol, lesstif2 is dropped from dapper
<chninkel> zakame: why that ?
<chninkel> zakame: where do you find this info ?
<zakame> chninkel: <pitti> zakame: because it's crack, and we don't want/need it
<zakame> chninkel: at -devel
<zakame> #u-devel
<Amaranth> xmakemol? what does that do?
<chninkel> Amaranth:  visualizing atomic and molecular systems
<chninkel> Amaranth: I don't use myself
<Amaranth> did someone request it?
<chninkel> Amaranth: it was in the merge list
<Amaranth> ah
<Amaranth> sounds like it'll have to be dropped
<zakame> indeed, if lesstif2 is crack
<chninkel> Amaranth: I'll check if it can be compiled with lesstif1 but I have still a problem with a missing header file
<zakame> chninkel: or, you could try hacking on xmakemol with upstream, and convince them to use something else other than lesstif*
<azeem> zakame: a different toolkit?
<chninkel> zakame: different toolkit would need a big rewrite no ?
<Amaranth> something we don't want to do, yes
<zakame> chninkel, azeem: yeah, but that wouldn't be needed to be done by MOTU
<zakame> indeed, it would be best for xmakemol to be dropped for now
<chninkel> zakame: ok will try to build with lesstif1, but I will drop this package if this can't be done
<chninkel> zakame: by curiosity, why is lesstif2 crack ?
<zakame> chninkel: dunno myself, ask pitti :)  I asked in -devel why it wasn't yet in dapper...
<Amaranth> chninkel: too many security issues
<Amaranth> basically it was a PITA to have because pitti kept having to make security updates
<chninkel> Amaranth: ok I see
<zakame> gn8 all, good luck chninkel :)
<chninkel> zakame: thks, gn8
<Yagisan> night all
<azeem> chninkel: lesstif2 will be back, it just needs a sync
<chninkel> azeem: ??
<azeem> chninkel: when pitti said "we don't need it", he meant in main
<azeem> it is supposed to be in universe, but on the merge blacklist right now, as it got built from two source packages
<azeem> that should be worked out soon
<chninkel> chninkel: ok
<chninkel> azeem: thanks for the answer
<LaserJock> bmonty | tseng : ping?
<thierry_> LaserJock : could you check https://launchpad.net/distros/ubuntu/+source/geg/+bug/5399
<Ubugtu> Malone bug 5399: "[PATCH]  adding a .desktop file to geg" Fix req. for: geg (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: New http://launchpad.net/bugs/5399
<thierry_> LaserJock : if it's alright, I'll start creating a lot of .desktop file for science apps
<LaserJock> thierry_: ok
<thierry_> LaserJock : and if you're a MOTU you can always leave a comment saying "ok to upload" :)
<LaserJock> thierry_: unfortunately, I'm not a MOTU yet
<jpatrick> me neither
<thierry_> k
<thierry_> LaserJock : so is it ok?
<LaserJock> thierry_: just a sec
<LaserJock> thierry_: did you create the icon?
<\sh> moins
<\sh> raphink: ping
<Gloubiboulga> hi \sh
<raphink> \sh: pong
<\sh> raphink: you remember what we talked about this morning, about wesnoth and the patch?
<\sh> raphink: http://gna.org/bugs/?func=detailitem&item_id=4992
<\sh> raphink: the upstream patch is totally wrong...ours is right :)
<raphink> hmm ok :)
<\sh> raphink: you can read it there :)
<raphink>  static int unit_internal_compare(wesnoth_unit* left, wesnoth_unit* right)
<raphink>  {
<\sh> raphink: it's the original bugreport btw :)
<raphink>  return (int)left->unit_ - (int)right->unit_;
<raphink>  }
<raphink> 
<raphink>  should be replaced by
<raphink> 
<raphink>  static int unit_internal_compare(wesnoth_unit* left, wesnoth_unit* right)
<raphink>  {
<raphink>  return (int)(left->unit_ - right->unit_);
<thierry_> LaserJock : no it's in the package source
<raphink>  }
<raphink> what's the diff???
<\sh> raphink: no read the comments :)
<raphink> oh yes
<raphink> I see the diff
<raphink> hehe sorry
<raphink> but it doesnt' change the (int) into (long) though
<raphink> this patch is wrong iyo?
* raphink reads the comments
<LaserJock> thierry_: it's kind of a bad name for an icon since one would expect it to be the same as the app's name
<LaserJock> thierry_: but if they did it and not you it's probably not good to go renaming it ;-)
<raphink> \sh: did you test it on 64 ?
<\sh> raphink: yes..the mentioned reporters patch is broken...I commented on this...and the guy replied and saw his mistake :)
<raphink> ok
<raphink> good
<\sh> raphink: I can
<\sh> 't play it :) I don't have a monitor and ssh -X and then chroot_dapper doesn't work :)
<raphink> lol
<\sh> raphink: but I know I'm right :)
<raphink> ok
<raphink> :)
<raphink> good
<raphink> so we shall not sync -2 from Debian
<raphink> since it's not fixed properly in it
<thierry_> LaserJock : it wasn't initialy the icon for the app, but the icon for sinus graph
<\sh> raphink: that's what I said this morning and we didn't :)
<raphink> yes
<raphink> I was just seeing a few hours ago that -2 had entered the repos in Debian so it's in the merge list now
<\sh> i'll take care about it :)
<raphink> ok :)
<LaserJock> thierry_: well, I'm not as good at reviewing stuff as ajmitch or
<LaserJock> \sh but it looks good to me
<\sh> LaserJock: but the amd64 patch debian applied is totally wrong
<LaserJock> \sh: sorry was taking to thierry_
<LaserJock> s/taking/talking/
<raphink> lol
<thierry_> LaserJock : ok and for category stuff, do we really only keep the science menu?
<\sh> LaserJock: oh ,)
<LaserJock> thierry_: what else would you suggest?
<raphink> \sh: I was just looking at openwengo today
<thierry_> well we talked about putting it also in education until gnome decide to put a real science menu...
<raphink> it's a nice app I've heard
<raphink> but I tried to package it once and the sources are a mess
<raphink> additionnaly, they have a .deb but it installs what should be in /usr/share in /usr/lib instead, which is very dirty
<raphink> :s
<LaserJock> thierry_: well, my view at this point is that if it isn't educational it should go there
<thierry_> k
<LaserJock> thierry_: we are more likely to get them to give us a science menu if there are apps that need it
<thierry_> LaserJock : so I can do other .desktop file like that for sciences apps?
<LaserJock> thierry_: have at it!
<thierry_> :D
<LaserJock> thierry_: I would never stop you from working
<raphink> there's something that's not very nice about REVU : you can't really tell from the list what packages are to be reviewed and which ones are not
<thierry_> Is there anyway to get a graphical text editor working in a dapper chroot (like gedit)?
<thierry_> raphink : well normally when they are on REVU, it's to be reviewed no?
<raphink> thierry_: when I have already put comments on a package on REVU, I don't necessarily want to review it again unless it has been changed
<raphink> thierry_: you can't easily find out what packages need to be reviewed or not
<raphink> meaning : some packages have already received enough comments to be changed, and I don't want to review them before these changes are commited
<\sh> the question is if we should move packages to a separate queue if the last upload is older then let's say 2 weeks from the last comment
<raphink> mhm
<raphink> hmm
<thierry_> good idea, like a to review list and a "waiting new upload" list
<raphink> how does cdbs deal with qmake?
<\sh> hmm..there should be a make command replacement variable
<raphink> mhm
<raphink> well this soft doesn't compile anyway
<raphink> and I'm just very lazy today :s
<raphink> basket is an interesting concept
<raphink> :)
<jpatrick> raphink: when you have time can you give my smb4k a poke? http://revu.tauware.de/details.py?upid=1422
<raphink> let's see
<jpatrick> it's just new upstream release
<raphink> jpatrick: this is not new soft and REVU might not be the best place for that
<raphink> imo
* raphink thinking
<jpat|away> ?
<raphink> nm
<raphink> I'll review it
<raphink> jpat|away: can you add precision to your changelog? It'll help in the future
<raphink> if you say that you switched to compat 5
<raphink> instead of just saying you bumped compat
<AngryAngryHippos> hi all, are you guys looking for LTSP testers?
<raphink> LTSP?
<AngryAngryHippos> ya, thin client
<AngryAngryHippos> Im looking to set up a tuxlab-style thin client environment
<raphink> why so?
<raphink> nice
<AngryAngryHippos> I was hoping to get some advice and hopefully provide some feedback to help improve the system
<raphink> why ask here?
<AngryAngryHippos> im new to ubuntu tho, so I didnt know where to go
<AngryAngryHippos> someone in #ubuntu told me to check here
<raphink> oh ok
<raphink> :)
<raphink> hmm
<segfault> where's pastebin src available?
<raphink> well let me try to understand your point AngryAngryHippos
<raphink> you want to setup a new app
<raphink> so your point is dev, right?
<AngryAngryHippos> um... I dont think so
<AngryAngryHippos> I just want to set up a thin client environment
* irvin points AngryAngryHippos to #edubuntu
<AngryAngryHippos> oh are they only doing thin client for edubuntu?
<irvin> yes AngryAngryHippos
<AngryAngryHippos> hm... is it possible to get it running with regular ubuntu?
<\sh> well no
<\sh> the thinclient implementation is as well in ubuntu..edubuntu is only a "only thinclient distribution"
<raphink> oh by thin client you mean X terminals ?
<AngryAngryHippos> is it possible then to make edubuntu LOOK like regular ubuntu?
<raphink> ^^
<AngryAngryHippos> yeah
<AngryAngryHippos> like tuxlab
<raphink> ooooh
<segfault> angryangryhippos: install ltsp-server-standalone.
<raphink> :)
<AngryAngryHippos> ok Ill try that
<raphink> well I guess if you make your server look like ubuntu
<raphink> then the terminals wil llook like it
<raphink> ;)
<AngryAngryHippos> segfault - is that for a dedicated server-only system?
<AngryAngryHippos> ie. I wouldnt want to install that on my desktop as a testbed
<segfault> it has the dependencies to make ubuntu work as a LTSP server (which is basically what edubuntu does)
* raphink wonders why it's not possible to set thin clients by simply installing basic stuff on the clients, enabling XDMCP on the server and setting the clients to log on the server ...
<AngryAngryHippos> ah ok
<AngryAngryHippos> let me try that
<raphink> or do I totally misunderstand the point?
<AngryAngryHippos> raph, that might work
<raphink> but?
<AngryAngryHippos> but we eventually plan to buy actual thin client systems
<raphink> ok
<AngryAngryHippos> ie with 64 megs of compact flash and no HD
<segfault> rephi: it is, you can use, on a client with local HD and X packages installed: X -query IP.OF.YOUR.SERVER
<raphink> yes
<LaserJock> wow, just emailed debian-science about the MOTUScience team. Didn't go over quite as I had expected.
<raphink> that's what I usually do segfault
<segfault> but in some cases the thin client has no local devices, and boot remotely using PXE/etc, get its kernel via tftp, and go on.
<raphink> segfault: so there are special stuff to make thin clients work without having them run X locally?
<segfault> raphink: yes, basically dhcpd, tftpd, nfs
<Mithrandir> uhm, you must run X locally on the thin client.
<AngryAngryHippos> ya segfault, thats what Im trying to do
<Mithrandir> raphink: just xdmcp is insecure.
<raphink> Mithrandir: thats what I thought
<raphink> Mithrandir: you can use xdmcp over ssh to make it secure
<Mithrandir> which is why edubuntu uses X-over-ssh
<raphink> hehe ;)
<LaserJock> I find vnc-over-ssh to be much better than X-over-ssh
<raphink> but then I guess it might use RSA keys to not both users with entering passwords Mithrandir ?
<Mithrandir> raphink: yes, obviously.
<raphink> LaserJock: it's just not the same purpose
<raphink> LaserJock: how would you use vnc to deal with a park of think clients sharing a server ?
<LaserJock> beats me :-)
<raphink> either I'm wrong or vnc cannot create new X sessions, it can only use already opened ones
<raphink> ;)
<AngryAngryHippos> hey segfault, is there a decent tutorial somewhere on how to set up ltsp-server-standaline?
<AngryAngryHippos> I've tried https://wiki.ubuntu.com/ThinClientHowto but its not much help
<AngryAngryHippos> im getting "* Starting DHCP server...                                               [fail] 
<AngryAngryHippos> "
<raphink> AngryAngryHippos: then once you find out how to set it up, you can improve the wiki page :)
<AngryAngryHippos> sure
<AngryAngryHippos> Id love to
<AngryAngryHippos> haha its pretty sparse now
<raphink> :)
<segfault> angra: check your daemon.log, maybe there's some typo in your dhcpd.conf
<raphink> well then set your dhcp server and retry ;)
<AngryAngryHippos> when I apt-get installed ltsp, it asked to overwrite my dhcpd.conf and I said yes
<thierry_> anyone know how to get a graphical text editor (like gedit) working in a dapper chroot
<Mithrandir> thierry_: you want to do a bind --mount /tmp /path/to/chroot/tmp to get X apps to work correctly.
<raphink> thierry_: use -d
<psusi> ok, I really do not like malone... can't you upload an attachment to a bug?
<psusi> ahh, there it is....
<raphink> thierry_: dchroot -c mychroot -d
* psusi misses bugzilla
<thierry_> raphink : I already do and I still get the "cannot open display" thing
<thierry_> Mithrandir : bash: bind: --: invalid option
<slomo> mount --bind /tmp /path/to/chroot/tmp
<segfault> mount --bind?
<slomo> the other way around
<psusi> hrm... the bug didn't get assigned to anyone... is there default assignee for e2fsprogs?
<Mithrandir> thierry_: sorry, mount --bind /tmp /path/to/chroot/tmp
<thierry_> I get : Xlib: connection to ":0.0" refused by server
<thierry_> Xlib: No protocol specified
<thierry_> (gedit:23331): Gtk-WARNING **: cannot open display:
<jpat|away> raphink: okay
<Mithrandir> you probably need to bind-mount your home directory as well
<thierry_> how
<Mithrandir> mount --bind /home /path/to/chroot/home
<thierry_> working! thanks!
<psusi> Theodore Y Ts'o is listed as the maintainer of e2fsprogs, but malone doesn't seem to know anything about him... why is that?
<Mithrandir> psusi: he's the debian and upstream maintainer, he doesn't maintain it in Ubuntu
<psusi> I see... so nobody maintains the -ubuntu version?
<jpat|away> raphink: reuploaded
<Mithrandir> psusi: there's nobody in particular caring for it, but as it's a fairly important package, it's being taken care of by the people who can upload to main
<raphink> what was wrong with it jpat|away ?
<psusi> hrm... looks like malone knows about the last person to modify the -ubuntu version... Tollef Fog heen
<psusi> I guess I'll assign it to him
<tseng> you are talking to him
<psusi> ohh.... hi ;)
* tseng points at Mithrandir 
<jpat|away> raphink: precision
<\sh> psusi: https://launchpad.net/distros/ubuntu/+source/e2fsprogs there is he mentioned btw
<psusi> ok... bug is assigned and has the .debdiff attached
<\sh> ok..all the new merges with mom reports are gone...just need to wait for the buildd
<psusi> Mithrandir, brw... do you have any idea why upstream even has ext2_types.h?  It appears to just duplicate what's in asm/types.h, so why didn't they just include that?
<psusi> s/brw/btw
<Mithrandir> psusi: because userspace shouldn't access the files from linux-kernel-headers directly.
<psusi> it isn't in the linux source tree, it's in /usr/include
<Gloubiboulga> \sh, do you think that xmms-wma could be included in multiverse ?
<\sh> Gloubiboulga: dunno...I'm not elmo :)
<Gloubiboulga> elmo is the multiverse master ?
<\sh> Gloubiboulga: if there are no legal problems with it...why not..but consult elmo first...
<Gloubiboulga> ok
<\sh> Gloubiboulga: no elmo is our licensing and legal specialist and ftpmaster :) if he says it's not worth it to include it because of troubles with others..he is 99% right :)
<Gloubiboulga> \sh, I'll ask the licensing specialist then :)
<\sh> Gloubiboulga: write an email go james@ubuntu.com and give him the location of the package :) and of upstreams homepage ... so he gets all infos
<Gloubiboulga> ok, thanks \sh
<psusi> can you not set other bugs as blocking in malone?
<Gloubiboulga> bbl
<marcin`> hello
<marcin`> could someone help me with texinfo package?
<marcin`> I use dapper
<marcin`> and currently texinfo package says:
<marcin`> /var/lib/dpkg/info/texinfo.postinst: line 56: update_ls_files: command not found
<marcin`> after installation
<marcin`> could someone tell me what is this update_ls_files command?
<marcin`> and why it's missing in dapper now?
<\sh> marcin`: there is a bug report about it...it's named update_lsr_files or something
<marcin`> yes
<marcin`> where can I find this bug report?
<\sh> bugzilla
<\sh> marcin`: http://bugzilla.ubuntu.com/show_bug.cgi?id=22004
<Ubugtu> Error: Could not parse XML returned by Ubuntu: not well-formed (invalid token): line 99, column 75
<marcin`> \sh: thanks
<\sh> marcin`: 4.8-3 fixes the issue and is in dapper
<\sh> oh wait..made a mistake
<\sh> no...I was right :) 4.8-3 is the correct working package
<\sh> but it's not in dapper...it will be synced soon :)
<\sh> hmmm...
<\sh> tiber just disappeard
<\sh> now its back :)
<slomo> \sh: hm, i can still login
<\sh> yes..but webserver was just gone
<ajmitch> morning all
<\sh> hey ajmitch
<jpatrick> morning ajmitch
<LaserJock> \sh: you didn't like plotdrop's .desktop file?
<\sh> LaserJock: argl...i didn't see it in the source :) i was searching for it in the debian dir :) forget it ...i just advocated it anyways :)
<LaserJock> \sh: np
<LaserJock> if a package is just put in sid will it get synced automatically to dapper?
<LaserJock> \sh: ^^ ?
<\sh> hmmm...should be
<\sh> i'm not sure how the auto sync stuff works
<LaserJock> until when, UVF?
<\sh> when it's regarding the Packages.gz etc. then it will
<\sh> LaserJock: sure
<LaserJock> man I sure didn't know how anti-Ubuntu some DDs could be :(
<LaserJock> I got an email from a guy telling me that if Ubuntu used stable's gcc then we wouldn't have to have MOTU (or something like that)
<tseng> good for him.
<tseng> we had a MOTU in hoary before gcc4
<LaserJock> then he told me to have a talk with Mark about how we are wasting time with duplicative packaging
<\sh> lol
<\sh> write him back he should use dope
<\sh> dope is bad for his brain
<\sh> he shouldn't use
<\sh> ,)
<\sh> well..maybe he should to get his brain straight...anyways
<LaserJock> I sent an email to debian-science introducing MOTUScience and saying that we will try to file ITPs etc. for new packages we introduce and want to help get Ubuntu work back in to Debian and that is what I got
<LaserJock> apparently I am splitting the community ;-)
<LaserJock> but to be fair I did get some positive emails as well
<\sh> LaserJock: but this is one of the reasons why i don't want to be involved in debian so strong as in ubuntu
<\sh> LaserJock: 1. I can't deal with 200 or more package maintainers...
<\sh> 2. it happend during UBZ that one maintainer mailed me about his package...and he wanted to have our patch against his package in ubuntu....I tried to send it to him..and his mail address wasn't reachable...so how should I communicate with those people? emailing bts is more difficult then press reply in my MUA
<LaserJock> well, I told them that I wasn't draining precious resources for Debian because I would be using Gentoo if it wasn't for Ubuntu so they in fact they gained resources
<LaserJock> I honestly don't see what the fuss is all about but I will persever anyway I guess
<\sh> and that is one of the biggest problems..we don't have the time to email 200 or more package maintainers in debian...or file every patch in the dbts...I'll check their packages, they can check my packages..so what is their (their as in some package maintainers...not all and not the majority of all) problem at allroblem
<LaserJock> they get bent out of shape when we don't give them every patch that we make or do anything on our own and then complain when we try to set up collaboration
<\sh> LaserJock: but collaboration means both sides of the coin...take and give...but not always presented on a golden plate
<LaserJock> anyway, sorry for the rant, I just needed to vent a little. I honestly was just trying to help Debian
<\sh> LaserJock: technical solutions can't solve social problems...always wasn't and always isn't
<LaserJock> \sh: all I asked for was possibly getting a list of DDs willing to sponsor science packages so us MOTU wannabes could file ITPs and get sponsors to get our stuff in Debian
<LaserJock> yeah, the problem is that it seems social problems effect technical solutions
<\sh> LaserJock: ask StevenK or ajmitch or tseng or Mithrandir or whoever can upload to debian and is working as well for ubuntu
<\sh> LaserJock: luk offered help as well
<LaserJock> yeah, we will see what happens after the dust settles, usually the nasty ones write first ;-)
<\sh> well yes I'm nasty, too ;)
<\sh> Hobbsee: morning btw :)
<Hobbsee> morning \sh :)
<LaserJock> is the modularized xorg that Ubuntu did in sid?
<\sh> LaserJock: dunno if the debian maintainer is working with daniels....
<LaserJock> I am trying to find places where Ubuntu work has been used in Debian
<\sh> LaserJock: d-i
<LaserJock> \sh: ?
<\sh> LaserJock: kamion and joey were working on debian-installer and some of the work from ubuntu is now inside debian ,)
#ubuntu-motu 2006-01-13
<Amaranth> iirc the original xorg (hoary) is the one in sid
<tseng> sid just got 6.9, actually
<keyes> plop
<keyes> siretart: hello !
<Amaranth> i seem to remember them saying they were going to wait for 7.0 :P
<Amaranth> as they wanted the modular release
<cyberix> How are ui translations synchronised between launchpad, Grumpy and the original project?
<psusi> after doing a debuild in a source tree, how do you clean it back up?
<crimsun> debuild clean
<thierry_> sudo debuild -S -sa does it for me
<thierry_> do what crimsun says, he's better than me :)
<crimsun> -S will clean it, too
<psusi> ahhh...
<crimsun> thierry_: s/better//g
<psusi> hrm... is there a better way to make a new dpatch than diffing by hand then appending it to the output of dpatch patch-template?
<minghua> dpatch-edit-patch?
<psusi> doh ;)
<minghua> yeah, the name is not that intuitive, but you create new text file with your text editor, don't you? ;-)
<psusi> hrm... seems to want you to make changes after you run it... I already made the changes ;)
<minghua> psusi: yes.  probably you can start from a new tree, than copy your modifiled filed into the chroot
<minghua> (or apply the patch inside the chroot if you have one patch already)
<psusi> this is kind of annoying.... why's it need a temp area?  instead of just extracting the .orig.tar.gz and diffing?
<minghua> because sometimes one patch depends on another, so you can't always start from .orig.tar.gz
<psusi> well, I mean start with the .orig.tar.gz then apply all patches... so it gets what you got when you apt-get source, then diff against the current dir
<minghua> not all dpatches in your work dir are already in the .diff.gz, so how can dpatch know where to get all the patches
<minghua> ?
<minghua> and nothing prevents people from using dpatch AND direct modifying the source (which will end up in .diff.gz) anyway
<psusi> well yea, but if it's already using dpatch you want to continue to use it don't you?
<crimsun> for easier maintenance, yes
<minghua> from MOTU point of view, yes, as we want to be as close as possible on packaging with Debian
<crimsun> like minghua said, though, there are only "best practices"
<psusi> jesus... it picked up all the other patches as well.. I guess I was supposed to dpatch disable-all before exiting
<psusi> or maybe dpatch enable-all before dpatch-edit-patch?
<crimsun> It would be great if http://tiber.tauware.de/~lucas/versions/unimultiverse.html#outdatedinB  ignored syncable versions
<crimsun> e.g., if bochs is 2.2.5-1 in Sid and 2.2.1-2 in Dapper, that's syncable and can be ignored
<crimsun> whereas amule is 2.1.0-1 in Sid and 2.0.3-3ubuntu2 can't be ignored
<crimsun> (ok yeah, poor grammar aside)
<StevenK> BLAH. It's so hard to find out what changed in Debian revisions with packages.d.o down.
<crimsun> StevenK: I end up keeping packages.qa.debian.org/x/xoo.html open
<StevenK> I want to be able to read the changelog without downloading the damn thing.
<\sh> StevenK: why is it down, btw?
<StevenK> saens is overloaded.
<Amaranth> ugh, no one ever talk to marcin on gimpnet
<marcin`> ;P
* StevenK tries to figure out why moin is insisting on Depending on python2.3
<\sh> StevenK: for debian or for ubuntu?
<psusi> is there a way to get pbuilder to use a local directory as an apt source, or does it do the update from inside the chroot?
<\sh> it does the update from inside the chroot
<psusi> hrm... let's see... maybe a bind mount?
<\sh> also not...
<\sh> but you can inject the package via pbuilder login
<\sh> and tell him to not clean up
<\sh> s/him/it/
<StevenK> \sh: Ubuntu
<psusi> looks like you can pbuilder --bindmounts to get it to bind mount a dir inside the chroot to the real dir holding the .debs
<\sh> hmm.apt-cache show moin give me but the 2.4 deps
<psusi> but how can you tell pbuilder login to not clean up?
<\sh> (dapper)
<StevenK> \sh: Yes, but it's 1.2.4-1ubuntu2, I'm preparing 1.4.99+1.5.0rc1-1ubuntu1.
<\sh> --save-after-exec
<\sh>               Save the chroot image after exiting from the chroot instead of deleting changes.   Effec
<\sh>               tive for login and exec session.
<\sh> StevenK: ah
<psusi> is /var/cache/pbuilder/result mounted inside the chroot?
<\sh> well..I don't use it...I use the pbuilder-<dist> example commands to build everything in my home dir :)
* StevenK wrote a wrapper.
<StevenK> So I can call pdebuild{,-breezy,-dapper}
<\sh>  /usr/share/doc/pbuilder/examples/pbuilder-distribution.sh is very nice...very very nice :)
<psusi> hrm... it looks like pbuilder keeps a deb cache in /var/cache/pbuilder/aptcache... maybe I can drop the .deb in there?
<\sh> hmmm
<\sh> libglade-gnome0 is gtk1.2 or gtk2 and gnome?
<crimsun> former
<crimsun> just looking at its depends
<hub> wow.
<hub> I have traceroute6 but not traceroute
<ajmitch> hm, I see zope 2.9 now required python >= 2.4.2
<ajmitch> compared to 2.8 requiring >= 2.3.3
<ajmitch> which will remove the major reason to keep python2.3 packages around
<\sh> hub: traceroute doesn't exists anymore ...it now named tracepath
<\sh> moins btw
<ajmitch> hey \sh
<hub> \sh: it does. it is in main as separate package
<hub> that
<hub> was
* ajmitch hopes we can get zope 2.9 & 3.2 in dapper
<hub> wan not installed
<\sh> hub: bsd traceroute ?
<hub> \sh: yeah
<ajmitch> hello hub
<\sh> hub: but linux distros changed a long time ago from traceroute to tracepath
<hub> ii  traceroute            1.4a12-20             traces the route taken by packets over a TCP/IP network
<hub> \sh: old habits die hard
<\sh> well...I don't like it (tracepath)
<\sh> hub: that is right :)
<hub> I didn't even know about tracepath
<\sh> oh wow...why is anybody bugging me now because of the bloody wesnoth patch...and upstreams proposed patch...is nobody reading bugreports?
<ajmitch> \sh: people don't read bugreports
<\sh> ajmitch: devels should do
<ajmitch> doesn't mean they do
<ajmitch> sadly
<\sh> well..to state this in public:
<\sh> If I patch a source, then I know I am right, even if debian or upstream says different...and if I say: Please don't merge the upcoming rev of a debian package because it includes a broken patch....then I mean it
<\sh> because on 64bit a calculation like (int)(pointer - pointer) is not always 32bit
<\sh> bah
<\sh> <rant />
<\sh> more to read on http://gna.org/bugs/?func=detailitem&item_id=4992
<\sh> grmp
<\sh> f
* ajmitch is trying to setup a zope instance & running into all sorts of evil bugs
<psusi> \sh, yea... code like that is broken... you fixed it and the upstream maintainers rejected your fix?
<\sh> psusi: no..they see that they were wrong :)
<psusi> of course... in reality, it isn't likely to cause a problem... because subtracting two pointers would only make sense to get the count of how far appart the two objects are, if they are in an array... and it isn't very likely that the array will contain > 4 billion objects ;)
<psusi> wait... nevermind.
<psusi> wait a second
<psusi> it isn't legal to add or subtract two pointers iirc
<psusi> only add/subtract integers to them, which has much the same effect as [] 
<psusi> now you've done it... now I'm confused
<psusi> hrm.... e2fsprogs fails to build from source...  looks like everything compiles and all, but then it says this:
<\sh> psusi: no..but pointers in 64bit are 64bit..and typecasting pointers should held the length properly on 64bit a pointer is 64bit an int but is 32bit on 64bit systems...forget the special case named intel 32bit
<psusi> install: cannot stat `/tmp/buildd/e2fsprogs-1.38/debian/BUILD-STD/doc/libext2fs_*.html': No such file or directory
<psusi> \sh, why is int 32 bit on 64 bit systems?  shouldn't it be the CPU's native word size?
<\sh> psusi: no
<\sh> a pointer is the native word size...but int is 32bit and long is 64bit on 64bit systems.
<\sh> psusi: it's only on 32bit systems that int and long are sharing the same size.
<\sh> there are some documents from AMD out on google...search for "porting 32bit to 64bit linux"
<\sh> or porting to amd64 and linux :)
<\sh> well...a lot of stuff :)
<psusi> I don't see how that should be... I work on a 24 bit extended version of the 16 bit z80 at work... a short is 16 bits, a long is 32 bits, an int and a pointer are both 24 bits...  isn't the point of int that it should be the native size?  if you cared about how big it was, you'd use short or long
<\sh> psusi: it's not :)
<\sh> psusi: this was our alltime war during breezy to fix those mistakes...
<\sh> psusi: and I read all the stuff I can..
<psusi> what is the reason int was kept as 32 bits on 64 bit compilers?  you're not supposed to use int if you actually care about how big it is... the idea being that it will be a different size on a different arch... did they just do it to support a lot of broken code that assumed int was 32 bit?
<psusi> can you get pbuilder to only build one binary-arch target of a source package, instead of all of them?
<\sh> psusi: most of the code is ritten for x86 machines
<\sh> psusi: you mean only one package out of N in debian/control?
<psusi> in other words, there's a ton of broken code that assumes int is 32 bit and you would rather not fix it all right?
<psusi> \sh, exactly
<psusi> e2fsprogs has a ton of target binary packages... I just need one... and for some reason, it fails to build from source... might be able to build the package I need though
<\sh> psusi: via chroot you can build the package and then don't clean up the object files
<\sh> and call make -f debian/rules build from there...so it's starts only from where it stopped
<\sh> psusi: lets say it like this: there is a lot of code, that thinks int is int..but int is not a pointer and typecasting a pointer into int is correct for x86 but not for amd64 or emt64
<\sh> anyways..I'm going to sleep now
<\sh> good night :)
<psusi> night
<psusi> what is a udeb?
<Yagisan> psusi: it's used for the installer
<Yagisan> psusi: it's a micro deb package for d-i
<psusi> hrm... what's it do?  I thought the installer just installed all the .debs
<minghua> no, d-i usually only install .udebs
<Yagisan> psusi: the installer needs them for it's runtime environment IIRC
<minghua> yeah, what Yagisan said
<minghua> (only install .udebs) for its own functioning
<Yagisan> G'day minghua - how are you today ?
<minghua> Yagisan: hello, I am good, what about you?
<Yagisan> minghua: not bad - got some interest in the x264 package on revu, so I'm updating it and doing some cleanup, then will send it back to revu
<minghua> Yagisan: glad to hear that
<psusi> I still don't understand how the .udeb differs from the normal .deb for a given package
<psusi> and why both are needed
<Yagisan> psusi: .debs need a fully installed environment to work - they are also rather large
<Yagisan> psusi: udebs, are rather slimmed down, contain only bare functionality needed, and can run from the d-i minimal environment
<Yagisan> psusi: udebs are only ever used by the installer - hence eg no wesnoth udeb
<psusi> so what kind of things are stripped out from the normal deb to thin them down?
<minghua> documentations and man pages, for exapmle
<Yagisan> psusi: check the source for the particular package you are interested in, but basically it's whatever is not essential
<psusi> wait... are the udebs used to build the setup cd, or they are what the installer installs to your hd?
<minghua> no, .udebs are never installed on harddrive
<Yagisan> psusi: setup cd == installer cd
<psusi> right... so the setup cd is itself built using the udebs... because it doesn't need docs
<Yagisan> psusi: the installer runs from the udebs, and installs normal debs to your system
<psusi> but when you go and install, it installs all the .debs and you get the docs on your hd, right?
<psusi> ok... yea... I get it now...
<Yagisan> :)
<psusi> ;)
<Yagisan> anyone have a link to the dpatch for dummies page ?
<hub> I prefer patchsys
<hub> in cdbs
<hub> less crack
<psusi> Yagisan, I've been figuring that out all day ;)
<Yagisan> I just want something simple to strip out crack in an upstream configure file
<Yagisan> they have cflags that don't exist in it ?!?
<psusi> ok... I have fixed the defrag package to build on amd64... but I also had to fix e2fsprogs-dev... now how can I make defrag build-depend on a version of e2fsprogs-dev that is at least the version I just fixed?
<Yagisan> I could just diff it out, but then it would be a pain to revu
<Yagisan> psusi: defrag ???
<psusi> Yagisan, yea...
<Yagisan> psusi: we actually need a defrag ?? for a non fat or ntfs based filesystem ?
<psusi> my fixex version is this: e2fsprogs_1.38-2ubuntu2.dsc so does that mean I want to change the build-depends line in defrag to: e2fslibs-dev (>= 2ubuntu2)?
<psusi> Yagisan, need is a relative term...
<crimsun> in defrag's debian/control:Build-Depends, you'd have e2fsprogs-dev (>= 1.38-2ubuntu2)
<Yagisan> psusi: Build-Depends e2fslibs-dev (>= 1.38-2ubuntu2)
<psusi> ext2 does a very good job of avoiding fragmentation... but some people really want things to be perfect ;)
<Yagisan> too slow
<psusi> plus it can be handy to pack all the files you need at boot in sequence at the start of the disk
<psusi> speed up boots
<Yagisan> psusi: have one for my jfs filesystems ?
<crimsun> well, Yagisan's is correct
<psusi> I thought I read somewhere that jfs has an online defragger?  or maybe that was xfs?  I dunno
<psusi> unfortunately, reiserfs does not have one...
<psusi> but again, it isn't _really_ needed
<psusi> I used the frag checker in the defrag package to see what kind of fragmentation I have on reiserfs... there's some, but not much
<Yagisan> psusi: It was just idle curiosity. I don't let my drives get full enough to worry about fragmentation myself
<psusi> it's nice to know though... and I also want to try packing all the files that readahead-list precaches at the start of the disk, so it can read them in faster... right now it only gets about 1/4 of my disk's maximum sustained throuhput
<Yagisan> psusi: will it eat data ? what if was run on ext3 ?
<psusi> well, right now it refuses to run on ext3... but you can tune2fs it back to ext2... I think I'm also going to reverse the dpatch that makes it refuse to work on ext3
<psusi> since as long as it is cleanly unmounted, there's no reason not to
<psusi> as for eating data... not sure if the power goes out... but otherwise... no
<psusi> but I have a UPS anyhow :)
<Yagisan> psusi: so the filesystem needs to be unmounted ? that may make it interesting to defrag / then
<psusi> oh absolutely
<crimsun> you could use a live cd
<psusi> there's two ways to defrag the root fs... 1) from a livecd or something and 2) build a custom initramfs with the defragger built into it ;)
<Yagisan> psusi: frag checker work on any filesystem ?
<psusi> yea... the frag checker works on any filesystem.. it is done online by using the GETBLKS ioctl
<Yagisan> psusi: thought I'd ask, as most pepole tend to have just 2 partitions, / and swap, so you'll need to document it for the users
<Yagisan> psusi: could you make a boot entry for it, like memtest86 ?
<psusi> Yagisan, sure
* Yagisan can't spell today
<psusi> have a boot entry for "Defrag"
<Yagisan> psusi: does it quit if run on a non ext2/ext3 partition ?
<Yagisan> psusi: and is it on revu - I'd like to run frag-checker over my large filesystems
<psusi> Yagisan, the frag checker runs on any fs... defrag will only run on a cleanly unmounted ext2 fs
<psusi> actually, I think it also supports ext ( 1 ) and minix... but who the hell still uses those? ;)
<psusi> no... it's an existing package in universe... I just fixed it to build on amd64
<psusi> it was i386 only
<Yagisan> psusi: I have amd64 ...
<Yagisan> psusi: would you like to check an amd64 package on revu for me :)
<psusi> hrm... someone said that was only for brand new packages?
<psusi> but hell... why not?
<Yagisan> psusi: details details - I send stuff there for peer revu
<psusi> I tried that the other day and clobbered things up ;)
<psusi> let me just make sure it compiles ok ;)
<psusi> then the hard part is getting the new version of the e2fsprogs into pbuilder so it can build defrag
<Yagisan> psusi: was it really required to adjust fsprogs ?
<Yagisan> psusi: I find having my own repo on the pbuilder sources list helps getting things in :)
<Yagisan> s/fsprogs/e2fsprogs
<psusi> yes... e2fsprogs had a header file that redefined 64 bit data types differently than asm/types.h does on amd64, so the compiler puked when both headers were used
<psusi> heh... I just copied the new .deb to /var/cache/pbuilder/aptcache, then did a pbuilder login --save-after-login and installed the new version with dpkg -i by hand from /var/cache/apt/archives
<psusi> hrm... I don't think I did this right
<psusi> previously, defrag's control file listed i386 as the binary target platform
<psusi> I changed this to all... only it generated a _all .deb...
<Yagisan> psusi: e2fsprogs, that's a main app right ?
<psusi> what should it be to mean "builds on any platform"?
<psusi> Yagisan, yea
<Yagisan> psusi: you need any not all
<psusi> ahhh ;)
<Yagisan> psusi: but does it really work on ppc etc ?
<Yagisan> psusi: is main ok with the fixed e2fsprogs ?
<psusi> hell if I know, I got it working on amd64 ;)
<psusi> no idea... they don't know about it yet
<psusi> and it doesn't have an official maintainer with ubuntu either
<Yagisan> psusi: I'd try to get them to ok it, before uploading the new defrag.
<psusi> sweet... the new defrag package is installed
<psusi> Yagisan, I am not authorized to upload to anywhere but revu ;)
<psusi> ok... now I guess I can put them there for you to take a look at
<psusi> let's see... how did you do that again?
<Yagisan> psusi: dput
<psusi> also, e2fsprogs did not build from source... there were some problems with texi2html converting the docs...
<psusi> I don't know jack about texi, so I just fixed the makefile to ignore errors trying to install the html docs
<Yagisan> not good
<psusi> I don't know how we have working binaries in the repository when it fails to build from source
<psusi> ok... they are uploaded
<ajmitch> simple, it was built with an older version of texi2html
<psusi> then the package should build-depend on the older version ;)
<psusi> hehe
<ajmitch> I hope you weren't entirely serious there :)
<Yagisan> G'day ajmitch
<Yagisan> ajmitch - is it ok to just bare diff out something, or should I use a patch management system ?
<ajmitch> Yagisan: it is acceptable
<ajmitch> if you're meaning to just make the changes in the source tree
<psusi> using a patch management system is nice for when you want to merge the patches upstream
<psusi> it's also handy for things like this:
<Yagisan> ajmitch: Upstream was smoking crack when they did their configure cflags - and as it is trivial, I was wondering is it really worth the effort
<psusi> the defrag package had a patch applied once that makes it refuse to manipulate ext3... it looks like the idea was that they were planning some sort of special support for ext3
<psusi> but it never got done... I see no reason why it shouldn't be allowed to work on ext3
<psusi> so I just dpatch deapply it
<psusi> Yagisan, in that case, if upstream still smokes crack next release, having a patch management system will make reapplying that change easier
<Yagisan> psusi: you mean that delete ;)
<psusi> Yagisan, you download those packages yet?
<Yagisan> psusi: not yet - giving my pbuilder a workout atm
<psusi> hehe
<Yagisan> psusi: downloading now. Would you mind checking out http://revu.tauware.de/details.py?upid=1399
<Yagisan> k, dpatch now added to x264 - time to upload to revu
<psusi> ahh, you're cross compiling 32bit binaries on amd64?
<Yagisan> psusi: is defrag supposed to be a native package ? e2fsprogs has no orig.tar.gz
<psusi> Yagisan, hrm... I have a .orig.tar.gz here... it didn't get uploaded?
<psusi> maybe I built it wrong?  I did debuild -S
<Yagisan> psusi: Gave up cross-compiling - it fail to often. I "repack" i386 debs, and make them depend on the support libs in that package
<Yagisan> psusi: -sa -S
<psusi> what's the -sa do?
<ajmitch> includes orig.tar.gz
<Yagisan> psusi: makes sure you always get the orig
<Yagisan> I'm really slow today
<psusi> Yagisan, good idea... I've been wondering actually WTF someone hasn't done something like that yet... would help a lot of people trying to get things like flash working, where only 32bit binaries are availible
<psusi> ok... rebuilding and reuploading
* Yagisan waves at psusi "I've been doing it - look at me - look at me"
<psusi> hehe... very cool ;)
<Yagisan> psusi: check out zsnes on revu - it needs the ia32libs-universe package
<psusi> ok... .orig.gz has been uploaded
<psusi> zsnes is only availible from upstream in binary form?
<Yagisan> psusi: nope
<psusi> then why not rebuild it for amd64?
<Yagisan> psusi: I uuencoded the i386 deb, because diff hates binaries. zsnes is mostly i386 asm
<psusi> rofl... a diff on a uuencode is equally useless ;)
<psusi> if you want binary diffs, use xdiff I think it was
<Yagisan> psusi: I can't binary diff, dpkg son't like it
<Yagisan> don't
<psusi> ohh, mostly written in asm?  I see
<psusi> why are you mucking with diffs at all?
<Yagisan> psusi: because I don't want to repack the orig
<psusi> don't build a source package... just build a binary release package
<psusi> don't put the orig in... just repackage the binaries
<psusi> like there was no source
<Yagisan> psusi: I need a source, or ubuntu won't install it. period.
<Yagisan> psusi: hence, the large diff
<Yagisan> psusi: Is defrag really a native package ??
<psusi> what do you mean it won't install it?  you can build binary only packages... like how they do packages for win32codecs
<psusi> yea... I got the source and fixed the bugs that kept it from building on amd64
<Yagisan> psusi: win32codecs no longer exists. anyway look at the source
<Yagisan> psusi: I think defrag should have a .orig, and a .diff
<Yagisan> psusi: wow - have you checked out lintian on defrag
<psusi> Yagisan, it does
<psusi> what is lintian?
<crimsun> it's definitely not native according to http://packages.qa.debian.org/d/defrag.html
<psusi> crimsun, what do you mean?
<crimsun> psusi: I mean that defrag as I see it requires an orig.tar.gz+diff.gz
<psusi> Yagisan, I don't think you should respackage the way you are and include the original source... repackaged 32bit binaries for amd64 should be binary only packages
<psusi> ohh... I thought native meant actually a 64 bit binary, not a 32 bit binary repackaged for amd64
<Yagisan> psusi: can't do that. I need the source that genrated the i386 version.
<psusi> no... it was an existing package in universe, and I just fixed it to build on amd64
<psusi> it previously only wason i386
<psusi> Yagisan, what for?
<psusi> it can be found in the source package
<Yagisan> psusi: you made a mistake when doing dpkg-source -b it cant find the orig.tar.gz for defrag
<psusi> I never did a dpkg-source -b... I just did a debuild -S -sa
<psusi> and it said it uploaded the orig.tar.gz
<psusi> the second time I did the dput
<psusi> Uploading via ftp e2fsprogs_1.38.orig.tar.gz: done.
<psusi> I think I confused revu again
<crimsun> oh, I know why revu blows up trying to perform a passwd recovery.
<crimsun> it's the same reason LP blows up.
<psusi> what do you mean it blows up?
<crimsun> it fails to do anything usefl
<psusi> I used the password recovery the other day
<crimsun> gah, can't spell.
<psusi> though it was kind of difficult
<crimsun> my key is sign-only, therefore passwd recovery obviously won't work.
<psusi> ohh... why is it sign only?
<Yagisan> psusi: My zsnes repackage is fully compatible with both the gpl and with standard policy of incluing the source a package was built from, even if that source FTBFS on a particular arch
<crimsun> because the subkey portion that matters was revoked
<psusi> Yagisan, the source is not included in the binary package
<psusi> there is already a source package... you are just taking the existing i386 binary package and relabeling it for amd64
<psusi> the binary packages don't contain the source
<Yagisan> psusi: please please look at the source closely - I make both i386 and amd64 from it. amd64 requires i386 to already be built
<Yagisan> psusi: it's not a new package, its an update of the existing one
<psusi> why are you making a source package at all?  you shouldn't need to compile anything.. .it's already been compiled in the i386 binary packages
<psusi> all you're doing is changing the platform label so you don't have to dpkg --force-arch to install it, aren't you?
<Yagisan> psusi: if you apt-get source zsnes on amd64 and you don't get source, I'd file a RC bug on it
<Yagisan> psusi: no, I do a bit more then that - please look at the source
<psusi> Yagisan, you would get source... the same source you get when you apt-get source from i386
<psusi> hrm...
<psusi> Yagisan, it looks to me like you have made a source package that contains all these other source packages
<psusi> it seems to me what you should be doing is modifying the original source packages so they have a new binary target for amd64, which is just a copy of the i386 binaries
<psusi> then when you build the original source package... you get two binary debs... one for i386, and one for amd64
<Yagisan> psusi: which package are you looking at ? ia32libs-universe or zsnes ?
<psusi> ia32libs-universe
<Yagisan> psusi: ia32libs-universe requires the libs to be extracted to /lib32. have a look at this http://revu.tauware.de/details.py?upid=1335 to see how an app would use it
<psusi> right... normally the source packages are set to (look/install) in /lib... so when they are built for i386, /lib links to /lib32
<psusi> when they are build for amd64, /lib links to /lib64
<psusi> but since you want 32bit-on64bit, you need to build the binaries for /lib32 explicitly
<psusi> you are creating an entirely new source package with one binary target: amd64... and you modified the original source to refer to /lib32
<Yagisan> psusi: no, I stick them in /lib32 and tell ldcache I have 32bit libs there. easy
<psusi> what I am sugesting is instead, to modify the original source package to have a new build target that changes the build rules to refer to /lib32
<Yagisan> psusi: not going to happen. /lib32 does not exist on i386, where the package is built
<psusi> right... the normal i386 binary target would not change
<psusi> only when building for the amd64-32 target would /lib32 be used
<psusi> see what I'm saying?
<psusi> did I scare you away? ;)
<Yagisan> brb - kid is puking
<psusi> eww.... that sucks.... hope he's ok.... and doesn't make too much messs
<psusi> it looks like you can give debdiff either the .dsc or the .changes files... which is better?
<minghua> I don't know, but I usually use .dsc
<psusi> works for me
<LaserJock> shouldn't matter should it?
<crimsun> it doesn't matter.
<psusi> now... the question is...what do I do with my shiny new packages?
<psusi> how do I get them to someone who can upload to the repository after review?
<crimsun> you can upload to REVU, correcT?
<crimsun> if they're main packages (I presume so from the semantics), file bugs in bugzilla
<Yagisan> re
<Yagisan> psusi: It's a she, and yes, she made quite a mess - banana as far as the eye could see :(
<ajmitch> Yagisan: ouch
<ajmitch> Yagisan: good luck cleaning up :)
<Yagisan> ajmitch: thanks - I'll need it. I wish I didn't have carpet right now
<Yagisan> psusi: I fixed your defrag package so it is non-native - want me to dcc it to you ?
<zakame> afternoon everybody :)
<Yagisan> afternoon zakame
<psusi> Yagisan, outch indeed... how about you tell me how to fix it... teach a man to fish and all ;)
<psusi> crimsun, aren't we supposed to be using malone now not bugzilla?
<psusi> crimsun, and what files do I need to attach to the bug?
<Yagisan> psusi: sure. dpkg-source -x defrag_0.73pjm1-7ubuntu1.dsc
<crimsun> psusi: I still use bugzilla for main; attach debdiffs
<Yagisan> psusi: mv defrag_0.73pjm1-7ubuntu1.dsc defrag_0.73pjm1-7ubuntu1.dsc.old
<Yagisan> psusi: apt-get source defrag (in i386 chroot)
<Yagisan> psusi: dpkg-source -b defrag-0.73pjm1
<Yagisan> psusi: all done
<psusi> crimsun, but the debdiffs can't be verified... they aren't signed it looks like
<Yagisan> psusi: we read the debdiffs before applying them
<psusi> Yagisan, yea... but if you apply them, then it's like you made the change... my signature isn't on it... wouldn't it be better if you had the new signed package, and could debdiff it yourself to see what changed?
<crimsun> no, it's easier to see the debdiff
<psusi> Yagisan, why apt-get source defrag again?  that's how I started... still have the orig.tar.gz
<psusi> and doesn't dpkg-source -b build a binary package?
<Yagisan> psusi: I *didn't* have the source
<crimsun> I wouldn't dare ask Martin to generate a debdiff himself for security-review
<Yagisan> crimsun: I did :) but I can get away with it
<psusi> Yagisan, yea... for some reason if you upload a package to revu without the source, even if you upload it again ( you had me debuild -S -sa the second time ) it won't show it
<crimsun> just like Martin wouldn't make Matt generate a debdiff himself
<Yagisan> crimsun: I gave him a 3 months heads up in a sec issue
<zakame> or `dpkg-source -x defrag_0.73-pjm1-7ubuntu1.dsc; cd defrag-0.73-pjm1 && pdebuild` would do, assuming you've set up pbuilder correctly ;)
<psusi> if I did a debuild -S -sa from inside the modified source tree, everything should be fine right?
<Yagisan> psusi: revu only updates every x minutes. maybe you need to wait
<crimsun> Yagisan: sure, I'm aware there are extenuating circumstances
<psusi> Yagisan, it updated... shows the second upload... it's just confused and won't show the .orig.tar.gz...
<Yagisan> crimsun: yep - like me stuck with dialup and unable to do it myself in a reasonable timeframe
<psusi> my .changes file shows that I changed the package, and signed off on it... I'm concerend that information will be lost if I only upload a debdiff
<zakame> psusi: the debian/changelog should have your name on it ;)
<psusi> zakame, it does... but it doesn't have my signature on it so how do you know I really changed it? ;)
<ajmitch> psusi: it won't matter at all
<ajmitch> psusi: someone else has to sign it before it goes in the archive anyway
<psusi> ahhh..... hrm.... well, ok....
<ajmitch> since you're not in the trusted keyring for uploads
<zakame> psusi: at least not until you're approved by TB to be included in the keyring
<psusi> ajmitch, right... which is why someone else needs to sign it too... just figured my signature should be on there somewhere as well ;)
<ajmitch> why?
<ajmitch> we have to review anything that's on revu :)
<psusi> now... hopefully someone who understands texi will fix the texi2html breakage in e2fsprogs and re-enable the disabled docs install step of the makefile
<ajmitch> since it's a fairly open upload policy
<psusi> cause I sure as hell have no idea how to fix it... so I just disabled it so the package builds
<psusi> is there someone around who can nuke the borked packages I uploaded to revu so I can do it again right?
<ajmitch> yes
<ajmitch> what package?
<Yagisan> ajmitch: could you revu http://revu.tauware.de/details.py?upid=1429
<Yagisan> ?
<ajmitch> Yagisan: depends on how much I get paid
<Yagisan> ajmitch: you get a warm fuzzy feeling for helping the motumedia team
<ajmitch> Yagisan: what an odd version number
<LaserJock> Yagisan: you could also double is current MOTU pay ;-)
<Yagisan> ajmitch: thanks - I took upstreams, and added ~ubuntu1 to it
<ajmitch> Yagisan: why did you use ~ubuntu1 ?
<Yagisan> ajmitch: I've been trying to "fix" it
<ajmitch> since that should be lower than 0.0 alone
<psusi> ajmitch, all that I have on there...
<ajmitch> psusi: not very helpful..
<ajmitch> I don't see anything of yours in incoming, so what is there to nuke?
<psusi> ajmitch, all packages by Phillip Susi... or... defrag and e2fsprogs... and...
<ajmitch> psusi: can't you just upload a new version?
<psusi> udftools
<Yagisan> ajmitch: he did - but the orig never showed up
<psusi> ajmitch, I uploaded the first one without the .orig.tar.gz... that seems to have confused revu... forcing the upload again this time with the .orig.tar.gz still doesn't get it to show up
<ajmitch> it was mentioned in the .dsc?
<psusi> Yagisan, you get it to build?
<ajmitch> & the .changes file?
<psusi> ajmitch, yes... it's in the .dsc and .changes
<psusi> and dput said it uploaded it
<Yagisan> psusi: not yet - I have a large queue on my pbuilder
<ajmitch> psusi: what package was this?
<psusi> ajmitch, all 3... udftools, defrag, and e2fsprogs
<Yagisan> ajmitch: e2fsprogs
<ajmitch> and how long ago was this?
<zakame> er aren't those main pkgs?
<psusi> udftools was the other day... defrag and e2fsprogs were about an hour or two ago
<ajmitch> e2fsprogs has orig.tar.gz there
<psusi> e2fsprogs is main I believe... the other two are universe
<psusi> ajmitch, http://revu.tauware.de/details.py?upid=1428 shows no .orig.tar.gz
<psusi> wait
<psusi> now it does
<psusi> hrm...
<ajmitch> revu doesn't process uploads instantly
<psusi> Yagisan, does that still look broken to you?
<psusi> ajmitch, I know... I gave it a few... and the second upload appeared at the bottom... but not the .orig.tar.gz
<Yagisan> psusi: e2fsprogs looks ok now
<psusi> cool!
<ajmitch> defrag still looks like it has no orig.tar.gz
<ajmitch> especially as the .dsc & .changes files haven't changed at all
<psusi> defrag still has no .orig.tar.gz
<psusi> heh ;)
<ajmitch> so why did you ask me to fix it for you?
<psusi> no... it is missing on revu... but it should be there
<psusi> it's in my .changes and .dsc, and dput showed it uploaded
<psusi> wait... nevermind.
* psusi does a double take
* ajmitch sighs
<Yagisan> ajmitch: I need to be a motu to review packages on revu don't I
<ajmitch> Yagisan: at the moment, yes
<psusi> it appears I have gremlins
<Yagisan> ajmitch: thanks for confirming
<psusi> ok... there we go
<psusi> now if I screwed this up AGAIN, I'm taking my ball and bat and going home
<Yagisan> psusi: I don't see your .orig for defrag
<psusi> Yagisan, give it a few
<Yagisan> psusi: you made it native again
<ajmitch> Yagisan: no, that's the same old one as earlier
<psusi> nope... debuild -S -sa just like the e2fsprogs... and the .orig.tar.gz is in the .dsc and .changes
<ajmitch> at least from what I can see
<psusi> just give revu a few to process it
<psusi> Yagisan, now back to where we were earlier...
* ajmitch isn't entirely sure where it is :)
<psusi> Yagisan, a source package can have several binary target packages... like e2fsprogs source package is used to build half a dozen binary packages
<ajmitch> ah, it's there in incoming
<zakame> gaah
<Yagisan> psusi: I see, it's still in incoming
<Yagisan> psusi: yes - but I will not create a new "arch" amd64-32 for something that is easier done by repacking
<psusi> Yagisan, for 32bit on amd64, I propose adding a new binary target package that modifies the make rules to refer to /lib32... the new target would only build on amd64... but would actually use the i386 binaries
<psusi> or rather... build i386 binaries
<Yagisan> psusi: I did try something like that, but you *will* get header collision, and it *will not* find the /lib32 before /lib
<psusi> Yagisan, repacking = adding new binary package target... e2fsprogs is compiled once... and bits and pieces of it are then packaged into a half dozen different binary packages
<Yagisan> psusi: lets use zsnes as an example, because it's easy and self contained
<psusi> Yagisan, actually... you would want to build the target as i386... then just make the package say it's for amd64
<Yagisan> psusi: could you show me what you would do to the rules to get this to happen ?
<psusi> and when the makefile sees it's buidling for the foo-32 target, replace /lib with /lib32
<psusi> Yagisan, I'm not sure exactly... just got the general idea... the control file right now only specifies a single binary target that builds on only the i386 arch right?
<Yagisan> psusi: I did try something similar, but it always tried to link to /lib rather then /lib32, and /lib was 64bit so it failed
<psusi> Yagisan, right... you need to change the makefile so that it replaces /lib with /lib32
<Yagisan> psusi: I called configure with a path with no /lib in it, onlt /lib32, but it still FTBFS
<psusi> trying to build it on amd64?
<Yagisan> psusi: yep
<psusi> right... because it's going to try compiling a 64bit binary
<psusi> you need to build it on i386
<Yagisan> psusi: nope -m32 to build i386
<psusi> ohh, yea... you told the ocmpiler to cross compile... ok... then you have dependency issues
<psusi> would be easier I think to just build it on i386
<psusi> and tell configure to use /lib32
<Yagisan> psusi: If I change it to /lib32 for an i386 package, it has nothing to link too
<psusi> then force the binary package to say it's amd64 arch
<psusi> no no...
<psusi> you have two different binary targets in the source package
<psusi> one is the current one... znes
<psusi> builds on i386 arch only
<psusi> add a new one... znes-lib32... that also builds only on the i386 arch... but uses /lib32 and the built binary package gets forced to say it's for amd64
<psusi> alternatively, you could actually get it to build on amd64 but you'd have to fix up all the build depends which could be a pain
<psusi> and the cross compiling
<Yagisan> psusi: I don't think that will work. Feel like giving it a try ?
<psusi> possibly ;)
<Yagisan> psusi: of course, when multi-arch is done, this is all moot anyway
<psusi> what's multi-arch?
<Yagisan> psusi: native running of eg i386 packages on amd64
<psusi> I was thinking about a way to do that too... need to get the 32bit ld.so to do some slight of hand and fill requests for /lib with /lib32 instead
<psusi> then get dpkg and apt and friends to understand that they can install an i386 binary package... but need to meet the depends with i386 packages
<Yagisan> psusi: Mithrandir is the multi-arch god. I'm just doing the hack I need to get my apps going for dapper
<psusi> and when dpkg actually installs an i386 package, needs to substitute /lib32
<psusi> ohh, multi-arch isn't going in dapper?
<Yagisan> psusi: no - it's a very big project. Debian was planning it before sarge, and it may end up being ready at etch + 1
<psusi> ajmitch, hrm... the .orig.tar.gz still isn't there
<psusi> Yagisan, wow
<psusi> Yagisan, you build defrag yet? ;)
<psusi> I think this is the most efficient defragmenter I've ever seen too
<psusi> once you tell it you have more than 2 megs of ram for it to play with ;)
<psusi> it goes nice and fast... uses very large block IO to minimize disk thrashing
<psusi> now... to see if it made booting faster! bwahah!
<lifeless> FWIW I've reuploaded opensync
* ajmitch saw it on the new queue page earlier :)
<ajmitch> thanks for doing that
<lifeless> and armin has fixed the sources for HEAD to be LGPL everywhere
<lifeless> well, for the two problem files
<lifeless> theres about a dozen that have no (C) statement at akk
<lifeless> *all*
<ajmitch> I appreciate having the source in bzr
<lifeless> ;)
<ajmitch> it's not fair when I have to go off & use cvs or subversion now - I just can't bring myself to like them :)
<dholbach> \sh_away: ping
<ajmitch> hey dholbach
<dholbach> hey ajmitch
<lifeless> ajmitch: lol
<zakame> hello dholbach
<dholbach> \sh_away: I don't want to be a pain in the ass, but you don't seem to have realized, that you didn't only mess with the python2.3 <-> python2.4 {Build-,}Depends, but you overwrote my complete packaging for the istanbul package
<dholbach> \sh_away: this is no urgent problem or anything, I just wanted to point this out - I'm going to revert this
<ajmitch> sleep time, night all
<dholbach> bye ajmitch :)
<dholbach> hey zakame
<dholbach> http://freeride.rubyforge.org/wiki/wiki.pl seems interesting for the ruby guys
<dholbach> Korean MOTU: http://ubuntu.or.kr/wiki.php/MOTU
<dholbach>  plus tard
<dholbach> *wave*
<crimsun> cya daniel
* dholbach hugs crimsun 
<thierry_> raphink : you are the cdbs guru here right?
<thierry_> raphink : is there anyway I can pass the option --enable-shared to the configure script with cdbs, or do I need to change my package to debhelper?
<chninkel> thierry_: DEB_CONFIGURE_EXTRA_FLAGS := --enable-shared
<chninkel> thierry_: after inclusion of autotools.mk
<zakame> evening all
<slomo_> thierry_: in general you can do almost everything with cdbs... https://wiki.duckcorp.org/DebianPackagingTutorial/CDBS
<rbelem> thierry_: wiki.ubuntu.com/MOTUDocumentationDraft
<ivoks> hi slomo_
<slomo_> hi ivoks :)
<rbelem> zakame: morning ;-)
<rbelem> hi slomo_
<ivoks> i'll quit my job :/
<zakame> heya rbelem , slomo_ , ivoks :)
<ivoks> i don't have time for ubuntu :)
<zakame> waah
<slomo_> hi rbelem
<rbelem> hey slomo_, my first package was uploaded yesterday =)
<slomo_> rbelem: cool, which one? :)
<rbelem> darksnow
<zakame> w00t
<Yagisan> rbelem: new version of x264 at revu
<slomo_> rbelem: :)
<rbelem> slomo_: i feel very well after that. my first uploaded packages =) ehehehe
<rbelem> Yagisan: cool
<rbelem> thanks Yagisan
<slomo_> rbelem: is it already in the archives? or in the NEW queue?
<rbelem> slomo_: not in archives yet, i guess
<rbelem> hey slomo_ maybe i'll get a job at mandriva
<rbelem> they are calling people that work with freesoftware
<ivoks> heh
<slomo_> rbelem: cool :) what exactly would you do there?
<ivoks> i got at redhat partner
<ivoks> and since then no time for ubuntu :/
<ivoks> so i'll quit :)
<rbelem> ivoks: ehheheehe
<ivoks> seriously... i will
<rbelem> slomo_: test analyst
<ivoks> ah, even now they call me :(
<rbelem> if mandriva accept me, i'll quit my currently job, that sometimes have to fix some windows servers :'(
<ivoks> :)
<zakame> in cdbs, can I usr tarball.mk and simple-patchsys.mk simultaneously?
<chninkel> rbelem: what will be your job at mandriva ?
<azeem> zakame: yes
<rbelem> chninkel: test analyst
<rbelem> :)
<chninkel> nice
<chninkel> :)
<zakame> azeem: hm, well I just tried doing so, {,p}debuild ran, but the patch failed :(
<rbelem> i sent my curriculum, just waiting to be called
<rbelem> there is not many people here that work with free software
<azeem> zakame: maybe you need to include tarball before patchsys
<zakame> hmm, lemme try
<chninkel> rbelem: I don't know, I think there more and more people involved in free software nowadays no ?
<ivoks> chninkel: true
<ivoks> i work only with free software
<rbelem> here at my city there are few people :/ I know almost everyone
<chninkel> where do you live ?
<rbelem> Manaus - Amazonas - Brazil
<Yagisan> night all
<rbelem> Yagisan: g'night
<chninkel> night Yagisan
<zakame> gn8 Yagisan
<chninkel> rbelem: how is mandriva doing in Brazil ?
<rbelem> chninkel: mandriva bought the major brazilian linux distribution, which is called conectiva
<rbelem> chninkel: i guess the things are going well for then
<rbelem> chninkel: they are working with embedded at my city
<chninkel> chninkel: they were pretty bad at some time, but it seems they're getting better
<rbelem> chninkel: sometime ago they almost close the doors :/
<zakame> I don't get this, cdbs-edit-patch applies the patch cleanly, but it fails upon debuild...
<dholbach> hello
<dholbach> lifeless, ajmitch: how's open/multi-sync coming on?
<dholbach> lifeless, ajmitch: we have UVF (which 'd apply for multisync) in less than two weeks - just as a heads-up.
<chninkel> dholbach: merging question, should python package depends on python2.4 or python ?
<dholbach> depends or build-depends?
<dholbach> chninkel: the most sensible way is to have python-dev (>= 2.4) in the Build-Depends and ${python:Depends} in the Depends: line - but you have to run dh_python in debian/rules for that.
<chninkel> dholbach: depends only
<tseng> depends should be done with dh_python
<chninkel> but is it worth applying a ubuntu specific patch for that ?
<dholbach> yes.
<chninkel> ok
<tseng> (oh man what the hell is that Internet icon in tango 0.6.4)
<hub> is it that hard to package opensync?
<dholbach> something blue with a crack-pipe
<tseng> yeah
<hub> oh
<tseng> it looks like a background from DeviantArt
<dholbach> hub: ajmitch and lifeless are working on it for some time now. i'm not sure how the state is.
<dholbach> hub: but i'm keen on having it in before uvf.
<hub> dholbach: yeah, that why I'm asking.
<andi5> hi. is there a way to accelerate a debian<->ubuntu pkg merge? the launchpad bug is 6 weeks old (for me this is nontrivial, but maybe i am just impatient)
<bmonty> andi5: what is the package or bug?
<andi5> bmonty: it is g-wrap, #5069
<bmonty> andi5: \sh is doing the merge on that package
<chninkel> how frequently are auto-sync with debian done ?
<Nafallo> daily
<chninkel> Nafallo: I was told lesstif2 would be removed from sync blacklist and put in universe
<hub> anyone with dapper can access a sourceforge CVS repository over SSH?
<chninkel> Nafallo: but it's still not there
<chninkel> Nafallo: who can I ask about this ?
<Nafallo> sounds like elmo-land ;-)
<chninkel> Nafallo: ok, thks
<hub> looks like openssh 4.2 is causing problems
<Nafallo> but best to ask in #ubuntu-devel after the weekend probably
<chninkel> Nafallo: ok
<d4ft> how do i add a package?
<jpatrick> d4ft: to what?
<d4ft> add the package i just compiled
<jpatrick> to universe?
<d4ft> yup
<d4ft> or contrib
<d4ft> either one^^
<jpatrick> d4ft: you have to get an MOTU to review and upload the package
<d4ft> ok
<ajmitch> morning all
<tseng> hi ajmitch
<sistpoty> hi folks
<ajmitch> hello tseng, sistpoty
<ajmitch> sistpoty: if you're bored & looking at the merge updates again, look at my updated ~/scripts/srcpkgs2merge.py
<ajmitch> runs in about 15 seconds now, half of that being download time
<sistpoty> ajmitch: I'm not really bored ;) and as long as the old version works, I guess I won't change it (because we only need it for a few days *g*)
<ajmitch> sistpoty: it uses britneymodule.so, which I'll also use for unmet deps :)
<ajmitch> only a few lines added
<sistpoty> cool :)
<ajmitch> so I'll work on tiber trying to get a list of unmet deps on dapper universe :)
<sistpoty> ajmitch: I'm not quite sure about it, but imo siretart has already some list-generator of unmet deps in his home on tiber
<ajmitch> probably from apt-cache unmet
* sistpoty hasn't had time to look yet
<ajmitch> britney is what debian uses for the purpose, and it's a little more accurate (and memory hungry)
<ajmitch> yep, looks to just use that
<sistpoty> ajmitch: if I want to add a patch to BTS for an already reported bug, what do I have to do?
<sistpoty> ajmitch: (and tag it as patch available)
<ajmitch> send in a mail with attachment, and tag it as patch
<sistpoty> ajmitch: only as a mail to somebugnum@bugs.debian.org? or do I need to cc control@bugs?
<ajmitch> I think you'd send a separate mail to control@
<ajmitch> but I use the bts util for that :)
<sistpoty> ajmitch: k, thx :)
<psusi> anyone feel like revuing my e2fsprogs and defrag package fixes?
<Mithrandir> uhm, e2fsprogs isn't universe, it's main, so it shouldn't go through revu
<psusi> I know... but Yagisan wanted to take a look at it... and I wanted someone to tell me how I screwed it up, and that's the only place I can put it ;)
<sistpoty> psusi: please add a comment to state that it's in main
<Mithrandir> heh, 'k.  I'd like it not to be uploaded until I hear back from tytso, though
<psusi> hrm... just say "This is in main, so do not upload, just comment"?
<sistpoty> psusi: or s.th. like "S.o. with main privs needs to review this"
<sistpoty> ;)
<psusi> ok...
<Mithrandir> sistpoty: it shouldn't be uploaded until we hear back from upstream.
<Mithrandir> is there any way to tell revu that?
<sistpoty> write a comment stating it ;)
<Mithrandir> uhm, what login should I use?
<psusi> commented
<psusi> so anyone feel like looking at it though and telling me how I screwed up the packaging? ;)
<psusi> or defrag... but it depends on that version of e2fsprogs
<sistpoty> Mithrandir: do you have review rights on revu? otherwise you won't be able to comment
<Mithrandir> sistpoty: probably not.  Or maybe.
<Mithrandir> sistpoty: I tend to just upload and not use revu, as I can upload to main
<Nafallo> Mithrandir: you probably don't even have an account then ;-)
<Mithrandir> I probably don't.
* sistpoty looks
<Nafallo> iirc you get an account on the first upload or something like that...
<Mithrandir> I've uploaded a lot of stuff. :-P
<Nafallo> to revu silly ;-)
* Nafallo nags Mithrandir :-)
<Mithrandir> oooh. :-P
<psusi> yea.. have to get your gpg key on the ring, then first upload creates your account with a random password which you can get by choosing password recovery... which sends you a gpg encrypted message with your password... heh
<Mithrandir> about what?
<Nafallo> Mithrandir: anything you like :-)
<psusi> so... are new bugs supposed to go in malone now or what?  I need to file a bug against the .25 i386 breezy kernel and don't know if it should go in malone or bugzilla
<psusi> damn thing dies hard core about once a day on my server at work... won't even magic sysreq
<Nafallo> fwiw, I always use malone and assign it to the person who should have it these days ;-)
<Nafallo> my girlfriend does aswell ;-)
<sistpoty> Mithrandir: what email did you use for packages, which you uploaded to revu?
<ajmitch> sistpoty: he said he hasn't uploaded to revu, right? :)
<Mithrandir> sistpoty: I haven't uploaded any packages to revu.
<sistpoty> oh, misunderstood that *g*
<psusi> there doesn't happen to be a less.... foofy... ui to malone does there?
<sistpoty> Mithrandir: then what email (login) do you want as an account for revu? (should be same that you use for uploading packages)
<Mithrandir> sistpoty: tfheen@ubuntu.com
<Mithrandir> (please)
<sistpoty> Mithrandir: account created... just use try to login with that email-addy and some random pw, then there should be s.th. for pw recovery ;)
<Mithrandir> http://pastebin.com/496782
<sistpoty> lol, I'm stupid *g* (need to import your key as well)
<Mithrandir> haha :-)
<Mithrandir> 817a996a
<Mithrandir> is the key id
<Mithrandir> (as you can verify on launchpad too)
<sistpoty> Mithrandir: there is no @ubuntu adress for this key, however I found 2C0753E3 for your ubuntu addy
<ajmitch> morning Mez
<ajmitch> ;)
<Mez> evening :D
<Mez> lol
<Mithrandir> sistpoty: yes, that is my smart card.  Please don't use that yet, look at https://launchpad.net/people/tfheen for my key ids.
<Mithrandir> hiya ajmitch
<ajmitch> hi Mithrandir
<Mithrandir> sistpoty: else, I'll have to go into the room next door to find the smart card and reader, and I'm lazy. :-P
<ajmitch> Mithrandir: I think I still have yours to sign here
<Mithrandir> ajmitch: I think I signed yours already, didn't I?
<sistpoty> Mithrandir: hm... then I'll need to change your login to match one from the first key ;)
<Mithrandir> sistpoty: that's a really silly restriction in revu, but feel free to use tfheen@err.no then
<sistpoty> Mithrandir: revu 1 has even more of these silly stuff ;)
<ajmitch> Mithrandir: yes, you've signed mine
<ajmitch> ah, found your business card
<sistpoty> Mithrandir: done... hope this works now ;)
<Mithrandir> sistpoty: yay, worked
<sistpoty> ajmitch: if I want to tag a patch in debian, I get: 550 Administrative prohibition :(
<Mithrandir> ooh, I'm logged in as admin as well.  Shiny.
<Mez> does the linux-source packages come with a config file already - or not ?
<Mithrandir> sistpoty: it would be useful if revu recognized urls as such and made them clickable.
<sistpoty> Mithrandir: already considered this for revu2... for this version you can still write plain html code
<Mithrandir> ouch
<Mithrandir> that's actually quite bad, since you can XSS and steal cookies that way
<sistpoty> yep... but whoever tries that must be in the keyring (otherwise no login) and thus it's easily tracable
<psusi> hrm.... malone doesn't appear to know about any linux-image packages
<sistpoty> anyone with amd64 here, who might help me test a fix?
<siretart> huhu sistpoty
<sistpoty> hi siretart
<siretart> sistpoty: I just arrived at home, but I think I can help you in a couple of minutes. what to test?
<sistpoty> siretart: u++
<chninkel>  /LOAD proxy
<chninkel> oups, sorry
<siretart> u++?
<siretart> interesting. it doesnt work on amd64?
<sistpoty> siretart: it FTBFS'd due to changed dpkg-architecture (the makefile is quite funny)
<sistpoty> siretart: and I did it right only for i386 :(
<siretart> sistpoty: ok, I'll take a look at it
<sistpoty> siretart: I'll put a patch on tiber in a minute ;)
<sistpoty> siretart: upp_debian_rules.patch (in my home)
<siretart> ok
<lucas> hi siretart
<lucas> how was snowboarding ?
<\sh> moins
<sistpoty> hi \sh
<rbelem> hi sistpoty
<rbelem> i have amd64
<sistpoty> hi rbelem:
<sistpoty> rbelem: I think siretart is already on it
<lucas> is thierryn at videotron.ca around ?
<rbelem> sistpoty: ok ;-)
<ajmitch> ah, siretart lives :)
<Nafallo> hehe
<ajmitch> good to see he's not lying unconscious in a hospital ;)
<Nafallo> they don't allow laptops + wireless on hospitals? :-)
<ajmitch> unconscious, I said ;)
<Nafallo> baah
<Nafallo> :-P
<ajmitch> though siretart would probably be in irc even in a coma
<Nafallo> hehe
<lucas> hey, could somebody open a revu reviewer account for me ? (or set my existing account to reviewer ?)
<siretart> ajmitch: hehe, I'm not thaat crazy ;)
<siretart> lucas: snowboarding in france is great! :) - I just arrived 2h ago, and I'm really tired from 10h driving ;)
<sistpoty> lucas: are you motu yet? (we usually give away reviewer accounts only to motu's)
<ajmitch> siretart: what are we deciding on having non-MOTUs reviewing?
<lucas> sistpoty: member, not motu
<lucas> siretart: where were you ?
<siretart> ajmitch: we have afaik only on non motu reviewer, based on that he gives really good comments
<ajmitch> right
<Nafallo> hmm
<sistpoty> lucas: you can post reviews to the reviewer ml... if they are good, we can set up an reviewer account, ok?
* Nafallo thinks he had review before he was MOTU :-P
<Nafallo> but I'm not certain ;-)
<lucas> ok
<ajmitch> Nafallo: I can't remember when you were made MOTU
<Nafallo> ajmitch: not me either :-P
<ajmitch> it was long enough ago now :)
<Nafallo> after we visited Mithrandir :-)
<Nafallo> so sometime this last summer ;-)
<ajmitch> aha
<Nafallo> baah. people think I'm a core-dev anyway :-P
<ajmitch> dunno why
<ajmitch> maybe because you seem wise & all-knowing
* desrt gets the same problem!
<ajmitch> desrt: that's just because you speak up a lot :)
<Nafallo> :-)
<desrt> ajmitch; not being a member of the MOTU probably helps too :p
<Nafallo> probably because I make people upload my stuff to main now and then ;-)
<sistpoty> btw: desrt: ghc6 ftbfs due to new make :(
<sistpoty> (it actually doesn't ftbfs but just sit running make forever)
<chninkel>  /set bell_beeps on
<raphink> sistpoty: that's not very convenient indeed ;)
<sistpoty> raphink: well I tried to build it on tiber and rechecked after 24h... only hot air produced *g*
<raphink> :s
<raphink> you mean you let it build for 24h ? ;)
<sistpoty> sure... it usually takes 6 hours on my slow machine
<raphink> haha
<sistpoty> s/takes/took :P
<ajmitch> slomo_: bug for you: https://launchpad.net/distros/ubuntu/+source/service-discovery-applet/+bug/6510
<Ubugtu> Malone bug 6510: "discovery-applet (Ubuntu) - Sometimes doesn't show any discovered services" Fix req. for: service-discovery-applet (Ubuntu), Severity: Normal, Assigned to: Avahi Team, Status: New http://launchpad.net/bugs/6510
<\sh> gnarf..."I should not post to debian-devel, I should not post to debian-devel, I never post to debian-devel again"
<slomo_> ajmitch: i already noticed it ;)
<slomo_> \sh: what happened?
<ajmitch> \sh: it's never a good idea to
<\sh> slomo_: nothing
<ajmitch> slomo_: he went into a thread about launchpad
<ajmitch> and he dared to reply to asuffield :)
<\sh> well, I'm just an asshole...
<\sh> ajmitch: whoever mr. suffield is
<ajmitch> notorious flamer :)
<\sh> ajmitch: thats why I quoted the last 2 lines of their code of conduct...
<ajmitch> that didn't go down well :)
<ajmitch> I didn't even know there was a code of conduct for debian lists
<\sh> ajmitch: well..I can use lynx :)
<\sh> ajmitch: and I'm not afraid of using google, even it can disappear with a big bang, because it's free but non-free sourcecode service
<ajmitch> but it's a very important point for debian to have freely available tools - launchpad & google are apples & oranges
<ajmitch> launchpad is designed to be central to distro development, google is not
<\sh> ajmitch: well...how many people from debian are using sf.net?
<ajmitch> for developing debian? very few, I'd say
<\sh> I think there are some, no for developing oss software :)
<ajmitch> for fetching upstream tarballs from? a much higher number
<siretart> huhu \sh!
<\sh> siretart: how was the holiday? :)
<ajmitch> and that developing floss software is not developing debian, the distribution
<siretart> \sh: the week was great! thank you! :)
<raphink> hmm
<\sh> ajmitch: it has everything in it. If they stand for what they
<\sh> 're saying, they would never use sf.net
<ajmitch> sure, and those developers that speak up probably don't use sf.net
<\sh> even for non debian work :)
<ajmitch> we're talking about using launchpad for all debian developers, or even a major part
<raphink> looking at the enlightenment package because there's a sync/merge required
<raphink> it seems there's a slight problem with it with last merged version
<raphink> it didn't build the enlightenment binary package from source
<ajmitch> so fix that with the next merge :)
<lucas> maybe we should start a "How to talk to Debian developers" wiki page
<raphink> so enlightenment_1:0.16.7.2-2 is available as source and not as binary
<raphink> ajmitch: sure
<raphink> lucas: ?
<raphink> ;)
<ajmitch> raphink: it was probably fixes in the last debian upload - it was missing build-depends
<raphink> UsefulDebianVocabulary
<raphink> ;)
<\sh> lucas: it's nothing compared to my early days in usenet :)
<lucas> raphink: the launchpad thread on debian-devel@lists.d.o didn't go very well
<lucas> \sh: yes, but it's a missed opportunity
<lucas> anyway, you didn't start the thread, I think
<ajmitch> lucas: did you expect it to?
<raphink> rationale : if you don't understand "checking BTS, found it was FTBFS so just uupdate", you have to study the Debian language
<lucas> ajmitch: not really ;)
<ajmitch> lucas: I don't push for other DDs to use launchpad for those reasons :)
<\sh> raphink: you mean something like "morons", or "you suck", well if I would stick to those behaviour, I would have to switch to windows ;)
<ajmitch> lucas: and what would you put on this 'how to talk to debian developers'?
<raphink> hehe
<lucas> 'free software is important to them. It isn't always for us.' ;)
<ajmitch> raphink: hm? what's so hard to understand about that sentence?
<ajmitch> raphink: you forgot to check the WNPP
<raphink> ajmitch: nothing for me since I wrote it ;)
<raphink> oh yeah ajmitch that's right
<\sh> lucas: well, it's useless in any sense..but sometimes my strong focus to make the world a better place comes through...
<raphink> but the WNPP is in the BTS
<ajmitch> yes, but it's a specific way of using the BTS
<ajmitch> with particular rules on bug titles, etc
<raphink> yes
<raphink> so a good sentence to introduce the necessity of knowing such a language
<lucas> \sh: can you point me to a location explaining why the LP code is not free ?
<ajmitch> \sh: some of your comments could be taken as very inflammatory :)
<raphink> would be to asked for ITP to be filed for WNPP in the BTS cause last vers is FTBSF
<raphink>  ?
<ajmitch> raphink: that would be utter crack
<raphink> ;)
<ajmitch> raphink: you'd file a wishlist bug on the existing source package
<raphink> oh yes that's right
<raphink> hmm not a good example, still , then
<Amaranth> -ETOOMANYACRONYMS
<raphink> ;)
<ajmitch> Amaranth: exactly what we're talking about :)
<slomo_> ajmitch: FTBFS is not wishlist imho... but i'm probably missing the context ;)
<ajmitch> true, it's a serious bug
<ajmitch> but you'd file a wishlist for new upstream version
<raphink> slomo_: ajmitch meant you wouldn't file an ITP for a FTBFS
<raphink> instead you would file a bug on the existing package, not against WNPP
<slomo_> yes
<ajmitch> raphink: slomo_ is an experience debian maintainer also :)
<raphink> :)
<slomo_> ajmitch: while we're at debian... you still didn't get the advocation mail? :(
<ajmitch> no, dunno why..
<ajmitch> I'll check my spam folders
<raphink> ;)
<\sh> lucas: because canonical said so, and they licensed launchpad in this way. There was somehow a talk or a document explaining why...but well, it's even said, that if canonical is disappearing from the market, lp source will be released as oss
<lucas> ok
<ajmitch> lucas: and thus you see why many DDs keep away from it
<Mez> ajmitch, you're advocating slomo for DD?
<ajmitch> Mez: yes, why?
<lucas> ajmitch: :-)
<\sh> ajmitch: why? because I'd compare non-elite and elite people? ,)
<ajmitch> \sh: because you call us DDs 'arrogant elitists' ;)
<Mez> lol - cause i think slomo would make a good addition :D
<Mez> lol
<ajmitch> Mez: sure, and it'll mean less sponsoring for me in a year or two ;)
<\sh> ajmitch: but you are ;)
<ajmitch> \sh: of course
<Mez> ajmitch, lol :D yeah - :P
<\sh> ajmitch: i mean I'm one of them as well...I never said something against it :)
<slomo_> ajmitch: i bet it will be around january 2008 ;)
<ajmitch> slomo_: optimist
<raphink> looool
<\sh> ajmitch: anyways...I'm just an asshole...but I will change, and not post to debian-devel again :)
<ajmitch> slomo_: it's listed me as advocate on the page but not verified your application - since I still haven't seen any mail :)
<lucas> \sh: you are not an asshole, but you failed to talk to DDs the way you have to talk to them if you want them to listen
<slomo_> ajmitch: weird... can you re-request the mail?
<ajmitch> nope
<ajmitch> I might be able to put myself as advocate again
<lucas> ajmitch: ask paulvt (Mozillion) about this, I think he had the same problem when he advocated me
<ajmitch> and how did that get fixed?
<slomo_> ajmitch: hmmm or write a mail to new-maintainer@debian.org and ask them where your mail was sent to ;)
<lucas> I dunno, that's what you should ask to him :)
<\sh> lucas: that's why i'm an asshole...I refuse to lick their feet
<lucas> it's not about feet-licking, it's about understanding that others sometimes think differently
<\sh> hope my dapper update is working somehow
<raphink> debian #346160
<Ubugtu> Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
<raphink> Ubugtu: debian bug #346160
<Ubugtu> Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
<raphink> hmm
<raphink> works when you don't want it to, and doesn't work when you need it ;)
* raphink goes to b.d.o
<slomo_> raphink: it's only this bug, others work fine ;)
<raphink> haha
<raphink> yeah yeah sure
<slomo_> debian bug 346161
<Ubugtu> Debian bug 346161: "serial card (fourport) stopped working" Package: linux-source-2.6.15, Severity: wishlist, Maintainer: Debian Kernel Team  http://bugs.debian.org/346161
<slomo_> :P
<raphink> :p
<\sh> lucas: I understand that very well, because we all think differently. But why should I think I'm better because others don't know how to use vi for writing html files? or why should I think I'm better because I know the manpage of tar and find and can use it quite fast, but others who don't are useless and shouldn't be involved in contributing to the project?
<lucas> debian bug 346160
<Ubugtu> Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
<raphink> heh
<raphink> no luck
<lucas> they don't think they are better. they just don't like hearing : "a command line interface ? ah ah ! look guys, the world has changed !"
<lucas> which is basically what you told them
* raphink likes when packages just have to be synced :)
<ajmitch> slomo_: hm, mail from that debian.org box reaches me fine.. retrying advocacy
<slomo_> ajmitch: thanks :)
<\sh> lucas: yes, because it's the truth. There is a new generation coming up, which don't want to use those tools anymore...they want it shiny, mouse-move-ish and translucent, and we should sit in our hobbit holes and denying that. But we can try to teach them, and if they're interested they can learn from us. Same applies to the old guys, they should not be afraid of this change towards shinyness etc. Actually, we have a choice, but others don't
<\sh> ting.
<\sh> "...,and we shouldn't sit..."
<lucas> then provide an old interface using web services from the command line
<lucas> so the old guys get to know your tool
<ajmitch> slomo_: the other option given on the newmaint list is that I send a signed email to there, and front desk will change it manually :)
<\sh> lucas: that's what we will do for launchpad e.g. that's what google was doing with their xmlrpc api
<lucas> great.
<lucas> then, before this is implemented, don't expect debian developers to get interested in LP
<ajmitch> even after that, there's still a tight dependency on a non-free tool
<\sh> lucas: no, it has nothing to do with "not interested", it has to do with "non-open-source", but as I said, nobody is refusing to use google :)
<\sh> lucas: and to be honest, many people are depending on google :)
<lucas> DDs are not forced to use google
<ajmitch> that's because, as I said before, debian developers would not be tied to google
<lucas> \sh: I find it disturbing that we all rely on google
<\sh> lucas: nobody is forced to use LP :)
<lucas> \sh: if a debian team starts using LP
<lucas> chances are high that new members of the team will have to use LP too
<ajmitch> lucas: and some have
<\sh> lucas: then they made a choice, and they have to live with it.
<lucas> they made the choice to become tied up with proprietary software
<lucas> not much better than being forced to use MS word to read complex .doc
<raphink> argh FTBFS :s
<\sh> lucas: if they choose to work with lp, then they weren't forced to use it.
<lucas> how easy is it to get out of LP currently ?
<lucas> like exporting data ?
<\sh> lucas: rosetta - very easy
<lucas> malone ?
<ajmitch> currently quite hard
<lucas> ok
<ajmitch> and I wouldn't want to try & do a full dump of it via xml-rpc
<ajmitch> when that interface is added
<lucas> anyway, </discussion on LP>
<lucas> \sh: I can't find your updated package from launchpad bug 6556
<\sh> lucas: was it wesnoth?
<lucas> yes
<\sh> then you will find the changes already in the latest upload of wesnoth.
<\sh> -2 of debian has the old patch and stuff inside, so I'm refusing to merge
<\sh> that's what I wrote on -motu
<lucas> ok, I understand
<\sh> -3 will be different
<raphink> hehe
<raphink> or you could merge and modify it
<raphink> instead of just synching -2
<raphink> syncing
<\sh> raphink: that makes no sense...I have to revert a patch and include my patch again, instead of waiting for -3 and sync
<raphink> ok
<raphink> thats' a point of veiw
<raphink> but yes given that -2 has older patches than -1ubuntu2 to fix the same bugs
<raphink> it's better to keep -1ubuntu2 obviously
<\sh> raphink: that
<raphink> \sh: I think the best thing about the amd64 bug might just be that you talk with isaac
<lucas> \sh: I can't find your patch on the debian BTS
* Burgundavia wonders if the motus spend more time with wesnoth because it is a game
<raphink> lol
<Q-FUNK> would anybody please be so kind as to sync rus-ispell from unstable?  the rus-ispell in dapper right now is hopelessly outdated and none of those diffs are needed.
<\sh> lucas: isaac has it already, because I filed my change upstream, and he has it in his svn tree (remembering what luk said(
<\sh> lucas: upstream == wesnoth bts
<lucas> mmh ok
<raphink> can't sync enlightenment
<raphink> doesn't build on dapper
<\sh> lucas: all this was discussed earlier on :) and there were some really nice mails and irc statements about it :)
<lucas> ok
* lucas wasn't here earlier ;)
* psusi tries to remember who the other person was besides Yagisan that was interested in the defrag package last night
<\sh> lucas: the last 3 days?
<lucas> I left after raphink did the first merge
<lucas> \sh could you file a bug on launchpad saying that wesnoth shouldn't be merged ?
<lucas> chances are quite high that somebody will start working on one ...
<\sh> lucas: well...why? it's not on the merge list anymore...it will show up again when -3 will come :)
<lucas> it's on the lists on http://tiber.tauware.de/~lucas/versions/ for example ;)
<\sh> lucas: yes, but this is not the tool, which I'm using to keep track of the merges.
<lucas> that you are using.
<raphink> but other people are using it \h
<\sh> raphink: sure, but other people reading as well -motu ML :)
<lucas> the lowest common denominator
<raphink> hopefully
<lucas> is malone
<lucas> anyway, if you don't want to, I'll file a malone bug about this.
<\sh> lucas: no...I'll write a comment to 6556
<lucas> I posted a new bug
<\sh> whatever...
<lucas> a comment on #6556 has very few chances to be found by the potential merger ...
<\sh> lucas: that's why we have the central station named revu in sistpoties home. to see the new, accepted and done merges...and as well attached to it the bugreports.
<lucas> the problem is that this central station currently misses some merges
<\sh> lucas: that's why a auto-generated list without a bit of more information from another source is no good. if you can hack your list code into sistpotys source, would be more useful instead of having two different versions
<lucas> I will
<raphink> ok well
<raphink> we have to sync/merge xlibs-data before enlightenment can be merged
<\sh> why/
<raphink> enlightenment -3 builds on some files provided by xlibs-data 6.9
<raphink> but not present in xlibs-data 6.8
<\sh> raphink: xlibs-data is daniels area :)
<raphink> he's gone :(
<raphink> I guess the new enlightenment activates new functions based on new xlibs-data
<raphink> so I just can't merge it, unless I deactivate these options and then there's no point in merging I guess ;)
<raphink> I'll update the bug with these infos and wait for xlibs-data to be upgraded I guess
<raphink> is that fine \sh ?
<lucas> /whois sistpoty
<lucas> oops
<lucas> /whois sistpoty
<lucas> rah
<raphink> lol
<\sh> raphink: well...xlibs-data is belonging to the xorg source package...so it should be done by daniels....
<sistpoty> I'm Stefan Potyra :P
* raphink takes lucas's space bar
<\sh> raphink: so the best think is we have to wait
<raphink> \sh: yes but I'll put this info in the bug I opened to merge enlightenment
<lucas> sistpoty: thank you, but I was looking for your idle time :)
<raphink> so people don't work on merging it before xlibs-data is ready
<\sh> raphink: sure :)
<sistpoty> lucas: hehe, was quite some time
<sistpoty> \sh: did you actually upload a newer version of wesnoth?
<\sh> sistpoty: -1ubuntu2 is the latest with all patches from debian and my amd64 bit patch applied...that's why I wanted to not merge/sync the latest -2 package from debian..I'm waiting for 3
<sistpoty> \sh: then you shouldn't have the bug marked as fixed... thus way it will move to new once I update the merge list
<\sh> sistpoty: well...I hope the package will come soon of isaac...I'm just optimistic...
<\sh> how long until the stupid update is finished here
<sistpoty> hehe, in case I update the list earlier on, just file a merge bug but don't mark it as fixed yet... thus the merge will stay on the assigned side
<\sh> sistpoty: I wonder if your tool can handle reopenings of bugs? :)
<sistpoty> \sh: not a chance :P
<\sh> sistpoty: ok :)
<sistpoty> \sh: but feel free to use update_status.py in /home/sistpoty/merge_offline ;)
<\sh> sistpoty: hmm...or I adjust your regexp to filter as well re-opened bugs :)
<sistpoty> hehe
<\sh> sistpoty: and update the db accordingly :)
<\sh> but first, the dist-upgrade must be finished :)
<\sh> can't even start a new browser or something else...
<ajmitch> ah that's better, pqm includes the right files on make dist now
<raphink> actually... I can't even build the _current_ enlightenment version in dapper !!
<\sh> raphink: what does the build log say?
<raphink> \sh: http://pastebin.com/497001
<raphink> X11/bitmaps/{flipped_gray,gray,gray3} are provided by xlibs-data
<\sh> ah
<raphink> and the current xlibs-data in ubuntu doesn't provide them
<raphink> I guess it provided it before
<raphink> since the -2 was synced in Ubuntu fine a few weeks ago
<\sh> yes..but not it's xbitmap
<\sh> s/not/now/
<\sh> i think
<raphink> oh ok
<raphink> sure?
<\sh> moment...just updating apt-file :)
<raphink> ok
<\sh> yes...xbitmaps
<raphink> ok
<raphink> so enlightenment should depend on it
<\sh> yepp
<raphink> ok
<\sh> build-dep
<raphink> yet -2 didn't depend on it
<\sh> you need it while you are building it :)
<raphink> it was just synced
<raphink> yes
<\sh> did -2 ever get build?
<raphink> yes
<raphink> I think so
<\sh> Version: 1:0.16.7.2-1ubuntu2
<\sh> of enlightenment
<raphink> but maybe it got build before xbitmaps was released
<raphink> actually yes
<raphink> -2 got synced but not build it seems
<raphink> so that might be the reason why
<raphink> we have to merge it with xbitmaps in Build-Depends
<raphink> I'll try that
<raphink> :)
<raphink> https://launchpad.net/distros/ubuntu/+source/enlightenment
<raphink> it says : pending ;)
<Nafallo> baah!
<Nafallo> ^w isn't ^q
<raphink> Nafallo_away: sorry?
* raphink feels Nafallo_away is speaking the gentoo language
<raphink> ;)
<\sh> oh tomorrow i have my second interview
<raphink> \sh: while I'm merging it, shall I update the standards version too?
<raphink> it has  3.5.9.0 currently
<\sh> raphink: why not :) we will see this package actually again :)
<psusi> can you get cut to give you only the LAST field on a line?
<raphink> ok :)
<raphink> lintian also shouts about the changelog file, for a good reason
<raphink> \sh: http://pastebin.com/497023
<raphink> do you think that should be fixed ??
<raphink> like removed or so
<raphink> we can't know what version this lines refer to
<raphink> s/this/these/
<raphink> given that previous version was -6.1 I guess this one is -6.2 but can't be sure
<\sh> raphink: what says the orig debian package?
<raphink> that's what's in the debian package
<raphink> ;)
<raphink> latest version of the debian package that is
<\sh> raphink: well...vorlon made an NMU so it should be something with a dot in the revision
<raphink> I didn't change it
<raphink> yes
<raphink> and since previous version was also an NMU : -6.1
<raphink> this one must have been -6.2
<raphink> I guess
<\sh> raphink: or file a bug in debian bts, complaining that they b0rked the changelog :)
<raphink> hehe
<raphink> ;)
<raphink> yes that's an idea
<\sh> well...he should have used dch instead of vi directly ,)
<ajmitch> enlightenment?
<raphink> ajmitch: yes
<\sh> yes the old shiny wm :)
* ajmitch fetches
<\sh> which has no use but funny themes :)
<raphink> ajmitch: line 96 in -3 version in sid
<Seth> Seveas, if you get a chance could you change my hostmask to just u/m/seth now that I own the proper nick :) thanks
<raphink> misses the package name & version
<raphink> line
<raphink> just fetching the lintian output
<raphink> which is quite verbose on this package ;)
<Seveas> Seth, you can poke array_random($FREENODE_STAFF) yourself :)
<raphink> E: enlightenment: wrong-path-for-interpreter #!/usr/sbin/install-menu != /usr/bin/install-menu (./etc/menu-methods/enlightenment)
<Seth> Seveas, ah, will do :)
<ajmitch> raphink: you know where to file bugs :)
<raphink> well I don't even have install-menu on my system
<raphink> I don't know what this is
<raphink> nevermind
<raphink> ajmitch: shall I file a bug for the changelog stuff?
<ajmitch> changelog was screwy before the last upload
<raphink> yes
<raphink> so I don't bother with it?
<raphink> or what?
<ajmitch> do it if you wish, but it'd probably be a minor bug at most
<raphink> yes
<raphink> well it makes lintian shouts
<raphink> otherwise it's surely not anything important ;)
<ajmitch> yep
<raphink> ooo there never was an -ubuntu version of enlightenment yet?
<raphink> hmmm
<raphink> yes there was ...
<psusi> what was the dpkg switch to find out from which package a file comes from?
<raphink> -S
<psusi> this is frigging weird
<raphink> what?
<psusi> the pktsetup that is installed from the binary deb is NOT built from the source deb
<psusi> for udftools
<raphink> how do you mean?
#ubuntu-motu 2006-01-14
<raphink> you mean the latest source did not produce any bin ?
<raphink> so the bins are from the latest but one source
<raphink> ;)
<psusi> the source code in the source package for pktsetup is an older version...only has two help lines in usage() that it prints with you give --help... if I run pktsetup --help, it gives more help and reports a newer version
<raphink> ?
<psusi> no, I mean the bin from the binary package was NOT compiled from this source ;)
<raphink> yes
<raphink> but the bin could have been built from an older version and the latest src could have not produced any bin
<raphink> this doesn't seem to be the case though
<psusi> no... the bin is built from a newer version
<raphink> ok
<raphink> that's weird
<psusi> yea
<raphink> what does p.u.c say about it?
<psusi> p.u.c?
<raphink> packages.ubuntu.com
<psusi> wait...
<psusi> ohh, there's some patches in debian... they must not be applied
<psusi> they arne't dpatch though... hand rolled looks like
<psusi> hrm...
* psusi is getting frustrated that the patches aren't applied automatically when you apt-source
<selinium> If you wanted to change the colour of a single word in a paragraph, what tag should I use? acronym? or is there a more suitable one?
<selinium> Duh, sorry guys, wrong channe;l
<psusi> ok... THAT looks like the right source ;)
* sistpoty is off to bed
<sistpoty> gn8 everyon
<sistpoty> +e
<raphink> \sh: debdiff uploaded
<\sh> raphink: number?
<seth> selinium, <span> probably
<raphink> #6558
<selinium> cheers seth! :) lol
<raphink> \sh: right?
<\sh> raphink: fetching package and debdiff now :)
<raphink> ok
<\sh> raphink: it complains again about the changelog...debuild fails
<raphink> fails?
<raphink> well I know about the changelog stuff, but it doesn't make debuild fail here
<\sh> parsechangelog/debian: error: found change data where expected next heading or eof, at changelog line 105
<\sh> dpkg-genchanges: error: syntax error in parsed version of changelog at line 0: empty file
<\sh> debuild: fatal error at line 768:
<\sh> dpkg-buildpackage failed!
<raphink> what makes it fail?
<\sh> raphink: the missing version entry
<raphink> what if you use debuild directly
<raphink> instead of dpkg-buildpackage ?
<raphink> actually I tested it with debuild
<\sh> raphink: i'm using debuild :)
<raphink> and with pbuilder
<raphink> and it worked
<\sh> raphink: I'm using it on dapper :)
<raphink> same here \sh I have dapper here
<\sh> raphink: it creates a source changes file yes, but it's not correct :)
<raphink> let's see again
<lifeless> hub: opensync is stuck in NEW at the moment
<lifeless> hub: the gui and plugins are ready to go after that
<raphink> it seems to build here
<raphink> just launched debuild
<raphink> does it fail at the end of the build?
<hub> lifeless: okay. there are directly uploaded?
<\sh> raphink: try this: debuild -S -v1:0.16.7.2-1ubuntu2 -ksh@sourcecode.de
<hub> lifeless: s/there/they/
<lifeless> EPARSE
<ajmitch> hub: to debian, yes
<\sh> raphink: I'm not building in chroot...I'm using this debuild call and pbuild it
<hub> ajmitch: ah you mean they do to debian and we resync....
<hub> ajmitch: ok cool
<raphink> wait it's building right now
<raphink> the build is finishing
<raphink> hmm right I get the same error as you with your command \sh
<raphink> but I don't get it when I run `debuild' simply
<raphink> \sh: I know why you get this error
<raphink> ;)
<raphink> there's no such version as 1:0.16.7.2-1ubuntu2
<raphink> ;)
<raphink> in this changelog at least
<\sh> raphink: didn't you merge the changelog?
<raphink> my version is 1:0.16.7.2-3ubuntu1
<raphink> \sh: I merged the changelog with the latest available source on ubuntu
<raphink> which was 1:0.16.7.2-2
<raphink> since it had been synced
<raphink> and thus didn't contain any ubuntu changelog ;)
<raphink> see http://archive.ubuntu.com/ubuntu/pool/universe/e/enlightenment/ \sh
<\sh> Previous Ubuntu Version: 1:0.16.7.2-1ubuntu2
<\sh> Current Debian Version:  1:0.16.7.2-2
<raphink> nope
<\sh> argl...
<\sh> the report is old
<raphink> previous source in ubuntu is 1:0.16.7.2-2
<raphink> and current debian is -3
<\sh> well..running version is 1ubuntu2
<raphink> which is the one I'm merging
<raphink> -2 never produced bins in Ubuntu
<raphink> yes \sh
<raphink> but then crimsun synced -2
<raphink> but it never built
<raphink> because it lacked the xbitmaps deps
<raphink> so now I'm basing my merge on -2, merging -3
<raphink> or should I base it on -1ubuntu2 although it's an old source?
<lucas> gnight
<\sh> raphink: forget it...I'll adjust it to but it complains about line 105...
<raphink> \sh: i'm ok to base it on -1ubuntu2 if you prefer it that way
<\sh> raphink: and line 105 is the missing entry :)
<raphink> line 105 must be the missing entry
<\sh> raphink: no...since -2 was synced
<raphink> yes
<raphink> it doesn't prevent from building though
<\sh> raphink: so we have all the changelogs we need..
<raphink> merges should not be based on synced versions?
<raphink> hmm?
<\sh> raphink: nono..it's ok...:)
<raphink> <\sh> raphink: so we have all the changelogs we need..  <--- in which version?
<raphink> \sh: no I'd like to understand really :)
<\sh> raphink: from the last ubuntu version to the actual version...-2 synced and -3ubuntu1 will be merged
<raphink> ok
<raphink> I should just have ignored -2, right?
<\sh> raphink: no you can't :)
<raphink> then what?
<raphink> :s
<raphink> use the changelog from -1ubuntu2, add -2 and -3 changelogs and dch ?
<\sh> raphink: nothing to be done for debuild...debuild -S -ksh@sourcecode.de is enough for here..
<\sh> but I wonder if we shouldn't fix up the changelog at all..
<\sh> ajmitch: what do you think?
<raphink> ajmitch said it was ok
<raphink> that it would maybe not even be considered in Debian
<raphink> since so small a bug
<\sh> ok..i'll build it now :)
<raphink> just as I'm not sure to report to Debian that I bumped standards-version to 3.6.2
<raphink> and reporting the xbitmaps stuff would be nonsense since they don't have this pb in Debian
<\sh> updating the standards version is normally a job for the maintainer
<raphink> yes
<raphink> I did it because it was an old one really
<raphink> and that's not a big diff ;)
<\sh> raphink: well..they don't have it not now :) wait until modular xorg is hitting debian :)
<raphink> yes exactly
<raphink> as long as they don't have modular xorg
<raphink> this patch will have to be applied on all merges of enlightenment
<\sh> well..you can file a bug with a debdiff attached and tell them that it is for the modular xorg...but I wouldn't do it, they know exactly where to look :)
<raphink> yes
<raphink> ;)
<raphink> and filing bugs for future work is not always appreciated imo
<raphink> does it build well now?
<\sh> yes no probs
<raphink> ok :)
<\sh> uploaded
<raphink> :D
<raphink> time for me to get uploaded to my bed
<raphink> ;)
<\sh> rebooting with new kernel...brb
<raphink> hehe ok
<psusi> why does this source package have man pages in section 8?  there is no section 8?  and when it is installed, it ends up in section 1
<\sh> re
<\sh> k...going to bed
<psusi> by gosh I'm making all kinds of patches for udftools... by the time I'm done with this thing it will be proper plug and play
<raphink> ajmitch: shall I email some guys about their package when they haven't uploaded a new version for a month and a half ?
<raphink> or even more ;)
<tseng> no?
<raphink> :p
<tseng> emailing people directly is a good way to annoy people
<tseng> thats what bug trackers are for
<raphink> well then we need to use a bug tracker on REVU
<ajmitch> raphink: new version on revu?
<raphink> lots of packages are lying there with comments
<raphink> and no modif has been done on them for months
<raphink> e.g. http://revu.tauware.de/details.py?upid=816
<raphink> or http://revu.tauware.de/details.py?upid=866
<raphink> or http://revu.tauware.de/details.py?upid=797
<raphink> just very old packages
<raphink> whose packagers didn't work on for ages
<raphink> and that are preventing (imo) reviewers from working efficiently
<raphink> hmm wait a min
<raphink> chmsee has been archived actually
<raphink> should very old packages be archived ajmitch ?
<ajmitch> why should they?
<ajmitch> are they any less valid?
<raphink> no
<raphink> but it seems their packagers have left with no interest in having them in dapper anymore
<raphink> when it's been almost 3 months
<ajmitch> that may be the case
<raphink> that's why I asked if maybe these guys could be emailed
<raphink> to get to know if they still want to work on these packages
<raphink> some people are waiting for up-to-date packages to be reviewed
<raphink> and old packages staying around with no modif doesn't help
<ajmitch>  http://revu.tauware.de/details.py?upid=866
<ajmitch> should be archived/nuked
<ajmitch> because a newer version is in dapper
<raphink> ok
<raphink> I'll archive it
<ajmitch> I was about to, but if you want, go ahead
<raphink> already done ;)
<raphink> http://revu.tauware.de/details.py?upid=738 hasn't been worked on in 3 months
<ajmitch> so?
<raphink> so nothing ...
<ajmitch> hub is around here at least every couple of days
<raphink> I guess
<raphink> that's right
<raphink> maybe we could have an automatic tool to check if the version if dapper has not made packages in REVU outdated
<ajmitch> sure, that'd only take a couple of minutes to do
<raphink> ok :)
<raphink> this way, packages who are obsolete could be nuked
<ajmitch> maybe a few more, anyway
<raphink> s/who/which/
<ajmitch> *most* packages are new packages anyway
<raphink> yes most
<hub> raphink: because there is an argument about a line in the license, and I have forgotten to write upstream for clarification
<raphink> oh ok
<hub> raphink: once I become MOTU, I'll give a hand...
<raphink> :)
<raphink> same here hub
<raphink> I wish to do more once I'm a MOTU :)
* spacey_ki @#$@ @ cups
<hub> raphink: I'll do what I cna
<raphink> sure :)
<raphink> hub: I'm a bit frustrated about REVU right now, cause it's not easy to know which packages are to be reviewed and which ones are not
<raphink> without checking all pages
<raphink> :s
<raphink> but I guess I should go to sleep and stop complaining ;)
<psusi> is there a way to ask cut for only the LAST field on the line?
<ajmitch> use awk :)
<psusi> heh
<hub> raphink: yeah it is a bit late on your side of the pond
<raphink> yes
<hub> 2AM?
<ajmitch> awk '{print $NF}'
<ajmitch> will tend to print the last field
<psusi> hrm...
<raphink> yes hub
<ajmitch> psusi: what do you need it for?
<raphink> k well I'll go
<raphink> later
<psusi> I have modified pktsetup to auto assign the first availible virtual device to the given cdrom device, and print it's dev number... I'm now writing a hal fdi policy callout that will run pktsetup and grab the device number and store it in a hal property
<psusi> that way all you have to do is install the udftools package, and hal will configure the pktcdvd devices for each cdrw drive it detects
<Mez>  sanyone interested in giving me a crash course on how to write man pages
<LaserJock> Mez: I did one using Docbook and converting it
* Mez has no idea how to do that either
<seth> http://jr.falleri.free.fr/files/kubuntu/sample.1.docbook
<seth> then in the build rule, docbook2x-man debian/blah.1.docbook
<crimsun> Mez: take the sample that dh_make gives you
<seth> and in the clean rule, rm -f blah.1
<crimsun> it's a pretty good starter.
<ajmitch> or if you're really lazy
<ajmitch> use help2man
<Mez> ajmitch, it doesnt have a --help or --version
<Mez> though it does have man pages
<Mez> which I didnt spot :D
<ajmitch> the program sucks then :)
<LaserJock> yeahhh!!!! my first package just hit dapper-changes!
<ajmitch> LaserJock: well done
<Mez> seeing as it has man pages and installs them automatically with the make install - I dont need to run anything else for it do I ?
* Mez grumbles
<Riddell> no
<Burgundavia> Riddell, do you feel dirty after touching a GNOME package? ;)
<Riddell> I always believe in being open to new cultures and experiences, even Gnome
<Burgundavia> sorry, had to ask that
<Riddell> Burgundavia: now go and revu the KDE packages!
<Burgundavia> Riddell, not a MOTU
<Riddell> write some KDE docs!
<LaserJock> lol
<Burgundavia> might be soon
<Riddell> infact to get you learning about new cultured and experiences please rewrite the whole of KDE docs and put them under a Debian-happy licence, that would make things much easier for us
<spacey_ki> anyone experience with figuring out the ipp URI from a network printer? :S
<Burgundavia> Riddell, the doc team is unlikely to move from GFDL/cc-by-sa 2.0. We (including Mako) made that decision at Mataro
<hub> Burgundavia: to be incompatible with debian? :-/
<Burgundavia> hub, no
<Burgundavia> hub, to be more compatible with the vast majority of docs out there
<hub> Burgundavia: I was sort of kidding.
<hub> Burgundavia: I have nothing against this license
<Burgundavia> From a documentation perspective, GNOME/KDE are the more important upstreams
<crimsun> I don't agree with the decision, but I didn't take part, and I don't care to debate it.
<hub> I was not about to debate either
<hub> maybe I should just shush
<jsgotangco> :D
<Burgundavia> I get ask that question a lot and since I was there for the decision, I usually tell people what happened
<Burgundavia> s/ask/asked
* jsgotangco just writes and let people like Burgundavia decide on licenses :D
<thierry_> any cdbs guru around?
<ajmitch> define 'guru'
<ajmitch> and don't ask to ask
<thierry_> I need to pass the option --enable-shared to the configure script but I'm using cdbs, is there anyway to do this or do I have to switch for debhelper?
<thierry_> ajmitch : what do you think?
<ajmitch> of course you can
<thierry_> how?
<ajmitch> DEB_CONFIGURE_EXTRA_FLAGS = --enable-shared
<ajmitch> is the most common way
<ajmitch> assuming you're using autotools.mk
<thierry_> ajmitch : ok thanks : last thing, I need to add the changes made in a file by the upstream author in the source of the librairy I package, how do I that?
<ajmitch> and put that line below the include lines
<thierry_> I add the change and that's all?
<ajmitch> yeah, unless you feel like using a patch system
<thierry_> ajmitch : and by below you mean under? (my english is not so good, I speak mainly french)
<ajmitch> yes
<ajmitch> for example http://lists.debian.org/debian-devel/2005/03/msg00083.html
<thierry_> k thanks
<thierry_> ajmitch : do I also need to change the file in the orig.tar.gz archive?
<ajmitch> no
<ajmitch> don't do that
<thierry_> k
<thierry_> ajmitch : would you mind checking my package? I already had a advocate before, but we found this shared librairy problem that I just solved so I think he's alright
<ajmitch> I'm very surprised it got advocated
<ajmitch> since it was an empty package
<thierry_> it was zakame
<ajmitch> I'll have to talk to him :)
<thierry_> don't poke him too bad :)
<thierry_> too hard*
<thierry_> anyway, do you have time to check my package?
<ajmitch> building it on tiber now
<thierry_> :D thanks!
<thierry_> it's a dependency for another package I want to do for dapper wich is in the universe candidates
<jsgotangco> wow Riddell thats a lot of CDs
<psusi> is there a gui tool that shows all the configurable settings in all the packages in the system?  rather than having to dpkg-reconfigure?
<thierry_> ajmitch : is it looking good
<ajmitch> -rw-r--r-- root/root    776012 2006-01-08 22:47:30 ./usr/lib/libfxscintilla.so.17.0.0
<ajmitch> lrwxrwxrwx root/root         0 2006-01-08 22:47:27 ./usr/lib/libfxscintilla.so.17 -> libfxscintilla.so.17.0.0
<thierry_> so? is it ok?
<thierry_> I knew I had my .so files... but is the whole thing alright to get an advocate? :)
<ajmitch> oh, I haven't done an indepth look :)
<thierry_> ho!... then I'll sleeping :) but if you want to leave a comment when you'll have the time to finish this, I would be grateful
<ajmitch> ok
* ajmitch has to see if the library has the right name or not
<thierry_> ho crap, it's the only thing I'm really not sure ;) anyway good night
<ajmitch> night
<ajmitch> why do people persist in using the mailing list to report bugs?
<ajmitch> or worse, the forums
<desrt> for a lot of people it's hard to tell the difference between a bug report and a support request
<Hobbsee> scared of bugzilla/malone?
<desrt> most computer users are used to "it's not working" being their own fault
<desrt> which makes a forum an appropriate place to seek help
<LaserJock> desrt: I agree
<LaserJock> I am still that way
<psusi> anyone else notice the firefox in dapper is HORRIBLY slow at redrawing it's window when previewing edits to the ubuntu wiki?  tab to a terminal and back, or worse, drag the terminal window over the dapper window, and holy moley it lags!
<LaserJock> I at least like to confirm that it's not me before I do a bug report
<desrt> psusi; sounds like you're not using accelerated X drivers
<desrt> psusi; fglrx is completely fixed now, fwiw
<psusi> dereks_, nope... it's accelerated... not using fglrx, but have dri and mesa working
<psusi> firefox is nice and fast otherwise, it is only when redrawing uncovered areas on the wiki preview page
<desrt> psusi; that has very little to do with 2D accel
<psusi> scrolling the preview page is plenty fast... doesn't even make my cpu bump up speed
<psusi> desrt, dri has everything to do with 2d accel
* desrt raises an eyebrow
<desrt> no.  it seriously does not :)
<psusi> ummm.... I'm prety darn sure it does
<desrt> dri is when libGL connects directly to the kernel
<desrt> (ie: bypasses the X server hence "direct")
<psusi> it's also for 2d apps to do the same, is it not?
<desrt> no.
<desrt> 2d apps always render through X
<psusi> well it sure as hell makes 2d go faster when you turn on dri ;)
<desrt> possibly because you're also enabling XRENDER acceleration at the same time
<psusi> well, got any 2d speed tests to check it?  scrolling works nice and smooth... might be that firefox scrolls sanely, but whenever it has part of the window uncovered, it repains the ENTIRE page, and this is a rather complex page... so it may be making a crap-ton of calls to the X server
<psusi> cause it does seem to be the X server that is actually getting bogged down
<desrt> uhm
<desrt> there is something
<desrt> xperftest or something
<desrt> i don't know the exact name
* Mez pokes his package onto revu
<Mez> anyone fancy reviewing
<psusi> hrm... yea... I think it is actually the X server that is bogging down... because if I tab to firefox, then immediately tab out again, the tab lags
<desrt> try out fglrx and see if the situation improves
<psusi> don't want to run proprietary code
<desrt> if it does, consider filing a bug against the dri driver
<desrt> arf
<desrt> intuition knocked again:
<psusi> getting rid of fglrx so mesa worked right was a pain
<desrt> i remember :)
<desrt> but that was your own fault :)
<psusi> hehe....
<desrt> the ubuntu fglrx packages install cleanly
<psusi> do they now?  they didn't for a while
<desrt> as of today they do
<desrt> i said so ^^ up there :p
<desrt> dapper is actually working great right now
<desrt> i'm pretty impressed with how rapidly it's coming together
<desrt> a lot of really nice things have happened in this release
<psusi> ok... nevermind... it seems dri broke somewhere ;)
<psusi> turn your back for 5 seconds and it breaks... sheehs... heh... ;)
<desrt> there's your problem :)
<psusi> desrt, I would be really pleased if dmraid could make it into dapper so I can cleanly install it
<desrt> file an RFE on bugzilla?
<desrt> if it's small, easy, and has a reasonable use it will probably get in
<psusi> I filed a bug when I first installed ubuntu breezy preview... it is currently assigned to infinity I believe
<psusi> fabione also had a hand in it, but seems to have more important things to work on
<psusi> he build the package from source and put it in universe before breezy was released
<psusi> I ended up making some initramfs scripts to go with it and wrote a howto on the wiki
<psusi> works fine for me and a few others, but the integration has not moved anywhere in months
<desrt> hmm
<psusi> https://wiki.ubuntu.com/FakeRaidHowto if you are interested
<desrt> nothx :)
<psusi> ;)
<desrt> my ubuntu install is not valuable
<desrt> and my home directory is backed up
<desrt> which reminds me
* desrt makes a backup :)
<psusi> hehe
<psusi> backing up will be nicer once I finish this: https://wiki.ubuntu.com/PacketCD
<desrt> i can't imagine backing up to cd
<desrt> that would be pain
<psusi> and why the hell does revu allways say access is forbidden when I try to look at the source.changes?
<psusi> desrt, it would? drag and drop your documents is a pain?
<psusi> full system backups are nice, but your averge user just likes to drag and drop a copy of their important files to a disc
<lifeless> I find that 'average user' argument really annoying
<lifeless> I've known lots of users, and my assessment of the average is they want to not do backups manually, just to set it up once, and then have a button to press that does it and /tells/ them it did it
<desrt> ya
<psusi> some people like that... some people would rather have a disc they can hold in their hot little hands and know their data is on it and they can open it in another computer ;)
<desrt> if i were an average user i'd have to agree with lifeless :p
<desrt> i like the idea of an external firewire drive
<desrt> it's large and i can unplug it
<psusi> for full system backups?  yea... that's great
<desrt> unplugging is important
<psusi> aye
<desrt> it means that if my computer explodes in the worst way possible it still can't take the backup with it
<psusi> well, as long as the backup is off site... the computer could burn the building down and the firewire drive with it ;)
<psusi> rsync snapshot backups look really nice
<lifeless> psusi: they get a disk
<lifeless> tand they can
<lifeless> *and they can*
<psusi> if you have a removable drive with more space than your main disk
<lifeless> psusi: no, you are making assumptions that were not present in what I said
<psusi> or it can be on a remote server... handy for those peskey fires
<psusi> huh?
<psusi> I was still talking about rsync snapshot backups... I have no idea what you said ;)
<desrt> psusi; ya.  rsync is what i use
<desrt> it's bloody quick
<desrt> it takes about 10 seconds if nothing has changed
<desrt> (and obviously longer if things have)
<psusi> desrt, I'd still like to have a chattr attribute or something for copy on write... then you could do rsync snapshot type backups on one disk, without wasting half the space
<desrt> psusi; but then you lose the advantage of the backup in the case your computer goes bonkers
<desrt> i want my backup offline, k thx
<psusi> desrt, yes... but you get the history without having to buy more hardware ;)
<desrt> i also want to protect against media faulure
<desrt> and that implies redundancy
<psusi> ideally, I'd like to have copy on write on all the time... then make periodic backups to removable media
<lifeless> psusi: you talked about drag and drop as what the average user *wants*
<lifeless> psusi: I dont think thats accurate
* Yagisan used to have two backup locations, gmailfs + dvd - but gmailfs died :(
<desrt> gmailfs is an amusing concept
<psusi> lifeless, why not?  from what I have seen, the _average_ person ( not the average linux user ) basically (only) understands copying things to removable media
<psusi> Yagisan, hey... welcome back
<Yagisan> desrt: I have so many accounts, I thought why not. I encrypt my backups anyway ..
<desrt> heh
<psusi> Yagisan, you ever build my defrag package?  I was playing with it last night... kept giving it different lists of files to store in order hehe...
<desrt> that's an amusing concept
<desrt> use a cluster of gmail accounts as a large disk
<Yagisan> psusi: not for long - I just stepped in, saw my name lit up, and have to leave in few minutes again
<psusi> Yagisan, btw... make sure you use the -p option... it defaults to only use 2 MB of ram to move data with... goes MUCH faster if you give it more
<Yagisan> psusi: I have only /boot and / on ext3, the rest are jfs - so I don't have much to defrag. btw on ext2/3 it will *never* completely defrag, due to the way ext2/3 stores files
<psusi> Yagisan, well, assuming it is a very large file, then yea... it can't be stored without being broken up to fit around the inode and bitmap blocks
<LaserJock> so do you guys use tar when you are backing up?
<psusi> it's fun seeing fsck report 0.0% fragmentation though ;)
<Yagisan> desrt: I was wondering if I could raid my gmailfs systems, but gmailfs stopped working before I could try - I have 3 active + 150 invites, so it could be a fun thing to try
<psusi> LaserJock, I do... but I see uses for rsync snapshots too...
<psusi> Yagisan, rofl
<Yagisan> LaserJock: I use sbackup in universe - but only because I converted my network to ltsp based, so I only need to admin 1 box :)
<LaserJock> I have only a few linux boxes and ~ 4 iMac OSX boxes that I would like to backup but I really don't know what the best way to back them up is
<LaserJock> right now it is pretty scattered, I just tar /home and try to have at least two copies on two different machines
<lifeless> psusi: I thnk you are insulting average, and substituting 'new'
<psusi> lifeless, I don't... I think you are thinking of linux users, which are not average ;)
<Yagisan> LaserJock: as you get bigger, bacula is good - even does non-linux systems
<psusi> LaserJock, I'd periodically backup the system with tar, and rsync snapshot /home back and forth between machines
<lifeless> psusi: no, I'm no
<lifeless> *t*
<psusi> lifeless, do you know a single average user who actually even makes backups?
<Yagisan> I rather have cron do my backup for me - every day at 5:30 it should be done, and every 21 days that needs to be a full backup
<Yagisan> psusi: All my clients do
<psusi> average windows user who couldn't explain to you the difference between sdram and rambus mind you
<lifeless> psusi: just think about this for a few minutes - how many people start using computers and in (saY) 5 years still dont understand the idea of 'backup software'
<psusi> Yagisan, personal or corporate?
<Yagisan> psusi: they are far from technical - it's a hard sell for me to get them as clients considering what I actually do
<Yagisan> psusi: mixed, mainly small business though
<psusi> Yagisan, incremental backups for 21 days?  with tar?
<lifeless> psusi: now, if that amount is < 50%, AND even a small fraction of users that start using computers dont stop using them, then the average user MUST understand backup software, by definition
<Yagisan> psusi: it's like 100mb a day on incremental
<psusi> lifeless, they might understand it, but I know virtually nobody who backs up their home computer regularly
<lifeless> psusi: the difference between sdram and rambus is irrelevant to everyone except when they are upgrading, and then they will ask around. backups however matter all the time, so I dont see why you bring that up
<psusi> Yagisan, then you're dealing with their IT guys are't you?  not average users
<psusi> Yagisan, incremental backups with tar for 21 days is insane... if you loose one of those daily backups in the middle, you can't restore to current
<ajmitch> psusi: small businesses like that don't necessarily have an IT guy
<Yagisan> psusi: I am the it guy
<Yagisan> psusi: It is also backed up to 3 locations
<lifeless> psusi: short story, there are several guys here disagreeing with your defn of average.
<lifeless> psusi:  if you want to say 'new users that dont have a clue - fine, just dont claim they are 'average''.
<psusi> yea... your average buisiness person understands they need an IT guy to do backups... now how many of them backup their home computers?
<Yagisan> psusi: 1 is off site, 1 is onsite on dvd, 1 is on a network box
<Yagisan> psusi: bigger workflow == shorter backup period
<psusi> how many of these average buisness users who understand the need to backup actually do backup their home computers?
<Yagisan> psusi: most of them - especially after I tell them what data recovery costs
<Yagisan> psusi: Of course, other non-ubuntu systems don't ship with a decent default backup system ...
<psusi> I don't know a single person who makes regular backups of their home computer
<LaserJock> Yagisan: your doing a lot better than me, I just backup when I'm feeling bored (every couple of months I would guess), and I don't do any incremental ;-)
<lifeless> I love the way you are moving the goalposts
<psusi> not one
<lifeless> you started out talking about 'wanting drag and drop'
<lifeless> now you are talking about who actually *does* backup, and these are pretty much unrelated.
<psusi> yea.... because it would help users backup their data ;)
<psusi> it is quit relavent to the discussion at hand... average users don't backup
<ajmitch> psusi: and I do, so your point is?
<psusi> ajmitch, my point is that your average home windows user does not backup their system... but they do understand how to copy important files to a disc to put in a safe place, and if doing that were easy, they would be more inclined to do so
<psusi> hence https://wiki.ubuntu.com/PacketCD
<LaserJock> psusi: maybe I'm showing my ignorance here but can't you do that with Nautilus
<ajmitch> https://wiki.ubuntu.com/HomeUserBackup
<lifeless> psusi: meh, backup windows is incredibly easy, there is a wizard to do it for just their own files
<lifeless> psusi: ease is -not- the problem!
<psusi> LaserJock, sort of...
<psusi> LaserJock, nautilus appends new sessions to the disc... can't remove stuff without reformatting
<LaserJock> ah, I see
<psusi> plus you can't write to it normally from the command line... i.e. you can't tar -czlf / /media/cdrecorder/backup.tar.gz
<Yagisan> LaserJock: well, not so long ago I felt the pain of complete system meltdown, with 1 backup failing to restore.
<psusi> with packet writing, you can
<psusi> lifeless, if it is so easy then why don't people do it?  because they have to find the wizzard... they already understand how to copy files around
<Yagisan> ajmitch: I think sbackup does what is listed on your wiki page
<ajmitch> Yagisan: probably, but it's not my spec :)
<lifeless> psusi: your logic is now inconsistent
<lifeless> psusi: as windows comes with packetcd support built in and AFAICT this has not changed things
<desrt> oh
<desrt> inconsistent logics?
<desrt> i'm totally in on this convo
<Yagisan> psusi: 1) does your packetcd thing work with dvds, 2) will windows/mac/netware read those discs ?
<desrt> are we assuming the axiom of choice?
<psusi> lifeless, no, windows does not
<Yagisan> brb
<lifeless> desrt: hell no, predicate logic need not apply
<psusi> you need incd or something to get packet mode in windows
<desrt> lifeless; ?
<desrt> lifeless; you do not need the axiom of choice to have a meaningful predicate logic
<psusi> Yagisan, I believe yes on both
<desrt> lifeless; hell.. you don't even need ZF
<lifeless> meh, I'm too tired and grumpy for this. psusi I support packetcd as something to implement and make easy, but if you invoke 'average user' be VERY VERY VERY careful to get your facts straight
<zakame> hi all
<Yagisan> re
<psusi> I just remember several users ago it seemed like everyone would copy their work to floppies at the end of the day for safe keeping
<psusi> they don't do that anymore
<desrt> floppies?  for safe keeping?
* desrt giggles
<desrt> my sister had a college class in effective web communication
<desrt> the teacher mandated the use of floppy disks because she didn't trust usb keys
<desrt> i told my sister to expect the worst
<psusi> rofl
<desrt> the worst, of course, occured.
<psusi> that's funny
<psusi> well, no... it's sad
<psusi> usb sticks are way more reliable than floppies ever were
<desrt> this is why i find funny
<desrt> the amount of memory i've casually amassed on my person
<psusi> I hate floppies... wrote a disk driver for them once... that hardware is hell
<desrt> 1gb on my keychain
<Yagisan> desrt: Oh no, you couldn't find replacement 8" disks ;)
<desrt> 1gb in my vorbis player
<desrt> 1gb in my camera
<desrt> i routinely have 3gb of memory on my body without even thinking about it
<Yagisan> psusi: me too - I did min in x86 asm. I though it was rather fun
<Yagisan> s/min/mine
<desrt> can you even imagine how ridiculous it would be to carry around 3gb on floppy?
<psusi> desrt, and it wasn't that long ago that a 40 MB hard drive was gigantic ;)
<desrt> you'd definitely be aware that you were doing it :)
<desrt> my camera takes pictures that don't even fit on a floppy :p
* Yagisan still has a working 40mb hard drive
<psusi> Yagisan, I nearly blew a gasket after I wrote it to detect the disc using the query command I found in the specs... then found out that NO disks on the market support it
<psusi> which is why you have to manually tell the bios what kind of floppy there is, if any... and the OS believes it... even if it's a lie
<desrt> yet
<desrt> linux can detect them
<Yagisan> psusi: oh - I never had specs - I reverse engineered the bios so I could add support for 3.5" drives on a 286 that didn't support them
<Yagisan> psusi: does you packetcd stuff work on a multi-user system ?
<psusi> desrt, no, it can't... it uses the info provided in the bios
<desrt> oh
<psusi> believe me... I pulled my hair out for days over that
<desrt> how... unlinuxy
<psusi> no disks support the required commands to detect... and both linux and windows grab the bios info during boot and run with it
<desrt> special.
<psusi> writing the code to control the dma in a 32bit os was especially fun... heh...
<desrt> dma used to be funny :)
<Yagisan> desrt: It's "fun" to play with floppys. Esp when you adjust tract and sector size to squeeze more data on is interesting too
<Yagisan> s/tract/track
* desrt remembers how linux could have 1.9mb floppies
<psusi> yea.... 1920 kb with mixed sector sizes
<Yagisan> desrt: 1.64 is the most you can reliably fit on a disk, and still have other systems read it
<psusi> but couldn't boot from them because the bios can only read the standard 18 512 byte sectors per track
<Yagisan> psusi: Yagisan: psusi: does you packetcd stuff work on a multi-user system ?
<psusi> but you could format track0 normally and the other 79 with MSS... and have the boot code in track0 talk directly to the FDC... heh
<psusi> Yagisan, yes... had to fix a few bugs in the kernel and the format utilities to make that work
<psusi> Yagisan, in a sane manner that is
<psusi> described it all on the spec page
<Yagisan> psusi: so multiple users can write to those disks at the same time ?
<psusi> Yagisan, ohh... well... yea... the way I got it set up now is a regular desktop user is going to have it auto mount with the uid= and gid= params set to their id
<psusi> which will cause the owner on disk for files they create/own to be set to -1
<psusi> which causes them to be owned by whoever is specified by the uid=/gid= params when mounted, so it can be used in another computer sanely, or by another user
<psusi> but if you really want to, you can do away with the mount options and multiple users can access it at once, and the real ids will be saved
<Yagisan> psusi: brb - but I'd like to talk about it more when I get back
<Yagisan> re
<jonshea> Does anyone know if there is a particular reason that mpeg2vidcodec isn't included as a package anywhere? Are the licensing issues?
<Yagisan> psusi: I wonder about the automount feature. eg on my ltsp system, when you put a cd/dvd in, it appears on everyones desktop
<Yagisan> jonshea: does a package exist ?
<psusi> ltsp?
<Yagisan> psusi: linux terminal server project. it's in breezy, and edubuntu uses it extensivley
<psusi> Yagisan, currently the automounter sets the uid/gid options when it auto mounts external media like cds and usb sticks, so only one user will have access to it, assuming it is fat, iso9660, or udf
<jonshea> Yagisan: Not as far as I can tell, which is about 30 minutes worth of looking. I'd love to have mpeg2vidcodec, because I use it with imagemagick convert.
<psusi> hrm... sounds very cool
<ajmitch> sigh
<Yagisan> psusi: I use it to make all those old p2/k6 boxes useful
<psusi> nifty
<jonshea> I can install from source just fine, but obviously packages are nicer. I I believe that fink has a package for it.
<Yagisan> jonshea: you'll need to package it yourself then
<psusi> Yagisan, how the heck does that work?  does each login get its own gnome-volume-manager?
<Yagisan> psusi: yep - I have one overpowerful amd64 box - and all the pc's people would chuck away hanging off it - rather cool, and easy to manage
<psusi> Yagisan, normally g-v-m sees the disc and mounts it... in a multi user environment like that you'd want it mounted only once... and either set to be accessible to everyone, or set to actually use the permissions on the disc..
<jonshea> I suspect I can handle that. Thanks.
<Yagisan> psusi: each log in gets there own everything - but most of the code and data can be shared in memory
<ajmitch> sigh
<ajmitch> hammer, please
<psusi> Yagisan, if multiple g-v-m's are running, then won't they race to be the first to mount the media?
<Yagisan> ajmitch: there there, it will be ok
<ajmitch> Yagisan: #ubuntu drones...
<Yagisan> ajmitch: I know - I avoid there, and the forums now. I learnt my lesson
<ajmitch> yeah
<zakame> gaah
<Yagisan> ajmitch: I got sick of being flamed for trying to stop them breaking the boxes
<ajmitch> someone who's convinced that only by having a fully 64-bit system without 32-bit exe support in the kernel will be faster
<Yagisan> psusi: I don't know - I've never noticed a problem so far
<Yagisan> ajmitch: tell them racing stripes will make their pc faster too
<psusi> Yagisan, which uid owns the files on the filesystem?
<ajmitch> hehe
* psusi loves to go up to those idiots with the after market spoiler bolted on their trunks and ask them why?
<zakame> i suppose having both types of systems at hand would be essential to understanding the prob
<psusi> they usually respond by saying it improves the drag coefficient... then they get all confused when I ask them what a drag coefficient is...
<psusi> Yagisan, so... which uid owns the files on the cd?
<Yagisan> psusi: I'm looking for a cd - just a second
<psusi> Yagisan, and I guess what you were interested in is what happens if you were to insert a packet mode cd?  if you want to you can have each user be able to have a home directory on it they have own ;)
<Yagisan> psusi: I just tossed a cd in, and apparently root owns it
* ajmitch breaks down & cries
<seth> aw
<seth> there there honey
<ajmitch> I think I should leave #ubuntu soon, I don't have the temperament for it :)
* Yagisan gives ajmitch a strong drink
<ajmitch> thanks Yagisan
<Yagisan> ajmitch: are you a mod there - ban everyone for a few hours ;) that will make you feel better
<seth> I need to leave #ubuntu b/c there's a guy with the nick sethk, and people ALWAYS ping me instead of him :P
<Yagisan> ajmitch: childish yes - but still good fun
<ajmitch> haha
<ajmitch> it's a very tempting thought
<psusi> Yagisan, did that answer your question?  I'm sleepy ;)
<Yagisan> psusi: I think so. Of course, I'd have to try it at some stage
<Yagisan> psusi: how can you be sleepy - I'm usually here until 4-5am my time. you can do it, go on
<psusi> ok.... the kernel patch is on the wiki, and udftools is on revu any time you want to play with it ;)
<psusi> Yagisan, I was here untill 4-5 am the last two nights... in the morning I have work ;)
<Yagisan> psusi: I have to work too - why can't customers beat a path to my door for little or no effort
<LaserJock> is there any web hosting for MOTU related material?
<Yagisan> ouch they are eating /sh alive on d-d
<lifeless> yes
<lifeless> comes of pushing rather than leading
<zakame> heya LaserJock , jamessan , whiprush :)
<LaserJock> I have some lists and things for the MOTUScience team that aren't very wiki friendly but I don't know where I can host them
<LaserJock> hi zakame
<jsgotangco> oh well
<zakame> LaserJock: how's packagingguide going?
<LaserJock> oh, its getting there
<jsgotangco> ouchh...
<LaserJock> I have been on vacation so it hasn't gotten far for a few weeks but I'm going to be working on it again
<ajmitch> Yagisan: yeah? I haven't read the carnage for a few hours
<ajmitch> oh not much new since I last looked
<Yagisan> ajmitch: I just get a digest. btw their digest is much better then what ubuntu uses - at least there I can easily reply to a message, which I have done on occasion
<minghua> hi zakame, I am going to pester you again about the octave2.1 sync
<minghua> zakame: did you request it?  it still hasn't shown up in build logs yet
<Yagisan> ajmitch: but as I don' want to be spit-roasted I refrain from posting if possible
<zakame> minghua: it hasn't, I don't have the ACCEPTED mail yet, though I've requested it already
<Yagisan> ajmitch: debian-mentors is a much safer place to post
<ajmitch> yep
<zakame> ajmitch: what carnage?
* ajmitch is going to run away & get some food now, bbiab
<minghua> zakame: ok I see.  I'll keep waiting, then, thanks
<zakame> ah, the d-devel...
<zakame> no prob :)
<jsgotangco> ouchhhh
<jsgotangco> the more i read it, the more i go ouchhh
<zakame> :(
<Yagisan> yep, I see /sh's point, but that won't fit debian culture - it's not the way they work. BTW that list should have a disclaimer, beware the of the asuffield
<jsgotangco> heh
<Yagisan> I do prefer if lp was oss though, but that's just my opinion
<zakame> Yagisan: haha, well asuffied bites, but he's a good guy :)
<Yagisan> zakame: I didn't say he was bad - just beware - it's like a gaurd dog, he's good to you, but he sees everyone else as lunch
* Yagisan goes off for some food
<zakame> hehe
<minghua> nice metaphor :-)
<zakame> hehe
<zakame> wb tritium :)
<tritium> thank zakame :)
<tritium> thanks, even
<zakame> back
<Burgundavia> all those who blog, lets push us up the google rankings for "linux desktop", as we currently have no juice there
<zakame> Burgundavia: blogging then :)
<jsgotangco> RedHat! SuSE!
* Burgundavia smacks jsgotangco 
<zakame> StevenK: linkchecker is in, the buildLogs says ftbfs on ia64, wait a while perhaps :)
<zakame> heya dholbach :)
<dholbach> good morning
<dholbach> hey zakame
<StevenK> zakame: It fails due to not being able to install stuff, which is just silly.
<lifeless> dholbach: opensync is in new
<lifeless> dholbach: its hurry up and wait time
<dholbach> lifeless: then upload it to ubuntu's NEW queue too
<lifeless> dholbach: I cant
<dholbach> why is that?
<lifeless> dholbach: I dont have upload rights to ubuntu
<dholbach> then tell me where the source packages are and i'll sponsor the uploads :)
<lifeless> in debian NEW ;0
<dholbach> right
<lifeless> back in  abit
<dholbach> lifeless: i couldn't find a link to the source packages there
<Burgundavia> dholbach, did you see that itp for the galago stuff?
<zakame> seen that
<dholbach> Burgundavia: yes i did - i talked to giskard about all the stuff, but found some problems in the packges, else they'd be in dapper already :)
<Burgundavia> dholbach, ah, figured as much
<Burgundavia> dholbach, that would be cool stuff to push for dapper+1
<dholbach> i'm confident in dapper universe :)
<Burgundavia> I mean by default for dapper+1
<dholbach> :)
<Burgundavia> I just pinged the xchat-gnome guys about doing a backend for it
<dholbach> cool
<lucas> hi all
<Tonio_> hi all
<Tonio_> hi dholbach
<dholbach> hellas Tonio_
<Tonio_> dholbach: I'll be there tomorrow for the CC
<dholbach> cool :)
<Tonio_> finally I'll get in ;)
<dholbach> Bug Day on Friday!
<freeflying> looking for reviewers for this http://revu.tauware.de/details.py?upid=1434
<raphink> hi dholbach
<freeflying> raphink: hi
<raphink> hi freeflying
<freeflying> raphink: looking for review
<raphink> sorry can't review right now
<raphink> I have to get going ;)
<freeflying> raphink:  :)
<dholbach> hellas raphink
<ajmitch> freeflying: I'd clean up debian/rules, remove all those unneeded dh_* calls
<ajmitch> you've also got the patch/unpatch rules commented out there
* ajmitch does't know much about the scim stuff :)
<freeflying> ajmitch: got it ,thx
<\sh> ogra: ping
<ajmitch> morning '
<ajmitch> morning \sh ;)
<\sh> hey ajmitch
<ajmitch> survived the night of d-d mails?
<\sh> ajmitch: as I said, I'm not posting anymore to d-d
<ajmitch> not a surprise
<Amaranth> ooh, another ubuntu flamewar on d-d?
<\sh> ajmitch: actually it is...I could send them a lot of nice greetings as well..but I don't do it...it's a time wasting afford.
<\sh> ajmitch: and I have other problems right now, as to argue with those people...
<freeflying> \sh: hi
<Amaranth> ooh, a launchpad flame
<Amaranth> this should be interesting
<ajmitch> not really
<Amaranth> flamewars are always fun to read/watch
<dholbach> Amaranth: it's as annoying and as demotivating as every other flamefest too
<Amaranth> because it's so damn funny
<\sh> Amaranth: it isn't ... the conclusion is: i'm an asshole..and fighting against windmills...and smoking shit
<Amaranth> \sh: You took the bait.
<\sh> Amaranth: was a mistake...I thought the people in debian were grown ups..
* Amaranth giggles
<Amaranth> some/most are
<zakame> hey a :0
<\sh> sometimes I have to make up my mind, and have to tell myself: well, nothing is changing, it's just like debian in the 90ties, and they will behave like this in the 21st century..if debian still exists then
<zakame> hi \sh, yes, 'twas smoking :)
<Tonio_> some debian users are really fabulous assholes....
<Tonio_> that's amazing....
<Treenaks> s/debian// ;)
<\sh> well anyways I have other problems
<Tonio_> Treenaks: lol
<zakame> I just regard them to have some serious communication gaps
<Tonio_> hum, they are proud of their geek power
<Tonio_> and afraid by seeing complated things accessible to standard users
<ajmitch> Tonio_: please refrain from inciting any further flames
<Tonio_> how is possible to criticize launchpad when you have seen that debian mess !!!
<Tonio_> ajmitch: okay
<zakame> err, wait
<Tonio_> ajmitch: note that I said "some" ;)
<raphink> not to give names ;)
<raphink> the list archives are public anyway
<raphink> anyone can get an opinion of `sectarian` behaviours ;)
<zakame> well, the thread lost its real point anyway
<raphink> yes
<ajmitch> Tonio_: I don't care if you said some, just what you said was highly inflammatory
<ajmitch> we do not need to carry it into here
<zakame> let's just respect what each side wants to do, after all, we are all for free software, right? :)
<jsgotangco> no!
<ajmitch> zakame: that's some of what the issue is about
<\sh> zakame: free software != opensource software
<raphink> yes zakame somehow
<zakame> \sh I am well aware of that distinction
* jsgotangco alerts the cavalry: continue the siege! prepare the catapults!
<\sh> zakame: and that was the discussion about..they would use launchpad, if it were OSS
<\sh> zakame: but because of not being OSS, it's bad, it's evil, and it's a webapp
<raphink> warf
<raphink> not sure they would use it if it were OSS
<raphink> actually
<raphink> they may find another excuse
<zakame> \sh : which almost got lost into ad hominem arguments
<\sh> raphink: ok..s/would/could/
<ajmitch> good bye, I'm sick of this argument
<raphink> yes
<\sh> ajmitch: there is a stop now...
<zakame> ajmitch : sick, indeed
<\sh> I'm wondering who would like to take over njam?
<zakame> njam?
<jsgotangco> awesome game
<\sh> Ok, some serious stuff now: It looks like that I have to give up my dsl line and some other stuff the next month, because I can't pay it anymore...so I need some volunteers to take over my favorite packages...which is python-sip4-qt3 python-sip4 python-kde3 njam (gajim will be taken over by motu im anyways)
<\sh> zakame: network enabled pacman clone with level editor etc.
<zakame> shawarma: checking packages.u.c/src:njam
<zakame> gaah \sh I mean
<\sh> zakame: I uploaded the last time a new upstream version, which has now autotools support...
<\sh> so there is nothing complicated anymore :)
<zakame> w00t
<\sh> zakame: also to mention, it's not in debian, and someone could find his/her way into debian with this package
<raphink> :)
<zakame> shawarma: well I'm looking for RFPs anyway, would it be ok if I proceed so?
<Burgundavia> \sh, how is the job hunt going?
<zakame> again, I mean \sh
<zakame> this bitchx is killing me
<\sh> Burgundavia: waiting for me 2nd interview with the big internet search company in 50 minutes
<\sh> zakame: you are welcome :)
<\sh> s/me/the/
<jsgotangco> big internet search company...
<jsgotangco> ahhh!!!
<zakame> w00t!
<jsgotangco> Teoma?
* jsgotangco hides
<\sh> lol
<Treenaks> msn?
<StevenK> No, it's alta vista.
* StevenK smirks.
<\sh> but I don't know if this works out as expected...and most propably I won't be able to hold to my normal standards of living....meaning, the worst thing what will happen, that I resign from all my ubuntu duties
<zakame> awww :(
* zakame proceeds to ITP njam with already-in-ubuntu tag
<\sh> so I need to know if somebody is interested in taking over my favorite packages, so that kubuntu can work with the python stuff and somebody has to take the duty to repackage wine from wine-hq which is sometimes a bit hard :) you can't use the debian wine-hq packages..because of their stupid numbering
<zakame> hm I though StevenK was doing something with wine/
<zakame> ?
<\sh> we don't even use the debian packages :)
<zakame> which is understandable :)
<Yagisan> re
<Yagisan> \sh_away: I wanted to talk to you about wine later, esp re wine on amd64
<\sh_away> Yagisan: is there a solution for wine on amd64?
<Yagisan> \sh_away: well I have some ideas on how to get win64 + win32 apps going, but I think I'll need some help with it
<Yagisan> \sh: wine should build on amd64, but when it does, it runs win64 apps only
<\sh> Yagisan: what I meant is, is there a solution from upstream for this? if there is, we could put it into the package
<Yagisan> \sh: upstreams says can't be done, but I think it can, as it is a packaging issue
<\sh> well make it :) and put some test packages on a website :)
<Yagisan> \sh: I built a 32bit libs package, its on revu - that should run 32bit wine
<Yagisan> \sh: what I need to do, is make a wrapper that can tell the difference between a win64,win32 and win16 app
<Yagisan> \sh: Would you be able to help test, or at least double check that I don't break anything too bad ?
<\sh> Yagisan: well..the problem with win64, win32 and win16 is, that win32 can run win16, and win64 normally can run win32 with a compatiblity layer in windows...
<Yagisan> \sh: nope, on windows it is seperate libs
<Yagisan> \sh: wine has gone the same way, 64bit wine only runs 64bit apps
<Yagisan> \sh: so I need wine + wine64
<\sh> Yagisan: i think that's the word at ms for "separate libs" ,)
<Yagisan> \sh: Oh, I thought you meant something like the WoW thunker
<\sh> Yagisan: well it works the same way as "linux32"
<\sh> the problem is, to get it build on amd64 as 32bit app
<\sh> without changing anything on the buildd
<Yagisan> \sh: nope, better idea
<Yagisan> \sh: build as 32bit on i386, repack for amd64
<Yagisan> \sh: see zsnes in revu for proof of concept
<\sh> Yagisan: argl..
<Yagisan> \sh: no one has a better solution, until then, I'd like to go with that
<\sh> Yagisan: are you sure, it's in law with infinity and lamont?
<Yagisan> \sh: it's from the same source, it just needs to successfully be built on i386, either in pbuilder, or by a buildd first
<\sh> and that is something we can't see somehow..
<Yagisan> \sh: it should be fine, but if you have a better idea, I'd love to hear it.
<Yagisan> \sh: we need multi-arch, but it does not yet exist, and we are a pure64 distro. cross compiles are failing for every test case I try
<Yagisan> \sh: next best thing is uuencoded i386 debs, repacked with support libs
<\sh> well...I just have a look on ubuntu-fetch-*
<Yagisan> \sh: ??
<\sh> you assume that the zsnes package in the archive is already the i386 binary package of the latest source
<\sh> Yagisan: I just read your zsnes debian dir :)
<Yagisan> \sh: I can't have network access at build time :( so I "assume" you built it ok first yes
<Yagisan> \sh: you can pbuilder it first, and stick the deb in /local/pkgs and it won't download from a mirror
<Yagisan> \sh: but I don't think that directory is in the diff, as it was empty when I made the package
<\sh> Yagisan: yes...but how to do it on the buildd? 1. there is no network 2. how do you get the i386 packages into the debian/pkgs dir, without manual intervention?
<Yagisan> \sh: there is a little issue of scheduling it, a bit like with OOo
<Yagisan> \sh: It was fully automatic, but Mithrandir said that was a bad idea(tm) - see the comments on ia32libs-universe
<Yagisan> \sh: :( file can't tell the difference between win64 and win32 apps
<\sh> well...back to the zsnes package...I read that you want to have local packages already in the source, means you have to compile first for i386 and then moving the binary packages into the source tree and compile again for amd64
<\sh> or you image you have during build time network access...which is sometimes not true
<Yagisan> \sh: yes, the multiple build. Intended as a stop-gap until multi-arch. The is no network access during build.
<Yagisan> s/The/there
<Yagisan> \sh: If done in a pbuilder, the first build won't affect the buildds, and only requires one source upload
<\sh> Yagisan: ok..so we are stuck with the multiple build..how can we achieve this with only one source package...and thinking about building i386 packages first, then downloading those packages, putting them again into the same source package and reupload the source
<Mithrandir> Yagisan: what are you trying to achieve?
<\sh> Mithrandir: wine for 64bit with 32bit support
<\sh> Mithrandir: compiled out of one source package
<Yagisan> G'day Mithrandir - want to run some i386 only apps on amd64, while waiting for multi-arch
<Mithrandir> so you want a 32 bit wine repackaged for amd64?
<Yagisan> \sh: I build the i386 package in pbuilder first, copy the resulting deb to /local/pkg, run the ubuntu-fetch-and-build script, repack source, and send to buildd
<Mithrandir> Yagisan: _no_.
<\sh> Yagisan: which is not secure :)
<Yagisan> Mithrandir: yes, but there is also a wine64 that only runs win64 apps
<\sh> Yagisan: i don't trust compiles from random hosts :)
<Mithrandir> Yagisan: you are to take the binaries which comes from the buildd if you do repackaging like that.
<Mithrandir> Yagisan: just build the _amd64.debs when doing the 32 bit build, then
<Yagisan> Mithrandir: how ?
<\sh> well, I think then about a wine-compat32 package
<Yagisan> \sh: already done
<Yagisan> Mithrandir: if I can build amd64 debs from i386, I'm very happy
<Yagisan> \sh: you are talking about the 32bit support libs for wine right ?
<Yagisan> Mithrandir: would it work if I swapped the control file during build ?
<Mithrandir> Yagisan: possibly
<\sh> ok....time for the interview :)
<Yagisan> Mithrandir: I tried cross compile first, but that failed. I'll try with zsnes again, see if I can make amd64 and i386 out of it
<\sh> wish me good luck :)
<Yagisan> \sh: good luck
<raphink> good luck \sh
<raphink> :)
<Tonio_> good luck
<segfault> hi
<raphink> hi segfault
<raphink> ouch 180 merges to go :s
<raphink> and LP down
<lucas> life sucks ;)
<raphink> haha
<Gloubiboulga> hi
<segfault> 180!?
<segfault> sometime ago were just 5
<Yagisan> w00t: dpkg-gencontrol: error: current build architecture i386 does not appear in package's list (amd64)
<Yagisan> guess switching doesn't work that easily
<juliux> hi, anyone here who wants to make a ubuntu-dev talk at the linuxtag 2006 in wiesbaden/germany ?
* Yagisan attempts again to force amd64 packages out of an i386 pbuilder
* Yagisan tries again
<Yagisan> G'day ogra_ibook
<ogra_ibook> hey Yagisan
<Yagisan> ogra_ibook: ever tried to force arch a out of pbuilder b ?
<ogra_ibook> you mean i386 on ppc or the opposite ?
<Yagisan> ogra_ibook: amd64 out of i386
<ogra_ibook> nope, but will work fine
<pappan> dholbach: hi
<Yagisan> ogra_ibook: I was told I'm not allowed to uuencode i386 debs :(
<dholbach> pappan: hellas! :)
<Yagisan> ogra_ibook: got a nice error -> dpkg-gencontrol: error: current build architecture i386 does not appear in package's list (amd64)
<pappan> dholbach: how are you
<pappan> query dholbach
<dholbach> pappan: thanks a lot, i'm fine - how are YOU?
<abelcheung> Hi, if a main inclusion report is ready, and all problems blocking upload of package are solved, what should be done next to ask for universe->main move?
<abelcheung> Oh, I asked the question here because the fixed package is in REVU, and waiting for review
<abelcheung> http://revu.tauware.de/details.py?upid=1436
* Yagisan slaps zsnes around.
<Yagisan> good -> dpkg-deb: building package `zsnes' in `../zsnes_1.420-0.1ubuntu2_i386.deb'.
<Yagisan> good -> dpkg-deb: building package `zsnes-32' in `../zsnes-32_1.420-0.1ubuntu2_amd64.deb'.
<Yagisan> bad -> dpkg-genchanges: failure: cannot open upload file ../zsnes-32_1.420-0.1ubuntu2_i386.deb for reading: No such file or directory
<Yagisan> :(
* Yagisan is happy he started with an "easy" app first
<Yagisan> ogra_ibook: wb
<zakame> evening MOTUs
<dholbach> hellas zakame
<Yagisan> G'day zakame
<Yagisan> why does dpkg-genchanges hate me ?
* zakame hugs dholbach and Yagisan :)
<dholbach> Yagisan: you could    strace -e open,stat   it
<Yagisan> zakame: not too close - I can't breath
<Yagisan> dholbach: it's in pbuilder when it chokes - it's looking for a non-existent file
<dholbach> permissions and disk space are cool?
<Yagisan> dholbach: yep - the error is a few lines up /|\
<dholbach> yeah, i read that
<zakame> Yagisan: buwahaha
<Yagisan> zakame: adopting debian packages ?
<zakame> yep
<zakame> I'm currently looking at njam though, it looks quite nice and good to have in debian :)
<Yagisan> zakame: I find it rather funny esp as I saw a few ubuntu doesn't contribute back to debian posts today - good luck, and have fun
<zakame> Yagisan: indeed, that's why I've made it a personal goal to debunk that claim ;)
<Yagisan> zakame: what is njam ?
<zakame> Yagisan: it's from \sh , pacman-like game
<zakame> network-friendly too :)
<Yagisan> zakame: cool - I like nice games, esp when waiting for pbuilder to finish
<\sh> zakame: remove my name completly from the package
<zakame> \sh: even from changelog?
<\sh> yes please
<Yagisan> \sh: I don't think they will keep flaming you. Sorry you had to meet it first hand
<zakame> \sh: awww, but I'll respect your wish, ok
<\sh> Yagisan: it's not the first time...so don't worry...no offense taken from that :)
<\sh> zakame: actually you decide..it's your package now :)
<zakame> hm seems I shouldn't have filed that ITP, there's already a previous debian #316706
<Ubugtu> Debian bug 316706: "njam -- Njam is a full-featured cross-platform pacman-like game written in C++ using SDL library" Package: ITP, Severity: wishlist, Maintainer: wnpp@debian.org</a http://bugs.debian.org/316706
<gypsymauro> hello
<zakame> heya gypsymauro
<gypsymauro> hello I've doenloaded some packages and then created a cd using dpkg-scanpackages, now I can add my cd  with apt-cdrom add but when I try to install a packages from the CD apt-get says "WARNING: The following packages cannot be authenticated!" a list of packages and "Install these packages without verification [y/N] ", how I can make them authenticated? I suppose it's cause I missed the Release file but I dunno how to crate 
<Mithrandir> gypsymauro: apt-ftparchive release can create Releases files.
<\sh> zakame: merge both ITP bugs then :)
<Yagisan> zakame: 1) it's old, 2) it's not in debian. 3) you could tag your itp with aready-in-ubuntu
<\sh> zakame: or mark the last one as duplicate
<ogra_ibook> gypsymauro, also make sure to use apt-key add to add the key the packages are signed with to the CD
<gypsymauro> Mithrandir: it works for cd too?
<zakame> Yagisan, \sh: indeed :) how can I not work without my wonderful MOTUs :)
<Mithrandir> gypsymauro: the CD is just a dump of what's available over HTTP ordinarily, so yes.
<gypsymauro> Mithrandir: it's something done with wget and so on, then I do a dpkg-scanpackages, so I can do an apt-cdrom add, but this is not enough it seems to authenticate packages
<gypsymauro> I'm missing something but i dunno what
<Mithrandir> gypsymauro: apt-ftparchive release, as I said.
<Mithrandir> you also need to sign the Releases file using gpg and have that key in the apt keyring
<gypsymauro> tanx Mithrandir :) now I c the light
* Yagisan wishes pbuilder used something quicker, like lvm snapshots
<azeem> quicker for what?
<Yagisan> azeem: It's taking a long time to tar and untar for every build
<azeem> the base system?
<azeem> sbuild doesn't do that, FWIW
<Yagisan> azeem: yep - i'm irritated, 17 ftbfs in a row
<Yagisan> 18 + new error message now
<jsgotangco> byzanz? wow dholbach
<hub> what
<jsgotangco> that's like only  yesterday
<hub> I did it last night too
<jsgotangco> ahhh
<hub> but didn't upload it to REVU :-/
<hub> :_/
<dholbach> jsgotangco: i only had to wait for the upstream author to tell me that it only worked on composite enabled x :)
<hub> I have libgopersist, but it FTBFS
<hub> dholbach: libdamage
<dholbach> hub: i added that
<hub> dholbach: my package has it :-)
<dholbach> my package has it too (if you mean the build-dep)
<hub> yep
<hub> whatever I'll just rm -fr it
<Yagisan> 19 :(
<dholbach> hub: gdk_screen_get_rgba_colormap (gdk_screen_get_default ()) returns NULL and makes the applet unusable on boxes that have no composite
<thierry_> ajmitch : thanks for sending a comment for my package! there's only two point I don't know how to fix : no pkg-config installed and no headers installed into -dev
<Mithrandir> thierry_: build-depend on pkg-config?
<thierry_> k thanks
<thierry_> Mithrandir : and how do I bump debhelper compatibility to 5
<thierry_> ?
<Gloubiboulga> thierry_, modify the compat file (4 -> 5)
<thierry_> only 5?
<thierry_> like Standards-Version: 5 ?
<Gloubiboulga> and in debian/control: debhelper (>=5.0.7)
<thierry_> ho ok
<Mithrandir> thierry_: echo 5 > debian/compat, usually.
<lotusleaf> <He-Man> I have the power!
<zakame> w00t
<zakame> gn8 all
<lotusleaf> ;-p
<thierry_> while updating my dapper chroot I get this : dpkg: error processing /var/cache/apt/archives/coreutils_5.93-5ubuntu1_i386.deb (--unpack):
<thierry_>  subprocess pre-installation script returned error exit status 2
<thierry_> Errors were encountered while processing:
<thierry_>  /var/cache/apt/archives/coreutils_5.93-5ubuntu1_i386.deb
<thierry_> E: Sub-process /usr/bin/dpkg returned an error code (1)
<thierry_> I think there's a porblem with coreutils
* lotusleaf challenges Fuddl to a duel with a +5 checkinstall whip
* Yagisan is shocked to see that obscenity here
<lotusleaf> lol
* Yagisan thinks he knows why dpkg-genchanges hates me. It's insisting on adding i386 to the package name, because that is the build arch
<siretart> hi
<Yagisan> G'day siretart
<Gloubiboulga> hello siretart
<siretart> huhu Yagisan, hi Gloubiboulga
<\sh> I hope I will manage today to sync my sleeping time to european standards again
<thierry_> siretart : are you in a ruby-pkg-extras debian team? Someone told me this team would review very fast my package : http://revu.tauware.de/details.py?upid=1414
* Yagisan kicks zsnes again
<Yagisan> \sh: I gave up syncing my sleep time to Australian standards
<siretart> thierry_: Sorry, I didn't touch ruby yet
<\sh> Yagisan: but it's not good for me, to stay awake from 17pm to 10am and sleeping from 10:01am to 16:59pm
<\sh> why do I mention "pm" now, when I'm using 24h format
<\sh> I'm tired already :)
<thierry_> k
<\sh> which means, I can adjust my times ...
<Yagisan> \sh: I understand - I'm a night person myself. daylight, whats that ;)
<lotusleaf> Yagisan, I got a wallpaper for the sun and the moon to remind me what they both look like
<Yagisan> lotusleaf: I don't use wallpapers, they use up valuable ram that could be used as disk cache
<lotusleaf> Yagisan, gotta have a little fun on at least one box ;)
<\sh> bbl...
<Yagisan> lotusleaf: well, I have been known to play doomsday on my server
<lotusleaf> Yagisan, Dungeon Crawl (aka 'crawl') forever! :P
<Yagisan> lotusleaf: I just like to shoot at things when I'm frustrated. I wish psdoom would work http://psdoom.sourceforge.net/
<Yagisan> lotusleaf: maybe one day, I'll get around to seeing why it didn't work last time
<lotusleaf> Yagisan, heh, I haven't played any of the Doom games in years. I was more of a Duke Nukem 3d fan, still waiting for the second coming of Duke Nukem Forever. :P
<Yagisan> lotusleaf: never going to happen. You like your doom games with eye candy ?
<lotusleaf> Yagisan, Well I haven't tried any doom games for nix.. only the doom3 demo and the only good thing about that was the super turkey fighter in-game game.
<Yagisan> night all.
* Yagisan hopes he can think of a way to get those amd64 debs built on i386 by the time he wakes up
<jsgotangco> night
<jsgotangco> me too
<jsgotangco> i gotta sleep
<lotusleaf> Yagisan, nn
<Gloubiboulga> could a MTOU have a look at my libtranslate package ? http://revu.tauware.de/details.py?upid=1442
<LaserJock> Is there any particular place other than the wiki were we can put MOTU material?
<seth> Gloubiboulga, your diff includes config.{guess,sub}, you should remove those in the clean: rule. Also maybe you could describe what the 3 upstream patches do, briefly :)
<Gloubiboulga> seth, thanks, but upstream provides config.{guess,sub}
<Gloubiboulga> and I don't anderstand why they appear in the debdiff
<seth> because your system changed them during compile
<Gloubiboulga> s/debdiff/diff.gz
<seth> that's why you remove them in the clean rule :) so they don't appear in the diff.gz
<seth> it's okay to leave them in the .orig
<seth> your system will re-create them when compiling
<Gloubiboulga> seth, ok
<seth> so the order is: remove config.{guess,sub} => .orig and .diff are created => compilation (and recreation of config.{guess,sub})
<Gloubiboulga> ok !
<seth> Gloubiboulga, also in the description: "allows to implement" => "allows the implementation of"
<seth> :)
<seth> I'm not a MOTU but it looks good
<Gloubiboulga> seth, french guys like me have some troubles with english :p
<seth> eh, je vous assure que j'ai beaucoup des problemes avec mon francais
<seth> (beaucoup PLUS) ;)
<Gloubiboulga> :)
<hub> Gloubiboulga: what is the issue with French and english?
<hub> I thought that english and french made peace
<seth> the language, not the people :)
<Gloubiboulga> yep
<hub> :-)
<seth> have a good day MOTUs and MOTU hopefuls, I am off to job training
<LaserJock> cya seth
<Gloubiboulga> bye seth, and thanks
<lucas> hello all
<Yagisan> woo hoo!! amd64 +i386 debs built out of the i386 pbuilder !!!!!
<Yagisan> ah shit - they aren't listed in the changes file
<thierry_> ajmitch : I resent my package at REVU (http://revu.tauware.de/details.py?upid=1439) and could it be possible that you delete the old one? (libfxscintilla1.6)
<Gloubiboulga> I've also reuploaded my package... http://revu.tauware.de/details.py?upid=1444
<seth> thierry_away, do you mean for libfxscintilla to be a native package?
<Yagisan> I did it. amd64 packages building out of an i386 arch pbuilder
<Yagisan> Mithrandir: siretart: Please revu this package. It builds BOTH amd64 and i386 in an i386 pbuilder. Is this method acceptable ? http://revu.tauware.de/details.py?upid=1445
<Yagisan> I'll be out most of the day, so comments on the page please
<Yagisan> bye
<sistpoty> hi folks
<dholbach> hellas sistpoty
<sistpoty> hey dholbach
<sistpoty> dholbach: read my proposal for motu-meeting?
<LaserJock> hi sistpoty and dholbach
<sistpoty> hi LaserJock
<dholbach> sistpoty: yeah, we should do it
<dholbach> sistpoty: we have a couple of planning to do
<sistpoty> fur sure
<dholbach> uvf coming on, NEW packages until ff, and we need universe action on the bug days
<sistpoty> dholbach: what about date/time of meeting?
<LaserJock> heah, you guys might be able to help me. I want to have some lists (similar to lucas's) for the MOTUScience team but I am hesitent to host them on my uni account, is there a place where things like that could be hosted?
<dholbach> sistpoty: if we don't overlap with other meetings any time is fine for me, just propose one on the mailing list, wait 1-2 days, do it :)
<dholbach> LaserJock: the wiki? :)
<LaserJock> well, I don't think they are terribly wiki friendly but I might just have to do that
<sistpoty> dholbach: I did propose a time (doesn't overlap as said on fridge) ;)
<dholbach> sistpoty: *whistle innocently* *has a look*
<sistpoty> hehe
<dholbach> is fine for me
<sistpoty> :)
<lucas> LaserJock: how did you generate them ?
<sistpoty> hi lucas
<lucas> hi siretart
<lucas> sistpoty:
<LaserJock> lucas: hopefully a combination of some python stuff of mine with a quite a bit of use of your scripts
<sistpoty> lucas: take a look at /home/sistpoty/merge_offline/mergebase_yappy.py ;)
<sistpoty> hm... why did I call this yappy? should be yaml
<lucas> LaserJock: what does your python scripts do ?
<sistpoty> LaserJock: we might as well put them on tiber
<lucas> sistpoty: excellent
<lucas> LaserJock: the easiest thing to do would probably be to integrate your scripts into mdt, and then run it on my account on tiber until you are a member
<lucas> (if you aren't already)
<LaserJock> lucas: well, I'm not completely sure of all I want but I was thinking of linking to http://people.ubuntu.com/~scott/patches/ for science packages
<LaserJock> as well as having the Debian/Ubuntu versions and bts links
<lucas> mmh
<lucas> will you be online later tonight ?
<LaserJock> probably
<LaserJock> what is tonight?
<lucas> I'm trying to configure gnomemeeting with my girlfriend
<Amaranth> i somehow have 18 launchpad karma
<Amaranth> woo?
<lucas> 1 or 2 hours from now
<LaserJock> oh, yes. that would be just after lunch here ;-)
<dholbach> Amaranth: congratulations
<LaserJock> btw, what does it take to get an account on tiber? MOTUness?
<dholbach> LaserJock: i don't have one :)
<dholbach> So I can't be blamed when tiber explodes or REVU auto-approves packages. :-)
<desrt> dholbach; not what he asked :)
<sistpoty> LaserJock: you should be trustworthy ;)
<LaserJock> dholbach: true
<LaserJock> dholbach: ignorance is bliss?
<eruin> Amaranth, I have 1502. that makes me your master, and you must follow my bidding ;-)
<sistpoty> LaserJock: just write a signed mail to admin@tiber.tauware.de requesting an account ;)
<Amaranth> eruin: i got mine by doing nothing :P
<eruin> bah
<dholbach> LaserJock: something like that, yes :)
<LaserJock> sistpoty: oh, ok. Am I considered trustworthy?
<dholbach> LaserJock: I have to fix *my* boxes all the time, so that's enough for me. :-)
<sistpoty> LaserJock: based that you hang around in -motu, and we can flame you if tiber is down :P
<dholbach> sistpoty: err, you'd better blame the solar radiation or something
<LaserJock> sistpoty: well, I think I am pretty good about just sticking to what I know and not killing other peoples stuff ;-)
<sistpoty> dholbach: or as bofh ;)
<dholbach> yeah :)
<sistpoty> ask even
<sistpoty> LaserJock: but we still will blame you if it's been an admin's fault :P
<LaserJock> sistpoty: sure I can understand that ;-)
<sistpoty> hehe
<LaserJock> ok, email sent. I think I signed it properly and everything ( I haven't had to sign anything since I got enigmail working in thunderbird).
<LaserJock> man, \sh has got >3000 karma
<Gloubiboulga> his next life will be really great :p
<sistpoty> LaserJock: what username do you want? laserjock?
<LaserJock> sistpoty: sure
<LaserJock> sistpoty: or you could us my LP id mantha if that is more convenient
<sistpoty> LaserJock: I guess laserjock is convenient as well, since it's your nick
<LaserJock> right, I just didn't know if it would cause any probs if it wasn't the same as my LP id. I guess they are independent of each other
<sistpoty> LaserJock: yep, tiber is a server on it's own ;)
<sistpoty> LaserJock: mail with password sent
<LaserJock> got it, thanks so much
<sistpoty> np
<Tonio_> re
<LaserJock> is it relatively easy to switch a svn repo to bzr?
<Amaranth> probably, if you want the full histroy
<Amaranth> err, history
<LaserJock> is bzr generally considered better for offline (local)  repos? I would like to start using a rcs for my packaging but I don't know what to use
<lifeless> lamont__: bzr ;)
<lifeless> Amaranth: svn2bzr
<Amaranth> lifeless: i thought it was kinda of...incomplete
<lamont__> lifeless: baz2bzr yet?  cvs2bzr yet?
<lifeless> Amaranth: the author seems to figure its done
<lifeless> lamont__: baz2bzr is usable but not the final output format yet
<lifeless> cvs2bzr haahhaahaha
<lamont__> lifeless: I don't care if it has particular patch history, I just want to be able to check out old CVS-tags from my new bzr repo...
<lamont__> you know: cvs get; bzr commit; loop until done
<lifeless> help out the guys working on ForeignBranch support
<thierry_> ajmitch : thanks again for the comment on my package, for the name of the package what do I put in the end??
<thierry_> is it the librairy name?
<sistpoty> thierry_: you mean libfxscintilla or a different one?
<thierry_> libfxscintilla
<sistpoty> thierry_: oh, daemon@poleboy.de is me ;)
<thierry_> ho ok!
<thierry_> by the way the libtool thing is needed, it's a change the upstream author sent me
<sistpoty> thierry_: ah, k
<thierry_> sistpoty : so what should be the name of the package? libfxscintilla17 ?
<sistpoty> thierry_: I suggest you name the _source_ package libfxscintilla (w.o. soname and w.o. version)
<sistpoty> thierry_: thus you won't end up getting new sourcepackage names once upon a new upstream version
<thierry_> ok, are you a MOTU, if yes, I'd like that you delete the bad names from the REVU list when I'll upload the new one
<sistpoty> thierry_: I am... will do that
<sistpoty> thierry_: if you would need to have more than one version of the same (source)package in the archives (e.g. many packages building against it and ftbfs with new version) you could append a verison number to the sourcepackage
<thierry_> :) thanks, in about 10 minutes I'll upload everything, and should be able to advocate it
<Ubugtu> An error has occurred.
<sistpoty> thierry_: the generated library package should match the soname however...
<sistpoty> thierry_: maybe you want to take a look at the library packaging guide, if s.th. is not clear: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
<thierry_> so in control I put Package: libfxscintilla17 ?
<sistpoty> thierry_: yes
<thierry_> and the changelog is also libfxscintilla17?
<sistpoty> no, the changelog refers to the sourcepackage
<thierry_> k
<thierry_> last thing : in scintilla/include/*.h           /usr/include/libfxscintilla
<thierry_> include/*.h                     /usr/include/libfxscintilla do I put libfxscintilla or libfxscintilla17 ?
<tseng> er
<tseng> libfxscintilla-dev ?
<tseng> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
<sistpoty> thierry_: you mean where to put the include files inside the -dev package?
<sistpoty> thierry_: name the directory like upstream does (but it should be in /usr/include/)
<sistpoty> thierry_: actually like upstream installs it ;)
<LaserJock> lucas: ping?
<sistpoty> Gloubiboulga: are you gauvain pocentek?
<Gloubiboulga> sistpoty, yep
<Gloubiboulga> thanks for the review :)
<sistpoty> hehe
<sistpoty> Gloubiboulga: there is no need to change the orig-tarball if it contains wrong directory name... dpkg-source is quite flexible in this regard ;)
<Gloubiboulga> sistpoty, ok, I will take care of this tomorrow, and include the fdl
<sistpoty> Gloubiboulga: cool
* sistpoty is off again
<sistpoty> thierry_: I will review your package tomorrow ;()
<sistpoty> ;)
<sistpoty> cya
<thierry_> goodbye
<seth> Seveas, sorry to bother, but $freenode_staffer won't approve the linking of my cloak to this new nick (I changed master nicks so I think it broke the cloak). He said I needed to go through you. (If you could make it just ubuntu/member/seth since I now own the nick 'seth', thanks)
<Seveas> seth, will do as soon as I speak lilo
<Gloubiboulga> time to sleep
<Gloubiboulga> bye
<lucas> LaserJock: pong
* lucas tired of trying to set up SIP through a NAT
<LaserJock> lucas: I was trying to figure out where to get the lastest mdt but I found it on https://wiki.ubuntu.com/MultiDistroTools
<lucas> oh ok
<LaserJock> I got an account on tiber so I was going to try to figure out what all I wanted and what you already have, etc.
<lucas> ok
<lucas> the best way to go is probably to work together on improving mdt
<lucas> since it already does quite a lot
<lucas> I don't mind rewriting some ruby scripts if you don't understand them
<LaserJock> right, I just need to think about what exactly I want to do ;-)
<lucas> ok
<lucas> my next steps were to make the HTML lists more configurable
<lucas> I'd like to be able to display columns on demand with javascript
<lucas> and add "comments/notes" columns
<lucas> so it's easily to keep some notes on some packages
<lucas> like "don't merge this, debian's is broken!"
<LaserJock> cool
<LaserJock> ok, this might be a silly question, if you make a bzr branch out of a directory can you move that directory somwhere else and have the branch be OK?
<lucas> yes
<LaserJock> hi crimsun
<dholbach> good night guys
<LaserJock> cya dholbach
<dholbach> bye LaserJock
<LaserJock> lucas: still around?
#ubuntu-motu 2006-01-15
<lucas> yep
<LaserJock> lucas: so I want to get the list of Universe source packages from the science, math, and tex sections
<LaserJock> lucas: I think that mdt will work nicely except for tex
<lucas> why not for tex ?
<lucas> you can use mdt-grep-dctrl-* to get the list of sources packages in those sections
<LaserJock> well, maybe it will but the problem is that if I use dist-grep-dctrl- I will get both tex and text sections
<lucas> what you are doing currently with grep-dctrl ?
<LaserJock> hmm, maybe it wouldn't be a problem with Universe packages because I could grep for tex/universe
<LaserJock> but then in Debian I don't know what would happen
<lucas> what's your current syntax ? :-)
<lucas> mdt dist-grep-dctrl-sources dapper -n -s Package -F Section -e "tex$"
<lucas> doesn't this work ?
<ajmitch> morning
<LaserJock> lucas: looks like it would, let me try it
<LaserJock> hi ajmitch and Hobbsee
<Hobbsee> hey LaserJock :)
<lucas> mdt dist-grep-dctrl-sources dapper -n -s Package \( -F Section -e "tex$" \) -o \( -F Section science \) -o \( -F Section math \)
<ajmitch> hello Hobbsee, LaserJock
<lucas> then mdt compare-versions sid dapper
<lucas> then mdt filter
<Hobbsee> hi ajmitch :)
<lucas> hi ajmitch
<theCore> does lighttpd will be include into the breezy repo, or only in dapper's one
<tseng> only dapper
<tseng> breezy is released, its done.
<theCore> ok
<irvin> theCore interested in lighttpd?
<theCore> irvin, yeah
<irvin> i have a debian package that can work in breezy, i'm using it myself :D
<theCore> where can I get it ?
<irvin> theCore pls wait, i'll rm .htaccess on the webserver
<irvin> theCore, http://www.metawire.org/~ippfx/lighttpd
<LaserJock> lucus: works wonderfully! For tex and science I got 1 or 2 packages less than what I got in Synaptic but that is ok for me
<theCore> irvin, thanks
<irvin> theCore, remembers that it is UNOFFICIAL, lighttpd from Debian unstable is broken on breezy
<irvin> s/remembers/remember
<theCore> irvin, it's a quite small bed file
<irvin> yeah
<theCore> irvin, does the dapper's deb would work with breezy ?
<irvin> theCore, i dunno
<irvin> the dapper deb requires a higher libssl version than the one on breezy
<theCore> maybe I will package it myself
<irvin> sure
<LaserJock> lucas: ping?
<lucas> pong
<LaserJock> lucas: sorry, I was just making the .html files but ruby was acting up. I think I have it fixed now.
<lucas> ok
<LaserJock> lucas: everything is working smoothly. The only thing is that the lists of source packages are different for Debian and Ubuntu so I am using the larger of the two to filter with
<lucas> you can use list_union and list_unify
<lucas> it's probably better to get the largest list possible
<crimsun> lucas: please add a note to http://tiber.tauware.de/~lucas/versions/unimultiverse.html#outdatedinB that libpng in Ubuntu does not correspond to Debian's libpng and thus should not be merged.
<crimsun> (Debian moved libpng3 -> oldlibs and renamed it to libpng, therefore the major versions don't match)
<LaserJock> lucas: is it possible to set what A and B when creating the html?
<lucas> mdt versions2html --help
<lucas> :-)
<lucas> --titleA & --titleB
<LaserJock> ah, thanks
<lucas> crimsun: done, it will show up during the next update
* lucas going to bed now
<lucas> good night
<LaserJock> lucas: thanks so much
<rbelem> g'evening people
<LaserJock> hello
<rbelem> hey LaserJock
<rbelem> LaserJock: can you test a package for me?
<rbelem> deb http://www.estudiolivre.org/videos/lives/ubuntu/breezy/ binary-i386/
<rbelem> the package is lives
<LaserJock> k
<rbelem> people reported some erros under i386 but i don't have one
<rbelem> to test
<crimsun> LaserJock: do you have a debdiff for #5598 ?
<crimsun> Ubugtu: 5598
<LaserJock> crimsun: sadly no, it is a big project and I am kinda feeling in over my head
<crimsun> I'll handle it, then.
<LaserJock> crimsun: I have worked on it but it isn't done
<crimsun> it's really a straight-forward merge. Most of the changes have been adopted by Debian, so you only need to check debian/control
<LaserJock> hmm, well I got the control stuff done, are you sure that there aren't changes that need to be done in debian/rules
<crimsun> LaserJock: just the 2.4-relevant stuff
<LaserJock> I was having a hard time figuring out what had been done
<LaserJock> rbelem: I ran lives-exe and it crashed on me
<rbelem> :/
<LaserJock> crimsun: I couldn't get it to generate control from control.in
<\sh> LaserJock: it's a cdbs switch :)
<LaserJock> \sh: but it doesn't use cdbs
<rbelem> LaserJock: under amd64 it run well
<\sh> then it's using some autotools magic :) or some magic in the rules file to sed some things in control.in
<LaserJock> there is a rule in debian/rules but it doesn't seem to work right
<LaserJock> at least I can't get it to work
<crimsun> you need to rm debian/control first
<crimsun> otherwise since debian/control exists, it will never be regenerated
<LaserJock> I get an error - sed: -e expression #1, char 55: unterminated address regex
<\sh> I wonder why the wine package from breezy is FTBFSing
<\sh> something is wrong with the fonts generation..and it should never have build on breezy in the first place
<rbelem> thanks LaserJock. i'll try to discover the problem
<LaserJock> crimsun: you're sure that nothing needs to be changed in debian/rules?
<crimsun> LaserJock: no, debian/rules is pretty messy. I'm hand-merging from a clean Sid package.
<LaserJock> crimsun: so how do you know that the previous Ubuntu changes have been applied to the sid package?
<crimsun> easy, you read the changelog.
<crimsun> then you check the source
<crimsun> if doko says upstream applied 'em, I tend to trust the entry.
<crimsun> the only changes that need to be made are libGL{U} and python2.4
<crimsun> pretty much everything else is referenced in the changelog
<LaserJock> crimsun: ok, so what about the last Debian entry?
<crimsun> LaserJock: the one that doko forward-references in the last entry of 2.4.4.1ubuntu1?
<LaserJock> crimsun: I guess so, well that makes it much easier. I could've done that
<crimsun> yep.
<LaserJock> crimsun: I was just being cautious and making sure everything was applied and I got swamped
<crimsun> when in doubt always revert to the Debian revision and by-hand [check-in]  the Ubuntu changes
<LaserJock> well, I was going to do that but I got confused when I couldn't get the Debian source that the Ubuntu version was based on
<LaserJock> crimsun: so did you upload it already?
<crimsun> no, I'm building it right now
<LaserJock> oh, ok. I was going to say that I could send a debdiff since I did the changes already
<LaserJock> when I did a debdiff between 2.4.4.1.1 and 2.4.4.1ubuntu1 I did get a bunch of changes in debian/rules where := was changed to =
<\sh> damn...I fixed the issue with breezies wine...now for the security patch
<LaserJock> crimsun: were you able to generate the control file?
<\sh> hmmm..someone else is now in favor of njam in debian as it looks like
<Amaranth> gnome 326379
<Ubugtu> Gnome bug 326379: "small leak in gweather applet" Product: gnome-applets, Component: gweather, Severity: normal, Assigned to: gnome-applets-maint@gnome.bugs, Status: RESOLVED, Resolution: FIXED http://bugs.gnome.org/show_bug.cgi?id=326379
<crimsun> mm hackety hack.
<Yagisan> re
<Yagisan> crimsun: where ?
<crimsun> Yagisan: wxwindows2.4's debian/rules triggers a sed anomaly.
<Yagisan> crimsun: thought you were talking about my new rules file for http://revu.tauware.de/details.py?upid=1445
<Yagisan> crimsun: makes i386 and amd64 debs out of an i386 pbuilder
<Yagisan> bbl
<\sh> Yagisan: as 32bit compat package for amd64?
<Yagisan> \sh:  yes. sorry I'm rather busy today - just about to leave for the embassy
<Yagisan> \sh: please check it out - if everyone is ok with it, I'll do the same for wine
<\sh> Yagisan: well...first of all, I have to enable --enable-win64 or something like this to have at least a real amd64 version
<\sh> and tweak a bit in debian/control
<Yagisan> \sh: this is for packages that can't be built 64bit, or that need to be build 32bit for certain functionality
<Yagisan> \sh: eg for wine, there will be wine, and wine-32 for amd64
<\sh> Yagisan: no :)
<\sh> Yagisan: there will be wine for 32bit, wine64 for amd64 and wine64-compat-32bit or something like this for the compat lib
* ajmitch just wants a wine that works
<\sh> where wine64 will only be build on 64bit archs
<\sh> ajmitch: -EOTHERWISH
<Yagisan> \sh: names are just details - I'll get it working first, then we can argue about names
<ajmitch> \sh: hey, wine used to work with diablo II here :)
<ajmitch> 0.9.4 completely broke it
<\sh> ajmitch: try it with 0.9.5
<\sh> which I uploaded today
<ajmitch> ok
<Yagisan> 0.9.4 broke every win app I used
* ajmitch mustn't have fetched that in the last update
<ajmitch> Yagisan: it's depressing seeing those regressions
<Yagisan> ajmitch: they have a 0.9.5, so maybe that works
<Yagisan> ajmitch: like my hackery with zsnes ?
<ajmitch> haven't seen it
<ajmitch> does it work?
* ajmitch blindly does a dist-upgrade
<Yagisan> ajmitch: I believe so - it built :) toss it into and i386 pbuilder and marvel at how it drops packages for two arches out
<ajmitch> impressive
<ajmitch> what hackery was required there?
<Yagisan> ajmitch: I had to butt heads with dpkg a lot. Check out my handiwork in the rules file here http://revu.tauware.de/details.py?upid=1445
<\sh> ajmitch: exchaning arch names of the packages from i386 to amd64  ,)
* Yagisan really needs to leave now
<\sh> rough overview that was :)
<ajmitch> will it work for wine? :)
<\sh> ajmitch: not exactly but somehow similar
<Yagisan> ajmitch: should - I'll do the dapper package tonight
* Yagisan leaves in a rush - bye all
<ajmitch> sigh
<ajmitch> downloading wine is taking too long
<\sh> ajmitch: first there has to be an amd64 native package...which means I have to ask for the arch type and if amd64/ia64/whatever and add --enable-win64 or something like this to configure
<\sh> ajmitch: on i386 side, we have to add another binary package control description like wine64-compat32 or something
<\sh> and toss the 32bit wine stuff into this package for amd64
<\sh> and changing the arch type of the package to amd64
<\sh> which is somehow tricky and i'm not sure if I want that really
<\sh> but anyways...I just made a new 0.9.5 upload today with wmf fix
<\sh> pitti has now breezy and hoary fixes for the respective wine versions
<\sh> so I'm done with wine for today
<ajmitch> I doubt it'll get diablo 2 going again, knowing the wine hackers
<ajmitch> wow, it runs again
<LaserJock> crimsun: so debian/rules did have a problem?
<TheMuso> c
<LaserJock> what app do I need to be able to send emails from a file or console via smtp?
<hub> postfix
<hub> sendmail
<hub> or any mta
<LaserJock> aren't those servers?
<ptlo> LaserJock: most console email apps use local mta to send mails ... examples are mutt, pine, elm. although i do believe mutt can use remote smtp server
<lifeless> simple-mail or something
<lifeless> theres a package that just gives you a mail sender
<ptlo> of course you can always use telnet for that, too ;-)
<lifeless> maybe it was xmail
<LaserJock> ok, I just want to be able to send out emails to my smtp server for the CLI without having to install an email server or something
<lifeless> ssmtp
<LaserJock> lifeless: ahh, I think that might be what I am looking for
<LaserJock> everything seems to assume I have a local mail server.
<psusi> postfix got installed for me when I installed apache I think
<psusi> so I just use that
<psusi> also installed dovecot on my server at work for imap access, and set up a cron job to pull the mail from lkml.org
<psusi> imap rules
<LaserJock> right now I'm just trying to use reportbug so I can send some stuff to BTS
<psusi> now I just need to get dovecot to be able to 7zip compress archive folders so my 50,000 old messages only take up 10 MB instead of 100 ;)
<mr-russ> How is decided what is in main or not?
<hub> mr-russ: what Ubuntu is willing to provide support for
<mr-russ> as in the paid developer people.
<mr-russ> or anybody who gets main upload rights.
<hub> as in "Ubuntu the project"
<hub> they have goal and package are here to achieve the goals
<hub> there are also security riquirements in these goals
<ajmitch> main inclusion reports get written up & software reviewed for it to go into main
<mr-russ> okay. that's giving a good picture thanks.
* mr-russ now asks noobie packaging questions.
<hub> mr-russ: universe is for the rest of the freely redistribuable sofware
<mr-russ> how do you alter a debian package so that is has ubuntu version?
<ajmitch> edit debian/changelog
<ajmitch> add a new revision, so that 1.2.3-4 becomes 1.2.3-4ubuntu1
<mr-russ> okay, so the deb gets the revision number for there.
<mr-russ> debian/ubuntu packaging is all a bit new to me.
<mr-russ> I always have to throw myself in at the deepend though.
<ajmitch> each revision has the version line, with distribution (dapper in our case, unstable or experimental for most debian uploads)
<ajmitch> :)
<ajmitch> it's the best place to start ;)
<hub> mr-russ: but only if you need to change something
<mr-russ> how are security patches to universe managed?  eg updates to packages in say breezy.
<mr-russ> hub: I've got one package that I've updated, and need to get updated in debian.
<hub> mr-russ: if there is a security report a patch is issued, tested and the current package patched to include the fix
<mr-russ> hub: I'm also trying to create some of my own specialized packages.
<hub> mr-russ: what do you mean. a new version?
<mr-russ> hub: so I'm trying to learn how to do everything :)
<hub> https://wiki.ubuntu.com/MOTU
<mr-russ> hub: one case is a new version been trying to merge 2 forks of a package, one maintained by me, one by the debian folk.
<hub> if the package is in main, file a bug
<mr-russ> I'm getting good a filing bugs :)
<hub>  any revu admin?
<ajmitch> yes?
<hub> I have a dput that failed
<hub> to to crappy internet connection
<ajmitch> :)
<hub> so I the file is stuck
<hub> gopersist_0.1.1-0ubuntu1.dsc
<ajmitch> yep
<ajmitch> removed
<hub> thx
<hub> fscking hell
<hub> this connection suck
<hub> anyone packaging synfig?
<crimsun> wow, so UVF is Jan 19th
<ajmitch> very close
<ajmitch> crimsun: still no closer with sound :)
<LaserJock> what has to be done before then?
<crimsun> all the merges, hopefully
<crimsun> ajmitch: d'oh :/
<crimsun> did you try those tree model= values?
<ajmitch> crimsun: there are quite a few comments on the upstream alsa bugtracker though
<ajmitch> no, I haven't tried that one
<ajmitch> #1517 on alsa's bugtracker if you're interested
<crimsun> err, s/tree/three/
<crimsun> (basic, hp, fujitsu)
<crimsun> ok, thanks
<LaserJock> arghh, why are there so many different MTAs
<crimsun> because there must be more than one way to break your system
<zakame> hi MOTUs :)
<LaserJock> all I want to do is be able to use reportbug and other CLI progs that send mail
<crimsun> LaserJock: you can set up an ssh tunnel to punt it to an upstream MTA
<crimsun> hi zak
<zakame> yep, or masqmail
<zakame> heya crimsun :)
<LaserJock> crimsun: what would and upstream MTA be?
<crimsun> LaserJock: I presume your ISP has one, or someone "outside" has a host running an MTA
<LaserJock> crimsun: yeah, I'm on a department LAN. There is a smtp server but I just don't know what program to use to that reportbug etc. will be able to use
<LaserJock> I think esmtp or ssmtp might work
<crimsun> you could set up exim to do forwarding to your LAN's smtpd
<zakame> LaserJock: that's a job for masqmail indeed :)
<zakame> or yes, exim can forward too :)
<LaserJock> zakame: will look into it
<LaserJock> crimsun: is that relatively easy to do? I don't want to have to do a bunch of configuration when I won't be recieving any mail just sending it
<crimsun> LaserJock: I can't speak for the others, but it was dead easy with exim in Debian Potato
<crimsun> I can only presume that masqmail, et al. would be even more straightforward
<LaserJock> ok, well I gotta get to bed, thanks crimsun and zakame for the suggestions
<zakame> crimsun: I can also vouch for Woody exim :)
<zakame> gn8 LaserJock :)
<ajmitch> crimsun: none of those models work, sorry
<crimsun> ajmitch: ok, thanks for testing.
* ajmitch doesn't know enough about sound drivers to hack up anything :)
<zakame> heya jaldhar_
<dholbach> good morning
<zakame_> good day dholbach :)
<dholbach> hello zakame
<Yagisan> re
<crimsun> re
<Yagisan> G'day crimsun
<crimsun> 'lo
<zakame> hi all
<crimsun> 'lo zak
* crimsun sighs. So many outstanding merges...
* zakame pats crimsun 
<zakame> heya Hobbsee
<Hobbsee_away> hey zakame
<crimsun> 'lo Hobbsee
<dholbach> lifeless, ajmitch: what about uploading *sync to ubuntu's NEW queue?
<dholbach> lifeless, ajmitch: i couldn't find the source packages to sponsor them to ubuntu
<dholbach> lifeless, ajmitch: UVF is in 9 days
<crimsun> yeah, that's why I've been scrambling w/ these merges
* dholbach hugs crimsun
<ajmitch> dholbach: you don't trust that they'll get through debian's NEW queue in the next 9 days?
<ajmitch> given that the average time in the queue has been 2-4 days lately
<lifeless> ajmitch: the plugins and guis definately wont
<lifeless> ajmitch: unless we are extremely lucky
<ajmitch> lifeless: not started yet?
<dholbach> so why do we wait for debian's NEW queue? why don't we upload them as 0ubuntu1 and sync whenever they are through?
<lifeless> dholbach: opensync is -not- ready for mainstream use anyway though
<lifeless> dholbach: whats the rush? the software is crackful at the moment
<dholbach> lifeless: would you consider mutilsync ready enough? :)
<lifeless> multisync is stable, the new multisync built on opensync is painful
<lifeless> missing gui bits, options that dont, its really quite painful.
<dholbach> ok
<Hobbsee_away> hi crimsun
<azeem> have there been any complaints for multisync-0.8x in breezy/dapper?
<azeem> I got another one that the last upload didn't fix the evo sync issues or so
<lifeless> azeem: hey there
<azeem> hi!
<lifeless> ajmitch: azeem did all the plugins, its just that they cant upload until libopensync0 is available for the buildds
<azeem> the GNOME people should just code up a decent "Syncing" Preferences capplet or something
<azeem> or maybe somebody should help abauer with his exams, so he can hack more on opensync :)
<\sh> grmpf...trying to fix qts immodule patch
<Tonio_> dholbach: hi ;)
<Tonio_> I won't be there for the CC meeting....
<Tonio_> the scsi perc card crashed last night on our fileserver...
<Tonio_> if I don't want to be fired today, I assume not spending time on irc is required ;)
<Tonio_> \sh: hi, how was your interview ? was it good ?
<dholbach> Tonio_: I'm sorry :/
<\sh> Tonio_: moment...I'll tell you later...have to fix something asap :)
<dholbach> Tonio_: you'll make it in the next one
<Tonio_> dholbach: has always ;) always for the next one hehe
<Tonio_> \sh: no pb :)
<dholbach> :)
<Tonio_> anyway, the most important is contributing, not especially beeing a member ;)
<Nafallo> Tonio_: it's easier to contribute when you're a member though :-P
<Tonio_> Nafallo: don't know what it changes exactly...
<Tonio_> beeing a motu gives a lot of different possibilities.... but beeing a member ?
<Nafallo> @ubuntu.com and requirement for motuness :-)
<Tonio_> okay ;)
<Nafallo> might even get some social stuff aswell :-)
<Nafallo> s/get/gain/
<Tonio_> in fact dholbach wanted me to come introducing at the CC for at least.... 6 month I think :)
<Tonio_> and there is always a problem lol
<Nafallo> ouch
<Nafallo> that's like 12 times :-P
<Tonio_> yep.....
<Tonio_> I have a job which takes me about 55 hours a week....
<Tonio_> so the only way to contribute is by night, and CC are most often during the day....
* Tonio_ is dreaming of a 9pm gtm+1 CC ;)
<Nafallo> :-)
* Yagisan tosses wine into pbuilder and waits patiently for 32bit and 64bit packages to emerge
<Nafallo> Yagisan: you should totally add a subpage to the PbuilderHowto! :-)
<Yagisan> Nafallo: what - how to abuse^Wuse the build system
<Nafallo> yea :-)
<Nafallo> I think my girlfriend would love me to stop using her box for i386 pbuilding ;-)
<Yagisan> Nafallo: you have amd64 ?
<Nafallo> yepp, my laptop :-)
<Yagisan> Nafallo: easiest way is to install pbuilder in an i386 chroot
<Yagisan> Nafallo: least effort - but needs more disk space
<raphink> lucas: I see you put notes on your merging page. Could you add a note to wesnoth so it's not merged?
<Nafallo> then I have to create an i386 chroot. and I'm lazy. so I rather ssh silverfairy ;-)
<raphink> lol
<raphink> Nafallo: build on her comp through ssh so she doesn't notice ;)
<Yagisan> Nafallo: amd64 boxes are quicker - even with 32bit code
<raphink> she'll only notice it's a bit slow sometimes ;)
<raphink> hehe
<raphink> creating an i386 chroot takes about 10 minutes
<Nafallo> Yagisan: yea, but then I have to use a chroot :-P
<raphink> if you're not too fast
<raphink> Nafallo: really setting up a chroot is very easy
<raphink> I have 2 running on this box
<raphink> Nafallo: https://wiki.ubuntu.com/DebootstrapChroot
<raphink> Nafallo: that takes you through the whole settings of a chroot ;)
<Nafallo> raphink: I know. but I would rather have pbuilder cross-compile and give me both amd64 and i386 in one go :-)
<raphink> oh sure
<raphink> for some reason, I use both pbuilder and dchroot ;))
<raphink> not for the same purpose
<raphink> different tools for different things :)
<raphink> if you just want to build stuff for i386 then sure pbuilder is better ;)
<Nafallo> I use pbuilder login :-)
* Yagisan has 6 chroots
<Nafallo> anyway. have to go after this upgrade.
* Nafallo is late already
<viviersf> guys
<viviersf> nm
* Yagisan curses at pbuilder for failing to download ed
* crimsun takes a break from merging
<raphink> Riddell: are you there?
<ajmitch> crimsun: bug reports on forums, of all places, about python-wxgtk2.4 not installing (bad postinst)
<crimsun> ajmitch: thanks, I'll look
* Yagisan wonders if tweaking wine's cflags for speed is worth it
<Mithrandir> Yagisan: it's not
<Mithrandir> unless you _know_ that you want something else than -O2, you don't
<Yagisan> Mithrandir: just idle thoughts now they are implementing directx.
<Mithrandir> Yagisan: -O2 is generally the fastest anyway
<\sh> Yagisan: please don't upload this package to revu...put it somewhere else where I can access it :
<\sh> )
<Yagisan> Mithrandir: yep, but some of the other flags are helpful too depending on the source
<Yagisan> \sh: I'll host it on my adsl connection then - 256K up
<\sh> brb
<Mithrandir> Yagisan: oh, like?
<Treenaks> Mithrandir: the CPU-specific ones! don't you read the Gentoo forums?
* Mithrandir smacks Treenaks with a large hammer
<lucas> raphink:
<lucas> the best would be to store the notes elsewhere
<Yagisan> Mithrandir: On some sources, -fweb, -funswitch-loops, and -ftracer can have an effect. -fomit-frame-pointer is nice on i386, but you can't debug with it
<lucas> I could easily fetch them, it's only a text file
<Yagisan> Mithrandir: but unless you want to sit there and measure it to be sure, it may not be worth it. I also observe that optimising for size
<Yagisan> Mithrandir: can sometimes be faster then -O2
<\sh> Yagisan: this is gentoo logic :)
<raphink> lucas: hi
<raphink> lucas: to store them where then?
<lucas> on the wiki maybe
<Yagisan> \sh: Only some apps that are cpu bound are worth testing like that
<lucas> I'll try to implement that later today
<raphink> lucas: ok
<Yagisan> \sh: on all apps, it's a waste of time
<raphink> lucas: then the best is that you create the wiki page you want to fetch from it
<\sh> Yagisan: well...apps like mplayer etc. are bringin in most of the time their own cflags ...
<raphink> with something like a table to put the notes in
<Yagisan> \sh: not my mplayer package ;)
<\sh> Yagisan: that's why many users of gentoo were fcked while they tweaked their cflags to hell..and were wondering that mplayer never worked properly
<Yagisan> \sh: sed is your friend :)
<raphink> lucas: superkaramba is also to be nuked from the list
<Yagisan> \sh: its a very bad idea to obsessively tweak cflags for all apps - things break. things like xvid, x264 tend to benefit most
<Czessi> \sh: my package is now in revu
<\sh> Czessi: cool
<Czessi> http://revu.tauware.de/details.py?upid=1457
<Czessi> but iam now away for the next hours
<\sh> k
<\sh> Czessi: advocated...everything is ok :) wow :)
<\sh> I wonder how amu is managing it, to catch the right people ;)
<Czessi> \sh: *falling down from my chair* ;)
<\sh> Czessi: now you need a second vote...and your first package will be uploaded :)
<Czessi> :D
<Czessi> \sh: iam away, see you later, bye
<\sh> Czessi: ok :) have fun :)
<lucas> can somebody install elinks on tiber ?
<lucas> siretart ?
<\sh> elinks?
<lucas> console web browser
<lucas> I need to be able to do a links -dump on https://wiki.ubuntu.com/MOTUNotes
<\sh> lynx -source ?
<lucas> lynx is not installed
<\sh> but anyways..installed
<\sh> now
<\sh> elinks
<lucas> and probably doesn't support HTTPS
<lucas> thanks, it works perfectly
* Yagisan sighs. after a very long wine build I just realised I'll have a name space collision between the 64bit and 32bit packages
<Yagisan> but on the bright side, I did make 32bit packages for amd64 and i386
<\sh> Yagisan: I told you :) you have to cover some things :)
<\sh> Yagisan: first of all, we have to create a wine64 package with real win64 dlls inside...which can be done via if arch == amd64 in the rules file and adding a --enable-win64 or something like this to the configure statement...then we need a new package for wine64-compat32 or something similar where all the 32bit libs are in (which are build for amd64 on i386 buildd) but we have to make sure, that they're installed in a different place...to no
<Yagisan> \sh: yeah, I know - but it's a start. most of the groundwork is there
<\sh> Yagisan: let me have a look...on how I can build a wine64 package...if this is done...you can grab the package and add your 32bit compat stuff...
<\sh> Yagisan: the most difficult part about it, it's the different location for those libs
<Yagisan> \sh: want my current package ?
<Yagisan> \sh: it's well documented
<\sh> Yagisan: no...I need only the rules file...but first let me create this amd64 package :)
<Yagisan> \sh: you'll need more then the rules file
* Yagisan already has set it up to build native amd64
<sistpoty> hi folks
<Yagisan> \sh: I'm just waiting for my amd64 dapper pbuilder to finish being created
<sistpoty> is kubuntu@czessi.net here? (regarding kiso upload)
<\sh> sistpoty: he is just gone...what about kiso?
<sistpoty> the orig tarball is changed
<sistpoty> this is a nogo for me :(
<\sh> what?
<tseng> sistpoty: if you update the same revision to revu why does it diff backwards
<tseng> sistpoty: it is --- new +++ old
<sistpoty> \sh: also it's explained in debian/changelog that the orig-tarball is modified... just to quiet lintian is no reason to do so
<Yagisan> \sh: my current rules for wine
<sistpoty> tseng: it shouldn't actually (checking)
<tseng> sistpoty: look at openvpn-admin
<\sh> Yagisan: can you send it to me via email?
<tseng> sistpoty: in the second upload i did s/cowbell/openvpn-admin in rules
<tseng> sistpoty: it shows the reverse (and shows the old diff.gz)
<Yagisan> \sh: yep -  I see dcc failed
<sistpoty> tseng: it shows it right... you need to select the latest upload first
<tseng> oh?
<tseng> ok
<sistpoty> tseng: it will always debdiff between the upload you clicked on and the one of the debdiff link
<sistpoty> (so you can do reverse or forward debdiffing to your liking)
<\sh> oh yes...I see...
<sistpoty> \sh: strange enough for almost every second package I reviewed the orig-tarball was changed :(
<\sh> well...for gajim I used the tar.bz2 which I repackaged to tar.gz...but right now it doesn't matter, because we are just upstream for gajim ;)
<lucas> ok, the comments on MOTUNotes now show up in the lists
<sistpoty> hehe
<lucas> now integrating sistpoty's merge info
<sistpoty> \sh: well, repacking is sometimes necessary... ;)
<\sh> sistpoty: I adjusted my decision...thx for pointing it out :)
<Yagisan> \sh: emailed
<sistpoty> \sh: you're welcome ;)
<\sh> sistpoty: but actually it's a little mistake...the package itself is quite nice :)
<\sh> Yagisan: thx
<sistpoty> \sh: just building it... and it looks quite good
<Yagisan> \sh: email arrive yet ?
<\sh> Yagisan: yepp..
<Yagisan> \sh: hmm - you don't seem to happy. what's wrong ?
<bmonty> good morning everyone
<Yagisan> G'day bmonty
<\sh> Yagisan: the wine app (in /usr/bin) do we need a 32bit version on amd64 as well, for 32bit compatiblity, right?
<Yagisan> \sh: yes. I think we should leave the name of the app as wine, as many (3rd party) scripts need it
<\sh> Yagisan: or will wine (real 64bit) start up with the 32bit libs, if it finds out that the windows app I want to start is 32bit?
<Yagisan> \sh: no. we need to write a wrapper ousrselves
<Yagisan> \sh: I'd like to concentrate firstly on getting 32bit wine on amd64 going, then 64bit wine, and finally a wrapper
<\sh> Yagisan: ok...so the problem is right now, to find a way to move all 32bit stuff to a new location...where we don't clash with the 64bit stuff
<Yagisan> \sh: yes. I can just mv /lib to /lib32, but we don't have a /bin32
<\sh> Yagisan: no, we have to do it directly...if I'm enabled wine for 64bit, the default package has the content of wine64
<bmonty> hmm....merge page is looking really good :)
<\sh> Yagisan: another question....do we need linux32 for it to start it in 32bit mode?
<Yagisan> \sh: no. linux32 just makes the arch appear to be i686 when asked
<\sh> I'm a sucker somehow...I never used wine...everytime I wanted to use it, my application I needed wasn't running with wine...
<bmonty> \sh: that is my experience with wine as well
<Yagisan> \sh: I know - it breaks on me too
<Yagisan> \sh: but virtualdub can't be ported, so I keep trying
<\sh> hmm..what I pressed now?
<Yagisan> \sh: do you have an amd64 system there ?
<\sh> Yagisan: let me think about a good solution...how we can deal with the clashes and the namespace
<\sh> Yagisan: yepp...but without a monitor..so I can only run it via ssh -X
<Yagisan> \sh: mv * *-64 ?
<Yagisan> \sh: also need to automagically adjust debian/files based on the version number
<\sh> no..I want to have the wine64 stuff the same way as it is on i386...but the wine32 compat stuff on amd64 must be named differently...the question is, the libs we can move to /lib32, I'm not sure, if we have to compile this beast again with the new location..or just add something to LD_LIBRARY_PATH
<\sh> I would like to see something like this on amd64: wine (for 64bit version) and wine32 for the compat thing
<sistpoty> \sh: kiso is really nice work... if the next upload changes only the orig-tarball, and you review it before me, you can upload it ;)
<\sh> sistpoty: ok :)
<Yagisan> \sh: just move the libs. ldconfig will scan the libs on install anyway
<\sh> Yagisan: but we will have a name clash with /usr/bin/wine
<bmonty> quick question, what are you all using for an editor/IDE for python?
<sistpoty> bmonty: vi ;)
<\sh> bmonty: emacs, vi, or eric :)
<Yagisan> \sh: yes - we need to rename or move the binaries
* Yagisan uses mcedit when coding
<sistpoty> bmonty: but apart from that I've once played with eric, which is cool for debugging. I've heard eclipse would be quite good as well
<bmonty> I'm using vi, but I didn't know eclipse spoke python also
<sistpoty> bmonty: didn't test it yet... just read about it
<\sh> Yagisan: I'll think about a good way to do it...need to rest a little..
<bmonty> sistpoty: I'll have to look in to that
<\sh> well..eclipse is heavy stuff for python :)
<\sh> to just edit a single source ,)
<bmonty> \sh: yeah, but I like eclipse
<sistpoty> \sh: you can do big projects (like revu2) in python as well :P
<bmonty> especially when there are multiple source files
<\sh> I like eric because it has a nice project management and only needs libqt pyqt
<Yagisan> \sh: feel free to email me changes
<\sh> sistpoty: hehe..I meant for "just a quick edit" ...
<sistpoty> hehe
<\sh> anyways...at 15:00 UTC there is CC meeting..I have to rest at least one hour or so
<azeem> \sh: didn't you say you had an interview yesterday?  How did it work out?
<\sh> well...I wasn't happy with myself...I started the day with stress..and during the interview, I just forgot everything I knew..the easiest questions...well..I managed somehow...and I will wait for them to call me again :)
<\sh> I will see
<azeem> hrm :-/
* bmonty hopes \sh gets the job
<\sh> best thing was "how is traceroute working"...actually I explained it a couple of months ago during my juniper training to the other people....and yesterday I just forgot everything about it...my head felt empty
<Riddell> raphink: hi
<raphink> hi Riddell
<azeem> \sh: you should have side-stepped the question and discuss whether traceroute should be in /bin or /sbin ;)
<bmonty> lol
<\sh> azeem: well..I should have told them that traceroute is not the standard on linux anymore...now it's named tracepath :)
<bmonty> yeah, the was bugging me this morning...
<\sh> bmonty: apt-get install traceroute and you feel home :)
<Yagisan> \sh: I thought it was mtr ...
<bmonty> \sh: I figured out that it is tracepath and I'm happy :)
<bmonty> apropos is your friend
<\sh> ok..going to sleep at least one hour...see you at the meeting
<sistpoty> cya \sh
<bmonty> cya later \sh
<Yagisan> bye \sh
<bmonty> I'm hoping my update completes before I have to leave for my plane
<bmonty> and...doh its downloading openoffice :(
<Yagisan> that's what 300mb ?
<bmonty> Yagisan: its working on a 25mb file right now
<bmonty> oh well, I'll probably have to cancel it
<bmonty> have a great day!
<mgalvin> hi all, i uploaded an updated gperfection icon theme package and a new the widget factory package to revu
<mgalvin> just a heads up, in case any might have time to review them, thanks
<mgalvin> s/any/any one/
<lucas> http://tiber.tauware.de/~lucas/versions/unimultiverse.html now includes sistpoty's info :-)
<thierry_> sispoty : what do you mean by you should provide/conflict libfxscintilla-dev  ?
<sistpoty> thierry_: did you take a look at the library packaging guide?
<thierry_> yes, but not for that, wait a minute...
<sistpoty> thierry_: look for the -dev package section, it's explained pretty good there (probably better than i can now ;)
<thierry_> sistpoty : and I put conflict and provides in control file?
<sistpoty> thierry_: yes
<thierry_> k
<thierry_> *sigh, I think there will be a third entry for my package in REVU list...
<thierry_> sispoty : will you be able to fix this?
<sistpoty> thierry_: sure
<thierry_> sistpoty : is it normal now that my package is name libfxscintilla?
<sistpoty> thierry_: yes, the sourcepackage should be named libfxscintilla, or fxscintilla (both would be valid)
<Yagisan> heh - wine FTBFS as 64bit
<raphink> cc time :)
<thierry_> sistpoty : sent the new package to REVU, you should now delete libfxscintlla1.6 and libfxscintilla17
<sistpoty> thierry_: ok, I've archived those
<thierry_> k
<Yagisan> \sh: wine FTBFS on amd64 native. I reported the bug upstream here http://bugs.winehq.org/show_bug.cgi?id=4281
<Ubugtu> Error: Unknown bugtracker
<Yagisan> \sh: I'll do some final cleanup on the package tomorrow, I also was given a suggestion on how to fix the naming issue
<Yagisan> \sh: if you have any changes - please email me
<hub> anyone knows how to tell apt-get source to fetch a specific version?
<azeem> hub: apt-get source foo=3.2.-
<azeem> eh, 3.2-1, whatever
<hub> nopr
<hub> does not work
<azeem> does apt-cache showsrc foo | grep Vers say 3.2-1?
<dholbach> -t <distro> should work now too
<dholbach> -t breezy or whatever you have in apt/sources.list
<hub> -t does not work
<hub> azeem: well, I apparently messed up with that
<hub> works now
<hub> azeem: thanks
<azeem> cheers
<dereks_> \sh: ping
<Riddell> smurf handles all the loco stuff right?
<tseng> yes
<LaserJock> do you guys think it would be nice to have the package name in the Subject of Malone emails?
<LaserJock> I get all these emails from ubuntu-bugs and a lot of the time I have to actually look at the email to find out what package the bug is in. Most of the time I like scanning for packages I know.
<sistpoty> LaserJock: it would be good imo, but I would need to update the mail-parser from the merge list :(
<sistpoty> d'oh.... s.th. smelling burned inside my computer
<Riddell> what is smurf's e-mail?
<Riddell> ah, foudn it
<Riddell> found it
<psusi> electronics contain magic smoke that makes them work... once they let out the magic smoke, they don't work no more ;)
<sistpoty> hehe
<LaserJock> man, on Saturday the laser down the hall started smoking
<LaserJock> It blew lik 5 fuses and a hug capacitor and now we have to send the whole thing back for repair
<LaserJock> hmmm, my e key wasn't working so well
<LaserJock> anyway, I bet it will be ~$10K for repair :(
<LaserJock> and my boss is gone to London for vacation
<sistpoty> hm... maybe it's may graphic card... fan doesn't seem to be running
<Yagisan> sistpoty: turn the pc off, and get a small brush to clean the fans. It's most likely clogged with dust
<Yagisan> night all
<sistpoty> Yagisan: well, I "repaired" the fan once, maybe that's a result from it... thx for the tip
<sistpoty> gn8 Yagisan
<segfault> anyone? http://revu.tauware.de/details.py?upid=1397 :-)
<sistpoty> raphink: for konq-kim, do you want to wait for the next upstream version?
<psusi> a can of compressed air goes a long way
<raphink> yes sistpoty
<sistpoty> raphink: ok, then I'll archive this one
<raphink> sistpoty: I mailed the dev about that somet ime ago
<raphink> sistpoty: sure :)
<raphink> siretart: shall I close Malone #5214 ?
<Ubugtu> Malone bug 5214: "superkaramba: merge new debian version" Fix req. for: superkaramba (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: Unconfirmed http://launchpad.net/bugs/5214
<raphink> siretart: it's an old one you opened months ago
<raphink> so I think it's obsolete
<sistpoty> raphink: please wait a moment... I think the email-parser, which sets bugs to fixed broke
<sistpoty> (on the merge-list)
<raphink> oh ok
<raphink> well it's a very old one
<raphink> from november
<sistpoty> grml... no the email-parser seems fine. lpbugs won't set bugs to fixed any longer :(
<sistpoty> raphink: if you've checked the buildlogs and they are fine, you can set them to fixed
<sistpoty> set the bug to fixed, even
<raphink> sistpoty: this source is obsolete
<raphink> I don't really mind whether it was built or not
<raphink> it shouldn't exist anymore
<raphink> ;)
<sistpoty> ah, I recall :)
<raphink> ;)
<sistpoty> raphink: does it still exist in debian?
<raphink> so I should mark it as fixed?
<lfittl> dholbach: ping
<raphink> sistpoty: well the source yes, but it's not used imo
<sistpoty> raphink: if the source is still in debian, don't mark it as fixed... otherwise it would have the chance to get to new back again (once i update the list)
<dholbach> lfittl: pong
<sistpoty> raphink: probably rejected or won't fix would be good
<raphink> sistpoty: I've put a comment on lucas' merge list about this
<raphink> ok
<raphink> that's what I wanted to know
<raphink> if I should reject it
<raphink> sistpoty: i'll mark as rejected with an explanation
<sistpoty> :)
<raphink> sistpoty: https://launchpad.net/distros/ubuntu/+source/superkaramba/+bug/5214
<Ubugtu> Malone bug 5214: "superkaramba: merge new debian version" Fix req. for: superkaramba (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: Rejected http://launchpad.net/bugs/5214
<raphink> there
<raphink> :)
<raphink> hmm
<raphink> doesn't print the explanation
<raphink> nm
<sistpoty> never mind... siretart will get the mail with the explanation
<raphink> ok :)
<elektranox> in dapper - nautilus is a small bug with the rights of a file...sometimes they couldn't be changed with nautlius Oo
<LaserJock> elektranox: have you tried finding a bug report at bugzilla.ubuntu.com or launchpad.net/malone ?
<LaserJock> hi minghua
* sistpoty needs to leave now and won't make it to TB tonight
<sistpoty> cya
<LaserJock> cya sistpoty
<minghua> hi LaserJock
<minghua> LaserJock: thanks for your efforts on motu-science
<LaserJock> minghua: do you think it is worth while?
<LaserJock> minghua: I hope I am getting somewhere
<minghua> LaserJock: yes, I think it's very worthwhile
<Gloubiboulga> evening
<minghua> LaserJock: I think motu-science can be a very good playground for potential science packages to eventually enter debian
<LaserJock> minghua: I agree
<LaserJock> minghua: I just got my first package (plotdrop) into universe and I just filed an ITP yesterday
<minghua> LaserJock: and if we have a team, and a centralized page and repository (aka universe), there is a better chance things will happen
<minghua> LaserJock: yes I saw your ITP :-)
<LaserJock> minghua: you did?
<LaserJock> minghua: sistpoty got me an account on tiber.tauware.de so now I can host some cool pages with package versions etc.
<minghua> LaserJock: yes, on debian-devel list
<LaserJock> minghua: check out the links on wiki.ubuntu.com/MOTUScience
<LaserJock> minghua: under "Ubuntu and Debian Packages"
<LaserJock> minghua: and I found out from Keybuk that packages.qa.debian.org links to the Ubuntu patches so everthing is right there for DDs to get the Ubuntu patches
<minghua> LaserJock: ok, will look at them, quite busy recently though
<LaserJock> minghua: np, I think I will email debian-science an overview of what is available for DDs to get Ubuntu patches
<LaserJock> minghua: maybe a little info will help the situation a bit
<psusi> how would backporting a package differ from patching it?
<psusi> if I want to backport a package from dapper to breezy, could it be as simple as getting the dapper sources and pbuildering it?  ( assuming that actually works ) or is there some special way to version it?
<Mithrandir> psusi: your fix for e2fsprogs would break ia64, so upstream considers it not a good idea.
<psusi> Mithrandir: how would it break ia64?
<psusi> I just made it compatible with the kernel header, which works on ia64, so it should too?
<Mithrandir> psusi: __s64 is signed long on ia64, not signed long long.
<psusi> ohh...
<psusi> in the kernel headers that's how it is defined?
<psusi> strange that it woul be long long on amd64 and just long on ia64
<psusi> btw... does malone not distinguish between releases?  it doesn't seem to have anywhere ot specify weather it is a bug in dapper or breezy
<psusi> Mithrandir: isn't there a #define that tells you which platform you are being built on?
<Mithrandir> psusi: eww.
<psusi> maybe the e2fsprogs header should be changed to use that instead of picking based on sizeof()?
<Mithrandir> psusi: there is, but I don't think that's a very nice way to go about
<psusi> well, if it really is defined differently on amd64 and ia64, I see no other way to get the correct definition
<Mithrandir> change it to use uint64_t and int64_t
<psusi> that isn't correct either because that's not how the kernel headers do it
<Mithrandir> *shrug*, so?  As long as it's correct and __s64 is the same as int64_t, always, I don't see the problem.
<psusi> the problem it caused for me was that defrag was including both e2fsprogs and kernel headers... and they differed in how they defined the those types, which causes a compiler error
<psusi> so however it gets defined, it needs to be the same in both places
<Mithrandir> not if e2fsprogs doesn't define it and doesn't use it.
<psusi> huh?  it does define it
<psusi> it just defines it in a different way than the kernel headers
<Mithrandir> in the hypotetical case that e2fsprogs were fixed to not define it and not use it.
<psusi> ahh... well, that would work too I suppose
<psusi> but that's not going to happen any time soon
<Mithrandir> why not?
<psusi> that would take a fair amount of work from upstream
<psusi> much simpler to just get the existing definition to jive with the kernel definitions
<Mithrandir> it's two lines of sed, not that hard.
<psusi> well... heck.. ok.... propose both to upstream and as long as they do one of them soonish, I'm happy ;)
<Mithrandir> I've mailed tytso this morning, so..
<psusi> now... question... the p7zip in breezy segfaults left and right for me... I just got the dapper version and it built fine on breezy and appears to be working much better... how would I go about getting that into backports?
<LaserJock> azeem: ping?
<azeem> pong
<azeem> LaserJock: ^^
<LaserJock> azeem: did you see malone bug 5643
<Ubugtu> Malone bug 5643: "[patch]  Ghemical .desktop file is not so good (absolute path, missing stuff, invalid stuff)" Fix req. for: ghemical (Ubuntu), Severity: Minor, Assigned to: MOTU Reviewers Team, Status: Unconfirmed http://launchpad.net/bugs/5643
<azeem> hrm, yeah I think I saw that
<bmonty> hey LaserJock
<azeem> I'm at the uni still though, so I can't commit anything to my local package
<LaserJock> hi bmonty
<LaserJock> azeem: but do you want to have us sync it from Debian?
<azeem> well, I guess I'll fix it with the next upload (if I do not forget), but I wanted to have amd64 back first
<azeem> if you need it fixed now, that's fine as well, and I'll sync back to Debian
<bmonty> LaserJock: do you have a patch?
<LaserJock> azeem: well it isn't a big issue I was just trying to clean up the ghemical malone bugs
<LaserJock> azeem: there are a couple about AMD64, are you working on that or is that going to take a new release?
<azeem> upstream said they would, but it might take a while
<bmonty> I can upload the desktop patch now if there aren't any other issues
<azeem> I should try to fix them, but I didn't get around doing so yet
<LaserJock> bmonty: the patch is on malone bug #5643
<Ubugtu> Error: Could not parse data returned by Malone: Connection to Malone bugtracker failed: The read operation timed out
<bmonty> got it
<LaserJock> also, I am not sure what to do with malone bug 5632
<Ubugtu> Malone bug 5632: "Ghemical won't start up (breezy amd64)" Fix req. for: ghemical (Ubuntu), Severity: Normal, Assigned to: MOTU Science, Status: Unconfirmed http://launchpad.net/bugs/5632
<LaserJock> I mean, the apparently the ATI driver was the problem
<bmonty> LaserJock: I think malone 5632 will require upstream to fix
<Ubugtu> Malone bug 5632: "Ghemical won't start up (breezy amd64)" Fix req. for: ghemical (Ubuntu), Severity: Normal, Assigned to: MOTU Science, Status: Unconfirmed http://launchpad.net/bugs/5632
<bmonty> LaserJock: we should also open a bug in Debian's BTS to have them push this patch into the debian version of the package
<LaserJock> bmonty: the .desktop patch?
<bmonty> LaserJock: yes
<LaserJock> bmonty: ok, I can do that. That way azeem will remember better ;-)
<bmonty> k, I uploaded the patch to ubuntu
<bmonty> this is fun....bugfixing in an airport :)
<LaserJock> lol
<zakame> bmonty: w00t
<zakame> ooh free (speech) flash, finally
<jamessan> zakame: wasn't that what libflash-* was? this is just promoted by the FSF and funded so it's actually made it further than previous projects
<zakame> jamessan: hmm, indeed :)
<Treenaks> it doesn't Work?
<bmonty> gnash doesn't look ready for primetime yet though...no firefox plugin working yet
<LaserJock> anybody know of a simple way of testing if exim4 is working?
<bmonty> telnet to it
<LaserJock> you can telnet to it?
<bmonty> yup...telnet host 25
<LaserJock> isn't that kindof a security problem
<zakame> not really
<bmonty> LaserJock: no, it is essentially the same as what your SMTP client does minus the telnet control stuff
<LaserJock> I just wanted to test if I can send out mail to my smtp server. I don't want to be able to receive mail.
<zakame> wb siretart :)
<bmonty> LaserJock: you asked for any easy why to test it :)
<bmonty> you could also look at the logs on the server and see if it shows the connections
<LaserJock> ok, well I think I am blocking telnet because I get a connections refused
<LaserJock> if I installed mutt would I be able to send a test email out?
<bmonty> did you put the 25 on the end of the telnet command?
<LaserJock> yeah
<bmonty> then you are blocking the default port for SMTP or your server isn't running
<LaserJock> well, is it ok to block the SMTP port? Will I still be able to send mail out?
<bmonty> not if you block smtp in both directions
<LaserJock> ok, so when I do /etc/init.d/exim4 status I get "19952 daemon: -q30m, listening for SMTP on [127.0.0.1] :25"
<bmonty> ok, so it is only listening on the loopback, so it will only accept connections from the local machine
<LaserJock> ok, well that sounds good
<bmonty> probably what you want :)
<LaserJock> OK, I installed mutt and sent a quick email out and it worked.
<LaserJock> bmonty: I sent a bug report to Debian about the .desktop and referenced the malone bug. Does that sound right?
<bmonty> yeah, you should also reference the BTS bug in the malone bug report
<zakame> yep
<LaserJock> bmonty: k
<bmonty> LaserJock: you might want to add a link to malone in case the debian dev doesn't know what malone is
<LaserJock> bmonty: the Debian maintainer is azeem ;-)
<bmonty> ahhh, nevermind :)
<Mez> psusi - email the backprts mailing list about it - ubuntu-backports@lists.ubuntu.com
<LaserJock> now that I got the mail thing figured out I gotta go see if I can get my package into Debian and work on the Ubuntu Packaging Guide :-)
<zakame> wb Kyral
<LaserJock> Kyral: Hi!
<LaserJock> Kyral: haven't seen you for a while
<bmonty> hey Kyral
<zakame> gaah
<bmonty> they just called my flight....so gotta go, cya all later!
<dholbach> bye bmonty - good flight :)
<zakame> heya luk , Hobbsee :)
<Hobbsee> hey zakame :)
<LaserJock> hi Hobbsee
<Hobbsee> hi LaserJock :)
<Czessi> Hi, can anyone review my package, pls? http://revu.tauware.de/details.py?upid=1464
<thierry_> anyone who would like to review my package? http://revu.tauware.de/details.py?upid=1459
<Kyral> Is anyone working on this right now http://everygui.sourceforge.net/?
<LaserJock> Kyral: is EasyChem in the universe repo yet?
<Kyral> LaserJock: yah
<Kyral> has been
<LaserJock> Kyral: do you want to get it into Debian?
<Kyral> LaserJock: yah
<LaserJock> Kyral: azeem (Michael Banck) offered to sponsor chemistry related packages you should file and ITP and let him know when you have it ready to go
<Kyral> okay
<Kyral> Lemme settle back to school ;P
* Kyral takes a look at EveryGUI
<LaserJock> Kyral: fine, I just wanted to let you know
<Kyral> hooo
<Kyral> its a Python thing
<Kyral> I think I can use cdbs python-distutils
<Kyral> I'm gonna send an email to the author asking if he would be alright with me packing it
<zakame> w00t
<thierry_> I want to package something but dependencies doesn't get reviewed :(
<Kyral> heh
<Kyral> meh...how do I force a version
<zakame> set it in debian/changelog
<Kyral> like the origiinal tarball is 0.99.b and dh_make is throwing a fit
<zakame> how come, what's the previous ver?
<Kyral> i guess .a?
<zakame> hm, doesn't uupdate -v 0.99.b work (if its a new upstream version)
<Kyral> It isn't packaged
<Kyral> at all
<zakame> ah :(
<Kyral> can I just rename the tarball?
<zakame> what's the original name?
<Kyral> everygui-0.99.b.tar.gz
<zakame> ooh, so that's why
<Kyral> Yah I know its why lol
<Kyral> How do I make DH_Make behave
<zakame> can you pastebin the err?
<Kyral> http://paste.ubuntu-nl.org/6919
<zakame> hm can you unpack the source first, cd to it, then dh_make -c gpl -e kyral@ubuntu.com? skipping -f ...
<Kyral> ah
<Kyral> Same error
<Kyral> and I have to go to dinner
<Kyral> leave it in a PMSG mkay?
<zakame> sure :( I'll try myself
<zakame> where can I find easygui btw?
<mr-russ> is the wiki available to anybody here, it's not working for me atm.
<zakame> 'tis down, and so is LP
<mr-russ> lp?
<Nafallo> database is down
<Nafallo> launchpad
<LaserJock> bummer
<mr-russ> it is a bit, just started the work day here.
<LaserJock> does BTS usually take forever to register a bug?
<Nafallo> yes
<Nafallo> :-)
<psusi> what is the 'debian way' to build a package with debug syms not stripped?
<dholbach> cd build-tree; DEBUILD_OPTIONS="nostrip" debuild
<psusi> ahhh... I wish there was some equivalent to --help for finding environment variables you can tweek
<Nafallo> hmm
<Seveas> psusi, it's called poke_dholbach
<Seveas> :)
<zakame> hehe
<psusi> heh
<Hobbsee> hehe
<psusi> OPTIONS=tellmeallyoursecrets command
<Nafallo> hmm
<zakame> wb ogra_
<psusi> hehe
<Nafallo> I might try that poke_dholbach
<Nafallo> what was it for comparing what ARCH I'm on? :-)
<Nafallo> DEB_BUILD_ARCH?
<dholbach> poke_dholbach: connection to  dholbach  lost.
<Nafallo> and x86_64 is the proper for adm64?
<Nafallo> :-)
<Nafallo> NOOOO! :-
<Nafallo> :-P
<dholbach> Nafallo: https://wiki.duckcorp.org/DebianPackagingTutorial/CDBS knows
<Nafallo> CDBS, hmpf! ;-)
<dholbach> it has the variables as well
<ajmitch> morning
<LaserJock> hi ajmitch
<Hobbsee> morning ajmitch
<zakame> morning ajmitch
<ajmitch> looks like I  missed another meeting, CC this time?
<zakame> yep
<zakame> I missed it too, I thought it was 2000
<ajmitch> no big loss then
* ajmitch wasn't needed anyway :)
<zakame> haha
<Nafallo> it does?
<Nafallo> dholbach: thanks, but I can't see what if x86_64 is valid for DEB_BUILD_ARCH :-)
<ajmitch> dpkg-architecture
* Nafallo hugs ajmitch
<ajmitch> we really need a decent place to make requests for universe software
<Nafallo> agreed
<Nafallo> call sistpoty :-)
<Nafallo> oh
<Nafallo> changed name to amd64 :-P
<ajmitch> launchpad dead again?
<Nafallo> emperor died
<Nafallo> znarl contacted I think :-)
<ajmitch> ah right
<ajmitch> SPOF
<zakame> bye all, breakfast :D
<lifeless> znarl has been contacted
<lifeless> eta 30 minutes - some
<Nafallo> :-)
<ajmitch> yes, I'd be surprised if noone had noticed & starting working on it
<dholbach> I'm off guys - have a nice evening.
<ajmitch> bye daniel
<LaserJock> cya dholbach
<psusi> does pbuilder not respect DEBUILD_OPTIONS?
<ajmitch> sigh, yet more f-spot bugs rolling in :)
<tseng> eh
<tseng> ill trade you for beagle bugs
<ajmitch> debian
<tseng> eh
<tseng> ill trade you for fighting with jose
<ajmitch> heh
<psusi> hrm... this program I'm debugging keeps getting signal 32... how do you tell gdb to ignore it and let the program handle it?
<psusi> there we go... figured it out
<dholbach> Please remember: BUG DAY tomorrow! :)
<dholbach> errr NOW :)
<ajmitch> heh
* dholbach needs some sleep before
<ajmitch> yes, you're meant to be sleeping
<dholbach> SIR, ajmitch, YESSIR!
<ajmitch> bed! now!
#ubuntu-motu 2007-01-08
<sistpoty> hi folks
<ajmitch> hi sistpoty 
<sistpoty> hi ajmitch
<sistpoty> ajmitch: I get bounces from you via tiber
<ajmitch> yeah, dsl is down at home, I fetched 100 or so mails elsewhere but exim was misconfigured
<ajmitch> got them alright now, but I have to probably reenable bug mail
<sistpoty> oh
<jdong> quick question, what happened to the "request backport in" button on launchpad?
<jdong> I'd like to close 70154 in Feisty but keep a Dapper and Edgy task on it open
<fdoving> jdong: tried #launchpad ? 
<jdong> will do
<fdoving> they are usually very helpfull, don't know if this is the best time, though.. 
<jdong> right
<PriceChild> fdoving: why what's happenning?
<fdoving> the clock is close to 0100 CET.
<fdoving> and it's monday tomorrow.
<fdoving> though, i don't know where the launchpad devs live.
<PriceChild> oh ok
<jdong> late is no excuse :D
<jdong> lol
<somerville32> mpt is around
<somerville32> Lots of activity in #launchpad
<somerville32> oh, lol
<somerville32> Thats you
<fdoving> there you go.. i'm off to bed.
<fdoving> nite.
<sebest> hello, is there a way to remove a package from REVU?
<LaserJock> sebest: you can request it to be removed
<sebest> LaserJock: oki, i'd like to remove "ps-watcher" because it's in feisty from debian
<sebest> LaserJock: i have another question: i did a package, and it was accepted in universe, now a new upstream release is out, how can i have it include, should i post it to REVU again?
<sistpoty> sebest: please do so
<LaserJock> sebest: you could file a bug against the package and give a URL to a new source package
<sebest> sistpoty, LaserJock: which solution is better? launchpad or REVU?
<sistpoty> sebest: the best solution is to put it to a dgettable url and ping a motu with that url ;)
<sistpoty> sebest: so either revu or a different place will do
<LaserJock> I'm not really sure, but if you do use LP make sure to subscribe the ubuntu-universe-sponsors team
<sistpoty> sebest: though revu has the advantage that a reviewer can make comments (same goes for a bug in lp)
<sistpoty> hi LaserJock btw.
<LaserJock> hi sistpoty, shouldn't you be in bed?
<sistpoty> LaserJock: yes... probably in half an hour or so ;)
<sistpoty> didn't do my security bug fix for today yet :)
<sebest> sistpoty: i think i'm in trouble: "Error '553 Could not create file.'"
<sistpoty> sebest: for revu?
<sebest> yes
<LaserJock> we're going to have to add a "Go to bed, now!" timer in here ;-)
<sebest> i hit "ctrl+C"
<sistpoty> LaserJock: hehe
<sistpoty> sebest: what package? I'll clean it
<sebest> innotop
<sistpoty> sebest: gone ;)
<sebest> my last question was related to launchpad and the packages that were accepted:
<sebest> sistpoty: thanx :)
<sistpoty> np
<sebest> on this page: https://launchpad.net/~sebest/+packages
<sebest> my packages are liste, but when i click on them, there is an error
<sebest> and, i don't see them in feisty repository
<sebest> eg: https://launchpad.net/ubuntu/feisty/+source/eaccelerator
<sistpoty> sebest: probably still in the queue
<sistpoty> sebest: https://launchpad.net/ubuntu/feisty/+queue
<sebest> sistpoty: it was uploaded on 2006-12-16 17:00:05 CET
<sistpoty> sebest: an archive admin needs to check these by hand first... and ubuntu archive queue is quite big atm. :/
<sebest> sistpoty: 22 days is a lot :)
<sistpoty> sebest: unfortunately 22 days is *not* a lot :/
<sistpoty> there have been packages sitting far longer in the queue
<sebest> sistpoty: btw , what is the queue? there a compiled?
<sebest> is it an automatic process?
<sistpoty> sebest: no... it's the queue of package, that an archive admin needs to look at byhand
<sistpoty> sebest: there are two possibilities that a package lands in this queue: new sourcepacakge and new binary package (though new binary usually gets processed much faster))
<LaserJock> https://launchpad.net/ubuntu/feisty/+queue
<LaserJock> doh, sistpoty already said it
<sebest> i don't need to do anything special except waiting, right?
<sistpoty> sebest: right
<sebest> ok :)
<sistpoty> sebest: unless you get a reject ::P
<sebest> he :)
<sebest> btw, uploading to revu seems really slow today
<sebest> 5 minutes to upload 60ko
<sistpoty> we should really ban all php apps from universe *g*
<LaserJock> sistpoty: hmmm, that'd take out quite a bit
<LaserJock> less work, +1 ;-)
<sistpoty> and much less security risks... e.g.: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dokuwiki
<sebest> what does NMU means?
<sistpoty> sebest: non maintainer upload... you can ignore that for ubuntu
<sebest> and for debian?
<sebest> i'm trying to submit a package to mentors
<sebest> i have the following lintian warning:
<sebest> changelog-should-mention-nmu
<sebest> source-nmu-has-incorrect-version-number 0.9.5-1
<sistpoty> sebest: if anyone, who's not the maintainer or in the uploaders field makes a changelog entry, than that's a nmu
<sistpoty> sebest: and then that should be mentioned in the changelog... 
<sistpoty> sebest: and a patch to the previous version must go into bts
<sebest> there is no maintainer as the package doesn't yet exist in debian
<sistpoty> sebest: I don't recall the numbering scheme for nmu's right now, but iirc it should be 0.9.5-1.1
<sistpoty> sebest: same name/email in debian/changelog as in control-file?
<sebest> it seems to be case sensitive :)
<sebest> thanx :d
<sistpoty> np
<zul> anyone seen this before? raise PyCentralError, "package has no field Python-Version"
<sebest> last warning is about "not-using-po-debconf" but i'm not using po :s
<zul> control has XS-Python-Version: current
<crimsun> zul: what package?
<zul> xen something has changed on me..
<sebest> ok, it was in "man po-debconf"
<zul> crimsun: i blame ajmitch 
<LaserJock> zul: good call ;-)
<LaserJock> although it's harder to blame him when his DSL has been down
<zul> true...but its fun though
<sebest> What about a wiki style REVU to create/update package in a community fashion?
<sebest> people could correct/comment the debian/* files online from a browser
<LaserJock> we are trying out using Launchpad
<sebest> LaserJock: really? it would be really quicker to developp quality package
<LaserJock> we have a team on LP where people can push branches
<LaserJock> it's a hard problem
<sebest> small typo could be fixed easily without the long process of : "editing , debuild, dput, revu"
<LaserJock> REVU is pretty good
<ajmitch> zul: I'm used to getting blamed
<zul> i know you are
<sebest> ajmitch: i upload eaccelerator packages to mentors.debian.net (if you are interested in this info)
<ajmitch> ok
<LaserJock> sebest: but it would really stink if people started messing with your packages and it wasn't just a typo
* ajmitch has been away from computers for a couple of weeks, so has some catching up to do
<somerville32> LaserJock: What are we doing with lp?
<somerville32> or plan to do?
<LaserJock> somerville32: using it for REVU like activities
<somerville32> Interesting
<somerville32> docs?
<sebest> LaserJock: this is the main issue with wikis
<sistpoty> hm... imo an uploader can (and should) fix typos as well... but imo there is also an educational value...
<LaserJock> somerville32: docs?
<sistpoty> e.g. if someone needs to reupload 3 times because he can't get the orig.tar.gz right, he'll remember to not mess with it *g*
<somerville32> LaserJock: spec?
<sebest> LaserJock: but most of the time wiki still documents tend to improve (or you rollback :)
<LaserJock> somerville32: there was an email to -motu
* somerville32 doesn't subscribe to -motu - should he?
<sebest> sistpoty: yes, but he could fixed it with its browser
<LaserJock> sebest: yeah, but this is packaging and not docs. I think a wiki is less than idea
<LaserJock> somerville32: most definitely
<sistpoty> sebest: that's what I mean with educational value :O
<sistpoty> :P
<plugwash> don't debian policies require the orig.tar.gz to be messed with in the rather common case that not everything in upstreams official release is dfsg-free
<sistpoty> plugwash: that case is pretty uncommon actually
<sistpoty> plugwash: but yes, then it's ok
* plugwash finds it surprising that its uncommon
<LaserJock> why? we should have dfsg packages if possible
<sebest> sistpoty: this would be packaging 2.0 ;)
<sistpoty> sebest: I guess bzr is packaging 2.0 *g*
<sistpoty> s/is/will be/
<LaserJock> mhm
<sistpoty> but it's not ready yet imo
<rexbron> crimsun: the issue I am finding is gcc is looking for python.c (provided by soma) in /usr/include/python2.4
<LaserJock> yeah, there's some issues
<sebest> sistpoty: 1.9, because you need a bzr client:)
<LaserJock> joejaxx: pingy
<joejaxx> LaserJock: pong
<LaserJock> joejaxx: left a review of ubuntustudio-meta
<joejaxx> today is not my day my screen session crashed :(
<joejaxx> LaserJock: oh ok 
* joejaxx looks
<crimsun> rexbron: that's nasty; hack the Makefile.in as per necessary
<rexbron> I will take a look
<sebest> sistpoty: would be great to have a packaging IDE full web: editing and pbuildiing, i could click a button and it would pbuild on dapper/edgy/etc
<rexbron> also, I was talking with upstream, they might provide a patch for it
<rexbron> or at least look into it
<crimsun> rexbron: that would be preferable
<sistpoty> sebest: pbuilding would indeed be nice
<LaserJock> sebest: well, Mark said we'll be getting pretty close to that soon
<LaserJock> but I imagine it'll take a while to get there
<sebest> LaserJock: the development of these features are closed source?
<LaserJock> LP, yes
<sistpoty> lol, I wanted to type sudo poweroff and instinctly typed sudo pbuilder *g+
<LaserJock> heh
<sebest> Is there any reason? I don't ask it to be gpl or anything, but it would be nice that the code is open to contribute to it
<sistpoty> sebest: canonical is a company... they wan't to earn money after all ;)
<LaserJock> it's a Canonical decision as for as I know
<LaserJock> basically, they want to build a single place for people to go
<LaserJock> and if they give out the code before it's ready it could cause problems
<sebest> sistpoty: the code can't be open with a license that state that you can't use it commercially?
<bhale> people need to move on from the OSS zealotry business
<bhale> 1) no one is asking for the code to Google on a condition of using it
<LaserJock> wow, out of the woodwork
<bhale> 2) if you had the launchpad code, it would be useless to you
<bhale> LaserJock: sorry, heard this a few too many times
<LaserJock> yeah, I think it'd be very difficult to open source it at this point
<sistpoty> sebest: I guess it could... but the code alone isn't the only thing to make money with there... as LaserJock said, they also want to create a single place were ppl. will go, which is kind of a business concept as well
<bhale> its hard enough to run by Canonical
<bhale> largeish staff of programmers and sysadmins
<bhale> to play the devils advocate, it is slighly unsettling that the tools to build ubuntu are under Canonical's complete control
<bhale> this is not that exciting of a point, because virtual no one other than elmo can run DAK, either
<bhale> and has the same big lock on Debian
<sistpoty> hehe
<sebest> sistpoty: i don't see why people would go elsewhere if it were opensource
<sebest> the value is not the sourcecode, but the data IMO
<sebest> but i see reason for people NOT using it because it is closed source
<LaserJock> well, but if every project had there own LP it would kinda defeat the purpose. I think that's the idea anyway
<LaserJock> I don't know, I go back and forth with it
<LaserJock> it's sometimes aggravating to have to bug LP people all the time
<LaserJock> and sometimes there are obvious features that are missing
<LaserJock> but on the other hand, I don't think it'd be as far along as an opensource project
<LaserJock> and if *I* were to get code I couldn't do anything with it anyway
<LaserJock> :-)
<sebest> btw: bed time for me, good night all
<LaserJock> cya
* sistpoty is off to bed as well
<sistpoty> gn8 everyone
<superm1> crimsun, ping
<crimsun> superm1: contentless pong.
<TheMuso> haha
<superm1> contentless eh?
<superm1> interesting concept...
<crimsun> yes, please include what you're asking about in the ping
<superm1> ah okay
<superm1> crimsun, i switched the mythtv package over to use update-alternatives instead
<crimsun> excellent
<superm1> its much cleaner now
<superm1> i'm glad you suggested that
<bhale> crimsun, democracy player totally bombs on python2.5 here
<crimsun> bhale: but works on 2.4?
<bhale> crimsun: it works *more* :)
<bhale> but not by much
<crimsun> I can remove 2.5 (and just list 2.4 explicitly) in the next merge if 2.5 is a complete disaster
<bhale> 2.5 crashes immediately, 2.4 shows the window and then crashes
<bhale> this is the first time ive tried democracyplayer
<ScottK> One could argue that 2.5 is better.  If it's gonna crash, might as well get it overwith.
<crimsun> impressive, all 11 bugs are crashers
<crimsun> ooh, nice, i10n error causes crash
<LaserJock> hmm, it annoys me when mailing lists don't send me my own emails
<ScottK> LaserJock: If it's a mailman list there's a setting for that.
<LaserJock> ScottK: yeah, but I don't admin all the lists I subscribe too ;-)
<persia> How should a sync be requested (the previous Ubuntu changes have been merged in Debian)?
<jdong> hahaha, freudian slip of the day: Rockbox identifies "Thrash Metal" ID3 tag as "Trash Metal"
<jdong> :D
<LaserJock> persia: file a sync request bug and subscribe  ubuntu-universe-sponsors
<persia> LaserJock: Thanks.
<crimsun> u-u-s is largely non-functional presently
<crimsun> better to just ping me with the bug #
<crimsun> (due to the bug contact email going to only one person)
<LaserJock> what?
<LaserJock> why is that?
<persia> crimsun: Ah.  Thanks.  The sync bug is #76590.  Other bugs to which I have subscribed u-u-s are #33580, #42622, and #78296.
<crimsun> https://lists.ubuntu.com/archives/ubuntu-motu/2006-December/001047.html
<Hobbsee> crimsun: did you want the email?
* Hobbsee hasnt had a response yet from ML - perhaps i emailed the wrong address or something
<crimsun> Hobbsee: I'd like to see it set to a group email as it was, but you mentioned it's being worked on
<Hobbsee> crimsun: actually, i can forward it to you, so we both get it
<Hobbsee> i think...
<crimsun> Hobbsee: that would rock, thanks
<LaserJock> why don't we just have a mailing list?
<LaserJock> that's the usual thing to do
<Hobbsee> LaserJock: because i havent figured out how to get one, and my email hasnt been replied to yet
<somerville32> Hobbsee, You need to e-mail rt
<Hobbsee> somerville32: i did
<Hobbsee> crimsun: where did you want it?
<LaserJock> well, we can use tiber
<Hobbsee> LaserJock: cool
<Hobbsee> that'd work, i presume
<LaserJock> I just think it's odd to be hung up for a lack of mailing list
<crimsun> Hobbsee: my LP email would be fine
<Hobbsee> LaserJock: indeed.  if we can get a mailing list on tiber, i'd appreciate that
<LaserJock> I don't really read a lot of bug email ( I don't like how LP sends stuff) but surely people would find it useful
<LaserJock> Hobbsee: just get siretart to do it
<Hobbsee> siretart: ping?
<siretart> Hobbsee: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I'll respond when I am around.
<Hobbsee> *grin*
<Hobbsee> siretart: ping @ a mailing list for u-u-s on tiber
<LaserJock> now we are going to have 2x as many pings
<LaserJock> first the contentless ping
<LaserJock> then the one with content
<Hobbsee> indeed
<LaserJock> :-)
<Hobbsee> will he reply twice?
<Hobbsee> plus your mention of his nick
<jdong> which is why you ping with  random trash attached
<Lathiat> ping +++ATH0
<Hobbsee> heh
<bhale> ATDT Lathiat 
<Lathiat> NODIALTONE
<bhale> :(
<bhale> CARRIER LOST
<Lathiat> you lose
<somerville32> Ok
* somerville32 stretches.
<somerville32> Lets package.
<ScottK> LaserJock: Mailman usually has the option to get your own postings at the user level too in the users page.  That's what I've always seen.
<LaserJock> ScottK: oh, interesting, I'll have a look
<LaserJock> darn, it'd be nice if you could subscribe to particular tasks
<joejaxx> LaserJock: i can keep the package at the same version right?
<LaserJock> yeah
<joejaxx> ok
<somerville32> For my pyneighborhood package, I'm just going to delete what I have and use cdbs
<Hobbsee> hehe
<somerville32> For debian/
<somerville32> A lot of files can have the binary package appended to it
<somerville32> like menu
<somerville32> etc.
<somerville32> It is preferred to have that even if there is only one binary package?
<crimsun> it's not necessary, but it's the packager's preference.
<LaserJock> somerville32: yeah, just abstract your way out of problems :-)
<somerville32> When a makefile installs the files to the wrong place, I just have to patch the Makefile, right?
<ajmitch> usually, yes
<somerville32> With man pages
<somerville32> What does the number at the end mean?
<TheMuso> ajmitch: Heya!
<persia> somerville32: The section.  man man for a description
<somerville32> What do I do if all the source code is on the top level directory?
<somerville32> I think I need to pass the directory for pysupport to look in or something
<ajmitch> TheMuso: hello
<TheMuso> ajmitch: How was your Christmas break?
<ajmitch> it was pretty good
<ajmitch> how about you?
* ajmitch is back at work now
<ajmitch> so not really on irc :)
<somerville32> oh wait, nvm
<Hobbsee> ajmitch!!!
<ajmitch> Hobbsee: yes?
<Hobbsee> ajmitch: heya :)
<ajmitch> hello
<ajmitch> how's it going?
<Hobbsee> good :)
* ajmitch hopes that everyone has been working hard lately
<Hobbsee> nah...
<TheMuso> ajmitch: Twas good thank you.
* ajmitch happily had almost 2 weeks without a computer
<Hobbsee> TheMuso: coming to the dinner after open day?
<crimsun> oh, suck. More acroread CVEs that I can't do anything about.
<TheMuso> Hobbsee: WOuldn't miss it. I hope you are.
* Hobbsee is, yeah
<TheMuso> Good.
<ajmitch> hello crimsun 
* ajmitch would love to come to LCA
<crimsun> hello ajmitch 
<LaserJock> ajmitch: me too :(
<LaserJock> why can't they have LCA at google HQ? ;-)
<TheMuso> LaserJock: Because then it wouldn't be LCA.
* ajmitch won't be going anywhere for awhile, I think
<LaserJock> me neither
<LaserJock> I think Mountain View almost did me in :-)
<LaserJock> hmm, ERC
* ajmitch doesn't need to be travelling the world for various fun conferences
<ajmitch> so has the motu council been formed yet?
<Hobbsee> ajmitch: doubt it
<Hobbsee> ajmitch: CC meeting is on tuesday
<ajmitch> I thought it was mainly the TB it was blocked on
<Hobbsee> oh yeah
<Hobbsee> probably
* Hobbsee shrugs
<ajmitch> until then, you can continue working
<LaserJock> yeah, we seem to have lost a little of the "pre-Christmas" momentum
<ajmitch> a little?
<LaserJock> well, crimsun's still working
<ajmitch> crimsun doesn't know how to stop
<LaserJock> but we did lose the ajmitch factor ;-)
<crimsun> it's bit-perfect crack-cocaine.
<crimsun> I promise I'll check myself in MOTU anonymous soon
<ajmitch> LaserJock: the ajmitch factor being the general noise in the channel, with no actual work?
<LaserJock> crimsun: don't bother, it seems nothing can help the raging Ubuntu-holic MOTU :(
<LaserJock> ajmitch: I was thinking "constructive discussion" but whatever ;-)
<ajmitch> hah
<ajmitch> funny man
<LaserJock> perhaps I'll get to be the Castle Grayskull court jester :-)
* ajmitch will be the beggar outside the gates then
<LaserJock> I thought that was bddebian
<ajmitch> nah
* LaserJock thinks we need some sort of ccache for crimsun's brain
<LaserJock> distributed uber-MOTUism
<crimsun> you'll end up with a -lot- of md5 collisions.
<somerville32> Do I use dh_install if the makefile installs the files anyhow?
<LaserJock> no
<somerville32> kk
<somerville32> I think I've finally figured this out :] 
* somerville32 builds his packages with his fingers crossed.
<LaserJock> crimsun: are merge/sync requests going to u-u-s too?
<Hobbsee> LaserJock: they already do
<crimsun> they should as per normal
<LaserJock> hmm, I don't see much
<crimsun> Hobbsee: were you able to added me to the bug contact email forward?
<crimsun> to add, sheesh
<LaserJock> I just wondered
<persia> Does anyone have an opinion on /usr/share/menu vs. /usr/lib/menu?
<Hobbsee> crimsun: oh yeah, was goign to.  had to experiment to see if it'd work
<Hobbsee> oh wait, no
<Hobbsee> crimsun: i can forward it to you, and not get the bugmail, if you like
<LaserJock> persia: http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.1
<persia> LaserJock: Thanks, although I'm not sure when a compliant menu file would be a binary :)
<crimsun> Hobbsee: that'd be no better than the current situation :/
<LaserJock> persia: I'm not really sure either
<Hobbsee> crimsun: sure it is - you're reading the mail feed
<crimsun> Hobbsee: bah
<Hobbsee> crimsun: done
<crimsun> ok, thanks.
<crimsun> should I file a bug against RT, then, so we can move this along more quickly?
<Hobbsee> crimsun: please do
<somerville32> Hmm...
<somerville32> It appears I'm actually installing to /debian/
<somerville32> or, err..
<somerville32> debian/
<somerville32> *debian/pyneighborhood
<somerville32> How do I get it to actually install it?
<crimsun> somerville32: rephrase, please.
* somerville32 is lost.
<ajmitch> bye all
<crimsun> cya ajmitch 
* ajmitch is out for the evening
<crimsun> somerville32: what are you trying to accomplish?
<somerville32> pyneighborhood
<somerville32> :)
<crimsun> (phone)
<somerville32> I've got three different attempts going at once
<somerville32> And I just lost of my train of thought
<somerville32> lol
<LaserJock> somerville32: it's installing to debian/pyneighborhood ?
<somerville32> LaserJock: Yeah
<somerville32> my Makefile
<LaserJock> ok, that's a good thing
<somerville32> :)
<somerville32> LaserJock: Does it install it after automagically?
<LaserJock> somerville32: well, when your building you are actually building in a subdir
<LaserJock> then once everything is in place it compresses it all up into a .deb
<somerville32> Ah
<somerville32> LaserJock: Are you busy?
<LaserJock> kinda-ish
<LaserJock> I'm at home cooking with the wife a little
<somerville32> LaserJock, Lets do a MOTU classroom session, lol. I think that if I worked through one package with someone (and they were verbose), I'd have things down pat :)
<somerville32> I'm just so frustrated with all the failed attempts I'm probably missing something simple
<joejaxx> LaserJock: how do i delete the one i already uploaded?
<joejaxx> somerville32: what are you trying to learn?
<joejaxx> :)
<somerville32> I'm trying to get packaging down
<somerville32> lol
<somerville32> But I always try it when I'm super tired
<joejaxx> lol
<somerville32> I can patch and all the stuff
<joejaxx> try it when you are well rested :)
<somerville32> It is building a package from scratch
* somerville32 nods.
<somerville32> I understand most of it
<somerville32> but the issue is actually installing the files, lol
<joejaxx> lol
<somerville32> and all the weird dh_ scripts
<joejaxx> ah
<somerville32> :D
<joejaxx> oh ok
<joejaxx> :)
<joejaxx> somerville32: too bad there is not a ddel
<joejaxx> lol
<LaserJock> joejaxx: it's automatically overwritten
<LaserJock> somerville32: well for dh_* they usually have pretty good man pages
<somerville32> LaserJock: They aren't too bad :] 
<LaserJock> I recommend going through your whole debian/rules and reading the man page for each dh_
<joejaxx> LaserJock: just found that out i reuploaded them
<joejaxx> when*
<joejaxx> :)
<joejaxx> i thought you might have had to delete them some kind of way
<LaserJock> nope
<LaserJock> REVU separates by time
<LaserJock> that's why you can upload the same version
<joejaxx> that is a nice feature:)
<LaserJock> somerville32: ok, so you're having problems with file installation?
<somerville32> LaserJock: Yeah, I see how I can fix it but it doesn't seem... logical
<LaserJock> ok, so it's help to think about the build process
<LaserJock> how does a .deb get built?
<somerville32> Magic? :)
<LaserJock> and how does it get installed?
<crimsun> the great motuaholic deems it so, and It Is So.
<LaserJock> hmm, not encouraging answers ;-)
<crimsun> we bow before your infinite motuness.
<joejaxx> LOL
<somerville32> :] 
<somerville32> I'm going to get a glass of Orange juice and then we can plow through this thing :)
<Hobbsee|NotHere> crimsun: haha
* somerville32 pours a glass of Orange juice for LaserJock and himself.
<somerville32> Lets start from the start (to make sure I got everything right)
<somerville32> We visit http://sourceforge.net/projects/pyneighborhood/ to download the latest version (which is 0.4)
<somerville32> We wait a few minutes for SourceForge.net to give us the file since it is so slow
* somerville32 downloads from the OSDN mirror.
<somerville32> Direct link: http://superb-west.dl.sourceforge.net/sourceforge/pyneighborhood/pyNeighborhood-0.4.tar.gz
* somerville32 closes the sourceforge.net tab quickly before it takes down him system with resource intensive JavaScripts.
<somerville32> So, I create a folder to work in
<somerville32> I then decompress the gzip and untar then then recompress with gzip
<somerville32> This produces the directory pyNeighborhood-0.4
<somerville32> Which I rename to pyneighborhood-0.4 to meet package naming requirements
* somerville32 takes a sip of orange juice.
<LaserJock> and then I tar'd it back up to pyneighborhood_0.4.orig.tar.gz
<somerville32> I use dh_make
* somerville32 enters the directory.
<somerville32> dh_make -c gpl -e cody-somerville@ubuntu.com -f ../*.gz
<LaserJock> k, I'm with you
<somerville32> Should I use cdbs or just use single binary?
<LaserJock> I did single binary
<somerville32> Ok, so we've set it up and now it is time to start editing our debian files :)
<LaserJock> if you're having problems understanding how the building works, abstracting it away to CDBS isn't going to help you learn, IMO
* somerville32 nods.
<somerville32> I've been using single so far
* somerville32 enters debian/
<somerville32> First, the easy stuff
<somerville32> Modify changelog
<somerville32> Change version to 0.4-0ubuntu1
<crimsun> anyone running dapper amd64?
<somerville32> unstable -> feisty
<somerville32> Change comments to just "* Initial release"
<somerville32> Save
<somerville32> rm cron.d.ex emacs* init.d.ex manpage* post* pre* pyneighborhood-default.ex *.EX
<somerville32> removed `cron.d.ex', removed `emacsen-install.ex', removed `emacsen-remove.ex', removed `emacsen-startup.ex', removed `init.d.ex', removed `manpage.1.ex', removed `manpage.sgml.ex', removed `manpage.xml.ex', removed `postinst.ex',removed `postrm.ex', removed `preinst.ex', removed `prerm.ex', removed `pyneighborhood-default.ex', removed `pyneighborhood.doc-base.EX'
<LaserJock> k
<LaserJock> somerville32: now what?
<somerville32> Modify the rules file
<somerville32> Umm... this is going to get tricky to rely everything I do back to here
<somerville32> What about a gobby session?
<crimsun> server?
<LaserJock> it's all python, right
<LaserJock> ?
<somerville32> The package?
<somerville32> The package is completely
<somerville32> err..
<somerville32> The program is programmed in Python, yes
<LaserJock> is the canonical gobby server still up?
<somerville32> Not sure
<somerville32> I can try setting up a sobby server
<LaserJock> yep, gobby.u.c
<crimsun> standard port?
<LaserJock> yep
<somerville32> gobby.ubuntu.com 6523 ?
<LaserJock> that or 6522, I can't remember
<LaserJock> it's 22
<somerville32> 6522
<ajmitch_> yay
<ajmitch_> only took 2 days to get DSL back at home
<LaserJock> \o/
<Fujitsu> keescook, what do you think about the vnc4 regression?
<keescook> Fujitsu: I'm not sure how to debug it; it's an ugly side-effect of it getting recompiled against edgy libraries.  :(
<Fujitsu> Looks like it.
<Fujitsu> There's no way we can migrate the Dapper binaries over?
<Fujitsu> (like the way they got into Edgy in the first place)
<somerville32> :)
<somerville32> gobby.ubuntu.com :)
<somerville32> Who wants to come help me? :)
<somerville32> lol
<siretart> morning
<siretart> Hobbsee|NotHere: hm. try via email perhaps?
<ajmitch_> hi siretart 
<siretart> huhu ajmitch_ 
<somerville32> Ok, I'm confused again.
<somerville32> lol
<somerville32> My makefile will install it to debian/prefix/blah
<somerville32> So...
<somerville32> my debian/install file..
<somerville32> Do I refer to the files as if they are in debian/prefix/blah/etc.
<somerville32> or do I just do it relative to package root?
<persia> somerville32: I use relative to the package root as the source location, and a shorthand (e.g. "usr/share/pixmaps") for the target location.  Note that only files that are not installed properly by the normal build process need to be included in debian/install
<somerville32> How do I know if they are installed correctly or not?
<somerville32> persia: Can you spare a few minutes to give me a hand?
<persia> somerville32: I think the easiest way is to inspect the resulting deb (after dpkg-buildpackage) manually, but others inspect the actual buld tree.
<somerville32> persia: Do you have gobby installed
<persia> somerville32: sure.
<somerville32> +?
<persia> somerville32: Now I do, but I have never used it.
<somerville32> Ok
<somerville32> Join gobby.ubuntu.com
<somerville32> :] 
<dholbach> good morning
<Lutin>  'morning dholbach
<dholbach> heya Lutin
<ajmitch_> hi daniel
<somerville32> dholbach, I need your help :)
<dholbach> hey andrew
<dholbach> hey somerville32 - fire away
<somerville32> dholbach, Do you have gobby installed? :] 
<dholbach> yes
<somerville32> Can you come take a peak at gobby.ubuntu.com?
* somerville32 sighs.
<somerville32> ${python:Depends} still isn't being replaced.
* somerville32 is so freaking close to get this package right that isn't even funny :] 
<somerville32> persia: IT didn't install my man page
<somerville32> persia, Is this when I use install? :] 
<somerville32> oh wait
<somerville32> I see what I may have done wrong
<somerville32> Is this an acceptable error?:
<somerville32> E: pyneighborhood: menu-icon-not-in-xpm-format /usr/share/pyNeighborhood/icons/pyneighborhood_48x48.png
<somerville32> What does this error mean?
<somerville32> E: pyneighborhood source: package-needs-python-policy-debhelper
<persia> somerville32: The common workaround for that error is to create debian/pyneighborhood.xpm, and install it in /usr/share/pixmaps (with debian/install).  Menuing systems that use .desktop files will select the .png as the preferred format, and debian menu-based systems will use the .xpm.
<somerville32> How do I make a .xpm?
<persia> somerville32: execute `convert wherever/pyneighberhood_48x48.pgn debian/pyneighborhood.xpm`
* persia s/pgn/png/
<somerville32> So I'll need to use install to install the .xpm icon
* somerville32 is starting to get the hang of this :)
<persia> somerville32: Yes.  debian/install is for all the miscellaneous files that don't get installed in the build.
<somerville32> Ok
<somerville32> :)
<somerville32> I'm so close I can taste it
<somerville32> persia: ping
<somerville32> E: pyneighborhood; Manual page pyneighborhood.8 is not compressed.
<somerville32> E: pyneighborhood; Manual page /usr/share/man/man8/pyneighborhood.8 is not compressed with max compression.
<somerville32> E: pyneighborhood; Manual page /usr/share/man/man8/pyneighborhood.8 is not compressed using gzip.
<somerville32> E: pyneighborhood; No manual page for binary pyNeighborhood.
<persia> somerville32: Are you installing the binary in sbin?  Usually, section 1 is used for even administrative commands in bin, as these are available to normal users.
<somerville32> no
<somerville32> I'm installing it to /usr/bin
<persia> somerville32: Is your package somewhere I can download it?
<somerville32> I'll upload right now
<somerville32> Ok
<somerville32> uploaded to revu
* somerville32 twiddles thumbs for it to appear.
<somerville32> persia: 
<somerville32> http://revu.tauware.de/details.py?upid=3991
<persia> somerville32: First thing I notice is that you want to put the .xpm file in usr/share/pixmaps (and adjust the menu file)
<somerville32> ok
<somerville32> for png one too? (I'd have to patch upstream)
<persia> somerville32: the png should definitely be in usr/share/pixmaps.  When upstream puts it somewhere else, I usually just copy it with an extra line in debian/install.  You'd also need a patch to change the .desktop (Icon=pyneighborhood_48x48)
<somerville32> Would the patch start with a 20 now?
<persia> somerville32: dh_python is deprecated.  As you are using dh_pysupport, this can be removed.
<somerville32> persia: k
<persia> somerville32: 20 is a fine number (anything larger than 10 is good).
<somerville32> What should I call it?
<somerville32> Are there any conventions?
<persia> somerville32: I usually call them something like desktop-file-update, I don't know of a convention.
<somerville32> Do, I can just change Icon=pyneighborhood_48x48.png
<somerville32> Or leave out the file extension?
<persia> somerville32: You don't need the .png (it is actually deprecated).  This lets themes use SVG (or whatever) if they prefer.
<somerville32> ok
<somerville32> done
<persia> somerville32: You probably want to rename then manpage to use the mixed capitalisation used for the binary
* somerville32 nods
<somerville32> done
<persia> somerville32: Adding dh_compress should solve a few of the warnings
<somerville32> Does it matter where in the chain of dh_* scripts?
<persia> somerville32: After dh_installman should be fine
<persia> somerville32: My apologies, but I have no idea about W: pyneighborhood: description-synopsis-might-not-be-phrased-properly
<somerville32> Hmm
<somerville32> haha!
<somerville32> I think I figured out my dependency issue
<somerville32> I install to /usr/share/pyNeighborhood
<somerville32> and the package is pyneighborhood
<somerville32> So it would look for it in pyneighborhood
<somerville32> haha
* somerville32 builds to see if he is right.
* somerville32 wonders if imbrandon got pbuilder setup yet
<somerville32> Yes!
* somerville32 cheers.
* somerville32 dances.
<somerville32> :D
<somerville32> I figured it out.
<somerville32> After weeks of hacking... I have finally figured it out!
<somerville32> :D
<somerville32> Someone give me a hug
* persia hugs somerville32
<somerville32> :D
<somerville32> E: pyneighborhood: menu-icon-too-big /usr/share/pixmaps/pyneighborhood_48x48.xpm: 48x48 > 32x32
<somerville32> Is there an easy way to make it smaller?
<persia> somerville32: I use GIMP - for a change like that (48->32), you may need to adjust the bits manually to make sure it still looks good afterwards, as 3/4 pixels tend not to be so clear.
<somerville32> ...
<somerville32> I have to be an artist too? :S
<Fujitsu> This is why SVG is good.
<somerville32> What are my options?
<persia> Fujitsu: It doesn't help for debian menu files (which require 32x32 .xpm files, but generally, yet.
<Fujitsu> True.
<persia> somerville32: If you load the image into Gimp, there is a "Scale Image" entry in the "Image" menu.  If you aren't too concerned with the final result, just save the result of this operation as the .xpm file.  You can script it, but my gimp-fu isn't up to that.
<somerville32> done :] 
<somerville32> As for the phrase issue
<somerville32> I think it is because I have a period at the end
<somerville32> Is this permissible? W: pyneighborhood: menu-command-not-in-package /usr/share/menu/pyneighborhood:3 gksudo
<somerville32> persia, Are you a MOTU?
<persia> somerville32: No.  I just write patches.
<lifeless> somerville32: what do you mean permissible ?
<somerville32> lifeless: Would a MOTU advocate with that warning present?
<lifeless> if your package is correct, then sure, whynot.
<lifeless> but if the package is correct, and nothing is wrong, override the warning
* somerville32 nods.
<persia> somerville32: http://huygens.ca.infn.it/cgi-bin/dwww?type=file&location=/usr/share/doc/lintian/lintian.html/ch2.html#s2.4 explains how
<somerville32> Thanks
<persia> somerville32: I can confirm the phrase issue was due to the period.  It should be removed.
<somerville32> schweet :)
<somerville32> I think I've packaged my first package successfully
* somerville32 hugs persia.
<somerville32> lifeless: Would you be able to do a quick review in a few minutes? I'm pretty sure the package is ready for advocating. :)
<lifeless> nope, sorry.
<lifeless> in meetings
<somerville32> kk
<somerville32> Does anyone know the new address for imbrandon's box?
* somerville32 founds it.
<crimsun> 56161 uploaded.
<somerville32> Is that my SRU?
<somerville32> Yes
<somerville32> Thanks Crimsun :)
<crimsun> somerville32: in the future, please append a number to proposed
<somerville32> What do you mean?
<somerville32> oh
<somerville32> Right
<somerville32> I read "append" and "send"
<somerville32> *as
<somerville32> crimsun: I'm just rebuilding my package. After I'm done, do you think you could review it for me? I think it is ready for advocating. :)
<crimsun> sure. I'll be in and out for the next hour or so.
<somerville32> Do you know whats up with imbrandon's build box?
<somerville32> It times out when I try to connect
<somerville32> and building the package takes like 5-6 minutes each time, lol - luckily this is a quick package to build.
<somerville32> Btw, when do we change the urgency on the changelog? What does it do?
<persia> somerville32: For Ubuntu it is almost never used.  For Debian, it controls what criteria must be met before the package can move from unstable to testing.
<somerville32> k
<somerville32> Alright!
<somerville32> No more lintian errors
<somerville32> Time to upload to revu :] 
<somerville32> crimsun: http://revu.tauware.de/details.py?upid=3993
<persia> somerville32: Just a note: you probably want to delete the 48x48 xpm, as it is not used.
<\sh> happy new year and moins :)
<persia> \sh: Happy new year
<crimsun> somerville32: what is ./usr/share/python-support/pynei
<crimsun> ghborhood.dirs
<crippledcanary> could I please, please have anyone to look at http://revu.tauware.de/details.py?upid=3772
<crimsun> crippledcanary: what's the deal with: -rwxr-xr-x root/root      1286 2007-01-08 03:06 ./usr/bin/.scribesclient    
<crimsun> i.e., why is it hidden?
<crimsun> crippledcanary: also, you need to b-d on python-support and use the Debian Python policy
<crimsun> (which means you need python-all and python-all-dev as b-d, too)
<crimsun> or just python-all-dev and python-support
<crimsun> then you need to adjust scribes's Depends
<crippledcanary> crimsun: I will fix the b-d and contact upstream about .scribesclient
<pef> hello
<crippledcanary> crimsun: if I add python-all, can I remove b-d on python then?
<crimsun> crippledcanary: if you b-d on python-all-dev, you don't need python or python-all listed
<crippledcanary> crimsun: should depends also point to python-all
<crimsun> crippledcanary: no, python-all-dev depends on python-all
<crippledcanary> yes -dev for b-d but shuld I use pyton-all for "d"
<crimsun> crippledcanary: you should use ${python:Depends}
* StevenK shakes a fist at crimsun for being far too fast. :-)
<StevenK> crimsun: Give us idiots a chance to answer. :-P
<crimsun> kk O:-)
* StevenK grins
<fernando> moin all
<Hobbsee> StevenK: now you'll be pressured into doing all the dirty work...
<Hobbsee> hey fernando 
<bhale> yay Hobbsee 
<fernando> hey Hobbsee 
<Hobbsee> hey bhale :)
<crippledcanary> So if I use ${python:Depens} in d then all dependencies is grabbed from b-d?
<StevenK> Hobbsee: What else is new? :-P
<Hobbsee> StevenK: heh.
<persia> Hobbsee: Thanks for adjusting the u-u-s list earlier
<Hobbsee> persia: :)
<Hobbsee> persia: adjusting it?
<persia> Hobbsee: As previously noted, crimsun is indeed addicted to bugmail (thanks crimsun)
<Hobbsee> persia: ahh :)
<Hobbsee> persia: yes
<Hobbsee> it's a little weird not seeing it in my inbox :P
* Hobbsee has gmail archive the copy
<Hobbsee> apparently you cant forward to two addresses in gmail.  shame
<somerville32> Hobbsee, http://revu.tauware.de/details.py?upid=3993 ? Please :)
* Hobbsee so isnt reviewing anything
* somerville32 offers cookies.
<Hobbsee> somerville32: ask StevenK 
* Hobbsee ducks
<StevenK> Grrr!
* Hobbsee runs away quickly
<Hobbsee> the mighty StevenK monster has woken up!  argh!
<StevenK> :-P
<crimsun> somerville32: did you fix the issue I asked about?
<crimsun> (no response is a review-killer)
<palski> is "Nominate for Release" used for ubuntu packages?
<Fujitsu> palski, yes.
<palski> Fujitsu: Since there are no release managers for ubuntu who is accepting nominations?
<Fujitsu> palski, ubuntu-core-dev members can accept them.
<Fujitsu> Which is rather annoying.
<dholbach> palski: there are release managers
<dholbach> Fujitsu: core-dev members can do what?
<palski> lp says: "There is no release manager for Ubuntu" =)
<Fujitsu> dholbach, accept release nominations.
<Fujitsu> More stupid LP-imposed bottlenecks.
<Fujitsu> Only the drivers of a distribution can accept them.
<dholbach> palski: there's the ubuntu-release team
<siretart> what does the nomination for release do?
<dholbach> Fujitsu: Where does it say the process works like that?
<Fujitsu> dholbach, in the code. It was discovered through practice.
<dholbach> aha
<Fujitsu> They say they'll look at it `post-1.0'
<Fujitsu> It is quite an inconvenience.
<siretart> Fujitsu: what's the deal with the 'Nominate for release' links?
<Hobbsee> hey siretart :)
<Fujitsu> siretart, what about them?
<siretart> huhu Hobbsee 
<siretart> Fujitsu: what are they for?
<Fujitsu> Anybody can nominate, but only core-dev can accept them.
<siretart> Hobbsee: you pinged me earlier?
<\sh> new wine is on its way...
<Fujitsu> They supersede the `Backport fix to releases' link.
<Hobbsee> siretart: yep.  laserjock suggested it, can we get a mailing list for ubuntu-universe-sponsors on tiber please?
<Hobbsee> \sh: yay :)
<siretart> okay, but when should I click on the link? when to nominate?
<siretart> Hobbsee: sure. do you want to admin it?
<Hobbsee> siretart: you'd you tell me what i need to do in terms of adminning....
<Fujitsu> siretart, it's for requesting fixes in stable releases, basically. Just adding a task for that distrorelease.
<Hobbsee> s/you/ have to/
<Hobbsee> siretart: i've never admined a list before - as long as it's not too difficult, then yeah, that's fine
<Fujitsu> Hobbsee, that regexp won't work!
<siretart> Hobbsee: no, its standard mailman and completely web driven
<Hobbsee> siretart: right
<Hobbsee> Fujitsu: no, probably wouldnt :P
<StevenK> s/you /have to /
<StevenK> Would, though
<Fujitsu> StevenK, yep.
<siretart> Hobbsee: btw, on tiber, there is no mailman installed. I'm setting one up on freiburg.tauware.de (my private vserver)
<StevenK> Fujitsu: You don't have to tell me, I know. :-)
<Fujitsu> StevenK, of course! You are one of the deities around here.
<StevenK> siretart: If you want to add me as a list-admin, I'm happy to be one.
* StevenK is no deity.
<Fujitsu> tiber is another Canonical ServerPronto box, isn't it?
<Hobbsee> siretart: cool :)
<Hobbsee> StevenK: sure you are - you're a DD
<StevenK> Just being a DD doesn't make me a deity.
<Fujitsu> StevenK, why not?
* StevenK shrugs.
<siretart> Hobbsee: you should have mail with an initial password now
<StevenK> Just because I have a account on a bunch of machines doesn't make me any more or less special than any of you guys.
<siretart> StevenK: do you happen to know if mailman supports multiple list-admins?
<siretart> Fujitsu: right
<StevenK> I think it does.
<siretart> hmm
<StevenK> Oh, it does
* StevenK just remembered the lists.u.c setup
<siretart> ah, yes I found it
<siretart> stevenk@ubuntu.com?
<StevenK> Sounds fine
<siretart> Hobbsee: StevenK and you are now listadmins. please pass StevenK the list password after you got/changed it
<siretart> have fun! :)
<StevenK> We'll be sure to tell you when we've broken it.
* StevenK ducks.
<siretart> :)
<StevenK> :-)
<Hobbsee> siretart: coo, sure
<Hobbsee> haha
<Hobbsee> siretart: thanks for that
<crimsun> rock
<geser> Hobbsee: where to subscribe to the u-u-s ml?
<Hobbsee> yay, kde
<siretart> geser: http://lists.tauware.de/listinfo/ubuntu-universe-sponsors
<siretart> geser: but let Hobbsee first do the initial configuration for the list
<geser> ok
<Hobbsee> hehe
<Hobbsee> i have to figure *how* to
<siretart> Hobbsee: slammed by mailman ;)
<Hobbsee> siretart: sorry?
<siretart> Hobbsee: I mean overwhelmed by the thousand of options you can set in the admin interface
<Hobbsee> siretart: ah, yes :)
<cypherbios> Hey people, 0.1~beta1+svn20070108-0ubuntu1 is an good number version? Or is wrong/too long??
<cypherbios> s/number version/version number/
<geser> looks ok to me
<cypherbios> geser: thanks :)
<persia> cypherbios: I'd recommend avoiding ~ unless you really need it: it breaks word selection in GNOME Terminal.
<cypherbios> persia: hmm... but if I wont use this '~' the version number will break, won't?
<persia> cypherbios: If it's a svn pull, I'd use 0.1+svn20070108-0ubuntu1, as it likely doesn't match a released beta.  If it's a released beta, you would do as well with 0.1+beta1.   As + is less than all the numbers, you shouldn't have any issues later, even if 0.11 is released.
<geser> it depends on the next released version
<cypherbios> persia: humm, make sense. So I think that 0.1+svn20070108-0ubuntu1 is more sane in this case, what you think?
<geser> cypherbios: will the next released version be 0.1 or 0.2?
<cypherbios> geser: probably will not have an new beta, the next upstream release will be 0.1
<persia> cypherbios: That sounds fine to me.
<cypherbios> geser: s/not have/haven't/
<persia> cypherbios: If this is pre-0.1, you might want 0.0+svn... instead.
<geser> cypherbios: 0.1 < 0.1+svn20070108
<cypherbios> geser: 0.1~beta1+svn20070108 < 0.1 ?
<enyc> There seems to be a problem (or many-day-delay) with upload -- https://launchpad.net/ubuntu/+source/qpsmtpd/+bug/78005 -- Version: 0.31.1-4ubuntu0.1~proposed1   has not appeared in the archive
<Ubugtu> Malone bug 78005 in qpsmtpd "[SRU]  request: dapper:qpsmtpd fix for bug #72602" [Undecided,Unconfirmed]  
<geser> cypherbios: dpkg --compare-versions 0.1~beta1+svn20070108 \< 0.1 && echo "yes"
<Hobbsee> geser: you can subscribe now, i think
<Hobbsee> siretart: email would have been fine, btw, or queried my |nothere, client :)
<Hobbsee> siretart: or just wait for me online again :P
<enyc> crimsun: see abevoe note, your upload appears to have not ggone trough
<enyc> crimsun: aha... I have no w subscribed the archive admins... forgot that! lol
<persia> Hobbsee: My message to Ubuntu-universe-sponsors awaits moderator approval.  Should I join the list to submit bugs there, or are you willing to accept spam?
<Hobbsee> persia: um....
<Hobbsee> persia: is that just your change on LP?
<persia> Hobbsee: LP generated mail from me based on a change to the list.  The list bounced to me because it is members-only.
<Hobbsee> persia: yes....that was supposed to be fixed...
* Hobbsee pokes StevenK 
<geser> Hobbsee: "You have successfully confirmed your subscription request to the mailing list Ubuntu-universe-sponsors, however final approval is required from the list moderator before you will be subscribed. Your request has been forwarded to the list moderator, and you will be notified of the moderator's decision."
<Hobbsee> geser: done
<geser> thanks
<StevenK> Hobbsee: Hrm?
<Hobbsee> StevenK: persia's comments
<persia> StevenK: LP is sending mail (as me) to U-U-S, and I receive a notice that it awaits moderator approval.
<StevenK> persia: Approved.
<persia> StevenK: Thanks, but my worry is that U-U-S will not receive new patches without extra effort.  That's fine for you and Hobbsee, but geser won't see the patches until one of you approves the message (or am I missing something)
<Hobbsee> persia: explanation:  "hobbsee hasnt touched mailman before, this is still a work in progress"
<geser> persia: I still can look them up in LP
<persia> geser: Yes, but that's no different than from when Hobbsee was the only bug contact.  I say this because I've seen significant improvement in U-U-S processing since mail was distributed to additional people.
* Hobbsee is getting there...
<persia> Hobbsee: No worries: I'm just reporting my experience.
<Hobbsee> right.  we're ignoring it till later.
* Hobbsee is an aussie!
<Guard] [an> hello
<Guard] [an> i'm new to building debian packages: let say i have an application that uses autotools, in a directory like myapp/ myapp/src myapp/data etc... would it be possible to generate multiple debian packages out of this ? like 1 package for the core application, and several packages for data/plugins ?
<Guard] [an> or do i need to have one directory and 1 build script per plugin ?
<geser> you can build several packages from one source
<geser> you have to say which files belong to which package
<persia> Guard] [an: It's possible, but note that building multiple packages from a single source is significantly more complicated than a one-to-one relationship.  You will need to configure your Makefiles to install to separate directories (or tour debian/ directory will be hard to maintain)
<Guard] [an> then i guess i need to read the maintainer guide again :)
<crimsun> enyc: I subbed u-a on Jan 6
<crimsun> enyc: it has to be approved by u-a before it will be synced out to the mirrors
<crimsun> enyc: that approval has yet to occur
<Guard] [an> well i guess the 1 source for multiple packages pattern applies since most of the stuff additional packages have to install will end in /usr/share/myapp/plugins/
<crimsun> siretart: / Hobbsee: cheers for the u-u-s list migration
<Hobbsee> crimsun: i subscribed you to the u-u-s list, it's a WIP
<persia> Guard] [an: Do any of the plugins conflict, would they be used by other packages, or are they really large (so the user doesn't want them all installed)?  It might be easiest just to install all the plugins.
<crimsun> Hobbsee: seems to work well; got persia's latest change to 47299
<Hobbsee> crimsun: cool.  that was manually approved
<crimsun> oh, going through moderation?
<Hobbsee> at the moment
<persia> crimsun: It's Tuesday for most of Australia :)
<Guard] [an> persia: it's very large so the user don't want them all, and it's really specific to my test application
<Hobbsee> crimsun: right now, it's about 1am.  with two aussies, we'll deal with it in the morning :P
<crimsun> persia: we have two different patches in 47299
<persia> crimsun: neutrinomass's patch is only for the .desktop file.  Mine is a debdiff including that (and the Encoding line).
<crimsun> persia: the Categories don't match
<persia> crimsun: "Application" doesn't validate
<geser> slomo: Hello, I'm looking at the merge of libsexymm 0.1.9-2. The only remaining change is the bump of build-depends libsexy-dev from >= 0.1.7 to >= 0.1.9. Merge or sync?
* crimsun pokes persia with a distribution stick of doom
* persia reels
<persia> crimsun: Umm..  What?
<crimsun> persia: s/edgy/feisty/
<persia> crimsun: OOps.  Which?
<crimsun> cupsys-pt. Fixed and uploaded.
<persia> crimsun:  Thanks.  Sorry about that.
* persia wishes there were faster SPARCs in the buildd pool
<enyc> crimsun: Oh I see, it needs another +1  (bug 78005)...
<Ubugtu> Malone bug 78005 in qpsmtpd "[SRU]  request: dapper:qpsmtpd fix for bug #72602" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78005
<crimsun> enyc: no it doesn't, it has 3
<crimsun> enyc: it has already been uploaded; it just has to be accepted by u-a
<crimsun> enyc: note the accepted: http://adhd.irule.net/~crimsun/Screenshot.png
<xopher-> Hi! Anyone have the time to check this out, Im sure its something trivial.. Having problems with prevu: http://rafb.net/p/yoSGGC52.html
<Hobbsee> xopher-: bug jdong about prevu-crack
<xopher-> You're not interested ? :P
<Hobbsee> not overly.  more to the point of "he knows the code, none of us do"
<xopher-> Anyway, should probably update prevu anyway, using some ancient version, could be fixed in a later version
<xopher-> That's a good pointer
<Hobbsee> ...
<Hobbsee> of *course* you should be using the latest version, before coming to ask about error messages
<Hobbsee> for bug fix releases, anyway
<crimsun> but I -like- using known-broken versions.
<crimsun> you know, and then I won't mention that I know it's known-broken.
<Hobbsee> crimsun: :P
<Hobbsee> crimsun: and you'll ask it of people who have never used it anyway?
<xopher-> Hobbsee I was. Just wasn't 100.001% sure of it at the time, update could come any minute
<bddebian> Heya gang
<Hobbsee> heya
<Lutin> heya bddebian
<bddebian> Hi Hobbsee, Lutin
<Hobbsee> OK, bedtime for me
<bddebian> Gnight
<Lutin> bddebian: could have a look to gfaim please ? =)
<siretart> Hobbsee|NotHere: sorry?
<cypherbios> geser: ping
<geser> cypherbios: pong
<bddebian> Lutin: Yeah, give me a bit
<cypherbios> geser: Lintian says: "E: packagename: bad-version-number 0.1~beta1+svn20070108-0ubuntu1"
<cypherbios> geser: it's normal?
<Lutin> bddebian: ok, np :)
<geser> cypherbios: sorry, I don't know. perhaps somebody else can answer this
<cypherbios> geser: is about the package that we are talking about 1 hour ago, remember?
<cypherbios> geser: btw, np :)
<geser> yes, but I don't know if lintian is right
<geser> Lutin: 01_gfaim.patch is leaking memory
<cypherbios> someone knows if 0.1~beta1+svn20070108-0ubuntu1 is really an bad-version-number?
<Lutin> geser: did I forget to free something ?
<bddebian> cypherbios: What does lintian -i say?
<persia> cypherbios: According to http://www.debian.org/doc/debian-policy/ch-controlfields.html, only alphanumeric and . + - : are allowed (no ~)
<geser> Lutin: you free only if loc != NULL
<cypherbios> bddebian: E: packagename source: bad-version-number 0.1~beta1+svn20070108-0ubuntu1
<cypherbios> persia: hmm, but I need to do something to 0.1~beta1+svn... be less than 0.1-0ubuntu1
<Lutin> geser: and whar is the pint to free something NULL ?
<Lutin> what's the point*
<xopher-> cypherbios if it's only for your own purposes, itll still work just fine, and be a lesser version. so why not use it. no one is perfect anyway
<Lutin> geser: forget what I just said :)
<persia> cypherbios: How about 0.0+svn20070108-0ubuntu1 (you previously indicated it was neither a 0.1 or beta1 release).
<xopher-> or 0.0.99+, which would be closer to the 1.0
<xopher-> s/1.0/0.1
<cypherbios> xopher-, persia: hm, could be. There is no problem with 0.0.99+svn20070108-0ubuntu1 so?
<persia> cypherbios: Personally, I prefer to avoid +, but it's commonly used for cvs/svn indicators, and that version is definitely < 0.1.
<cypherbios> persia: thanks, will be 0.0.99+... so :)
<cypherbios> bddebian: what you think about it?
<bddebian> I see ~ used a lot these days so I dunno, sorry :-(
* proppy hugs dholbach
<Lutin> bddebian, geser: ok, fixed now
<dholbach> hiya proppy
<persia> How does one request a retry of a build?
<slomo> geser: sync
<geser> persia: a failed build?
<persia> geser: Yes  Rapidsvn failed to build 2006-12-15, due to an insufficient version of libsvn.  This has been fixed, and it should build now (it certainly builds locally for me).  I can generate a patch for a new version (with useful changes) if that is easier, but a rebuild fixes 90% of the known issue.
<bddebian> Just do a -Xbuild1 push
<persia> bddebian: Nah - if a new upload is required, I'd rather fix the other 10%.  I thought there might be a magic button in LP that would retry the build.
<geser> persia: ask Mithrandir in #ubuntu-devel to give-back rapidsvn
<persia> geser: Thanks.
<cypherbios> bddebian: please, see if still +1 for you, if not leave some comments.
* cypherbios loves comments ;)
<cypherbios> bddebian: http://revu.tauware.de/details.py?upid=3996
<bddebian> Lutin: What is the purpose behind debian/legal.txt?
<persia> cypherbios: If you are installing a .desktop, you need dh_desktop in order to refresh the user's active menus after the install.
<cypherbios> persia: the Makefile does this, at make-time
<persia> cypherbios: dh_desktop does postinst/postrm changes.  Your Makefile shouldn't.
<cypherbios> persia: hmm...
<cypherbios> persia: so, how can I do it?
<persia> cypherbios: Add dh_desktop after dh_installman in debian/rules
<cypherbios> persia: just it? or I need to do something else to dh_desktop recognise the .desktop file?
<Lutin> bddebian: the very important prpose to show you that I'm kind of stupid =)
<bddebian> Lutin: No, that's OK, I am just asking :-)
<Lutin> bddebian: forgot to remove it
<persia> cypherbios: Just that.  dh_desktop will change the postinst to call update_menus, which will then read the .desktop installed by the Makefile into the current session.
<cypherbios> persia: so I keep the installation done by Makefile also, right?
<bddebian> Lutin: No worries
<persia> cypherbios: Yes.  Only add the one line.
<cypherbios> persia: I got it, updating...
<cypherbios> persia: tnx
<cypherbios> persia: done ;)
<Lutin> bddebian: ping ?
<bddebian> Yo
<Lutin> bddebian: imprec is a little wrapper script internally used by gfaim for printing
<Lutin> do I really need to add a manpage for it ?
<bddebian> Hmm
<cypher1> arghh.. Proxy error (some upstream server error) when adding comments to launchpad.. does anyone else facing the same problem
<Lutin> bddebian: ?
<bddebian> Lutin: Hmm == I don't really know for sure :-)
<Lutin> bddebian: ah ok :)
<Lutin> bddebian: is there someone I could bug about that ?
<cypher1> geser, i was looking at the genpower build failure
<Nafallo> !info wlassistant
<ubotu> wlassistant: User friendly KDE frontend for wireless network connection. In component main, is optional. Version 0.5.5-0ubuntu3.2 (edgy), package size 115 kB, installed size 572 kB
<somerville32> Can anyone please review? http://revu.tauware.de/details.py?upid=3993
<LaserJock> oh man
<LaserJock> the inventor of Ramen noodles died Saturday
<bddebian> Heya LaserJock
<LaserJock> hi bddebian 
<ajmitch> hi LaserJock 
<bddebian> ajmitch!!
<Nafallo> !info network-manager-gnome
<ubotu> network-manager-gnome: network management framework (GNOME frontend). In component main, is optional. Version 0.6.3-2ubuntu6 (edgy), package size 245 kB, installed size 1608 kB
<giskard> Nafallo, prr ;)
<somerville32> Hi LaserJock
<somerville32> LaserJock: I figured out all my issues :)
<dholbach> somerville32: lucky you ;-)
<Nafallo> giskard: hi mate :-)
<somerville32> dh_pysupport looks at several different locations *based* on the package name.
<Nafallo> giskard: you don't happen to have nm-svn packaged somewhere? :-)
<somerville32> The program's name is pyNeighborhood
<somerville32> So it installs to /usr/share/pyNeighborhood
<bddebian> somerville32: reviewed
<somerville32> However, the package name "pyNeighborhood" violates policy so is made to become "pyneighborhood".
<giskard> Nafallo, no :( do you want it?
<somerville32> So what I had to do was pass /usr/share/pyNeighborhood to py_support to make it looks there instead of /usr/share/pyneighborhood
<somerville32> lol
<LaserJock> somerville32: ahh, I see
<somerville32> So simple yet I've been pulling my hair out for the last two weeks! :D
<Nafallo> giskard: I was thinking about it. but I think the proper fix to my problem would be to use rt2x00 instead of rt2500 legacy driver. wext is fun to have I've heard ;-)
<somerville32> bddebian, thanks :)
<somerville32> Woot! One advocacy! :D
* somerville32 hugs bddebian
<somerville32> LaserJock: Would you have time for a quick review? :)
<zul> hey LaserJock 
<LaserJock> somerville32: perhaps, what's the URL
<LaserJock> hi zul 
<somerville32> http://revu.tauware.de/details.py?upid=3993
* LaserJock does his morning feisty pbuilder updates
<LaserJock> and registers for Spring 2007 :/
<LaserJock> hmm, so this is my 17th semester in a row
<LaserJock> how pathetic
<zorglu_> semester = 6month ?
<LaserJock> well, technically they are about 15 weeks
<LaserJock> but there's only 2 main ones a year
<LaserJock> fall and spring
<LaserJock> if I counted Summer it'd make me cry ;-)
<zorglu_> so it is like 8.5 years....
<zorglu_> quite a lot :)
<LaserJock> yeah :/
<zorglu_> phd at least ? :)
<LaserJock> yeah
<LaserJock> at least I better
<zorglu_> well not that bad then :)
<LaserJock> heh, my first "short" planet post :-)
<somerville32> :)
<LaserJock> somerville32: so are you liking dpatch ok?
<somerville32> I love it!
<LaserJock> somerville32: cool
<somerville32> LaserJock: Did you get a chance to review yet? : )
<LaserJock> working on it now
<somerville32> Any complaints so far?
<LaserJock> not really
<LaserJock> I personally like to stick with 3.7.2 for Standards-Version
<LaserJock> but that's no biggy
<LaserJock> somerville32: the only thing I'm not sure about is your mixing pyNeighborhood and pyneighborhood
<Adri2000> fam conflicts on gamin... so fam depencies should be replaced with gamin, right?
<somerville32> LaserJock: pyNeighborhood is the upstream name. 
<somerville32> pyneighborhood is the package name
<LaserJock> somerville32: I know
<persia> Adri2000: Most packages seem to use fam | gamin (both seem to have ongoing development)
<somerville32> LaserJock: What would be the issue?
<LaserJock> case-sensitive tab completion ;-)
<Adri2000> persia: right
<somerville32> LaserJock: I still don't see the issue. There are tons of commands that aren't all lowercase.
<LaserJock> somerville32: I just like consistency :-0
<LaserJock> :-) rather
<somerville32> LaserJock: I'll keep that in mind for the future. :)
<LaserJock> somerville32: ok, little bit of a problem
<somerville32> Oh no :(
<LaserJock> somerville32: the md5sums of the .orig.tar.gz doesn't match the md5sum of the tarball downloaded from the website
<Lutin> Toadstool: pingus
<somerville32> Is it because I did: gzip -d *; tar -xf *.tar; gzip *.tar ?
<somerville32> (to unpack)
<LaserJock> probably
<somerville32> Is it... admissible?
<LaserJock> I'd like it fixed :-)
<somerville32> Can I fix it w/o re-uploading?
<somerville32> I don't want to lose my 1 advocate, lol
<Lutin> LaserJock: if you have a minute, could you have a look at gfaim on revu and tell me if you think I really should add a manpage for imprec ?
<persia> When is the universe merge deadline again?
<Lutin> persia: 8 feb iirc
<LaserJock> somerville32: yeah, you can send me the correct .orig.tar.gz
<LaserJock> somerville32: I think there is a wiki page on how to compress them right
<somerville32> LaserJock : I think so too. I'll go read it.
<persia> Lutin: Thanks.  I was worried it was sometime this month (and looking at the list of my patches that need to be merged).
<somerville32> LaserJock: If I e-mail you the correct tarball, will you upload to universe? :)
<Adri2000> question to MOTUs: If I want to fix a bug in a package which version is (example) 0.1.2-3 in ubuntu and 0.1.3-1 in debian, can I use the debian source, fix the bug and upload that without requesting a sync first? (I think the answer is yes, just to confirm)
<persia> Adri2000: Yes, but you will want to document the merge with a merge bug, and be sure to upload as 0.1.3-1ubuntu1 (IANAM)
<Adri2000> merge? if the current version in ubuntu has no change, it's not a merge
<persia> Adri2000: Right.  I read that wrong.  Please ignore everything above except the part about the version number.
<Adri2000> :p
<crimsun> yes, you can upload 0.1.3-1ubuntu1.
<LaserJock> somerville32: yes, I will
<ajmitch> yes, you are expected to upload 0.1.3-1ubuntu1 as long as it's before UVF :)
<Adri2000> crimsun: and I should generate a .changes file with change since the 0.1.2-3 ?
<crimsun> yes.
<Adri2000> changeS since the 0.1.2-3 version, ok
<somerville32> If you upload something and the version is 0.7.0-beta3... would it be wrong if someone packages it as version 0.7.2?
<somerville32> *0.7.3
<crimsun> yes
<somerville32> Well, someone did
<somerville32> lol
<somerville32> Or I think they did atleast
<somerville32> picard 0.7.2-2ubuntu1
<somerville32>  Component: universe Section: sound on Mon,  4 Dec 2006 00:32:12 +0100 by Lukas Lalinsky <lalinsky@gmail.com> 
<somerville32>         picard     - Next-Generation MusicBrainz audio files tagger
<ajmitch> then they shouldn't have
<ajmitch> & they should be taken out the back
<somerville32> http://musicbrainz.org/news/picard.html
<somerville32> Latest release is 0.7.0 
<Adri2000> crimsun: I will apply for membership tomorrow, if you want to say something at the CC...
<somerville32> 0.7.0-Beta2 was released recently
<somerville32> or not so recently?
<Lutin> Adri2000: =)
<somerville32> ajmitch, crimsun: nvm
<somerville32> That page is old
<LaserJock> somerville32: figure out the md5sum problem?
<somerville32> Almost :] 
<Lutin> LaserJock: if you have a minute, could you have a look at gfaim on revu and tell me if you think I really should add a manpage for imprec ?
<LaserJock> Lutin: where does imprec get installed to?
<somerville32> LaserJock: What did you get for a checksum?
<LaserJock> somerville32: of the downloaded tarball?
<Lutin> LaserJock: /usr/bin
<somerville32> LaserJock: Yes.
<LaserJock> somerville32: 1cecae28bb5753f39fb0b6a9a0f5364e
<LaserJock> Lutin: it seems a little odd to do a manpage for it
<LaserJock> Lutin: "Each program, utility, and function should have an associated manual page included in the same package. It is suggested that all configuration files also have a manual page included as well. Manual pages for protocols and other auxiliary things are optional."
<Lutin> LaserJock: ok :)
<Lutin> LaserJock: just wanted to be sure
<LaserJock> Lutin: perhaps this is an "auxiliary thing" but I don't know
<Lutin> I think it is
<LaserJock> seems more like a utility
<LaserJock> but an axiliary utility
<Lutin> it's a oneline wrapper used internally for printing
<LaserJock> my only thought would be that I don't know if /usr/bin is the best place to put it if it's just internal
<Lutin> not even a utility that could be useful to someone/thing else but the program itself
<LaserJock> but whatever
<Lutin> LaserJock: where should I put it then ?
<LaserJock> I don't know :-)
<LaserJock> I think I'd probably just leave it as it is
<Lutin> ok
<somerville32> LaserJock: Link. I'm having problems connecting for some reason
<somerville32> sf.net is horribly slow now with all their resource intensive javascript
<Lutin> LaserJock: if you have some ime to review it then ... =)
<LaserJock> hehe
<LaserJock> Lutin: I'll put it on my todo list
<Lutin> LaserJock: ok, thanks :)
<somerville32> s/Link./Link?
<LaserJock> is bddebian around?
<bddebian> No :)
<LaserJock> bddebian: oh well :(
<bddebian> LaserJock: Whatcha need man?
<LaserJock> bddebian: your review of gfaim
<bddebian> Yeah?
<LaserJock> there was a lintian warning about a binary without a man page
<bddebian> Yeah, Linda warning, lintian error
<LaserJock> IMO, it's ok
<LaserJock> as the binary in question is an internally use wrapper with 1 line
<bddebian> Lutin: Probably the best thing to do then would to just be to add a lintian override
<LaserJock> bddebian: what do you think about it?
<bddebian> Yeah, I think it's bogus but I'm no "policy" expert by any stretch :-)
<shawarma> Why not move it to usr/lib/gfaim ?
<Lutin> bddebian, LaserJock: do you both think an override would be ok ?
<LaserJock> Lutin: yes
<Lutin> ok
<LaserJock> shawarma: "/
<bddebian> shawarma: That's a thought too
<LaserJock> bah
<LaserJock> my paste doesn't work
<LaserJock> LSB says "/usr/lib: Libraries for programming and packages"
<LaserJock> s/LSB/FHS/
<shawarma> bddebian: {,/usr}/{,s}bin should really only be for stuff that a user should be calling. If a user should be calling it, it needs a man page.
<shawarma> LaserJock: libexec, then.
<shawarma> /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. [22] 
<Adri2000> crimsun: still here?
<shawarma> "internal binaries"
<shawarma> LaserJock: Also from FHS.
<Lutin> bddebian, LaserJock: just dput'd gfaim, should be ok in a couple of minutes =)
<LaserJock> shawarma: ah, that does look better
<bddebian> Here's from the Debian policy manual:  "Each program, utility, and function should have an associated manual page included in the same package."
<LaserJock> somerville32: you got a .orig.tar.gz yet? my trigger finger is getting tired ;-)
<LaserJock> bddebian: but for "axuiliary things" it's optional
<shawarma> bddebian: which section?
<bddebian> Where's that stated?
<LaserJock> I think /usr/lib/ is the best
<bddebian> shawarma: 12.1
<LaserJock> bddebian: right after the part you quoted
<shawarma> bddebian: I think it's implied that it's only programs, utilities or functions that the end user should care about. 
<LaserJock> I think the most "correct" way to do it is /usr/lib
<shawarma> bddebian: There's no need to document every private funtion inside each program.
<bddebian> :-)
<LaserJock> shawarma: right, but those should also not be in /usr/bin ;-)
<LaserJock> well, in seperate files anyway
<shawarma> LaserJock: Exactly.
<ScottK> I've got a packaging question that I'm not sure how to solve...  There is a PERL package that used to distribute two programs.  Upstream, because one of the programs was not going to be updated anymore, they broke it into two packages.  The other program has a new updated version.  Debian (and Ubuntu from Debian) currently has the last integrated version packaged.  Is there a way I can update a single existing package int
<ScottK> r REVU?
<geser> LaserJock: seems like I got g-c-u build with libgoffice-0
<geser> can you test it?
<imbrandon> no more noodles ;(
<zul> there will always be noodles just no new noddles
<imbrandon> ahh true
<zul> and you are making me hungry
<imbrandon> hehe
<zul> crud its 4 already?
<somerville32> LaserJock, almost got it :] 
<imbrandon> 3 , shush
<Lutin> LaserJock: so, /usr/lib or override ?
<LaserJock> geser: certainly
<LaserJock> Lutin: I now prefer /usr/lib :-)
<geser> LaserJock: http://members.ping.de/~mb/gchemutils/
<bddebian> doh
<shawarma> *G* It's always fun to stop by, cause a stir, and the fade back into silence. :-)
<LaserJock> mhm
<bddebian> Yeah, "thanks" shawarma ;-)
<somerville32> LaserJock, Ok. Just want me to upload to revu?
<shawarma> bddebian: :-)
<LaserJock> well, why don't you just send it to me, so I can just upload it
<shawarma> bddebian: any time.
<LaserJock> geser: ok, I've got it, building now
<LaserJock> so much for a nice productive day at work
<ajmitch> LaserJock: just ignore irc
<somerville32> LaserJock: e-mail?
<LaserJock> mantha@u.c
<somerville32> Just the .org.tar.gz?
<LaserJock> yep
<somerville32> LaserJock, Did you get it? :] 
<LaserJock> yep
<somerville32> All goods? :] 
<somerville32> Does an Archive Admin or something have to review it first?
<somerville32> Or does it go right into Universe?
<geser> somerville32: if it's a completely new package it needs to be reviewed by an archive admin
<Toadstool> heya everybody
<somerville32> How long should it take?
<geser> the review? some days (it depends on the archive admins)
<Lutin> heya Toadstool, how are you ?
<somerville32> Who are archive admins?
<somerville32> aka, who is someone I can bug, lol
<Sp4rKy> heya Toadstool :)
<Sp4rKy> please, i've a python app, but the install script is a bash script (install.sh). How can set cdbs to run install.sh and not setup.py for installation ?
<Toadstool> hey Lutin, Sp4rKy 
<bddebian> Hi Toadstool
<Toadstool> Sp4rKy: take a look at /usr/share/cdbs/1/class/python-distutils.mk, you want to modify DEB_PYTHON_SETUP_CMD in your debian/rules
<Toadstool> hey bddebian 
<Sp4rKy> Toadstool: thx :)
<Toadstool> Sp4rKy: and maybe a couple of other variables 
<Toadstool> Sp4rKy: hint: the documentation for cdbs is cdbs itself :p
<Sp4rKy> :)
<bddebian> heh
<Lutin> bddebian, LaserJock: gfaim should be ok now, could you have a look ? =)
<Sp4rKy> Toadstool: strange, i've added the variable but it doesn't work
<Sp4rKy> Toadstool: and the duckorp doc doesn't talk about smthg else
<Toadstool> Sp4rKy: never really modified this variable, can I have a look at your package?
<Sp4rKy> Toadstool: i just try smthg
<Sp4rKy> and upload it if it doesn't work
<Sp4rKy> ok, it "works"
<Sp4rKy> but the issue is it's a bash install script
<Sp4rKy> and python-distutils run python install.sh :/
<Sp4rKy> so i shouldn't use python-distutils class :)
<somerville32> Hobbsee :)
<somerville32> Hobbsee, I got my package uploaded. Say yea for me! :)
<Hobbsee> hey somerville32.  yay :)
<ScottK> Now he gets to join the club waiting for NEW.
<ajmitch> Hobbsee: you're up early
<Hobbsee> ajmitch: yes.  meeting
<ajmitch> poor soul
<Hobbsee> indeed :P
<cypherbios> bddebian: if you aren't busy, please say if still +1 from you [if needed]  for this package http://revu.tauware.de/details.py?upid=3999
<LaserJock> somerville32: check your ubuntu-motu mailbox ;-)
<somerville32> I have a ubuntu-motu mailbox?
<somerville32> lol
<geser> LaserJock: have you had time to test the g-c-u 0.6 debs?
<crimsun> Adri2000: yes
<Adri2000> crimsun: could you take a look at http://adrishost.homeip.net/~adri2000/ubuntu/toupload/doodle_0.6.6-1ubuntu1.debdiff please
<crimsun> in 20 mins
<Adri2000> to fix bug 78497 as specified in the changelog
<Ubugtu> Malone bug 78497 in doodle "doodled package can't be removed" [Medium,Confirmed]  https://launchpad.net/bugs/78497
<Adri2000> ok
<crimsun> (meeting atm)
<LaserJock> geser: gah, gimme a sec. I forgot about that
<crimsun> LaserJock: which source package for pyneighbourhood did you upload?
<LaserJock> crimsun: the one from REVU + fixed .orig.tar.gz
<crimsun> does the generated binary still dump the dirs into /usr/share/python-support/ ?
<crimsun> since somerville32 has seen fit to completely ignore the question from my reviewing
<LaserJock> crimsun: you reviewed it?
<bddebian> LaserJock: You gonna archive that upload? :-)
<LaserJock> oh, crikey
<crimsun> LaserJock: yes
<Adri2000> shawarma: do you know how to apply the same fix you have just upload for listen to a perl program? :)
<somerville32> crimsun: What question?
<LaserJock> crimsun: ok, I don't see it on REVU
<somerville32> Umm...
<somerville32> pyNeighborhood doesn't generate a binary
<crimsun> it absolutely does, what other deb are you going to install?
<crimsun> it's fairly useless for a source package to not generate a binary package
<somerville32> oh
<somerville32> For the binary package, it places the source code in /usr/share/pyNeighborhood/src/
<somerville32> and places a script in /usr/bin/
<crimsun> the dirs issue that I pointed out 12 hours ago?
<somerville32> crimsun: Didn't get it.
<crimsun> LaserJock: do you still have the source package that you uploaded, and if so, may I download and pbuild?
<LaserJock> crimsun: darn it you're right
<somerville32> What did I do wrong?
<LaserJock> somerville32: you are installing pyneighborhood.dirs to /usr/share/python-support
<Sp4rKy> why a ls debian/packagename or ls debian/tmp with cdbs doesn't works ?
<Sp4rKy> in the install/packagename:: section
<Lutin> Sp4rKy: why do you want to ls ?
<somerville32> LaserJock, What is pyneighborhood.dirs?
<somerville32> From the dh_pysupport manpage:
<somerville32> "       If a file named debian/pyversions exists, it is installed in /usr/share/python-support/$PACKAGE/.ver
<somerville32>        sion.
<somerville32> "
<Sp4rKy> Lutin: it's a test, because a mv doesn't work :)
<Lutin> Sp4rKy: oh, I see
<Lutin> Sp4rKy: what package ?
<Sp4rKy> entrance :D
<Lutin> hehe
<Lutin> nice =)
<Toadstool> Sp4rKy: let me see your debian/rules
<Sp4rKy> oh,no, devede  not entrance ^^
<Sp4rKy> Toadstool: of course
<Lutin> Sp4rKy: grrr =)
<Sp4rKy> Toadstool: http://pastebin.ca/310626
<Sp4rKy> Lutin: cdbs appears to doesn't work properly if i use tarball.mk && simple-patchsys
<somerville32> crimsun, LaserJock: that file must be generated by the pysupport or something. I don't have a pyneighborhood.dirs file
<Lutin> Sp4rKy: lol
<LaserJock> somerville32: I see that
<crimsun> it is generated by python-support
<Lutin> Sp4rKy: I have about 20 packages which all uses simple-patchsys and tarball.mk perfectly
<shawarma> Adri2000: Heh.. which one?
<Lutin> Sp4rKy: are you talking about cdbs-edit-patches ?
<Sp4rKy> Lutin: i guess :)
<Sp4rKy> Lutin: indeed
<Lutin> heh
<crimsun> somerville32: my question is whether it's correct for your source package
<Lutin> don't use it =)
<LaserJock> crimsun: I'm afraid I don't see the problem. Is he installing the .py to the wrong place?
<Sp4rKy> Lutin: grrr, why ?
<crimsun> LaserJock: it's not a problem; see above
<somerville32> crimsun, LaserJock: There are all kinds of .dirs file in /usr/share/python-support
<crimsun> somerville32: of course
<LaserJock> somerville32: but look at the contents
<Toadstool> Sp4rKy: try to move your install/devede:: target after the include
<LaserJock> somerville32: of yours
<Lutin> Sp4rKy: patching the files the old way will take you less time than trying to make cdbs-edit-patches work properly =)
<crimsun> the contents -should- be correct, but have you verified it?
<somerville32> no
<Sp4rKy> Lutin: ok ...
<Sp4rKy> Toadstool: i try
<crimsun> somerville32: that's all the question was
<LaserJock> it points to the dir above teh actual .py files
<Adri2000> shawarma: in fact I'm not sure your fix fixes the bug I'm thinking about. I'm thinking of that: killall gnome-panel and then the icon in the notification area doesn't re-appear, is it the bug you fixed?
<LaserJock> I'm not sure it it matters
<shawarma> Adri2000: Nope.
<LaserJock> crimsun: it looks ok to me
<crimsun> LaserJock: it's a process question
<LaserJock> mhm
<Sp4rKy> Toadstool: not better :/
<Sp4rKy> Toadstool: http://pastebin.ca/310636
<Sp4rKy> the last part of my build
<LaserJock> crimsun: dget http://tiber.tauware.de/~laserjock/pyneighborhood/pyneighborhood_0.4-0ubuntu1.dsc
<crimsun> persia: please don't unassign the person who uploaded your source package
<Adri2000> sharms: ah :( I just tried killall gnome-panel and programs like rhythmbox, gaim reappeared, but checkgmail didn't, maybe you have an idea how to fix that... :)
<Adri2000> shawarma* ^
<persia> crimsun: What?  I don't remember doing that.  Which bug?
<crimsun> persia: cupsys-pt
<LaserJock> geser: still around?
<crimsun> 47299
<geser> LaserJock: yes
<Hobbsee> bug 47299
<Ubugtu> Malone bug 47299 in cupsys-pt ".desktop does not validate" [Unknown,Unconfirmed]  https://launchpad.net/bugs/47299
<Hobbsee> ah
<persia> crimsun: https://bugs.launchpad.net/ubuntu/+source/cupsys-pt/+bug/47299/+activity doesn't show any changes to assignee.  Did something go wrong?
<shawarma> Adri2000: Hmm.. Not in perl, that's for sure. :-)
<Adri2000> shawarma: okay :p
<persia> crimsun: Ah, never mind, I see it now.  I didn't mean to do that.  Sorry.
<crimsun> persia: (I use it to track self-blame for uploads ;)
<Sp4rKy> so, sleep time
<LaserJock> geser: well, it seems to work
<Toadstool> Sp4rKy: change install/devede to binary-post-install/devede
<Sp4rKy> gd night :)
<LaserJock> geser: I'm just checking on your specific chages
<Sp4rKy> Toadstool: i check
<persia> crimsun: Wait, no.  I didn't paste that statusexplanation.  I am suspicious of the log.  I only set it Fix Released when it built on all architectures (which doesn't show in the log)
<Toadstool> Sp4rKy: wait... do you ever call install.sh in your debian/rules? :)
<persia> crimsun: Never mind.  I don't understand, but I'll try not to do it again.
<Sp4rKy> Toadstool: no
<Lutin> hehe, it maybe the cause then
<Sp4rKy> Toadstool: in fact, i don't use it at all, and i only install files by hand
<crimsun> persia: well, I won't rule out an LP boog
<geser> LaserJock: please check if I got the conflict/replaces against the old packages right
<Lutin> Sp4rKy: in the rules you pasted, you seem to install nothing
<Toadstool> Sp4rKy: then, do you really think that anything will be installed in debian/devede/usr/bin/?
<Sp4rKy> Lutin: Toadstool oh yep, it may be the cause ^^
<Sp4rKy> Lutin: i use a .install file :)
<Sp4rKy> Toadstool: works now !
<Sp4rKy> with binary-post-install :D
<Toadstool> ok great
<Toadstool> cdbs dark magic
<Sp4rKy> so, the last part of this package will be done tomorrow
<Sp4rKy> sleep now 
<Toadstool> good night
<Lutin> g'night Sp4rKy
<Sp4rKy> good night
<Sp4rKy> thx Toadstool :)
<geser> persia: see the second last change (assignee): old value = crimsun ; new value = 
<persia> geser: Yes, some of my comments above are misinterpretation (the rendered page is significantly wider than my browser), but I still don't understand why it happened (and only for this bug, out of the many favours that crimsun has extended me recently).
<LaserJock> geser: the only thing I might say is to maybe just add our Replaces/Conflicts, instead of replacing the Debian ones
<persia> On an unrelated note, I have questions about sync's and drops.  If a package is dropped from Debian, will it automatically be dropped from Ubuntu?  Is a bug required to force it to drop before feisty release?  Also, if there is a newer Debian package, but it offers no tangible benefit, should it be sync'd?
<LaserJock> persia: for the first, a bug needs to be filed if we want it gone
<LaserJock> for the second, it's kinda up to the person doing it. if you don't think it's worthwhile then don't do it, IMO
<geser> LaserJock: what's the point on conflicting on libgcu02ca which isn't in Ubuntu?
<geser> for those who installed the Debian packages?
<persia> LaserJock: Thanks.
<LaserJock> geser: keeping tighter to Debian and yeah, if somebody installed the Debian .debs
<geser> LaserJock: something else to fix?
<LaserJock> geser: also, you need to take out the config.{sub,guess} out of your .diff.gz
<LaserJock> geser: but the apps seem to work fine
<LaserJock> geser: none of the libgoffice changes were on the core libraries
<geser> LaserJock: how? I see several packages copying config.{sub,guess} from autotools-dev from the clean target
<geser> that's why it's in the diff.gz
<LaserJock> use filterdiff to get rid of them then
<LaserJock> it's a mess to have them in debdiffs
<geser> why do I need a debdiff?
<LaserJock> well, you don't, but I did :-)
<LaserJock> I like to check on what I'm changing from Debian
* persia believes that config.sub and config.guess should be deleted in clean: when using autotools-dev to make the diffs nice.
<geser> I do it also, but I'm nearly used to skip over config.{sub,guess} when reading a debdiff
<geser> persia: no, you need the original config.{guess,sub} from the orig.tar.gz
<geser> else you get the removal of then in the diff.gz
<LaserJock> I think probably the best solution is to put the config.{guess,sub} lines in configure: instead of clean:
<LaserJock> but that's not what dh_make does
#ubuntu-motu 2007-01-09
<persia> geser: The original files are dropped in during package unpack, and deleted during clean, then the diff is generated, followed by the copy from autotools-dev during configure, and then the build.  config.sub and config.guess (I miss the close-bracket key) are never in the diffs, but present in the original.
<geser> the README for autotools-dev suggest to add them to the clean target
<owh> Greetings. I posted an email to ubuntu-devel about implementing a FAT dirty flag for dosfsck on January 2nd. It is still awaiting moderation. I'm not currently a developer, but I'm fixing bugs in dosfsck together with sistpoty (Stefan Potyra) and I wondered what I should do next. The email is here: http://paste.ubuntu-nl.org/880/
<owh> BTW, on launchpad I am onno-itmaze.
<LaserJock> geser: but the autotools-dev example rules puts it in configure :-)
<LaserJock> owh: actually, you could email ubuntu-devel-discuss instead
<LaserJock> owh: it's open to everybody
<tenshu> Apologize me but is that normal if my packages are stuck in ftp://revu.tauware.de/incoming/ ?
<bhale> hello LaserJock 
<LaserJock> hi brandon
<owh> LaserJock: Would it not get lost in the noise?
<LaserJock> owh: there's not a lot right now I don't think
<geser> persia: as clean is called during source package building, aren't config.{guess,sub} missing when diffing against orig.tar.gz when they are removed in clean?
<owh> LaserJock: Cool. Tah.
<LaserJock> owh: you could also ask sistpoty to send it for you
<LaserJock> tenshu: which package?
<owh> LaserJock: sistpoty is writing a thesis and is a tad busy :-)
<LaserJock> ah yes
<tenshu> popstation & docmaker
<LaserJock> hence why I see him normal hours in my time zone :-)
<LaserJock> tenshu: you need to upload source packages, not .debs
<tenshu> oh my mistake sorry :q
<LaserJock> tenshu: you'll need to get a REVU admin to clear those out
<LaserJock> tenshu: also, why do they have "oea" in the versioning?
<tenshu> thats is the name from the upstream author
<Lutin> tenshu: ask siretart for the pkges removal
<tenshu> OE for open edition
<LaserJock> interesting
<geser> LaserJock: latest debdiff for g-c-u: http://pastebin.ca/310669
<geser> something else to change before I upload it?
<LaserJock> geser: looks good to me
<LaserJock> geser: thanks a ton for your work on that
<Lutin> LaserJock: could you check if gfaim is ok for you ?
<somerville32> For versioning
<somerville32> It goes: Major.Minor.Nano.Micro ?
<somerville32> Or Major.Minor.Micro.Nano ?
<azeem> probably the latter
<Adri2000> nano < micro
<azeem> but who nows, some projects might have strange versioning schemes ;)
<LaserJock> hi azeem 
<LaserJock> Lutin: this is only for French?
<LaserJock> :(
<Lutin> LaserJock: yep
<Lutin> LaserJock: on the other side, this can be translated
<LaserJock> I was going to say, it might be a good way to get my wife to use Linux more
<LaserJock> but she doesn't know any French
<Adri2000> hehe :P
<azeem> LaserJock: heya!
<Lutin> hehe
<LaserJock> azeem: geser has prepared (and is uploading) gchemutils 0.6.3 today
<azeem> cool
<LaserJock> azeem: yeah, he was able to patch it to work with our version of goffice
<geser> it's already uploaded
<azeem> excellent
<LaserJock> the author of gchempaint and gchemutils hopes to have a stable release early to mid March
<LaserJock> I'm hoping I can squeeze it into Feisty
<ScottK> Anybody up for REVU of a simple Perl package? http://revu.tauware.de/details.py?upid=4004
<Lutin> even if I was a motu, I can't even understand one line of perl ^^
<ScottK> Version 1.6 of this program (I've packaged 1.8) in included in https://launchpad.net/ubuntu/+source/libmail-spf-query-perl/1:1.999.1-3, but since the main Mail::SPF::Query program won't be updated, this associated program needs to get pacakged separately to get updated.
<LaserJock> Lutin: you realize gfaim-data is non-free?
<persia> ScottK: I'm not a reviewer, but it's odd to see so much of debian/ in orig.tar.gz.
<Lutin> LaserJock: suitable for multiverse though, isn't it ?
<LaserJock> Lutin: I think so
<ScottK> Well, as we discussed here a few days ago (when you weren't around) the upstream for this package and a couple of others I've done includes his own /debian in the release.
<ScottK> First time around I was asked to ask him to remove it.  I asked.  He declined.  Makes my life easier anyway.
<Lutin> LaserJock: at least when tfheen rejected it from entering the archive, ha didn"t told me about non-free issue related to the package
<persia> ScottK: It's fine, just odd :)
<ScottK> OK.
<LaserJock> Lutin: he might not have ogtten that far
<Lutin> LaserJock: indeed
<Lutin> LaserJock: do you want me to pastebin his mail ?
<persia> ls
<LaserJock> Lutin: I somehow feel like you should make it clearer that the recipies are only in French
<Lutin> LaserJock: ok, how can I do that ?
<LaserJock> Lutin: well, I was thinking maybe you could put it in the short description
<LaserJock> at least of gfaim-data
<Lutin> ok
<LaserJock> I think you should also include the GPL preample in debian/copyright
<Lutin> didn't I ? damn ^^
<LaserJock> well, you have a statement
<LaserJock> that could be sufficient, I'm not sure
<mwolson> you definitely don't need the GPL preamble there
<LaserJock> I see it a lot though
<LaserJock> and have wondered
<mwolson> just something to the effect of "This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version."
<LaserJock> but the Debian Policy just says to link to it
<Lutin> ok, changed
<mwolson> and maybe a warranty disclaimer
<LaserJock> Lutin: well, it looks pretty ok to me
<Lutin> LaserJock: ok, wait a minute before adding a comment ;)
<Lutin> LaserJock: just uploaded the fixed desc and copyright
<Lutin> LaserJock: should be ok now 
<LaserJock> Lutin: does imprec work still?
<Lutin> LaserJock: I wanted to ask you =)
<Lutin> LaserJock: imprec is called by a call to system()
<Lutin> don"t know the way he gets the path
<LaserJock> Lutin: when I try to print it segfaults
<LaserJock> :-)
<LaserJock> Lutin: it looks to me like he's just relying on it being in your path somewhere
<Lutin> LaserJock: according to posix.1, system() calls exec sh -c, so it relies on the system path
<Lutin> LaserJock: of course I could try to symlink /usr/lib/gfaim to /usr/bin/gfaim, but I wonder if it's worth it
<Lutin> to move it, and then symlink its previous location would be kind of weird
<Lutin> well, it's 2:25 here and I really need some sleep
<LaserJock> other then that it seems ok
<Lutin> ok
<Lutin> well, gotta go
<Lutin> see you later guys
<Lutin> and thanks a lot LaserJock =)
<bddebian> Heya gang
<bhale> hi bddebian 
<chillywilly> hi
<bddebian> Hi bhale, chillywilly
<persia> hi bddebian
<bddebian> Hi persia
<ScottK> hi bbdebian: Got a moment to look at a very simple package with one tricky question? http://revu.tauware.de/details.py?upid=4004
<bddebian> ScottK: What's the tricky question, I'm a little tied up with RL work atm :-(
<ScottK> ...
<Hobbsee> ScottK: tell what the questoin is, and you're more likely to get an answer
<ScottK> The one actual program in that package was previously package in https://launchpad.net/ubuntu/+source/libmail-spf-query-perl/1:1.999.1-3.  The problem is that the main program in that package is not being updated and so this helper program has two more versions that I'd like to get released.
<ScottK> Sorry. on other channels I've used ... means I'm busy typing the question, not ignoring you.
<ScottK> So I'm not sure exactly what the right way to proceed is here.
<Hobbsee> ah
<ScottK> I expect I have to have a new package to continue with the one program, but I was hoping to find a way to avoid NEW since a program that's already been part of a larger package.
<ScottK> If you look you'll see that the older, combined package is already two released behind.
<zul> yay update-grub works
<persia> ScottK: Perhaps in addition to postfix-policyd-spf-perl_1.08-0ubuntu1, you could upload libmail-spf-query-perl_1:1.999.1-4, which includes the split, and add appropriate conflicts for libmail-spf-query-perl=1:1.999.1-3 to postfix-policyd-spf-perl_1.08-0ubuntu1?   To avoid NEW, you could also include the new code directly in libmail-spf-query-perl/1:1.999.1-4 (with no new package), and just indicate the helper update in the cha
<ScottK> I could probably get that done, but the other part is that while postfix-policyd-spf-perl currently with libmail-spf-query-perl. libmail-spf-query-perl is obsolescent and unmaintainable.  There's a new Perl implementation that I have in the queue http://revu.tauware.de/details.py?upid=3976 that will replace it.  So I don't want to keep the postfix policy daemon tied to the old library.
<persia> ScottK: I think you have to go through NEW then :(  You still probably want a versioned conflicts to prevent dual installation: there's no requirement that conflicts targets be in the archive, so it won't have a lasting effect.
<ScottK> OK.
<ScottK> Well I was hoping.
<Hobbsee> ScottK: it may not take that long - particularly if it's only for new binary, not new source
<ScottK> Is there a way to indicate that in the package?
<ScottK> Or does the big magic system in the sky figure that out?
<persia> Hobbsee: It's the other way: old binary from new source.
<Hobbsee> ah
<ScottK> Yes.  Sorry.
<ScottK> I'm still pretty new to packaging.
<persia> ScottK: The big magic system in the sky is called LP.
<ScottK> OK.  Does that mean I need to file a bug against the old package or some such thing to indicate the new source for the binary?  It sounds like I also ought to do a libmail-spf-query-perl/1:1.999.1-4 without the now separate program so things can stay in synch.
<persia> ScottK: If the other binaries in libmail-spf-query-perl are still useful, you want to do that.  If you are replacing them with other new packages, it's probably better to raise a removal request (or just have everything conflict with it).
<ScottK> Next question for the gurus...  If I am going to repackage libmail-spf-query-perl/1:1.999.1-3 this way for Ubuntu (I will also ask the Debian maintainainer to do a -4 there) what's the right ubuntu version number for my package?  is it -3ubuntu0 to stay below 4?
<persia> ScottK: -3ubuntu1
<ScottK> Thanks
<ScottK> Eventually the other stuff will go away, but the new Perl library, http://revu.tauware.de/details.py?upid=3976, is new from the ground up so both the old and the new ought to be available for a transition period.  It sounds like conflicting is the way to go so people can pick.
<persia> ScottK: In that case -3ubuntu1 probably wants to conflict with all the new packages, just to make that clear.  On the other hand, if the new packages conflict, the old package will fade into obscurity, especially if more important packages choose to recommend the new packages.
<ScottK> Can I conflict with a package that isn't in the repository yet?
<persia> ScottK: Yes.
<ScottK> Thanks.
<metres> I all, do anyone have an idea on fixing that bug ?  http://lists.gnupg.org/pipermail/gnupg-devel/2005-August/022279.html 
<nixternal> Laser_away: ^^ :)
<persia> metres: You've come at the quietest point in the day (about 9-10 hours from now seems the most active).  My memory of earlier discussion about this issue was that seahorse required en environment variable to be set properly to work within a shell with redirected stdin and stdout.  Looking briefly at debuild, it appears to do make some fairly significant efforts to control which environment variables are passed to the build env
<metres> persia : do an update of gnupg may help ?
<persia> metres: I'm not sure.  If it works with --preserve-envvar, I would think a patch to devscripts to automatically preserve the necessary variable would be easiest.  If that doesn't work, I'm not sure where the fix should be applied.
<metres> persia : I'll try to uncheck the ssh shell issue in the seahorse graphical config...
<persia> metres: Looking at seahorse, it looks like you either want to start `seahorse-agent -A` (which is insecure) or pass "--preserve-envvars DISPLAY" to debuild.  I'm not sure what unchecking the ssh shell issue will do.
<persia> BTW, there's a bug on the seahorse-agent manpage: it thinks it's a daemon :)
<metres> Thank you for your hint persia... have a good day :)
<persia> metres: Did it work?
<LaserJock> hmm
<Hobbsee> LaserJock!!!
<LaserJock> Hobbsee!!!
<LaserJock> somerville32: are you still up? or just getting up?
<somerville32> Still up
<somerville32> I never sleep :)
<LaserJock> what TZ?
<somerville32> ATS
<somerville32> @now atlantic
<Ubugtu> Current time in Canada/Atlantic: January 09 2007, 01:06:53
<Fujitsu_> Afternoon, LaserJock/.
<LaserJock> hi Fujitsu_ 
<Hobbsee> somerville32: it doesnt kill you to read logs, you know
<somerville32> Hobbsee, Which logs?
<Hobbsee> meetings ones, whichever
<somerville32> Did I miss a meeting?
* LaserJock is confused
<Hobbsee> no
* somerville32 is confused too.
* Fujitsu_ throws himself into the pile of confusion.
<somerville32> \o/
<LaserJock> hmm, so it seems the only one not confused is Hobbsee 
<LaserJock> women :/
<LaserJock> ;-)
<persia> Is there an easy way to download sid sources from a feisty workstation?  I'm going through my patchlist to file debian bugs, and downloading from packages.qa.debian.org is frustratingly inconvenient.
<tepsipakki> persia: just add the deb-src line to sources.list
<persia> tepsipakki: Doesn't that mean I get the newest available package when I apt-get source foo or aptitude download foo, rather than the sid package?
<tepsipakki> and then use 'apt-get -t sid source foo' to download from sid
<LaserJock> unfortunately it doesn't quite work like that
<persia> tepsipakki: Thanks.
<tepsipakki> works for me
<persia> LaserJock: No?
<LaserJock> there is a bug
<tepsipakki> at least on dapper it does :)
<LaserJock> well, what happens is it only grabs from one
<tepsipakki> yes?
<tepsipakki> is that a bug?
<LaserJock> no, I mean it doesn't respect -t
<LaserJock> it takes from the first deb-src line it finds the package
<LaserJock> it works ok with deb lines
<LaserJock> but not deb-src
<persia> LaserJock: Is there another way that works?  I don't really want to build a sid chroot, but that would be easier than my current workflow.
<tepsipakki> oh..
<tepsipakki> hmm
<LaserJock> persia: dget is at least easier
<LaserJock> tepsipakki: yeah, I got all excited too :/
<LaserJock> but then I started looking at where the packages were actually coming from
<tepsipakki> well, this hasn't been a problem yet :P
<tepsipakki> anyway, a bug, yse
<tepsipakki> yes
<LaserJock> I think if you only have 2 deb-src distros it might work a bit better
<persia> LaserJock: So I set my browser to use dget for .dsc files, and continue downloading from packages.qa.debian.org?  I was hoping for mirrors.
<LaserJock> persia: well, write something up :-)
<persia> /persia starts inspecting at-spy
* persia doesn't use IRC enough :)
<Hobbsee> persia: use /me
<Hobbsee> ie, /me starts
<persia> Hobbsee: It's the gap between the fingers and the brain, really.  It's just not automatic.
<Hobbsee> hehe
<tepsipakki> hmm, quite warm out there, so I'll grab my bike today as well
* tepsipakki hails global warming
<persia> tepsipakki: Depends where you are - it's only 10 here.
<tepsipakki> +5.38C here
<tepsipakki> normally s/+/-/
<tepsipakki> in January..
<persia> That's warm?  Never mind: depends who you are.
<tepsipakki> heh
<LaserJock> according to Debian bug #152129 you have to have corresponding deb lines for the deb-src lines to have the -t work right
<tepsipakki> sucks
<LaserJock> so I guess I could add the deb lines too
<LaserJock> but that seems a bit messy
<tepsipakki> yes, imagin dist-upgrade
<LaserJock> I don't want it acidentally grabbing feisty .debs :-)
<tepsipakki> +e
<persia> LaserJock: Ah, so if you add the deb lines as well, it works?  The other options seem to be related to apt-src and apt-get -c.
* persia likes feisty debs.  When they don't work, it's an opportunity :)
<LaserJock> persia: it's probably pretty straightforward to write a tool that keeps a local Sources cache
<LaserJock> and then does the right dget
<LaserJock> the really tricky one would be Launchpad
<LaserJock> since it doesn't work with dget (grrr)
<persia> LaserJock: apt-get can do that with -c, you just configure for alternate sources and an alternate cache directory.  I'm still playing, but I think it can be done with user-owned workspace (~/apt/...)
<TheMuso> 
<persia> LaserJock: If I get a working wrapper script, I'll paste it somewhere.
* Hobbsee mumbles quietly about ircing as root...
<persia> Does anyone know which APT option is used to prevent the dpkg run after update?
<Hobbsee> dpkg run?
<Hobbsee> as in, download only?
<persia> Hobbsee: I'm writing a wrapper for apt-get that allows the download of sources or binaries from archives to which the system is not subscribed.  I'm using a local apt repository in the user's home directory, but when I run update, it complains about wanting to update /var/lib/dpkg/lock.  It works fine for downloading stuff after this failure, but I'd rather make it pretty.
<persia> The goal is to easily download sid packages to make patches so I can submit things back to Debian, but it might also be useful for those who want to play with feisty sources from an edgy workstation without a chroot.
<`6og> --download-only to only aquire packages, as Hobbsee said
<persia> apt-get --download-only -c apt.conf update still complains about /var/lib/dpkg/lock.  I'm pretty sure I need something in apt.conf to prevent this behaviour.
<Hobbsee> persia: -d
<`6og> apt aquires the lock when its run, not when dpkg starts
<JaeSharp> Is anyone packaging the Second Life Linux client now that it has been released under the GPL? I was wondering if anyone was already working on it?
<somerville32> Interesting idea!
<persia> `6og: apt aquires a lock on Dir::State/lists/lock.  This is for dpkg.
* persia goes hunting in apt-doc
* persia grumbles about pretty HTML man pages
<dholbach> good morning
<somerville32> Morning! :)
<\sh> moins
<persia> I finished the wrapper.  src-get is available from https://wiki.ubuntu.com/EmmetHikory.  I'd be very happy if anyone could get binary download to work correctly (or knows a better way to do this easily).
<somerville32> Gah
<somerville32> The archive admins rejected my upload :
* somerville32 summons Laser_away
<Adri2000> somerville32: who rejected your upload?
<somerville32> Tollef Fog Heen
<somerville32> Simple fix
<somerville32> I just need someone to upload it for me
<somerville32> debian/copyright had version 2 or later while the source code has version 2 only
<Adri2000> okay
<somerville32> I'm surprised it got reviewed so quickly by the archive admins
<somerville32> I thought they had a big backlog
<xerxas> Hi all 
<somerville32> hi
<somerville32> Are there any MOTUs around? :)
<somerville32> http://revu.tauware.de/details.py?upid=4009
<Lutin> somerville32: not really sure that you should have autoadvocated your package
<somerville32> Does it make a difference? :)
<Lutin> I think it does, yes :)
* somerville32 waits for Lutin to enlighten him.
<Lutin> somerville32: afaik you're not a motu. only motus have to advocate packages
<somerville32> Lutin: It doesn't really make a difference - or atleast I don't think it does.
<Lutin> somerville32: do whatever you want then 
<mr_pouit> it's also a way for MOTUs to find quickly package that needs onyl 1 advocate left
<mr_pouit> *only
<somerville32> Right
<somerville32> I just need a motu to upload
<somerville32> the package has already been approved
<mr_pouit> somerville32, if your package has already been, uploaded, you don't need 2 advocates anymore
<somerville32> mr_puit: It was rejected by the archive admin.
<mr_pouit> only 1, therefore you shouldn't auto-advocate ^^
<mr_pouit> somerville32, I know, I have 3 packages rejected as well
<somerville32> Anyhow, I need sleep
<proppy> hi!
* proppy hugs dholbach
<crimsun> sweet, the soyuz grue has reared its head again
<\sh> is this possible: chroot <chroot_dir> SUDO_FORCE_REMOVE=yes apt-get --assume-yes install sudo-ldap ?
<siretart> crimsun: you uploaded scorched3d? whats the diff to debian?
<crimsun> siretart: dh_iconcache
<siretart> oh. hm
<siretart> does dh_iconcache exist in debian as well, or are there any plans for it in debian?
<crimsun> it doesn't exist in Debian, and afaik people are still "discussing" what changes need to be made
<crimsun> http://librarian.launchpad.net/5653813/M78523.patch is the diff I applied against Sid's current scorched3d source package
<crimsun> not that it really matters, since soyuz has silently eaten both signed scorched3d uploads I've made in the past hour
<siretart> crimsun: damn :/
<crimsun> hehe, I'm used to it now
<siretart> it would be great to have 40.1d in the archives, since most public servers are running it and won't accept connections from the older version
<crimsun> I started writing a script last night to poll my inbox and automatically reupload if the accept doesn't show up within 17 minutes
<StevenK> Hrm.
<StevenK> Couldn't the time be better spent plotting ways to harm the Soyuz developers? :-P
<crimsun> nah. They're paid to work on it; I'm just a grunt who chucks stuff at the archive every so often. ;)
<bddebian> Heya gang
<lupine_85> quick q., if anyone's willing :) - is ~0foo1 a higher or lower version than ~0foo1~bar ?
<dholbach> daniel@lovegood:~$ dpkg --compare-versions ~0foo1 gt ~0foo1~bar; echo $?
<dholbach> 0
<dholbach> daniel@lovegood:~$ 
<dholbach> ~0foo1 > ~0foo1~bar
<lupine_85> ah, cool. thanks :)
* lupine_85 notes dpkg --compare-versions for future reference
<dholbach> anytime :)
<lupine_85> easier than building two packages and playing with them :D
<dholbach> hgehehehe
<effie_jayx> dholbach,  where can I find info on how to be a motu... or how to participate... :S?
<\sh> wiki.ubuntu.com/MOTU/ ? :)
<effie_jayx> the ubuntu-motu-school is it active?
<effie_jayx> geee thanks
<effie_jayx> :D
* Hobbsee hugs dholbach 
<dholbach> http://wiki.ubuntu.com/MOTU/Documentation too
<\sh> effie_jayx: you're welcome :)
* dholbach hugs Hobbsee back
<\sh> ajmitch: how much I have to pay you to package more zope/plone packages? ,-)
<jonibo> gtk for directfb does not seem to be available in Feisty...
<jonibo> ...is it coming back?
<Lutin> bddebian: around ?
<ScottK> Is anybody available to delete one of my uploads? http://revu.tauware.de/details.py?upid=4008 I just discovered an issue that will require some upstream changes and I don't want anyone to waste their time REVUing it since it has to be updated anyway.
<bddebian> Lutin: Sort of, what's up?
<crimsun> ScottK: then just note it in a comment
<Lutin> bddebian: nothing urgent, just wanted to say that finally gfaim should be ok for review :)
<bddebian> Well my REVU records has been sucking lately :-(
<ScottK> OK.  Will do.
<crimsun> bddebian: at least you're reviewing
<imbrandon> hrm something is wrong with the nuke script
<imbrandon> its archived for now , i'll nuke it when i can poke siretart 
<imbrandon> ScottK, ^^
<imbrandon> moins all
<ScottK> Thanks.  No wonder I couldn't find it when I went to comment on it....
<bddebian> crimsun: Thx but I'm not sure what good that is when I'm wrong all the time :(
<crimsun> bddebian: you're not wrong at all
<crimsun> your comments on revu are solid
<bddebian> But I seem to miss a lot :-(
<crimsun> that's the nice thing about peer reviews
<bddebian> Not after I've already uploaded (aka murrine) :-)
<bddebian> s/uploaded/advocated/
<davromaniak> bddebian, I corrected ccd2iso, so when you will have some free time, would you take a look at it ?
<bddebian> davromaniak: Sure
<davromaniak> thanks
<LaserJock> geser: oops, gchempaint FTBFS because libgcu-dev still has a dep on libgoffice-1
<geser> already fixed
<LaserJock> geser: really?
<LaserJock> dang your good ;-)
<bddebian> Yeah he is
* bddebian changes God page to geser
<crimsun> time to promote geser to deity status :P
<LaserJock> man, I need more machines
<LaserJock> too many pbuilder jobs to run at the same time :/
<zul>  /join #ubuntu-meeting
<LaserJock> zul: why?
<LaserJock> :-)
<zul> LaserJock: umm...er..
<Nafallo> hehe
<bddebian> LaserJock: I hear that man.  I need an amd64, a ppc, and a Sparc ;-P
<Nafallo> I just need a new laptop :-/
<LaserJock> bddebian: I'd just go for more i386's at this point
<LaserJock> I'm using all I can at work
<LaserJock> and my 2 home computers
<crimsun> why don't you ask imbrandon for access?
<zul> bddebian: you dont need you want
<LaserJock> crimsun: come to think of it, I might already :/
<bddebian> zul: No, I NEED :-)
<LaserJock> bddebian: why? you keep saying you don't do anything. Which is it? ;-)
<bddebian> So I can do nothing on more architectures ;-P
<LaserJock> ah
<Nafallo> lol
<LaserJock> ok, I'd like to sync a NEW package from Debian experimental, do I just need to file a sync bug and subscribe ubuntu-archive?
<LaserJock> I think that's right
<bddebian> Yep afaik
<LaserJock> geser: when did you upload the fix to gchemutils?
<geser> LaserJock: https://lists.ubuntu.com/archives/feisty-changes/2007-January/003176.html
<LaserJock> geser: ah, it just showed up in LP for me
<Lutin> LaserJock: I fixed gfaim on revu, could you have a look ?
<Lutin> LaserJock: I can't say the imprec script works fore sure cause I have no printer to test it, but at least the prog no longer segv and finds it properly
<LaserJock> ok, I'll add it to the todo
<Lutin> thanks :)
<LaserJock> i've got a lot of things to do today, but I certainly try to get to it as soon as I can
<Lutin> ok LaserJock, thx :] 
<nixternal> anyone know if a shirt is shipped from Germany to the US (DHL) if it is dutiable or non-dutiable?
<LaserJock> I don't know :/
<LaserJock> that's a long way to get a shirt
<zorglu_> i believe that if you say it is a gift, it is not :)
<nixternal> LaserJock: but they are way cheaper than we can get them for here
<nixternal> zorglu_: orly
<zorglu_> the us has some rules about that, if a gift, notax
<nixternal> $50 shipped to Chicago for 1 Polo and 1 T-Shirt both embroidered
<nixternal> you can't get screenpressed shirts that cheap here
<zul> apple tv? so basically a tivo?
<hub> no
<ogra> a tv powered by applejuice ?
<LaserJock> :)
<LaserJock> so now I know why my iMac seems sticky
<tenshu> hi all i received a mail from Tollef saying my upload of daxcr to Feisty has been rejected because the licence file was missing from the orig tarball. Since i have no right to upload to Ubuntu the only way to fix this is to send my package back to REVU?
<LaserJock> tenshu: that's an easy way to do it
<Adri2000> tenshu: yes, or you can ask directly the MOTU who uploaded the rejected package
<LaserJock> or you could probably send a fix to the MOTU that uploaded it
<Adri2000> LaserJock: :)
<tenshu> :-/ erf
<LaserJock> ogra: marble rocks!
<ogra> LaserJock, ;)
<ScottK> I got a similar message (package rejected due to license file missing in orig.tar.gz).
<ScottK> I went back to the upstream and he added the URL of the license, but not the actual text.  That's as far as he'll go.
<ScottK> There's no confusion about how the code is licensed, just how much bother upstream is willing to go to for Ubuntu.
<ScottK> This isn't one of those times where I have to change orig.tar.gz is it?
<tenshu> hard punishment to reject the upload for this, we already list it in debian copyright and provide a copy on the system and giving FSF adress
<LaserJock> it's better to fix it now
<ScottK> You go argue with Tollef and tell me how it comes out...
<ScottK> OK.  Is the fix for me to add it to orig.tar.gz?
<LaserJock> ScottK: you could probably just provide a patch that has the text from the URL
<LaserJock> he might take that
<LaserJock> but we do often times act as upstream police
<LaserJock> making sure software authors provide good info and enough of it
<ScottK> OK.  I was hoping for a more definitive answer than 'might'.  I searched on both the Debian and Ubuntu sites for definitive policy on what has to be in orig.tar.gz and didn't find anything.
<LaserJock> ScottK: that's what an archive admin is for :-)
<LaserJock> if the archive admin isn't ok with that software going into the repos then it doesnt go
<ScottK> Yes, but I was REALLY hoping to be able to say "See, Debian says in xxyyz document that it HAS to be there..."
<ScottK> Agreed.
<LaserJock> yes, Debian packaging is more art than science, IMO
<LaserJock> I would just ask tollef what he suggests
* ScottK goes off to learn about how to include proper patches in /debian (haven't had to do it before).
<LaserJock> if the upstream refuses to add the file then you need to know what the archive admins will accept
<tenshu> does the rules so "hard" on the debian-side?
<LaserJock> tenshu: what do you mean by "hard"?
<LaserJock> like what they accept and reject?
<tenshu> yes
<ogra> way harder
<tenshu> ok
<ScottK> I guess I already know the answer to the "what will the archive admins accept" question, since Tollef said, "rejected because..."
<LaserJock> ScottK: well, there can certainly be some dialoge there
<LaserJock> like, "Upstream won't put it in there, only a link, can I add the text in a patch or add it directly to the .orig.tar.gz?"
<tenshu> ok i correct the upload, can a motu reupload it again? http://revu.tauware.de/details.py?upid=4017
<LaserJock> tenshu & ScottK : a good resource for things the archive admins might be looking for is: http://ftp-master.debian.org/REJECT-FAQ.html
<ScottK> LaserJock: Thanks.  I'll try that then...
<tenshu> LaserJock: thanks too
<LaserJock> in the past I've gotten good help from the archive admins when they rejected something of mine
<LaserJock> as long as don't say something like "Fix it for me, pleeeease"
<LaserJock> :-)
* ScottK waits anxiously for Tollef to respond...
<Lutin> Toadstool: around ?
<Toadstool> Lutin: well, kinda busy at work right now..
<Toadstool> hi everybody
<Lutin> Toadstool: ok :)
<Lutin> Toadstool: ping->when you'll see that, please tell me what you found wrong in kayali, apart the source tarball :)
<Adri2000> crimsun, geser, bddebian: I'm applying for membership today (CC is at 2100UTC), since you have uploaded some packages/acked syncs for me, maybe you will want to say something :] 
<ajmitch> morning all
<bddebian> Heya ajmitch
<Lutin> 'morning ajmitch
<bddebian> Adri2000: I'm swamped at work but I'll try
<Adri2000> thanks
<zul> hey ajmitch 
<Marsmensch> i, wie kann ich den die cpu temp leicht rausbekommen?
<Nafallo> Marsmensch: du pratar utrikiska :-P
<Marsmensch> h?
<Marsmensch> ups wrong channel sorry
<Nafallo> hehe :-)
<Marsmensch> & wrong server
<Marsmensch> wanted to ask on linux.de on quakenet ;)
<Nafallo> Marsmensch: I just told you in Swedish that you were talking something other than English :-)
<Marsmensch> i just startet xchat to get help with my laptop ... it has become so slow in the last days/week
<Nafallo> :-)
<Marsmensch> ok, so go on ;)
<Nafallo> yay! back to idling ;-)
<geser> Tonio_: is it ok if I merge yakuake?
<Tonio_> geser: sure, is there a new version available ?
<geser> only a new Debian revision
<Tonio_> what are the changes ?
<Tonio_> I'm not sure the packaging is the same, but if there is a new patch, it can be interesting to merge it indeed
<Toadstool> Lutin: there is a bashism in your debian/rules
<Lutin> Toadstool: where ?
<Toadstool> when you remove the fonts
<Toadstool> {font1,font2}.ttf
<Lutin> eeek. yes
<Toadstool> and why do you use install file dest/ and then mv dest/file dest/another_name?
<Toadstool> you can simply use install file dest/another_name...
<Lutin> Toadstool: I tried, but instead of changing the name, I was installed in dest/another_name
<Toadstool> uh?
<Lutin> (in the folder named another_name, with its original name)
<Toadstool> that's weird
<Toadstool> I'd take a closer look at this and I'd use kayali.dirs instead of adding a mkdir in debian/rules too
<Lutin> Toadstool: would install -d be better ,
<geser> Tonio_: looking at the changelog there aren't any interesting changes beside that Debian is now also at 2.7.5
<Lutin> ?
<Sp4rKy> Toadstool: heya
<Toadstool> hey Sp4rKy 
<Tonio_> geser: no need to merge then...
<geser> Toadstool: and it uses now quilt instead of simple-patch-system
<Toadstool> geser: -EWRONGNICK :)
<geser> indeed
<Toadstool> Lutin: install -d for what?
<Lutin> Toadstool: to create install dirs, instead of mkdir
<Toadstool> well, you still have to put this in a target in your debian/rules... imo, the smaller the debian/rules the better when it comes to cdbs, you should use debian/kayali.dirs :)
<Lutin> Toadstool: ok :)
<Lutin> Toadstool: also asked upstream for the source tarball, he told me he was going to release a cleaner one :] 
<Toadstool> great! :)
<Toadstool> Lutin: in your build-deps, you should move python-central from BUild-Depens-Indep to Build-Depends
<Lutin> Toadstool: why ? it's an archindep package
<Toadstool> Lutin: 'cause lintian complains about it? :)
<Lutin> Toadstool: :/
<Toadstool> Lutin: and also according to lintian and the python policy you should use debhelper (>= 5.0.37.2) in debian/control
<Lutin> oh thanks, didn't see that
<LaserJock> well, lintian complainging about Build-Depends vs Build-Depends-Indep can sometimes be misleading
<Lutin> hummm
<metres> Hi all, i'm having a problem signin files with debuild... I had this error when trying..: http://paste.ubuntu-nl.org/986/
<LaserJock> metres: that's a known bug with seahorse and debuild
<metres> LaserJock : but it was working...
<LaserJock> hmmm
<metres> I think before changing locales
<slomo> metres: hmm, works fine for me... is this on feisty?
<metres> edgy
<slomo> ok, worked on edgy too for me ;) i use it all the time... does seahorse-agent still run, is the file there present?
<slomo> does restarting seahorse-agent (killall seahorse-agent && seahorse-agent) fix it?
<metres> no seahorse running 
<slomo> ok so it was killed at some point for some reason... hm
<slomo> probably fixed with 0.9.10 in feisty, the version in feisty has one million bugs fixed compared to edgy ;)
<metres> doesnt fix the problem... gpg: problem with the agent - disabling agent use
<metres> when executing debuild
<slomo> how is it started for you? gnome session properties?
<metres> I dont understand what you asked slomo...
<metres> I also have this ewarning : gpg: WARNING: unsafe ownership on configuration file `/home/metres/.gnupg/gpg.conf'
<guibis> hi slomo
<slomo> hi guibis 
<slomo> metres: how do you start seahorse?
<metres> automatically in the session , I supposed...
<metres> I just start it in the shell but it does the same error
<metres> If I want to update gnupg and seahorse, I on;y have to download source and install it ?
<metres> or do I have to uninstall..? cause uninstalling gnupg uninstall lots of package including gnome.desktop...
<metres> I try dpkg-reconfigure gnupg and seahorse...
<Lutin> Toadstool: lintian doesn't say anything about python-central in B-D-Indep
<Toadstool> Lutin: hmm?
<Toadstool> Lutin: lintian -i kayali_0.3.1-0ubuntu1_i386.changes? :)
<marola> hi people
<marola> good evening for every body
<Lutin> Toadstool: nope
<Lutin> it's not listed
<Toadstool> Sp4rKy: which version of lintian?
<Toadstool> er
<Toadstool> Lutin: ^
<marola> anyone has ubuntu 6.10 installed on sony vaio?
<Lutin> Toadstool: 1.23.16ubuntu2
<Toadstool> Lutin: 1.23.27ubuntu1 here
<Sp4rKy> Toadstool: :)
<Toadstool> Sp4rKy: sorry ;)
<Sp4rKy> np :d
<Lutin> Toadstool: I run it on Sp4rKy's server, it runs dapper =)
<Toadstool> well i run it on a sarge server but in a feisty chroot ;)
<Lutin> :)
<Lutin> Toadstool: ok, I can see it on my edgy box
<crimsun> Adri2000: sorry, meetings IRL. Do you still need me to vouch?
<Adri2000> crimsun: if you can't, no problem. it should be ok anyway (I have good comments from Gauvain on my wiki page :))
<persia> crimsun: Thanks for all the uploads.  I'm curious, did I do something wrong with ksimus (74967), or did it just get lost in the u-u-s transition.
<crimsun> bug 74967
<Ubugtu> Malone bug 74967 in ksimus "Desktop entry not shown in GNOME" [Undecided,Confirmed]  https://launchpad.net/bugs/74967
<crimsun> the latter
<crimsun> it never crossed my inbox
<persia> crimsun: OK.  Thanks.
<crimsun> Adri2000: I won't be able to make it (particularly since you're fairly far down the list, and I have another lecture in 10 minutes)
<crimsun> Adri2000: I'll leave some notes on your wiki page
<Adri2000> great, thank you
<Adri2000> crimsun: #ubuntu-bugs? you meant -motu?
<allee> hi, what tool is used for the pkg merge at http://merges.ubuntu.com/ ?   I would like to use it to merge against debian experimental pkgs.
<LaserJock> you mean, what tool is used to create merges.ubuntu.com?
<LaserJock> allee: ^^?
<allee> LaserJock: only the part that creates as output from three releases thttp://merges.ubuntu.com/d/digikam/
<allee> LaserJock: I've the base, lasted kubuntu and experimental sources on disk.  now I would like to get what merges.u.c shows
<persia> allee: Are you looking for debdiff?
<LaserJock> allee: well, that is MoM (Merge-O-Matic) which is a proprietary app written by Keybuck
<LaserJock> but you could probably at least script the debdiffing parts pretty easily
<allee> persia: no. something like debmerge debian-base debian-lastest, kubuntu-lasted
<persia> allee: I think you'd need to script that.
<LaserJock> allee: you'd have to talk to Keybuck, but I think it's too tied to LP/Canonical to be useful outside
<LaserJock> *Keybuk
<allee> LaserJock: okay, thx.  I'll do it with old-bug-free tools ;)  Problem at hand is not complicated to merge.  but I'm lazy, so I thought I ask ;)
<LaserJock> :-)
<persia> allee: You might get something useful with `dpkg-source -x kubuntu-latest; debdiff debian-base debian-latest | patch`, but this only works if there's not a new upstream version.
<LaserJock> dang, if only I could get sabdfl to ask me what my LP wishlist was :-)
<persia> LaserJock: I'm reminded, did you want my script to collect alternate distribution sources?
<Toadstool> LaserJock: what would you answer? :)
<LaserJock> Toadstool: well, I'd have to collect my thoughts for a little bit
<LaserJock> but +subscribedbugs by default
<LaserJock> being able to subscribe to just tasks
<LaserJock> dropdown menus for status changes
<LaserJock> xml-rpc support
<persia> ls
<LaserJock> Toadstool: ^^ is a few
<LaserJock> persia: sure
<persia> LaserJock: https://wiki.ubuntu.com/EmmetHikory?action=AttachFile&do=get&target=src-get
<Toadstool> LaserJock: yay for xml-rpc! :)
<persia> It's not very robust, but it works for me.
<Toadstool> persia: for the download part, you could use aptitude download
<LaserJock> persia: interesting, thanks
#ubuntu-motu 2007-01-10
<persia> Toadstool: Aptitude doesn't respect -c, so I'm not sure how to use the local APT repositories.
<geser> Adri2000: congrats
<Adri2000> thank you geser :)
* Adri2000 is happy :p
<Toadstool> Adri2000: next step, -dev? :)
<somerville32> What happened?
<Adri2000> Toadstool: yes, probably :] 
<Adri2000> somerville32: I just got approved as a member :p
<somerville32> Omgz!
<somerville32> I missed the CC!
* enyc looks confused... i cant see the 2 new  qpsmtpd packages in archive.ubuntu.com edgy-proposed dapper-proposed
<enyc> Im sure I found the edgy-proposed version on the archive actually... see https://launchpad.net/bugs/77485 etc. -- but its not there now?? somebody please let me know what is going on ;-)
<Ubugtu> Malone bug 77485 in qpsmtpd "[SRU]  request: edgy:qpsmtpd fix for bug #72602" [Undecided,Unconfirmed]  
<geser> enyc: I can only see that it was uploaded to edgy-proposed, as packages to edgy-proposed aren't let to the archive automatically an archive admin must let them through
<enyc> geser: interesting... i thought -proposed was part of the arctive... not separate... please let me know how this works
<geser> enyc: it's part of the archive but the admins can set for edgy, edgy-proposed, edgy-updates, feisty independent if new uploads are accepted automatically (feisty), manual (edgy-proposed) or not at al (edgy)
<bddebian> Heya gang
<geser> hello bddebian 
<enyc> geser: right... so I need no be asking archive team to do this accept from  edgy-proposed  somehow? (not sure how to explain to them)
<bddebian> Heya geser
<somerville32> LaserJock, Did you get a chance to reupload my package?
<LaserJock> somerville32: oh yeah, I just wanted to confirm with you that it should be (that somebody hasn't already done it, etc.) as you pinged me 2am 
<somerville32> LaserJock: Not that I know of :] 
<LaserJock> somerville32: so I'll do it now then
<somerville32> thanks
<geser> enyc: I assume they should spot it on their own but if it isn't there after some time (say a week or two) you can ask them gently
<geser> enyc: the normal queue is visible but afaik not the queue for egdy-proposed
<geser> for mere mortals
<enyc> geser: bah confusing... o well ;-)
<enyc> geser: I understand... upload queue
<LaserJock> darn, it's hard to think of pings with content now :/
<imbrandon> LaserJock, lol
<Nafallo> haha
* imbrandon wants an iPhone 
<apokryphos> me too
<Nafallo> a what?
<apokryphos> the presentation on them today was such an annoying tease
<imbrandon> apokryphos, ++
<imbrandon> Nafallo, apples new phone / ipod / media thing
<Nafallo> eeew
<imbrandon> along with AppleTV
<Nafallo> I don't want that :-)
<imbrandon> looks nice too
<apokryphos> http://www.engadget.com/2007/01/09/live-from-macworld-2007-steve-jobs-keynote/
<apokryphos> no shortage of software celebrities at their conferences, too, it seems. Google CEO, Yahoo co-founder...
<somerville32> imbrandon: What happened to the build boxs?
<imbrandon> they are all getting upgrades, i've just been lax about accounts and ips
<imbrandon> i'll get on it asap i guess hehehehe
<imbrandon> i replaced all the 32bit with 64bit dual core or better and lots more ram
<imbrandon> :)
<ajmitch> hello Hobbsee, imbrandon 
<imbrandon> heya ajmitch 
<ajmitch> imbrandon: ship some of the 32-bit boxes this way
<bddebian> Heya ajmitch, imbrandon
<imbrandon> moins bddebian 
<Hobbsee> hey ajmitch 
* Hobbsee pokse imbrandon 
<imbrandon> i know, konversation
<imbrandon> hehe
<Hobbsee> :P
* ajmitch pokes Hobbsee 
<imbrandon> grr if i run twinview computer keeps hard locking
* Hobbsee pokes ajmitch 
<imbrandon> ajmitch, where can i get the source / binarys for that new nv driver
<ajmitch> imbrandon: haha funny
<imbrandon> i wanna see if it will stop my hard locks
<ajmitch> you'll need to do things like upgrade libdrm, compile a kernel module, etc
<imbrandon> ouch
<ajmitch> nouveau.freedesktop.org
<imbrandon> hrm
<ajmitch> it is *not* stable or complete
<Kyral> why do I hang out here again?
<ajmitch> the 2d part requires you use the drm kernel module for mem allocation
<imbrandon> hrm , binary lockups or nv no 3d
<ajmitch> Kyral: we have no idea
<Hobbsee> Kyral: because you'r einsane
<imbrandon> Kyral, you love us
<Hobbsee> RT finally got back about u-u-s mailing list...
<imbrandon> brb reboot
<bddebian> Damn, I swear that REVU is like some kind of perpetual motion machine...
* ajmitch isn't touching revu
<persia> bddebian: How so?
<bddebian> persia: Every time I look it seems like there is more and more..
<bddebian> ajmitch: Why?
<joejaxx> anyone knows whether ubuntu uses the stable or testing netinstall image for the ubuntu install disc?
<ajmitch> lost motivation to do anything :)
<joejaxx> ajmitch: :P
<bddebian> ajmitch: Well you have to correct all my mistakes :-)
<ajmitch> nah
<ajmitch> you can do just fine by yourself
<bddebian> No, I can't :-(
<bddebian> I can't even get my own packages in :(
<somerville32> imbrandon: You already gave me a new account
* ajmitch might just drop all his packages on someone & run off into the sunset
<somerville32> imbrandon, but now when I try to connect, they time out
<bddebian> ajmitch: pshaw
<ajmitch> bddebian: you'll survive
<imbrandon> somerville32, yea they are all powered down at the moment , redoing some cabling etc to get them all on the same vlan 
<imbrandon> so i can make one account domain ( ldap ) for the whole mess
<imbrandon> etc
<somerville32> cool :] 
<imbrandon> thats why i said service might be iffy for the next week or so 
<somerville32> kk
<somerville32> Do you have any experience with ltsp, btw?
<imbrandon> limited, i mostly only know/use the pxe booting part ( i have a deployment server that pxe boots the linux / windows installs and kickstarts them when i build a new box )
<imbrandon> as far as desktop pxe no
* somerville32 nods.
<imbrandon> LaserJock has some experince with it iirc ( edubuntu )
<somerville32> If you have time, do you think you could give me a crash course in ldap?
<imbrandon> ldap is pretty sreight forward but yea i can sometime
<Nafallo> imbrandon, somerville32: dudes. count me in on that one :-)
<imbrandon> the ladap or buildd's ?
<Nafallo> both would be good :-)
<imbrandon> the builds i'm just making it sync from LP MOTU group so you'll have an account
<imbrandon> as far as the ldap stuff i guess i could do a ubuntu-classroom thing sometime
<imbrandon> like ummm next tuesday or soemthing
<Nafallo> yea. that was what I thought you guys where talking about :-)
<Nafallo> LDAP in the classroom :-)
<imbrandon> well it dident start that way but i guess i can
<imbrandon> ;)
<Nafallo> hehe
<somerville32> Awesome.
<somerville32> It's a deal then.
<somerville32> LDAP Lecture by imbrandon in #ubuntu-classroom next Tuesday, exact time TBA ;] 
<imbrandon> i'll poke arround and make sure no one else has anything scheduled for next tue
<somerville32> :] 
<imbrandon> Hobbsee, wanna do some hacking ?
<imbrandon> i want guidance-power-manager to do this .... http://www.robster.org.uk/blog/2007/01/10/gnome-power-manager-strikes-again/
<imbrandon> heheh
* Kyral shrugs and goes back to idling
<Hobbsee> imbrandon: neat!!
<imbrandon> Hobbsee, yea i'm sure it wouldent be hard to add that sicne g-p-m is python and uses hal already for the other stuff
<imbrandon> tis a neat idea 
<Hobbsee> imbrandon: i dont have a wifi mouse
<Hobbsee> er a wireless mouse
<Hobbsee> indeed :)
<imbrandon> i do, i guess i could goof with hal and see what it reports
<imbrandon> shouldent be too hard, one afternoon i should be able to do it
* Nafallo hints #ubuntu-se :-)
<Hobbsee> hehe :)
<Nafallo> Hobbsee: I want a WiFi-mouse!! can it do WPA2? :-)
<imbrandon> lol
<Hobbsee> Nafallo: *grin*
<imbrandon> does it run linux, can you cluster them ?
<Nafallo> imbrandon: lol. looking for new buildd? ;-)
<imbrandon> lol
<Nafallo> time to sleep
<somerville32> imbrandon: I got some people who are also interested in attending
<somerville32> imbrandon, When would we be able to get a time?
<LaserJock> darn, it. spent so much time thinking of content for the ping I forgot what I was pinging about
<LaserJock> ;-)
<imbrandon> somerville32, lets say 1pm CST 
<LaserJock> imbrandon: hi dude
<imbrandon> heya LaserJock 
<somerville32> LaserJock: imbrandon told me you have experience with LTSP?
<imbrandon> he /might/ hehe
<imbrandon> e.g. edubuntu
<LaserJock> somerville32: might is a good word
<LaserJock> I've actually never done it personally
<somerville32> But you've worked on Edubuntu?
<LaserJock> because you need to have a network with no other DHCP server except the LTSP server
<LaserJock> somerville32: oh yes, I do work on Edubuntu
<somerville32> Could I chat with you via pm real quick?
<LaserJock> certainly
<imbrandon> LaserJock, well not really but you need the dhcp server to be able to serv a pxelinux.0 file and then point to the real dhcp
<imbrandon> but yea much easier to run just one
<LaserJock> well, yeah
<somerville32> LaserJock, Did you get my query?
<LaserJock> I got to see my first Edubuntu thin client setup in Paris
<LaserJock> ogra and highvoltage just ran a patch cable from a laptop acting as a server to one of ogra's thin clients
<LaserJock> it was pretty slick
<imbrandon> LaserJock, hehe
<LaserJock> doh, I remembered what I wanted to ask
<LaserJock> crimsun: do you think you'd be available to teach a MOTU Session sometime soonish?
<ajmitch> ooh, motu school
<somerville32> :)
<rexbron> I would definately attend
* somerville32 wants to go to school.
* ajmitch would like to learn stuff
* rexbron is in school
<imbrandon> ahh pics of my new 22in setup :) http://www.imbrandon.com/misc/new_workzone.jpg
<LaserJock> I want him to do a bug reporting session
* imbrandon lubs it
<LaserJock> imbrandon: only 1 can?
<imbrandon> hehe well thats all thats on my desk, thus the frequent mt dew runs
<ajmitch> imbrandon: I hate you again
<somerville32> Windows Vista...
<imbrandon> actualy kde :)
<LaserJock> yeah, I had to look twice
<Hobbsee> ajmitch: you already know it all...
* somerville32 looks closer.
* imbrandon likes to make kde skins
<LaserJock> but noticed it was that kde theme
* ajmitch has to make do with a 21" CRT & a 20" LCD
<ajmitch> Hobbsee: no I don't
* somerville32 should take a picture of his work area.
<imbrandon> that crt next to it thats off is a 20 in
<imbrandon> ajmitch, ^^
<LaserJock> bah
<imbrandon> but my vid card wont run both and do lots of colors
<ajmitch> imbrandon: hence why I hate you :)
<ajmitch> ah
<imbrandon> so the crt gets turned off
<ajmitch> unfortunate
<LaserJock> I have a 14.1" laptop and a 17" CRT
* ajmitch has 3200x1200 at 32-bit colour
<somerville32> I have a 19" LCD
* ScottK doesn't have room for a second display on his desk because, well, stuff just seems to accumulate...
<ScottK> No pictures of my office either...
<imbrandon> my desk seems pretty "clean" compared to most
<somerville32> I have room for two more monitors but not at head level
* ajmitch has a very messy desk
* LaserJock stabs ajmitch in the back and runs of with his 3200x1200
<imbrandon> but then again i just swiped all the papers to the other desk for the pic LOL
<ajmitch> LaserJock: good luck lifting it
<somerville32> hehe
<LaserJock> ajmitch: good point, I'll bring help
* imbrandon runs 1620 x 1080 or some such
<ajmitch> I preferred to not get the widescreen lcd
<imbrandon> err 1680 x 1050
<LaserJock> well, my primary working area is a wooden TV tray
<imbrandon> just looked, yea widescreen reses are strange
<imbrandon> somerville32, yea here was my XP theme for dapper
<imbrandon> http://www.buntudot.org/people/~imbrandon/screenshots/snapshot2.png
<imbrandon> i've been working on this vista one for feisty :)
<imbrandon> its not quite right yet
<ajmitch> sick
<somerville32> oh cool :] 
<ajmitch> kill the teletubbies theme
<bddebian> heh
<imbrandon> heh
<Hobbsee> hehe
<Hobbsee> ye,s please do!
<imbrandon> ponies !!
<imbrandon> http://www.buntudot.org/people/~imbrandon/screenshots/ponies1.png
<ajmitch> careful, you'll get crimsun running 
<imbrandon> hehe
<imbrandon> i got that new glass penguin for my bday
<imbrandon> i'm scared i'll knock it off my desk
* imbrandon yawns
<imbrandon> hrm i should post a meme to get everyone to take pics of their desk/workzone
<ajmitch> that'd mean I've had to clean mine
* somerville32 just took one.
* ajmitch doesn't have a blog, so can't take part in memes. what a shame
<imbrandon> ajmitch, get a blog !!
<Hobbsee> imbrandon: you know, if you did something else apart from vista theems, i might stop poking you so much :P
<imbrandon> Hobbsee, you too, well it can be your first post :)
* Hobbsee has a blog....somewhere
* Hobbsee hsa forgotten where to get ti added
<ajmitch> imbrandon: I don't see any reason
<imbrandon> ajmitch, there realy isnt one
<ajmitch> I do nothing interesting, and have no interesting opinions
<imbrandon> look at my posts the last few months, not much, but still something
<ajmitch> so why add to the general inanities of the internet?
<LaserJock> http://laserjock.us/ubuntu/desktoparea.jpg
<imbrandon> heh
<LaserJock> http://laserjock.us/ubuntu/laptoparea.jpg
<imbrandon> hehee
<imbrandon> both have the screen off , awe
<imbrandon> :)
<LaserJock> not the laptop
<LaserJock> just a bad angle
<imbrandon> ohh no the lappy has ubuntu
<imbrandon> cant miss the brown
<ScottK> desktoparea is still MUCH more organized than mine...
* ajmitch doesn't have the brown on his desktop|laptop
* Hobbsee has no hackergotchi
<LaserJock> ScottK: yeah, I was actually using it today so I had to make some mouse space
<ajmitch> actually no, I do have a brownish orange background for the desktop
<ajmitch> Hobbsee: neither do I
<imbrandon> here is my original workarea before xmass and i upgraded the computers
<imbrandon> http://www.imbrandon.com/misc/workzone.jpg
<LaserJock> I think I'll have to clean up for BehindUbuntu :/
<imbrandon> hehe
<imbrandon> i still havent gotten an invite for an interview /me feels left out 
<imbrandon> heh
<LaserJock> imbrandon: oh yeah, that's right. I had that same desk. I remember
<ajmitch> besides, if I start blogging, people will expect me to actually do stuff with ubuntu
<imbrandon> yea that desk finaly died
<bddebian> ajmitch: We would never do such a thing :)
<LaserJock> imbrandon: man, if I had a stove that desk would have been firewood
<imbrandon> hehe
<imbrandon> mine got put on the street corner
<LaserJock> my father-in-law took mine for firewood :-)
<imbrandon> some poor soul come grabbed it before trash day, i was like good riddance
<imbrandon> more dew, brb
* somerville32 ponders how he is suppose to get his photo off his "online album" he just uploaded to from his phone.
<ajmitch> hah
<LaserJock> that's like when my lab put out all our old computer parts in the hallway
<LaserJock> people kept coming by
<Toadstool> heya
<imbrandon> i'm a hardware hore though, i would ahver took them all
<LaserJock> I didn't have the heart to tell them it was just a bunch of junk
<ajmitch> so how is MOTU going lately, anyway?
<ajmitch> I've been out of touch since before Christmas
<Toadstool> er.. quick question, what do you guys think about gfaim-data's license on REVU?
<imbrandon> yea i have mostly too, just now getting back arround to working the last few days
<imbrandon> trying to catch up
<ajmitch> I'm wondering if I should bother trying to get back into it or not
<lifeless> ajmitch: get back in
<LaserJock> Toadstool: it'll go to Multiverse
<Toadstool> LaserJock: erm, ok :)
<LaserJock> ajmitch: please do, at least a little bit
<LaserJock> Toadstool: it seems distributable but very non-free
<Toadstool> yup
<LaserJock> ajmitch: we have a fair amount of merges left
<ajmitch> yeah I know
<bddebian> We do?
<bddebian> Have all the sync requests gone through yet?
<LaserJock> not by any means
<LaserJock> but still: http://tiber.tauware.de/~laserjock/motutodo/universe.html
<Toadstool> uhuh
<LaserJock> there's 96 outstanding merges on merges.ubuntu.com/universe.html
<bddebian> Egads
<LaserJock> I don't imagine all of them are waiting sync requests
<LaserJock> but I could be wrong
<ajmitch> LaserJock: that seems quite high
<Hobbsee> bah.  planet appears not to like me
<Hobbsee> no blog for planet
<LaserJock> Hobbsee: please do
<imbrandon> Hobbsee, ?
<persia> LaserJock: What do the colors mean?  I don't mind making clean patches for some of them.
<ajmitch> and a few zope packages I should look at
<Hobbsee> sarah@sarah:~/Desktop$ bzr checkout sftp://jrhakr@bazaar.launchpad.net/~planet-ubuntu/config/main planet-ubuntu
<Hobbsee> Permission denied (publickey).
<Hobbsee> bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net;
<imbrandon> LP being nuts
<LaserJock> persia: on tiber or merges.ubuntu.com?
<persia> LaserJock: Either.  I've only done ~5 merges, but I didn't know where to find the list of things to be done.
<Hobbsee> imbrandon: yeah...
<LaserJock> I'm not sure on merges.ubuntu.com
<LaserJock> but on my list the first section is just outdated packages in Feisty compared to Debian unstable
<LaserJock> but that's normal
<ajmitch> Hobbsee: and your username on LP is jrhakr?
<LaserJock> the second section is the list of outdated packages with an ubuntuX version
<LaserJock> i.e. things that need to be merged
<LaserJock> or perhaps they were merged once but are again outdated
<Hobbsee> ajmitch: point
<persia> LaserJock: OK.  For the second list, is the workflow 1) Open a merge bug, 2) Make the patch, 3) attach it to the bug?
<Hobbsee> dammit, got caught out  :P
<LaserJock> persia: and then subscribe ubuntu-universe-sponsors
<persia> LaserJock: Got it.  Thanks.
<LaserJock> persia: you'll just need to make sure a bug hasn't already been filed
<LaserJock> as there are a lot of outstanding sync requests, etc.
<persia> LaserJock: If there is an outstanding merge or sync request, is there an expiration window that should be observed prior to performing work?  I'm guessing the "Debian version is newer" and "New upstream version", etc. count, although the language is different.
<LaserJock> hmm, I don't quite understand what you said
<LaserJock> expiration?
<persia> LaserJock: If a merge request exists, but has shown no activity in x days, I presume a patch would be welcome, I'm just not sure about x (14 or 28, I would think).
<somerville32> My desktop: http://cody.zapto.org/files/2.jpg
<LaserJock> ah, I doubt you'd come across any that didn't at least have a patch or something
<somerville32> s/desktop/workplace
<LaserJock> but I'd say just leave a comment asking if it's ok to do the merge or not
<dsas> somerville32: Do you actually use it? :p
<somerville32> dsas: Yes :P I just cleaned last night though
<LaserJock> geeze
<persia> LaserJock: Generally these have been entitled "new Debian version" or "New Upstream release (with a link the the Debian package), but I suspect the intent is the same.
<LaserJock> ah
<joejaxx> somerville32: microsoft optic blue?
<somerville32> joejaxx: Nope. Centrios
<LaserJock> that screen looks like something I'd see down south of here
<somerville32> What does that mean?
<LaserJock> persia: I think you could hijack it if it's obvious that they are just asking not intending to do the work
<LaserJock> somerville32: I live in Nevada, Area 51 and nuclear testing facilites are south of me
<persia> LaserJock: OK.  I'll snoop Launchpad profiles for decisions.  Thanks.
<somerville32> LaserJock, lol
* Hobbsee adds
<LaserJock> hmm, Java2 and PSAT
<LaserJock> fun
<somerville32> It's a good time for sure
<somerville32> Notice the penguin mascot? He keeps me going late at night ;] 
<LaserJock> gosh, it's been like 10 years since I took the PSAT
<somerville32> LaserJock: We don't have PSATs in Canada ;] 
<LaserJock> heh
<LaserJock> lucky you
<somerville32> not quite
<somerville32> I did the PSAT anyhow
<LaserJock> I didn't have to take the SAT though, out west they seem to prefer the ACT
* somerville32 nods.
<LaserJock> I always wanted to do it anyway just to see, but it didn't really matter anyway
* somerville32 nods.
<LaserJock> I just wen to the little uni in my home town anyway
<LaserJock> *went
<Hobbsee> right.  no one else can whine about my blog not being on planet :P
<somerville32> LaserJock: I'm hoping to go to MIT to do my PhD. : ] 
<LaserJock> somerville32: yeah, I thought about it too, but I didn't want to live there
* somerville32 nods.
<imbrandon> meme posted http://www.imbrandon.com/index.php/2007/01/09/computer-areas-ultimate-meme/
<LaserJock> go for goodness sakes
<LaserJock> s/go/oh/
<joejaxx> imbrandon: i hope that one of your satas do not go down :(
<imbrandon> joejaxx, i keep backups
<imbrandon> trust me i've lost too much data over the years
<joejaxx> imbrandon: yeah :(
<LaserJock> Hobbsee: hahaha
<somerville32> imbrandon, Are your comments moderated?
<imbrandon> no, there is akismet spam thing that checks it against RTBL but other than that no
<somerville32> Hmm
* somerville32 is a failure then.
<imbrandon> ( and i have it set to where you need an account to post iirc )
<imbrandon> nope , just tested , posting comments works fine
<somerville32> Ok
<somerville32> I tried but I'm too lazy to try again
<imbrandon> lol
<LaserJock> akismet is pretty good
<imbrandon> it will hit planet in a few minutes , i'm sure i'll get some comments
<imbrandon> it will be nice/funny if sabdfl actualy posts a meme
<LaserJock> I just added one of those "type what's in the image" thingies
<LaserJock> for comments
<imbrandon> yea i just have the check against the RTBL built into the akismet wordpress , no false positives as of yet
<imbrandon> and only one out of about 100 spams got through
<imbrandon> soo i think it works well
<LaserJock> well, this image thingie got rid of basically all my spam
<LaserJock> it doesn't even get to akismet now
<LaserJock> at least I don't think
<LaserJock> maybe nobody can comment :-)
<imbrandon> Blog Stats
<imbrandon> There are currently 28 posts and 79 comments, contained within 6 categories.
<imbrandon> Spam
<imbrandon> hehehe
<imbrandon> Akismet has protected your site from 3,188 spam comments.
<LaserJock> heh
<ajmitch> meh, blogs
<LaserJock> whatever
<imbrandon> notice i put ajmitch's name in the post of who he wants to see blog a pic 
<imbrandon> :)
<LaserJock> mhm
<LaserJock> I think we need a petition or something
<imbrandon> i just registered a domain and setup a site on my server for my little bro to blog
<LaserJock> either that or we need to make a blog for him
<imbrandon> ericholtsclaw.com ( nothing much there yet , he'll fill it out tomarrow )
<LaserJock> we could start blogging for him
<LaserJock> that would be fun
<imbrandon> hahah yea just copy/paste irc comments
<LaserJock> mwuahaha
<imbrandon> lol
<imbrandon> ajmitch's irc blog
* ajmitch will drop off irc
<imbrandon> :)
<LaserJock> lol
<imbrandon> heh just teasin , i wouldent 
<LaserJock> I would
<LaserJock> ;p
<ajmitch> exactly
<LaserJock> nah
<imbrandon> ahh tis finaly on planet, that thong is slow sometimes
<LaserJock> I know I'd get a serious butt kickin' at the next dev summit or something
* ajmitch might watch & lurk on irc, but not speak up
<imbrandon> lol
<ajmitch> nah, I wouldn't be at the next dev summit
<imbrandon> you will at 7.10 :)
<imbrandon> as will I hopefully
<ajmitch> nah
<LaserJock> ajmitch: if you aren't I know you can get people there to beat me up
<imbrandon> hahahahaha
<LaserJock> you'll just tell the Aussies one of those bad jokes about AU that you NZ people know and say it was from me
<imbrandon> yea i dont think i can make it to spain this time , possibly but i doubt it
* ajmitch is probably finished with dev summits
<imbrandon> why ajmitch ?
<Hobbsee> hey cool - my post got published!
<ajmitch> I'm done with wasting money
<imbrandon> Hobbsee, hehe 
<LaserJock> Hobbsee: wow, you have a beard
<imbrandon> now you need a hackergotchi
<LaserJock> Hobbsee: and no eyes!
<imbrandon> ajmitch, just get sponsored from now on ( if you can )
<Hobbsee> hehe, argh!
<ajmitch> imbrandon: exactly - it won't happen :)
<LaserJock> ajmitch: when zope grows wobbly windows you'll get sponsored ;-)
<imbrandon> heh
<LaserJock> hmm, I think the MOTU Council should get sponsored
<somerville32> How often do people get sponsored? Do you have to be well known?
<ajmitch> that may happen
<superm1> hey imbrandon while your here, did you get a chance to upload/look at the mythtv bzr branch?
<LaserJock> somerville32: it's more like "what do you bring to the table?"
<imbrandon> somerville32, depends on what you work on i guess, i got sponsored this last time but they say they wont sponsor you every time only every other but who knows
<somerville32> LaserJock: So maybe I could get sponsored for Xubuntu stuff? :)
<imbrandon> superm1, actualy thats what i was doing right now
<LaserJock> perhaps
<somerville32> but unlikely? lol
<imbrandon> somerville32, perhaps
<superm1> imbrandon, ah very good :)
<LaserJock> imbrandon: they really said they wouldn't sponsor every time?
<imbrandon> LaserJock, not officialy but thats what Riddell told me
<persia> LaserJock: Blame community growth.  Start scaring new people away :)
<LaserJock> imbrandon: ah
<somerville32> How do they evaluate "what I bring to the table"?
<imbrandon> thats why i said i probably wont make it to spain, unless i get sponsored two times in a row
<LaserJock> somerville32: if it's something Canonical wants :-)
<ajmitch> s/Canonical/Mark/
<somerville32> lol
<LaserJock> well, not always Mark
<ajmitch> if it's shiny, sure
<LaserJock> the individual people running projects seem to have a fair amount of input
<imbrandon> i was basily one of 5 core kubuntu peeps is why i got sponsored this last time
<LaserJock> but in general, they decide on what they want to focus on
<LaserJock> and then bring in people who have knowledge and input
<Hobbsee> imbrandon: who are the others?  Ridde*ll, you, lure, tonio...
<Hobbsee> oh, raphink
<imbrandon> you me tonio lure sebas seele riddell raphink ( kinda )
<imbrandon> i dont mean core as in "core-dev"
<imbrandon> i mean the day to day movers and shakers
* Hobbsee does nothing
<imbrandon> core dev i think there is only me, tonio, and Riddell 
<imbrandon> not 100% sure
<LaserJock> is lure a core-dev?
* ajmitch does nothing overall
<imbrandon> i dont think he is even motu LaserJock 
<Hobbsee> no, he's not
<LaserJock> raphink is core-dev, but busy
<LaserJock> I thought there was somebody else
<imbrandon> not really heh
<LaserJock> ah well
<imbrandon> crimsun does a fair ammount of kubuntu stuff too but i dunno if he would be categorized as a "kubuntu person"
<LaserJock> well, Edubuntu's got Oliver
<imbrandon> or really anything other than a god :)
<LaserJock> mhm
<LaserJock> I'm hoping I can make Edubuntu's second core-dev
<somerville32> Crimsun is an Xubuntu person :P <g>
<LaserJock> but school is such a pain
<imbrandon> crimsun is just an all arround deity ;)
<bddebian> crimsun is just an all around stud..
<imbrandon> LaserJock, i hear ya
<LaserJock> +1
<bddebian> Doh imbrandon, you beat me to it ;-P
<somerville32> :)
<somerville32> It's true
<imbrandon> bddebian, hehe
<imbrandon> it just amazes me at times how the offical diretives can run with such few people at times, let alone the few that run ubuntu proper
<LaserJock> methinks he's probably working his butt of while we're all sitting here talking about him :/
<imbrandon> lol probably
<bddebian> Aye :-)
<imbrandon> hey i have a build or two going in the background hehe
<imbrandon> :)
<bddebian> I
<somerville32> :)
<bddebian> 'm "trying" to REVU
<Hobbsee> sure you are...
<somerville32> I'm reading... IRC
* ajmitch is slacking as per usual
* imbrandon is building konversation and mythtv
<bddebian> Well and playing NWN2 of course :-)
<imbrandon> bddebian, hahaha i downloaded that today , havent installed it yet
<ajmitch> as well as talking to someone about doing some plone migrations
<bddebian> imbrandon: Don't do it.... ;-P
<LaserJock> I'm trying to chart the future of the packaging guide, but getting a little writer's block
<imbrandon> LaserJock, post a meme , it will help, promis
* LaserJock decides to go take a shower instead. Most great writing starts in the shower.
<somerville32> Indeed it does
<LaserJock> I don't know how anything was written before indoor plumbing
<imbrandon> dancin in the rain
<imbrandon> dude the more i look at the iPhone , the more i want it 
<imbrandon> and i thought i wanted a greenphone from QT, this thing puts it to shame
<imbrandon> even at $499 i'm going to grab one right away in june
<superm1> not gonna jump on the 8GB model?
<imbrandon> possibly, depends on how much cash i have at the time :)
<superm1> hehe
<superm1> any ideas what CPU is in the thing - with the claims of it running OSX?
<imbrandon> could be anything, i'm guessing some kind of ARM like the ipod 
<imbrandon> nano's run dual 75ghz ARM's
<imbrandon> err 75mhz
* superm1 wishes i had a nano with a 75ghz ARM
<bddebian> Brr
<synic> what do I need to do to get an app that's in sid in fiesty?
<imbrandon> request a sync and have a MOTU ack it
<synic> is there a doc on how to do that?
<_MMA_> imbrandon: synic is the developer of Exaile.
<imbrandon> ahh
<somerville32> Woot! :)
<imbrandon> yea i think there is a doc, i'm not sure where its at , lemme look ( you can always just look at a previous sync req )
<Toadstool> I saw a sync request about exaile somewhere on Malone a couple of days ago
<Toadstool> bug 78588
<Ubugtu> Malone bug 78588 in Ubuntu "please sync exaile 0.2.7+debian-1 from Debian unstable (main)" [Wishlist,Fix committed]  https://launchpad.net/bugs/78588
<synic> I'm going to guess that Malone requesting that is a good thing.
<imbrandon> malone is the name of the LP bugtracker, so yes
<synic> oh :)  nice
<imbrandon> brb foood :)
<somerville32> I'm hungry too :)
<Toadstool> synic: exaile is awaiting approval by the archive admins in the NEW queue -> https://launchpad.net/ubuntu/feisty/+queue
<Toadstool> as it's a sync from Debian, it should not be rejected
<somerville32> Oh lookie
<somerville32> My package is at the top of the list :)
<Hobbsee> somerville32: mithrandir goes from the bottom :P
<somerville32> Hobbsee, Not tofleg (sp)
<synic> Toadstool: awesome
<Hobbsee> somerville32: sorry?
<somerville32> Hobbsee, It took just over 24 hours for my package to get rejected :)
* Hobbsee was kidding anyway
<Hobbsee> hehe
<Hobbsee> yeah, well.  rejections are easy
<somerville32> Feisty is frozen?
<somerville32> Oh, must be for Heard 2?
<Toadstool> yep
<poningru> somerville32: speaking of which
<poningru> have we started doing that yet?
<poningru> you wanna work on that tommorow?
<poningru> err wrong channel
<somerville32> . . .
<somerville32> poningru, whats the correct channel?
<poningru> -marketing?
<ademan> why isn't netbeans in the repositories?
<dholbach> good morning
<somerville32> Good Morning! :] 
<dholbach> hi somerville32
<somerville32> Hi dholbach 
<somerville32> Have a good sleep?
<dholbach> yeah thanks
<dholbach> how are you?
<ivoks> hi there
<somerville32> I'm fine, thanks :)
<ademan> anyone here that's dealt with java apps, i assume you need to compile with the sun jdk for performance to be anywhere near acceptable, correct?
<ademan> hey doko's here, doko, i'm thinking about packaging netbeans (if it's got source available) and i was wondering about what it takes to package a java package, the sun-java5-jdk i would assume
<doko> ademan: you can look at some other packages like libxalan2-java, libxerces2-java, bouncycastle, etc
<ademan> thanks
<ademan> there doesn't seem to be a source package available, but there IS cvs access, cvs is undesirable isn't it?  Since it could be an unstable snapshot?
<ademan> geeze, this sucks
* proppy hugs dholbach
* dholbach hugs proppy back
<ajmitch> hi daniel
<dholbach> heya andrew
<dholbach> Hobbsee|NotHere: you have a blog on planet! WOAH!
<ajmitch> yeah
<ajmitch> the ranks of the blogless diminish by one
<ajmitch> sad to see
<dholbach> ROCK :)
<dholbach> more MOTUs on planet :)
* Fujitsu will be sure to resist the blog revolution.
* ajmitch won't succumb to peer pressure
<ajmitch> not even when I get named by people like imbrandon 
<white> Fujitsu: do you have a spare weekend in the middle of february to catch up for some debian stuff in melb?
<white> of course ubuntu stuff should also be welcome
<ajmitch> heh
* ajmitch would love to come to melbourne as well & catch up, but that's not likely to happen in feb :)
<white> :)
<ajmitch> maybe later in the year
<white> ajmitch: sure, just write a mail to the debian-melbourne list :)
<Fujitsu> white, I should, and Debian stuff is good :)
<ajmitch> white: yeah, I've been on that list for the last 2 years or so :)
<white> well not much traffic there, i'll try to change that :)
<Fujitsu> A good idea, white.
<ajmitch> white: you're studying in melbourne still?
<white> ajmitch: yes, hopefully for the next 2,5 years :)
<ajmitch> great
* ajmitch is in NZ
* somerville32 is in Canada.
<white> ah great, i was too lazy to search on db.debian.org :)
<ajmitch> heh
<Fujitsu> How many DDs are there in Melbourne, white?
<white> Fujitsu: not quite sure, but always enough if you need anything :)
* ajmitch has met a few
<Fujitsu> It will be nice to finally have trusted key at some point :)
<white> Fujitsu: you will be the first one getting my sig when we finally catch up 
<ajmitch> sure, next time I'm visiting my friend in ringwood :)
* poningru wonders which melbourne
<Fujitsu> poningru, there's one in CA, isn't there?
<ajmitch> one in florida, iirc
<ajmitch> the real melbourne in australia is a little bigger
<poningru> yeah fl
* poningru is from fl
<Fujitsu> CA, FL, same thing.
<poningru> :p
<poningru> go gators
* poningru ducks
* ajmitch wanders off for sleep
<kgoetz> when i get the source for a package with apt-source, then build it (with dpkg-buildpackage), shouldnt it produce debs?
<gpocentek> it should
<Fujitsu> kgoetz, that is correct.
<kgoetz> um. hm.
* kgoetz wonders whats gonig on
<kgoetz> wonder if eclipse needs special treatment of some sort then :(
* kgoetz leaves eclipse for someone with knowhow... its not worth me wasting time on :)
<gnomefreak> crimsun: are you up yet?
<gnomefreak> kgoetz: eclipse is not real fun to build. everytime ive ever tried it failed :(
<kgoetz> gnomefreak: oh :( i'll start running then
<Fujitsu> kgoetz, that's the right attitude :)
<kgoetz> hehe. pity though, i need eclipse-ecj working. guess i have to wait :)
<gnomefreak> wth
<fernando> moin all
<gnomefreak> moin fernando 
<Hobbsee|NotHere> dholbach: i do now, yeah :P
<Hobbsee|NotHere> Fujitsu: i just wont *write* much, if anything, on said blog.
<crimsun> gnomefreak: I'm awake but not near the computer much this week due to moving offices
<Hobbsee> hey crimsun!
<Nafallo> anyone on up-to-date feisty with an IPv6-router in the distance? :-)
<crimsun> Hobbsee: hi!
<Adri2000> hey crimsun, just a question: "Adrien has been an asset in #ubuntu-bugs", you meant -motu?
<crimsun> Adri2000: no, I meant -bugs.
<Adri2000> really? :o
<crimsun> yes, since the times I've glanced there you've been active.
<crimsun> how was the CC meeting?
<Adri2000> good :)
<crimsun> were you approved for ubuntu-members?
<Adri2000> yep!
<crimsun> ah, congrats!
<crimsun> (your LP page must not be updated, then)
<Adri2000> yes, they didn't updated LP pages during the meeting, I believe it's Seveas' job to do it today :p
<crimsun> ah, ok, new delegation
<Amaranth> Seveas handles that now? I thought sabdfl did it during the meeting
<Adri2000> (to Seveas) (07:41:37 PM) sabdfl: and please ack the ones we handled completely tonight, tomorrow :-)
<gpocentek> Adri2000: you know what the next step is... ;)
<Adri2000> huhu, I guess... :)
<Amaranth> that reminds me, i need to clean up my vala package
<persia> Any KDE people around?
<Hobbsee> yes
<persia> Hobbsee: In kdelibs, acinclude.m4.in sets xdg_appsdir to /usr/share/applications/kde, to which any KDE compiled .desktop files are stored.  I was under the impression that the .desktop files belonged only in /usr/share/applications, and wondered if I was mistaken in the case that the application was compiled with the kdelibs acinclude file.
<Hobbsee> persia: i dont know that much:P
<persia> Hobbsee: OK.  Thanks anyway.
<persia> Would anyone running an Xfce environment be willing to install a KDE application?  I'm curious if dolphin appears twice in the menus under Xfce.
<crimsun> persia: please remember to insert a bug reference in the changelog :)
<persia> crimsun: OK.  I'll do that for further changelogs.  Thanks for the pointer.
<crimsun> excellent job w/ following up on the builds
<crimsun> although I am wondering why I'm receiving two copies of each u-u-s email
<crimsun> Hobbsee: perchance I'm still being forwarded a copy from your gmail if your gmail is subbed to u-u-s?
<persia> crimsun: Thanks.  There was a build failure for drscheme, but less failures than previous uploads, so I left it alone.
<Hobbsee> crimsun: no, i reforwarded that.  you're getting double mail?
<Hobbsee> crimsun: did you sign up to the ML?
<crimsun> Hobbsee: ah, yeah, I believe I signed up after you had already subscribed me
<Hobbsee> crimsun: that'd be it
<crimsun> I'll look at that in an hourish
<ScottK> Good morning (morning for me anyway) everyone.
<Hobbsee> hey ScottK 
<ScottK> On the off chance anyone was wondering... I heard back from Tollef about my package that he rejected because a copy of the license wasn't in orig.tar.gz.  " The orig.tar.gz needs to contain a copy of the licence, so you need to add it there.
<ScottK> "
<ScottK> So, looks like I don't have to learn how to patch it in today.
* ScottK goes off to do paying work and perchance squeeze in a little packaging as he goes...
* persia needs not to comment on bugs when tired :)
<\sh> ajmitch: ping...
<Hobbsee> \sh: gone to bed
<\sh> hmmm..ajmitch and sleeping? ,-)
<Hobbsee> yes...seems to happen occasionaly
<Hobbsee> or maybe just not near irc
<Adri2000> foo should recommend or suggest foo-doc?
<persia> Adri2000: Suggest seems more common
<Adri2000> ok
<persia> Is there a URI to download packages that have been Removed from launchpad?
<Hobbsee> persia: do you have them in your apt-cache??
<persia> Hobbsee: No.  I'm hoping for something official and public.
<Hobbsee> persia: sort of, is the ansewr
<Hobbsee> persia: they're on launchpad, but you have to go to the package, click on the version you want, go to the build that you want (see left hadn side), then grab the binary off that page
<Hobbsee> (it links to another page which contains the binary)
<persia> Hobbsee: OK.  My specific issue is that I'm working on the merge of yakuake, and the .orig.tar.gz files differ between unstable and feisty.  I'm hoping to backtrack all the Ubuntu versions to try to determine what has been done in the hopes of building a sensible patch.
<Hobbsee> persia: patches.ubuntu.com should work nicer
<Hobbsee> persia: also, yakuake should be on MOM
<persia> Hobbsee: Thanks.
<Hobbsee> persia: :)  MOM will make it easier for you
<Hobbsee> persia: check out changelogs.ubuntu.com as well, for just the changelogs
<persia> Hobbsee: The current versions are based on separate packings of 2.7.5.  The last common version MoM can find is 2.7.3-2, although this does reduce my search tree.
<Hobbsee> persia: ah right
* Hobbsee looks
<Hobbsee> persia: now that doesnt look fun
<persia> Hobbsee: It's fairly ugly, but a fun challenge.  Knowing the LP links to Removed packages work gives me a good chance to get something working in the next few hours.
<Hobbsee> persia: sources are fairly easy to find on LP
<persia> /persia downloads 14 versions of the source
<Hobbsee> persia: i'm going to grab the new version of dolphin, will add your patch
<persia> Hobbsee: It's not really my patch, I just wrapped it.  Please credit Michael Biebl.
<Hobbsee> :)
* Hobbsee just applied it
<persia> Hobbsee: Thanks.
* Hobbsee waits...
<geser> persia: I've talked about merging yakuake with Tonio_ and he's against a merge unless the is benefit of it by additional fixes/patches from the Debian package
<persia> geser: Additional debian patches include cleanup of libtool, more copyright, update of standards & compat, a change to quilt, and fixes to the .desktop file (my favourite).  If you think it proper, I'll reject the merge bug as "don't merge this".
<Hobbsee> persia: you might wait for tonio_
<persia> Hobbsee: Do you know his timezone?
<Hobbsee> persia: he's in france, or near it, iirc
<gpocentek> yep, in France
<gpocentek> anyone familiar with svn->bzr conversion?
<incorrect> hello!  i am just trying to pervu subversion,  infact this isn't package specific
<jdong> ok
<incorrect> i found i've found a web site with someone with the same error,  
<incorrect> you have told them they are using the wrong .dsc
<incorrect> however i followed the howto
<jdong> what's the error
<incorrect> i don't see what i missed
<incorrect> http://ubuntuforums.org/showthread.php?t=268687&page=11
<incorrect> i have the same error
<incorrect> just i was doing the gdebi
<jdong> incorrect: you're gonna have to give me the post number; I likely have different posts/page than you
<incorrect> ill just drop it into pastebin
<jdong> ok
<incorrect> wow pastebin seems b0r3k
<incorrect> http://pastebin.com/855928
<crimsun> don't use pastebin.com
<incorrect> oh
<incorrect> what should i use these days?
<Hobbsee> pastebin.ca
<jdong> paste.ubuntu-nl.something or something like that
<Hobbsee> or rafb.net/paste
<Hobbsee> that works too
<incorrect> oh
<incorrect> sorry i don't keep up
<jdong> incorrect: nobody has an error like that....
<jdong> "hostname: Unknown host"
<incorrect> oh
<jdong> ^^ that's your real error message
<jdong> the rest is a standard Python traceback after issuing an exception
<siretart> gpocentek: yepp. doable with tailor
<jdong> the cause of your error message is likely that your system does not have a hostname set
<incorrect> sure it does
<jdong> incorrect: issue hostname at the console and see if it reports back
<incorrect> how does it look up hostnames?
<siretart> gpocentek: but hostely, if it is an opensource project, I'd let do the conversion by launchpad
<jdong> incorrect: hostname at a console
<incorrect> hostname gives back seeds which is the name of my computer
<jdong> incorrect: try hostname -f
<incorrect> thank you
<incorrect> oh there is someone else with the same error
<incorrect> he had unknown hostname too
<jdong> ah, then I must've missed it
<incorrect> google's top entry for pervu unknow hostname
<jdong> I'm still amusingly puzzled about how it happens
<incorrect> and you talked about a missing dsc file
<jdong> ubuntu installer sets the hostname
<incorrect> that work! thank you
<incorrect> oh yeah very cool idea for an app
<jdong> incorrect: I said Toehead: maybe you didn't do prevu-init or something like that? At any rate,.....
<incorrect> second question,  if i need to compile up libs to get another app to compile
<jdong> that was my best guess at the time
<incorrect> okey dokey
<incorrect> do i prevu libneon26 subversion ? to get subversion to compile?
<jdong> no
<jdong> you first prevu libneon26
<jdong> then run prevu-update
<jdong> then prevu subversion
<incorrect> oh i get it now
<crimsun> argh
<incorrect> sorry,
<jdong> you also need to look at 'apt-cache rdepends libneon26' or whatever the actual library is called
<crimsun> backporting makes baby jebus WEEP.
<jdong> and rebuild any reverse dependencies
<jdong> crimsun: sorry baby jesus :)
<crimsun> I have to reintroduce an alternate b-d just for the vlc crack addicts
<jdong> crimsun: and we really appreciate it :)
<incorrect> i used to backport by hand, would take ages
<incorrect> on debian,
<jdong> (although to me VLC 0.9.6 looks just like the SVN snap Edgy shipped with)
<crimsun> ...0.9.6?
<bddebian> Heya gang
<jdong> crimsun: s/9/8/, you know what I meant :D
<crimsun> no, it's definitely not the same
* crimsun throws a Hobbsee at jdong 
<jdong> well, crimsun, I totally blame it on my keyboard
<crimsun> no, referring to the svn snap/release
<crimsun> the release has a fair number of bugs fixed
<crimsun> and well, still has a crackload open
<jdong> hmm
<jdong> what kind of bugs?
* jdong has yet to encounter problems with VLC
<crimsun> there's an entire LP page full...
<jdong> ha, ok
<crimsun> I need an amd64 with a dvd-rom
<jdong> crimsun: what needs to be tested?
<crimsun> that crasher's one of the most reported
<jdong> I got a feisty amd64 with a dvd drive
<crimsun> see if feisty's vlc explodes when you attempt to play a dvd
<jdong> ok, brb :D
<crimsun> oh great, CVEs
<crimsun> ooh, bddebian's here. I -know- he wants to fix these! :D
<jdong|amd64> crimsun: css-encrypted DVD plays fine in vlc on feisty
<jdong|amd64> /exec uname -a
<jdong|amd64> grr
<crimsun> I'm so tempted to reject all those bugs and blame hw :/
<jdong|amd64> Linux amd64 2.6.20-4-generic #2 SMP Fri Jan 5 02:54:59 UTC 2007 x86_64 GNU/Linux
<crimsun> -4-'s outdated ;)
<jdong|amd64> crimsun: can ya link me to one of those reports?
<jdong|amd64> and I know, slow wifi link
<jdong|amd64> don't feel like updating every day :)
<jdong|amd64> ooh, beryl blurring a negative movie :)
<jdong|amd64> *ahem* sorry back to work
<crimsun> bug 54334
<Ubugtu> Malone bug 54334 in vlc "vlc give segmentation fault on amd64 when playin dvd" [Undecided,Confirmed]  https://launchpad.net/bugs/54334
<bddebian> crimsun: Fix what?
<jdong|amd64> err
<crimsun> bddebian: these CVEs :)
<jdong|amd64> crimsun: [50811.419804]  hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
<bddebian> Hmm, first I'd need to know what a CVE is :-)
<jdong|amd64> that's probably VLC's "graceful error handler" for sector reads
<jdong|amd64> errors
<jdong|amd64> and I'm not gonna sandpaper any dvd's today to prove it :)
<crimsun> I honestly have better luck w/ totem-xine than with vlc
<jdong|amd64> but in any case, I cannot reproduce this on feisty amd64
<gpocentek> siretart: thanks, I'll have a look at tailor, but I'll certainly use LP anyway
<jdong|amd64> heh, vlc works fine for me
<geser> bddebian: CVE = Common Vulnerabilities and Exposures, see also http://cve.mitre.org/
<jdong|amd64> I typically use it over totem and others
<jdong|amd64> because it can boost audio using pre-amp  equalizer
<bddebian> geser: Ah, thx
<jdong|amd64> my laptop has pathetic speakers
<crimsun> I normally have four different players installed, which really cramps my HD space
<crimsun> (currently 30 MB free)
<jdong|amd64> ouch
<jdong|amd64> vlc doesn't need much space, does it?
<crimsun> normally frees about 35 MB by removing it and its dependencies
<jdong|amd64> well, for me that's not much, but for you that doubles your free space :D
<jdong|amd64> thought about mounting squashfs+unionfs for your root yet?
<jdong|amd64> LMAO
<jdong|amd64> a nice zapping of /usr/share/doc usually works wonders too
<crimsun> that was one of the first things I did
<crimsun> I even kill all the modules I don't need
<jdong|amd64> if you have muscle in your RAM and/or CPU, squash+union on like /usr/lib isn't a half bad idea
<jdong|amd64> I do that on a 2.5GB laptop
<jdong|amd64> P3-500, didn't slow down significantly
* jdong|amd64 heads back upstairs
<jdong> hey guys I had the worst nightmare ever, I dreamed that I was helping debug a VLC crasher and had to use gaim as my IRC client!
<Nafallo> ouch :-P
<jdong> Nafallo: say can we just bump up x264 and fix the build failures as they get reported? :D 
<jdong> (kidding)
<jdong> I'll finally have some time in about 6 hours
<jdong> need to brush up my starcraft skills for an asian party :P
<Nafallo> :-)
<jdong> apparently I'm not supposed to wall everything off with an enormous number of cannons?\
<Sp4rKy> hi
<Sp4rKy> please, i'm packaging a software which contains a duplicate font of the ttf-freefont package
<Sp4rKy> what is the best :
<Sp4rKy> 1) remove this copy and make a link to the correct ttf-freefont file
<Sp4rKy> 2) remove & patch the soft to use the good file ?
<sistpoty|uni> hi folks
<imbrandon> heya sistpoty|uni 
<sistpoty|uni> hi imbrandon 
<bddebian> Heya sistpoty|uni, imbrandon
<sistpoty|uni> hi bddebian 
<webben> I'd like to update a source package to the latest svn. As I'm likely to be hacking the source too, I'd ideally like to make the svn build directory and the package build directory the same.
<webben> Unfortunately when I try and checkout from subversion into the package directory, svn cannot complete because the debian directory, for example, already exists
<webben> Is what I'm trying to do craaazy? or am I just missing an obvious way to do it.
<sistpoty|uni> webben: do you have write access to svn?
<webben> sistpoty|uni, meaning what? do you mean do I have commit rights to the subversion repository I'm pulling down code from?
<webben> (if so, no)
<sistpoty|uni> webben: yes
<webben> i just want to get updates if they're made
<sistpoty|uni> webben: then I don't know really a way to use the same directory
<webben> ah bother
<webben> is there a good way to move files from a svn'd directory into a package?
<webben> because that would be the next best option.
<webben> (the svn'd directory kept up to date with svn update, but also containing my hacks)
<sistpoty|uni> webben: svnbuildpackage is quite good at that
<webben> sistpoty|uni, hmm ... interesting ... I'll have to read up on that. Thanks.
<Sp4rKy> please, i've 3 python files in /usr/lib/<mysoftware>/
<Sp4rKy> linda  warn me to put into /usr/share only 1 of this 3 python files, why ?
<sistpoty|uni> Sp4rKy: no idea, but I'd look at the shebang lines (or if these have shebang lines after all)
<sistpoty|uni> Sp4rKy: or if these are executable
<Sp4rKy> the three has chmod 644
<Sp4rKy> and has a shebang :/
<Sp4rKy> sistpoty|uni: so should i really move them (the three) on /usr/share, or not ?
<sistpoty|uni> Sp4rKy: please look at the new python policy (I still don't know it by heart)
<Sp4rKy> k
<Sp4rKy> These modules should be installed in /usr/share/module, or /usr/lib/module if the modules are architecture-dependent 
<Sp4rKy> :)
<sistpoty|uni> Sp4rKy: if these are modules, you should consider using python-support or pycentral
<Sp4rKy> i already use pysupport
<sistpoty|uni> :)
<Sp4rKy> so, this 3 files are python scripts, so they're arch-indep , right ?
<geser> herzi: hello, I'm looking at criawips. Is criawips 0.0.12 good enough to go into feisty or should the patch from bugzilla be applied on the current version?
<Sp4rKy> so, the python policy says i've to put them on /usr/lib/module
<Sp4rKy> right ?
<sistpoty|uni> Sp4rKy: right
<sistpoty|uni> Sp4rKy: ahm... no
<sistpoty|uni> Sp4rKy: sorry
<sistpoty|uni> Sp4rKy: if they are arch-indep, they should go to /usr/share/module
<Sp4rKy> what ?
<Sp4rKy> the python policy says : "These modules should be installed in /usr/share/module, or /usr/lib/module if the modules are  architecture-dependent
<sistpoty|uni> Sp4rKy: exactly... arch-dependent -> /usr/lib, arch-*in*dependent -> /usr/share
<herzi> geser: if you apply the patch you'll be at 0.0.12
<herzi> so, please include 0.0.12
<Sp4rKy> oups
<Sp4rKy> sistpoty|uni: sorry, i'd read arch-indep :)
<sistpoty|uni> hehe
<Sp4rKy> sistpoty|uni: so i put the 3 in /usr/share
<Sp4rKy> can i put them in /usr/share/<package> ?
<sistpoty|uni> Sp4rKy: doesn't pysupport do that for you actually?
<Sp4rKy> no
<Sp4rKy> because i use it only for python dep
<Sp4rKy> the files installation are done with .install file
<sistpoty|uni> Sp4rKy: ah... then please use it for more than the python dep...
<Sp4rKy> because the software is in python, but doesn't have python installation
<sistpoty|uni> Sp4rKy: so these are only private modules?
<ScottK> I'm back with another shot at libnet-dns-resolver-programmable-perl.  http://revu.tauware.de/details.py?upid=3977  I've never had to deal with recontructing orig.tar.gz before.  I'd appreciate it if someone could take a quick look and see if I did the directory/file naming properly...  
<geser> herzi: ok, I've already build 0.0.12 in a pbuilder and will hopefully upload it today.
<ScottK> I had to do this because Tollef rejected the original package due to not having the actual license text included in orig.tar.gz.
<Sp4rKy> sistpoty|uni: yes they are
<Sp4rKy> sistpoty|uni: there is one main script in python, and those 3 (private) modules
<sistpoty|uni> Sp4rKy: imo than to /usr/share/module... but as I already wrote, my knowledge about python stuff since the transition is quite limited
<Sp4rKy> k
<Sp4rKy> i'll try to just put the in /usr/share/module/ and patch the source for path
<Sp4rKy> and we'll see
<sistpoty|uni> Sp4rKy: maybe this will help: http://wiki.debian.org/DebianPython/NewPolicy
<Sp4rKy> i'm reading
* ScottK is afriad his last post was a real buzz kill...
<\sh> hooray....I can install ubuntu on most of our servers ... good news..
<Solarion> hello MOTU
<imbrandon> ello
* sistpoty|uni needs to run
<sistpoty|uni> cya
<synic> wait, fiesty is frozen?
<Solarion> anyone else have synaptic touchpad problems with a second user logged in?
<ScottK> synic: I think just for Herd 2 https://wiki.ubuntu.com/FeistyReleaseSchedule
<Solarion> I suppose I should upgrade someday sooner rather than later
<Solarion> later than the comps, tho
<synic> ScottK: ah, nice
<dholbach> geser: thanks for updating criawips
<geser> dholbach: np
<LaserJock> good morning MOTU land!
<palski> Just made my first merge, somebody want to review it?
<LaserJock> palski: got a URL for a debdiff?
<palski> wait a second, i'll upload it somewhere
<geser> palski: a better way is to file a bug, attach the debdiff and subscribe ubuntu-universe-sponsors
<palski> well, ok then I'll do that =)
<bddebian> Heya LaserJock
<LaserJock> hi bddebian 
<LaserJock> geser: but then I have to go look at u-u-s ;-)
<palski> hmm, I'll do both =)
<geser> LaserJock: perhaps palski writes you the direct url for the debdiff
<palski> LaserJock: http://www.vi64pa.net/Merge/jabber-merge.debdiff
<LaserJock> palski: hmm, your debdiff has some issues
<LaserJock> are you sure you debdiffed the right versions?
<palski> at least I tried?
<ScottK> Good morning Laserjock
<geser> LaserJock: it looks like a debdiff between the last ubuntu version and the merged one
<palski> LaserJock: against 1.4.3-3ubuntu2
<LaserJock> palski: debdiff <Debian version> <merged Ubuntu version>
* palski is debdiffing
<palski> LaserJock: second try http://www.vi64pa.net/Merge/jabber-merge2.debdiff
<LaserJock> palski: oh, that looks better
<LaserJock> palski: looks good, those are the only Ubuntu changes?
<ajmitch> morning
<palski> according to this http://patches.ubuntu.com/j/jabber/jabber_1.4.3-3ubuntu2.patch it seems so
<bddebian> Heya ajmitch
<ajmitch> \sh_away: you'll have to ping me sometime when I'm awake :)
<ajmitch> hello bddebian 
<LaserJock> palski: you just had a little mistake with the version, it should be ubuntu1 not ubuntu0
<palski> alright, changing that
<palski> LaserJock: is that ok after the change?
<LaserJock> palski: yep
<palski> LaserJock: ok, thanks for help =)
<LaserJock> palski: do you have a new url for it?
<LaserJock> or should I just make the change locally
<palski> already done that and filled a bug for merge
<palski> LaserJock: or are you goingto upload it right away?
<LaserJock> palski: what's the bug number? and yeah
<palski> bug #78721 and thanks again 
<Ubugtu> Malone bug 78721 in jabber "[Merge]  Jabber from debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78721
<LaserJock> palski: marked the bug as "Fix Committed", please mark it "Fix Released" when it builds ok
<palski> LaserJock: when it builds ok?
<geser> palski: you can also wait till hits the archive
<LaserJock> palski: I like to make sure that it infact builds in the Ubuntu buildds on all supported archs
<LaserJock> I just test i386 as that's all I have
<LaserJock> sometimes we just upload and forget and leave other archs busted
<ajmitch> and then find out 2 days after release
<ajmitch> & deal with user complaints for the next 6 months :)
<LaserJock> mhm
<ajmitch> not that LaserJock is bitter ;)
<LaserJock> never
<LaserJock> nor cynical
<palski> ok, thanks, but how do I know when all builds are ok?
* ajmitch was just reading the forums
<ajmitch> that always cheers me up
<LaserJock> haha
<ajmitch> go to the upload on launchpad, eg 
<ajmitch>   }else{
<ajmitch> bah
<ajmitch> https://launchpad.net/ubuntu/+source/zope2.9
* ajmitch waits & waits for launchpad to respond
<LaserJock> bah
<ajmitch> click on the latest version
<ajmitch> (or any version, really)
<ajmitch> and it shows you the builds
<palski> ok, thanks ajmitch 
<LaserJock> palski: it'll take a while for it to show up because of the Herd 2 freeze
<ajmitch> yay, freezes
<Adri2000> universe is not really frozen
<Adri2000> only manual approving
<Lutin> bddebian: fixed that damn typo in gfaim
<bddebian> :-)
<somerville32> Can someone poke for pyNeighborhood to be approved? Xubuntu people are going to want to test it in Heard 2.
<Adri2000> Seveas: are you going to approve new members on LP today?
<Seveas> Adri2000, if I have som time left
<LaserJock> somerville32: it was uploaded wasn't it?
<LaserJock> I did it yesterday
<somerville32> It still isn't approved by Archive Admins
<Adri2000> Seveas: ok, could you also set my cloak when I'm approved on LP please?
<Seveas> Adri2000, will do
<Adri2000> thanks
<Lutin> Seveas: could you also set my cloak when I'm approved ?
<Seveas> Lutin, check
<LaserJock> somerville32: I'm guessing that'll take a while
<LaserJock> somerville32: perhaps a week or so
<geser> Seveas: could you also set up a cloak for me while you are at it?
<Seveas> noted
<ernstp> Has anyone thought about adding http://debian.are-ata.org/capt/ to Ubuntu?
<Seveas> any others? :)
<ernstp> It's drivers for a special Canon printer protocol
<ajmitch> ernstp: you could package it if you wanted, and if it's freely distributable
<ernstp> there's allready a guy who's made his own debian packages of it:
<ernstp> #for cupsys capt driver
<ernstp> deb http://debian.are-ata.org/ all main
<ernstp> deb-src http://debian.are-ata.org/ all main
<mr_pouit> Seveas, if you could also set a cloak for me when I am approved, thanks :)
<Seveas> mr_pouit, you still have to wait for mako, right?
<LaserJock> ernstp: then make sure that they work on Ubuntu and upload them to REVU
<Seveas> ernstp, and make sure they're freely redistributable :)
<mr_pouit> Seveas, yes
<Seveas> mr_pouit, then pease poke me when you're approved
<mr_pouit> ok ^^
<bddebian> Lutin: Does the Jan 9 upload of kayali have a new orig.tar.gz?
<Lutin> bddebian: unfortunately not yet
<bddebian> OK
<Lutin> bddebian: updtream told me he would provide me a nex this weekend
<Lutin> upstream*
<bddebian> OK
<Lutin> bddebian: btw, I'm really not sure about the license of some fonts in the package (see my first comment). could you have a look to tell me what you think about that ?
<bddebian> I'm the wrong guy to ask about licensing :(
<Lutin> ok 
<Lutin> bddebian: who could I bug about that ?
<bddebian> Maybe sistpoty or crimsun?  Dunno.
<Lutin> ok, thanks :)
<ScottK> bddebian: Do you have a moment to look at another package (should be an easy one): http://revu.tauware.de/details.py?upid=4027
<Lutin> thanks bddebian :)
<Lutin> LaserJock: could you have a look to gfaim when you'll have some time ?
<LaserJock> Lutin: did you take care of the other comments?
<bddebian> Lutin: Already done man :-)
<bddebian> ScottK: Give me a sec
<Lutin> LaserJock: yep, should be fixed. at least I hope
<ScottK> Thanks
<LaserJock> somerville32: ;-)
<somerville32> LaserJock: had to try ;] 
<LaserJock> Lutin: working on it now
<Lutin> LaserJock: cool :). thx
<metres> Hi all, i'm having a question : why does when using debuild on a package with a - in the name result as an _ in the name ?
<Lutin> metres: maybe because it is the way it works
<metres> it's normal then
<Lutin> yes
<LaserJock> metres: I think it's because we use - for versioning
<LaserJock> and yeah, it's normal
<Sp4rKy> bddebian: during your review, if you want re-review devede, i've correct all the linda/lintian warning :)
<bddebian> Sp4rKy: OK
<metres> another question... is it normal that I have been able to install a program(xvidcap) and that the packaging process ask for scrollkeeper package which is not in the repos..?
<Lutin> metres: yes, it's possible
<Sp4rKy> bddebian: thx :)
<sladen> metres: if it doesn't "just work", then it's not normal and a bug that needs reporting
<metres> so I have to package scrollkeeper package first...
<LaserJock> no
<Lutin> metres: scrollkeeper is already in the repos
<sladen> metres: no, it's installed by default
<sladen> metres: what is your /exact/ error message?
<metres> configure: error: Couldn't find scrollkeeper-config. Please install the scrollkeeper package: http://scrollkeeper.sourceforge.net
<Lutin> metres: but we may want to specify it as a build-dependancy in debian/conotrol
<Lutin> you*
<sladen> metres: this is during when you compile 'xvidcap' ?
<LaserJock> Lutin: gfaim should depend on enscript don't you think?
<metres> sladen : sudo pbuilder build *dsc
<Lutin> LaserJock: I read the debian policy about that several times
<Lutin> LaserJock: and still don't know
<bddebian> LaserJock: Why?
<LaserJock> Lutin: there's a print button in the UI
<sladen> metres: do you have the build-deps installed/specified as Lutin says?
<LaserJock> it has to have enscript to use that print button
<bddebian> Ahh
<LaserJock> that seems like a Depends to me
<metres> I just find libscrollkeeper-dev  I will put it in the build-depends...
* LaserJock tries not to make any jokes about his previous comment
<metres> thanks guys :)
<Lutin> np metres
<sladen> metres: if the complation calls a program, that needs to be a build-dep
<Lutin> LaserJock: so, I set it as Depends: ?
<sladen> Lutin: yes
<Lutin> okok
<Lutin> thx guys
<Lutin> hope that will be the last upload
<Lutin> =)
<metres> when i change the control file, do I have to make the debuild -S -sa ? or only the pbuilder build ?
<Lutin> metres: you have to re-run debuild
<metres> thanks
<LaserJock> Lutin: "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality."
<LaserJock> Lutin: I think printing counts as "significant amount of functionality"
<Lutin> LaserJock: I think it's because I don't have any printer :] 
<LaserJock> well, if the print button was optional I could see it
<LaserJock> but it's on the toolbar
<Lutin> yep
<Lutin> thx for poiting this out
<LaserJock> and believe me, my wife likes to print recipies :-)
<Lutin> hehe =)
<Sp4rKy> is there a special thing to do to use path with both tarball.mk & simple-patchsys.mk added to rules ?
<Lutin> sure, it's important. 
<Lutin> Sp4rKy: mean patch ?
<Sp4rKy> of course :)
<LaserJock> Lutin: done
<LaserJock> Lutin: get bddebian to look it over again and upload
<Lutin> thanks LaserJock :)
<LaserJock> Lutin: np, thanks for contributing to Ubuntu
<Lutin> :)
<Lutin> bddebian: around ?
<bddebian> Lutin: Yo
<Lutin> bddebian: should be ok for upload now
<ScottK> bddebian: Thanks for the REVU and advocating.
<bddebian> NP
<ScottK> Any other takers?  http://revu.tauware.de/details.py?upid=4027
<bddebian> ScottK: BTW, don't get too excited, most of my reviews are wrong :-)
<ScottK> bddebian: Is OK.  I'll take what I can get.  I got a relatively hard one for you if you're up for it. http://revu.tauware.de/details.py?upid=4024
<ScottK> Odd are good it's obviously enough wrong it won't take long....
<crimsun> gfaim doesn't need to b-d explicitly on pkg-config
<crimsun> libgtk2.0-dev already depends on it
<LaserJock> good point
<Lutin> should I re-re-re-re-upload then ?
<LaserJock> why not ;-)
<Lutin> hehe
<Lutin> just curious, is it really a problem ?
<crimsun> no
<Lutin> done :)
<Lutin> crimsun: btw, could you have a look at kayali ? I was asking me some questions about the font licensing
<crimsun> ScottK: you don't need the previous debian/changelog entries below 1.08.1-0ubuntu1, because they're already listed in CHANGES
<ScottK> Understand that.  The previous upstream maintainer has a bad habit on that.  He puts /debian in his upstream packages and does that.  I went back to him and asked him to fix some stuff today and the response I got was, OK, you maintain it.
<ScottK> So as of today, I am the upstream, but I didn't want to mess with what I inherited more than necessary on day one.
<crimsun> it'll make life simpler for you in this respect if you separate the upstream changes (CHANGES) from packaging ones (debian/changelog) imnsho
<ScottK> I will.  I just hoped to avoid doing it today.
<Lutin> LaserJock, bddebian: ok, fixed the B-Ds
<Laser_away> Lutin: done
<crimsun> there's an apparent license conflict for the database
<crimsun> wrt gfaim
<Laser_away> conflict?
<crimsun> The recipes database is freeware, please see legal_english.txt for further
<crimsun> informations
<crimsun> note "freeware"
<Laser_away> bah
<crimsun> "freeware with stipulations" == fun
<Lutin> lol
<crimsun> oh well, let the archive admins sort it
<crimsun> your job's done
<Lutin> crimsun: tollef didn't point that out when he rejected it the first time, so I thought it'd be ok
* ajmitch decides it's time to do the first upload for the year
<crimsun> Lutin: it should be fine since it's just a condition on the freeware portion
<Lutin> ok
<Lutin> hope so :)
<crimsun> [off-subject, but I hope msikma in -devel is referring to 4.-10-] 
<ajmitch> heh
* ScottK is off to cook dinner for the family...
<Sp4rKy> please
<Sp4rKy> entrance: maintainer-script-needs-depends-on-adduser postinst
<Sp4rKy> adduser is a based packaged
<bddebian> Sorry gang, gotta head home.  I'll catch devede and gfaim (again! :-)) after I get home.
<Sp4rKy> so i don't need to include it  in BD, right ?
<Sp4rKy> bddebian: ok thx bddebian :)
<Toadstool> heya everybody
<Sp4rKy> heya Toadstool 
<Lutin> heya Toadstool
<crimsun> Sp4rKy: not b-d. See the lintian message.
<Toadstool> Sp4rKy: adduser is not Essential, so it should be added to your B-D?
<Toadstool> hmm?
<crimsun> (note adduser's Priority anyhow)
<Sp4rKy> Toadstool: crimsun ok, i add it in dep
<Toadstool> oh yes, ... /me tired, not b-d, depends :(
<Sp4rKy> Toadstool: :)
<Sp4rKy> done the same mistake
#ubuntu-motu 2007-01-11
<Seveas> Adri2000, Lutin: cloaks are set
<Lutin> Seveas: great! thanks :)
<Adri2000> yay :)
<Seveas> geser (n=michael@ubuntu/member/geser) has joined #ubuntu-motu
<Seveas> geser, cloaked :)
<geser> Seveas: thanks
<metres> Hi guys, Lintian gives me that : E: xvidcap: menu-icon-not-in-xpm-format /usr/share/xvidcap/xvidcap.png any idea of the procedure..?
<somerville32> Yes
<somerville32> You need to convert it to png
<somerville32> use convert
<crimsun> you meant the other way.
<somerville32> then place the new xpm in debian/ and patch the source to use it
<somerville32> crimsun: right
<somerville32> You need to convert it to xpm, sorry
<metres> somerville32 : yes I convert it with gimp I want to know where to search in source to patch it...
<somerville32> debian/menu ?
<somerville32> and you'll want to patch the desktop file too
<somerville32> If it is just debian/menu, just edit it directly
<metres> there is no debian/menu... 
<metres> Sorry i got xvidcap.menu...
* somerville32 nods.
<metres> Lintian now return me that... : W: xvidcap: menu-icon-missing /usr/share/xvidcap/xvidcap.xpm which file tell which files are copied ?
<somerville32> You need to install your new xpm icon
<somerville32> and it should goto /usr/share/pixmaps
<somerville32> use dh_install
<somerville32> and the install file in debian/
<somerville32> ie.
<somerville32> debian/xvidcap.xpm /usr/share/pixmaps/
<metres> Thank you somerville32 
<somerville32> np
<somerville32> :)
<somerville32> When you upload to revu, want me to look it over to make sure you did everything right?
<metres> yeah but I have to get in the motu first... pending request to the ubuntu-dev team...
<somerville32> You can upload to revu w/o being in ubuntu-dev
<somerville32> Do you have a lot of experience packaging?
<metres> my frst :)
<metres> first sorry
<somerville32> lol
<somerville32> You might want to get some more experience before applying to ubuntu-dev
<somerville32> You can still contribute super easily though
<somerville32> You can upload your packages to revu where they get reviewed by MOTUs
<somerville32> then they'll upload it for you if it meets criteria :)
<metres> Nice, how do I upload to revu ?
<Lutin> metres: execute 'dput revu yourpackage*source.changes' in a console
<somerville32> metres: There is also some excellent info on the motu wiki
<metres> I'm opening it right now...
<somerville32> To upload to revu, you need to add yourself to this group: http://tinyurl.com/fgpgy 
<somerville32> And then it needs to be synced
<somerville32> So you'll need to wait for a revu admin
<metres> Im now a Contributor of packages for ubuntu universe
<somerville32> Awesome! :)
<somerville32> Welcome!
* somerville32 hugs metres.
<somerville32> Now you'll need to bug  someone like ajmitch to sync it for you
<metres> hehehe
<somerville32> After you upload your first package, you'll be able to login to the web interface to make comments on your uploads
<bddebian> Heya gang
<ajmitch> hello
<bddebian> Hi ajmitch
<somerville32> ajmitch: Can you sync revu with lp for metres please?
<metres> I still have my menu-icon-missing issue... 
<somerville32> metres: What does it say?
<metres> W: xvidcap: menu-icon-missing /usr/share/xvidcap/xvidcap.xpm
<somerville32> Did you install it to /usr/share/pixmaps ?
* ajmitch shouldn't speak up in here
<somerville32> @lart 28 ajmitch
<zul> yeah you shouldnt
<metres> yes
<somerville32> :)
<somerville32> metres: Then you need to modify the menu file to point to /usr/share/pixmaps/xvidcap.xpm instead of /usr/share/xvidcap/xvidcap.xpm
<metres> I add /usr/share/xvidcap/xvidcap to my /debian/xvidcap.files
<zul> somerville32: i think ajmitch is at work
<metres> I also made a   dh_install debian/xvidcap.xpm /usr/share/xvidcap/
<bddebian> At what point should we archive uploads with no responses?
<somerville32> crimsun: ping
<ajmitch> keyring resynced
<Jerub> hi!
<Jerub> I'd really like to be able to use universe package named 'ipset' with ubuntu, but I can't because there isn't a kernel module for it.
<Jerub> the kernel module can be built and packaged seperately to the kernel, but I'm not really sure how to go about that.
<Jerub> I've done the work of extracting out of patch-o-matic-ng the required patch, which I've put here: http://shiny.thorne.id.au/~stephen/set-2.6.20.patch
<Jerub> it's a netfilter module.
<lifeless> ajmitch: ^ who knows external kernel module packaging here ?
<bddebian> Not I
<somerville32> Not I
<jdong> Not I </bandwagon>
<somerville32> - Said the three little pigs.
<somerville32> Or wait.. wrong fairytale.
<bddebian> somerville32: Did pyneighborhood get uploaded or not?
<somerville32> bddebian, It did. Waiting for archive admins to approve it
<bddebian> OK, thx
<somerville32> np :)
<zul> lifeless: it shouldnt be too hard but i dont have the time or knowledge
<ajmitch> lifeless: not sure, sorry
<lifeless> zul: yeah, I know it shouldn't be too hard.
* ajmitch is heading out for a few min, too
<lifeless> zul: the question wasn't 'how hard is it', it was 'who knows already' ;)
<Jerub> of course, it's trivial to do incorrectly.
<Jerub> I'd rather it weren't done incorrectly however :)
<LaserJock> darn
<bddebian> Well hello to you too LaserJock :-)
<LaserJock> bddebian: sorry, just realized I missed the President's speech
<LaserJock> that's what I get for staying at the lab too long
<bddebian> I watched it
<somerville32> A president made a speech?
<LaserJock> they do that now and then
<metres> about 20 000 more americans in IRAQ
<zul> heh
<zul> suck
<metres> what a mess
<metres> Got a question on my missing file issue, how do I use dh_install, I tried in console and in th rules file but hadnt worked...
<LaserJock> you can do an install file and then call dh_install in debian/rules
<metres> in the debian/rules, I put the call in the build section ?
<somerville32> Yup
<LaserJock> metres: probably the install: rule
<lifeless> hmm
<bddebian> mmh
<LaserJock> mhm
<Jerub> hhm
<lifeless> I'm wondering what packages provide modules already
<ajmitch> lirc, alsa-modules, etc
<ajmitch> there aren't that many
<lifeless> Jerub: look at one of those ;)
<Jerub> lirc-modules-source is one of those annoying ones you have to build against the running kernel
<lifeless> Jerub: try alsa-modules
<Jerub> and alsa-modules isn't in feisty.
<lifeless> oh hmm
<lifeless> let me query
<lifeless> debian has tonnes
<lifeless> msidn-kernel
<Jerub> lifeless: looks like if you Build-Depends: patch-o-matic-ng, linux-source-2.6.20, then you can do something useful.
<lifeless> Jerub: yes, you still need to build the module and install it correctly
<Jerub> and patch-o-matic-ng isn't in ubuntu
<Jerub> oh, and how do I make something build-depends on the source of something else...
<lifeless> ok, table scan time
<lifeless> Jerub: dont depend on the other source, just have the files you need to build as independent. If you can.
<lifeless> Jerub: how would you build it manually?
<Jerub> don't know.
<Jerub> I guess I'd just use patch-o-matic and build the whole kernel.
<Jerub> but patch-o-matic depends on the source of iptables it seems.
<lifeless> in a few minutes I'll have a complete list of packages installing modules
<Jerub> (no wonder non of the patchomatic stuff is packages)
<lifeless> make-kpkg knows how to build module packages
<lifeless> but I'd ask benc
<rexbron> bddebian: Would you mind re-reviewing murrine, it's upid is 4033
<rexbron> also, that review request is open to anyone else
<bddebian> rexbron: I fear crimsun :-)
<rexbron> bddebian: I am asking him too
<persia> bddebian: You could just comment, without advocating...
<rexbron> =)
<lifeless> ok, heres some packages Jerub 
<lifeless> vmware-player-kernel-modules
<lifeless> linux-restricted-modules
<lifeless> linux-image-kdump
<lifeless> vmware-tools-kernel-modules
<lifeless> vmware-server-kernel-modules
<lifeless> Jerub: ^
<lifeless> they should all be reasonable examples of building kernel modules outside the kernel
<bddebian> rexbron: Did you do either of the two things crimsun mentioned?
<rexbron> bddebian: I did to the best of my knowledge as I remove an unessicarry dirs entry
<rexbron> s/remove/removed
<bddebian> rexbron: Where did you removed them?  You still have /usr/bin and /usr/sbin in debian/dirs file?
<bddebian> Also, you did not add the CREDITS file to the debian/docs file
<rexbron> ....
<rexbron> I thought I did
<bddebian> Hmm, maybe I didn't get the latest file when I downloaded?
<rexbron> this is strange...
<bddebian> Yeah, afaict I did
<rexbron> oh well, I will fix it
<Jerub> lifeless: yipe.
<Jerub> lifeless: applying this patch mutates iptables.
<lifeless> Jerub: so its not just new modules ?
<Jerub> oh, that's okay
<Jerub> iptables already has the patch
<rexbron> bddebian: I removed /usr/share/themes, that is what I believe crimsun was refering to
<bddebian> Ahh
<bddebian> You don't install anything in /usr/bin or /usr/sbin do you?
<rexbron> bddebian: it was there from the original upload
<rexbron> I will do a prefix install and check
<rexbron> bddebian: nope, they will be gone
<rexbron> but should the dirs file still exist?
<ScottK> Good evening/night/morning/afternoon, as appropraite...
<ScottK> appropraite/appropriate
<bddebian> rexbron: Nope
<rexbron> ok
<ScottK> Does anyone have a moment that is familiar with directory/file naming conventions when you have to reconstruct orig.tar.gz?
<rexbron> bddebian: ok done, care to re-evaluate?
<bddebian> rexbron: Done
<rexbron> thanks
<ScottK> Just in case someone is reading the backscroll later and is willing to take a look... http://revu.tauware.de/details.py?upid=4024
<persia> ScottK: I've never before seen a native package with a remote package style version name.  I'm not sure this is incorrect, but it is surprising.
<ScottK> OK.  
<ScottK> It's not meant to be a native package.  I had to reconstruct orig.tar.gz to add license text.
<ScottK> As I read the Debian (I think it was) Policy manual, that appeared to be the way to name it, but I wasn't sure.
* ScottK is looking for the reference.
<rexbron> ScottK: I hope upstream is includeing the licenses in the next release
<somerville32> It is my understanding that if the package doesn't include the license upstream then you don't have permission to distribute it or something
<ScottK> Sorry, it was the Debian Developers reference.
<ScottK> http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz
<somerville32> ScottK: I would refuse to package it until they have a proper license
<ScottK> Upstream said which licenses were applicable and pointed to URLs.
<somerville32> ScottK: If I told you that I had a copy of Microsft Windows OS and it was licensed under the GPL, do you think that would be good enough?
<ScottK> No.
<ScottK> But if you were the author of a program and you said it's licensed under GPL, I think it would.
<persia> ScottK: Either you missed item #4 in this (should have name *.orig.tar.gz), or I'm reading the data from REVU incorrectly.
<ScottK> After Tollef bounced the package ther first time, I e-mailed him and he said...
<lifeless> somerville32: theres no requirement for the licence to be in the source code for the code to be licenced.
<lifeless> somerville32: its just a best practice
<somerville32> lifeless: Ah, thanks.
<ScottK> That would be me misreading #4.  Thanks.
<persia> somerville32: If you had copyright for MS-Windows, then yes.
<lifeless> clearly, *I* can write some code, put the code [without a copy of the licence text]  up somewhere I control, and state 'I wrote this, and this is under GPL'
<ScottK> I'll go fix that then...
<lifeless> but it would be stupid
<somerville32> persia: Incidentally I just happen to have it here in my back pocket ;] 
<ScottK> If you go look, a large fraction of the Perl packages we get from Debian do not have license text in the package.
<persia> lifeless: Or just as result of inexperience :)
<lifeless> persia: stupid is as stupid does
<ScottK> This is a very small package, it's just a library needed for a more important one to follow.
<ScottK> Thanks again persia.
<persia> ScottK: No worries.
<persia> I'd like to add a patch to restore .desktop files to rapidsvn, but am not sure whether it should apply against the latest Ubuntu version or the latest Debian version.  The only differences between the two are the version numbers (-0ubuntu1 vs. -1) (even the maintainer is the same).  Opinions?
<LaserJock> they are exactly the same?
<persia> LaserJock: Well, the maintainer used his @ubuntu address in the ubuntu one, and his @debian address in the debian one, but otherwise, yes.
<LaserJock> Matthias
<LaserJock> persia: I think you can "merge" the debian and add your .desktop
<LaserJock> persia: although it should come from Debian or upstream upstream
<persia> LaserJock: Thanks.  If I find anything else like this, I'll merge.  In this case, it appears that the recent rebuild supercedes my earlier investigation.
<ScottK> Wow.  Looks like there was a little hicuup while I was working on my package.
<ScottK> I made another try - http://revu.tauware.de/details.py?upid=4036 persia - If you're still there I'd appreciate another look.  I think I'm closer, but still not sure I got it.
<persia> ScottK: The package structure looks more normal now.  I've nothing to add.
<superm1> crimsun, ping: did you get around to mythtv after i mentioned it the other day?
<ScottK> Thanks again for the help.
<crimsun> superm1: I haven't, no (mid-stride office migration, so everything's chaotic)
<superm1> ah, k
<ScottK> Good night everyone (it's getting a bit late here at UTC -5).  Thanks for the help/comments.
<somerville32> I'm UTC -4 and I'm still here :P
<LaserJock> somerville32: you're in CA?
<LaserJock> hi Hobbsee 
<somerville32> LaserJock: Yup :)
<Hobbsee|NotHere> hey LaserJock 
<LaserJock> anybody konw what the difference between dpkg-scanpackages and apt-ftparchive
<persia> LaserJock: man apt-ftparchive describes the differences.
<LaserJock> well, I read that
<LaserJock> it says it's dpkg-scanpackages+
<persia> LaserJock: As far as I know, apt-ftparchive packages foo is basically like dpkg-scanpackages foo, but apt-ftparchive also has the other commands (sources, contents, etc.).
<crimsun> nixternal: BenC motivated me to push him the conexant changes; your sound should be fixed RSN (probably in the next kernel?)
<Sp4rKy> hi there
<joejaxx> LaserJock: i just read your ml post how whould we go about that?
<LaserJock> joejaxx: using bzr?
<LaserJock> or -derivative mailing list
<joejaxx> LaserJock: whoops i meant the u-d ml
<LaserJock> ?
<joejaxx> yes that one
<LaserJock> make and rt request I suppose
<LaserJock> once there is some "critical mass"
<nixternal> crimsun: awesome!
<joejaxx> LaserJock: yeah
<nixternal> for the life of me i cannot find the freeze schedule for KDE now
<Hobbsee> nixternal: d.k.o
<nixternal> that's where it was a few days ago
<nixternal> unless, i bet it is removed since the 3.5.6 release is next week or so
<Hobbsee> you mean it's not there now?
<nixternal> they haven't set a freeze schedule for 4 yet
<Hobbsee> nixternal: http://developer.kde.org/development-versions/kde-3.5-release-plan.html
<Hobbsee> indeed
<nixternal> ya, they changed that page around. before when you went to the schedules, it was 3.5-r-p by default
<LaserJock> joejaxx: feel free to chime in on behalf of fluxbuntu on that thread
<LaserJock> I was glad to see somebody from Nexenta say something
<joejaxx> LaserJock: nexenta?
<joejaxx> i must have missed that one
* joejaxx looks
<LaserJock> opensolaris derivative
<joejaxx> they posted?
<joejaxx> i did not see that
<LaserJock> Erast Benson
<joejaxx> ahh
<joejaxx> oh ok
<Amaranth> quick question: are any of you actually subscribed to the -discuss mailing list?
<Hobbsee> Amaranth: i am.  for the moment
<Lathiat> -discuss? ;)
<Lathiat> is that the new non moderated list?
<Amaranth> yeah
<Lathiat> no
<Amaranth> it's worse than sounder from what i've heard
<Amaranth> i'm not on it
<LaserJock> I was
<Lathiat> you knwo why
<LaserJock> it wasn't
<LaserJock> bad
<Lathiat> because people are no longer afraid to post
<Hobbsee> Amaranth: yeah, it is.
<Lathiat> on -devel you'd get LARTed
<Amaranth> my -devel action is read-only though :/
<Hobbsee> everyone just posts crap on there
<LaserJock> really? I didn't think -discuss was as bad as the original -devel
<Amaranth> crap about eric raymond even, i've heard
<Hobbsee> LaserJock: it's worse.
<Hobbsee> LaserJock: dunno when you stopped joining
<Hobbsee> er, subscribing
<LaserJock> well, I just unsubscribed the other day, it must have gone downhill since then
<Lathiat> Amaranth: EVERYBODY LOVES ERIC RAYMOND
<Hobbsee> hehe
<somerville32> Rowdy in here tonight
<somerville32> ;] 
<LaserJock> I just trimmed my lists, I didn't have a prticular reason to unsubscribe
* Hobbsee headdesks
<LaserJock> hmm, doesn't look too bad at all to me
* Hobbsee contemplates being evil
<joejaxx> oh wow
<joejaxx> this list IS ridiculous
<Hobbsee> haha
<joejaxx> "what third party repository do you use ?x155"
<joejaxx> what a shame
<joejaxx> lol
<LaserJock> I'm still not seeing it, are you sure we are talking about the same list?
<Hobbsee> joejaxx: yeah...saw that...
* Hobbsee contemplates violating IRC OP laws, and using her ignore
<LaserJock> that was a good idea
<LaserJock> I thought, anyway
<LaserJock> although it's kind of not the best place to ask
<LaserJock> Hobbsee: they have OP laws?
<Hobbsee> LaserJock: yeah.  well, guidelines - dont stay op'd longer than you need to, etc
<dholbach> good morning
<ScottK> good morning.
<dholbach> hey ScottK
<ScottK> Hey
<ScottK> I left here 3 hours ago saying I was going to sleep, but no luck...
<Hobbsee> hehe
<ScottK> It's OK.  I got a couple of hours of coding done.  If all goes well I may have another package to add to the three I'm waiting on for revu now...
<ScottK> Anyone have a moment to REVU?  I've got two that I'd appreciate a look at...  One should be straightforward: http://revu.tauware.de/details.py?upid=4027  The other is slightly obtuse: http://revu.tauware.de/details.py?upid=4036 I'll be here for a bit still not sleeping...
<somerville32> I'll take a peak
<ScottK> Thanks.
<persia> ScottK: postfix-policyd-spf-perl doesn't exist in Debian (with this package name), so you might want to shorten the changelog (especially due to the native/non-native versions).
<ScottK> I've just taken over that package today (yesterday now) and the previous maintainer had a habit of including he /debian folder in the orig.tar.gz.
<ScottK> He also put ALL the changes in /debian/changes.
<ScottK> I thought it best to keep the changes I made for packaging to a minimum.
<somerville32> I thought we had to use @ubuntu.com address for the maintainer field
<lifeless> somerville32: why ?
<lifeless> somerville32: as in, got a url reference for that?
<somerville32> Yup
<somerville32> https://wiki.ubuntu.com/FeistyReleasePlan
<somerville32> mdz is the author
* ScottK is pulling it up now.
<somerville32> "Packages which have been modified in Ubuntu must now have their Maintainer field set to an @ubuntu.com email address, and the original Maintainer field renamed to Original-Maintainer, per DebianMaintainerField."
<lifeless> ok
<ScottK> OK.  News to me.
<lifeless> shame about the diversity a little, but fair enough. The change in fields is normal for some time
<persia> Ah.  New stuff to do when merging.  Is there a standard address to use for universe, or should each merger use their own?
<ScottK> Does this mean that I need to find someone to 'maintain' the packages for me or do I have an @ubuntu.com address I don't know about...
<Hobbsee> ScottK: are you a member?
<Hobbsee> ScottK: i presume you can use any address - your @ubuntu.com one, if you have one
<Hobbsee> (which most people do, as they're members)
<ScottK> Actually I found the 'official answer' I think...
<ScottK> https://wiki.ubuntu.com/DebianMaintainerField
* persia now has an incentive to become a member.
<somerville32> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
<ScottK> If the package is in universe or multiverse, the Maintainer field will be set to ubuntu-motu@lists.ubuntu.com
<ScottK> Am I the "Uploader" then?
<somerville32> For, postfix-policyd-spf-perl, debian/copyright isn't right
* ScottK opening the file...
<somerville32> You need to include the preamble or w/e it is called for the GPL
<somerville32> You also need a copyright notice for the debian package
<Hobbsee> ScottK: yeah, but you dont need to list the uploader
<Hobbsee> ScottK: as we dont do NMU's
<somerville32> ie.
<somerville32> The Debian packaging is (C) 2007, Cody A.W. Somerville <cody-somerville@ubuntu.com> and is licensed under the GPL, see above.
<ScottK> OK.
<ScottK> I can understand that.
<Hobbsee> ScottK: it still shows on LP that you made teh changes, and with you in the changelog, etc
<ScottK> Ah.
<ScottK> Sure.
<somerville32> "Contributions by various members of the SPF project" <-- I don't think you can assign copyright to a team like this
<somerville32> You also need to list the upstream authors
<ScottK> It came from upstream that way.  I read it as more of an acknowledgement than a copyright statement.
<persia> or at least the primary authors, as the contributors may be assigning copyright.
<somerville32> ScottK: It says you own the copyright and are the debian package maintainer?
<somerville32> Also, you need to have the date of debianization
<ScottK> There isn't actually a Debian maintainer...
<ScottK> Yet.
<somerville32> "This package was debianized by Cody A.W. Somerville <cody-somerville@ubuntu.com> on Mon,  8 Jan 2007 01:48:14 -0400."
<somerville32> ah
<somerville32> Ok, you need to remove that part from the copyright, I believe.
<ScottK> Will do.
<somerville32> You should refer to the packaging guide
<somerville32> It'll give you an example of what it should look like
<ScottK> Will do.
<ScottK> Thanks.
<somerville32> README.Debian is for notes about the package
<somerville32> It seems like you're giving notes about the software you're packaging
<\sh> moins
<ScottK> That one is there because what you have do to integrate with Postfix is different if you installed via a Debian package.
<ScottK> Because the path to the program is different.
<ScottK> Is there a better place to put that kind of information?
<somerville32> Is it for package maintainers or for users?
<ScottK> Users
<ScottK> System administrators
<somerville32> Then I don't think it should be there since they won't ever see it
<ScottK> Makes perfect sense.
<somerville32> You can use dh_installdocs
<ScottK> OK.  I'll look at that.
<somerville32> Right, you'll want to use that to install the rest of the documentation too
<ScottK> Thanks.
<somerville32> ie. README and INSTALL
<somerville32> Is postfix-policyd-spf-perl an executable script?
* ScottK is thinking the guy I took this over from doesn't know as much about debian packaging as he thinks he does...
<ScottK> It's called by Postfix and Postfix talks to it via stdin/out.  It's not a standalone script.
<somerville32> Your rules file is a little messy
<ScottK> Because of the stuff that's commented out and left there?
<somerville32> You don't currently need dh_install or dh_installdirs
<somerville32> Get rid of the commented out dh_* scripts
<ScottK> Because I already installed the one file that needs installing, right?
<ScottK> Yes.
<somerville32> Right
<ScottK> Thanks.  Am taking notes as we go...
<somerville32> Also
<somerville32> You're installing to the wrong place I think
<somerville32> arch-indep should go in share, not lib
<somerville32> but I might be wrong in this case
<somerville32> Is there a link for this code?
<somerville32> Like a website or something?
<ScottK> http://www.openspf.org is the project site.
<somerville32> Ok, then you need to add that to the description
<ScottK> OK.
<somerville32> Also, you're manually specifying the perl dependencies
<somerville32> You should have ${perl:Depends}
<ScottK> OK.
<ScottK> Debian-policy is where I look for guidance on where to install the file, right?
* somerville32 nods.
<somerville32> arch-indep in share and arch-dep in lib
<ScottK> OK.
<somerville32> Depends: libversion-perl, libmail-spf-query-perl -> Depends: libversion-perl, libmail-spf-query-perl, ${perl:Depends}
<\sh> yes..I'm LPIC-1 certified...
<\sh> now I can do the LPIC Ubuntu Vertification ;)
<ScottK> Ah.
<somerville32> Also, you'll find that that dh_perl won't work if you install to a non-standard directory
<somerville32> Which you do
<somerville32> So you'll need to manually specify
<somerville32> see man dh_perl
<ScottK> OK.
* somerville32 pants.
<somerville32> lol
<ScottK> That or put it in a standard one.  I don't feel a burning need to be non-standard.
<somerville32> ScottK: To be standard, you would install to:
<somerville32> /usr/share/<package-name>
<somerville32> so it's ok to be non-standard in this case (it appears)
<ScottK> No reason I can't do that.
<somerville32> The software will still work?
<ScottK> Sure.  I just need to change the documenation to match.
<somerville32> Could you use a post installation script to do that for the user?
<ScottK> I'd have to mess with Postfix config files.  Is that allowed?  I thought not?
<ScottK> I'm not sure it's a good idea even if it's allowed.
<somerville32> Will people expect this to work after they install it?
<ScottK> If they read the readme they'll know that they have to change their Postfix to use it.
<somerville32> Most people expect easy integration
<ScottK> Yes, but Postfix isn't famous for it.
<ScottK> Is it allowed for one package to mod another package's config?
<somerville32> In that case, you'll want to edit your control file to make a note in the long description to refer to the documentation giving a full path
<ScottK> That makes sense.
<ScottK> I'd rather leave them no worse off if they don't read the docs then break their system if their config is one I didn't anticipate.
<somerville32> And should the priority be extra or optional?
<ScottK> I'd say optional.
<ScottK> Well, maybe not...
* ScottK reads to the END of the description.
<ScottK> I'll change it to extra.
<somerville32> I think optional would be safe
<ScottK> OK.  I won't change it extra.
<somerville32> Also, instead of specifying the documents to install the the rules file
<somerville32> put them in debian/docs
<somerville32> one per line
<ScottK> OK.
<ScottK> I really appreciate you making the time to give me such a thorough review.
<somerville32> np
<somerville32> :] 
<somerville32> I just know I hate it when I have to wait for people to review my packages
<somerville32> So I figured I'd give it a shot and try and help you out
<ScottK> Thanks.  I've learned a lot.  I'll be back...
<somerville32> me too :)
<somerville32> see you in a bit
<metres> Hi guys i'm having a problem... http://paste.ubuntu-nl.org/1145/ can someone figure it out ? or do I have to bypass the configure file ? 
<ScottK> OK.  I"ve update the package and it's fixed (or at least better) http://revu.tauware.de/details.py?upid=4027
<ScottK> This time I"m really going to bed.  Thanks again for all the help.  I'll be interested to read any comments you have when I get up in two hours...
<somerville32> :)
<\sh> metres: configure expectes python version 2.3 and you have python 2.4 and 2.5  installed...which is the default nowadays...you have to update the source to use python 2.4 or 2.5
<metres> thank you \sh I succeed 
<\sh> metres: np
<persia> siretart: ping
<siretart> persia: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I'll respond when I am around.
<somerville32> :)
<somerville32> How many packages does a person usually package before the TB would consider them for -devel ?
<persia> Could somebody please type a close brace for me?
<somerville32> }
<persia> somerville32: Thank you (jp106 still doesn't map that key).
<somerville32> hehe
<Adri2000> somerville32: I think new packages is good, but MOTU is also merges and bugs :)
<christopher_l> Hello all, my new keyboard won't work, here's some information: http://pastie.caboo.se/32556. Someone?
<persia> somerville32: As Adri2000 said, it's not about the number of packages, it's about doing the hard and the tedious of universe maintenance (stealing the fun stuff isn't an incentive for recommendations).  Merges, library transitions, bug management, etc.  Look for hints in the topic of this channel as release approaches.
* somerville32 nods.
<somerville32> Thats what I meant
<somerville32> ;] 
<Adri2000> christopher_l: you are in the wrong channel, #ubuntu should be more appropriate
<christopher_l> nobody knows how to fix the problem there, so I am trying to find someone on differnet channels
<persia> somerville32: I reached about 20 patches applied to the archive before anyone approached me about starting the process.  That was a while ago, so the numbers may be inflated due to team growth.
<Adri2000> does anyone know gtk-doc? if I understand correctly, the upstream source tarball should only contain sgml/, and make should generate the tmpl and/or html files, right?
<Nafallo> Adri2000: I would ask in #ubuntu-desktop if I where you :-)
<siretart> persia: yes?
<persia> siretart: I was looking at the merge of oops, and thought I'd check with you in light of the hijack, but I couldn't get it to compile, so I gave up.
<siretart> persia: I think a sync should just be fine. if it doesn't compile, feel free to send me an buildlog
<siretart> persia: I'll check on the debian side and fix it there
<persia> siretart: OK.  For the buildlog, shall I just send `dpkg-buildpackage > oops.buildlog`?  Also, I liked all the readability fixes in debian/rules for 1.5.23.cvs-2.2ubuntu2, although I suppose it's cleaner to drop them.
<siretart> persia: I'd use 'tail', so you see the output in the shell. in general, I'd rather suggest using debuild instead, which creates buildlogs on every build in a '.build' file
<siretart> btw, both sbuild and pbuilder support  creating buildlogs
<persia> siretart: I've been trying to install pbuilder every few months since you first suggested it to me (still without success).  I'll take a look at sbuild.  Separately, expect an email with .build from debuild soon.
<siretart> persia: sbuild takes some more efford to setup. in combination with schroot and lvm snapshot, I think its unbeatable. I wrote a wiki page describing this setup
<siretart> persia: the build log really surprises me, cf. http://buildd.debian.org/fetch.cgi?pkg=oops;ver=1.5.23.cvs-3;arch=arm;stamp=1138342531
<siretart> pardon http://buildd.debian.org/fetch.cgi?pkg=oops;ver=1.5.23.cvs-3;arch=amd64;stamp=1142759810 for amd64
<persia> siretart: Given the lack of source changes, the fact that 2.2ubuntu2 is available on AMD64 was enough to make me stop at that point.  I don't understand the threading libraries well enough.
<siretart> persia: might be worth discussing it on #ubuntu-toolchain. unfortunately, I'm currently busy at work
<persia> siretart: No worries.  Looks to me like the difference between glibc 2.3 and glibc 2.5, but that's getting into lower-level stuff than I well understand.  May I leave it to you to chase tomorrow?
<siretart> persia: I'm not particulary keen on this, but I'll try to reproduce your bug by trying glibc from debian/experimental
<siretart> thats the drawback with having 'real' maintainers for one package ;) - (i'm co-maintaining it in debian)
<persia> siretart: OK.  As you are busy, If I can get sbuild configured in the next few hours, I'll send a buildlog from sid+experimental glibc.  Thanks for the help with this.
<\sh> wine-0.9.29 on its way
<siretart> \sh: w00t :)
<\sh> siretart: hehe ... birthday, LPIC-1 certification and new wine...what a great day :)
<siretart> \sh: todays your birthday?
<persia> \sh: Happy Birthday
<\sh> yepp
<siretart> \sh: congrats boy!
<\sh> every year on the 1th january...since 1971 ;)
<\sh> 11th :)
<siretart> noted ;)
<ogra> \sh, HAPPY BDAY !
<\sh> thx oliver :)
<jsgotangco> woooo
<poningru> \sh: happy bday
<poningru> will that .29 make it in time for herd 2?
<poningru> should I put it in the release notes
<\sh> Accepted:
<\sh>  OK: wine_0.9.29-0ubuntu1.dsc
<\sh>      -> Component: universe Section: otherosfs
<\sh>  OK: wine_0.9.29.orig.tar.gz
<\sh>  OK: wine_0.9.29-0ubuntu1.diff.gz
<\sh> This upload awaits approval by a distro manager
<poningru> sweet
<poningru> oh
<\sh> so someone from distro team has to approve it
<persia> Isn't there a freeze on to support the herd 2 build?
<\sh> that's what it says :) approval by a distro manager...build servers are in manual mode
<\sh> but wine is not in main
<\sh> so it's actually not release critical for herd2
<poningru> well yeah but marketing likes to put in stuff in universe as well ;)
<poningru> we're crazy like that
<persia> marketing could speak to distro management...
<\sh> well you could ask someone from the build admins...if it could be build and released before herd2 release...for me it's not so important if it's coming before or after herd2 release :)
<\sh> for me it's important that we could get a 1.0 release with Ubuntu 7.04
<poningru> persia: eyes and ears set to open, ramble away my friend
<persia> poningru: ?
<poningru> hehe nothing
<\sh> poningru: Accepted:
<\sh> wine 0.9.29-0ubuntu1 was ACCEPTED.
<\sh> 	Component: universe Section: otherosfs
<\sh> it will be build :)
<poningru> sweet
* poningru goes to changing a number
<hub> dholbach: why did you assign me bug 6090
<hub> dholbach: I'm neither upstream nor the package maintainer
<Ubugtu> Malone bug 6090 in nautilus "allow RAW pictures thumbnailing" [Wishlist,Confirmed]  https://launchpad.net/bugs/6090
<dholbach> hub: oh... you said something like "i need to figure this out", so I thought you'd intend to work on it
<hub> there are some bugs
<hub> with the gnome thumbnailer that cause problem with the package un *universe*
<hub> the wishlist is about to have that by default *in main*
<hub> but it does not matter
<hub> just that I'm not really working on it atm
<hub> if canonical wants to contract it, I'm fine :-)
<dholbach> ok - if you want you can just reassing it to desktop-bugs that's fine with me
<hub> ok
<dholbach> thanks
<bddebian> Heya gang
<dholbach> hiya bddebian
<bddebian> Hi dholbach
<\sh> moins bddebian
<bddebian> Heya \sh
<bddebian> dholbach: Do you have an opinion on what to do with packages that have been sitting on REVU for a while with no response?
<dholbach> bddebian: like you reviewed it, asked for some changes and nothing happened?
<bddebian> Like it has 3,4, some even have 7 comments with no response afaict
<bddebian> Of course part of the problem is that I don't really know what year they were uploaded :-)
<dholbach> no response of the uploader?
<bddebian> Aye
<dholbach> bin them
<dholbach> a month should be enough time to answer a request
<bddebian> OK, thx
<dholbach> thank YOU :)
<bddebian> Bah, I'm pretty useless lately :-(
<Lutin> s/pretty useless/reviewing a lot/ and I agree with you
<Lutin> dholbach: do you think that bug 61624 should be fixed ?
<Ubugtu> Malone bug 61624 in gnus "Please Recommend: or Suggest: idn" [Undecided,Unconfirmed]  https://launchpad.net/bugs/61624
* \sh needs to find the time to fix sitar asap.
<dholbach> phew, no idea about gnus
<Lutin> k
<\sh> moins nixternal
<Lutin> what's the section 'grml' in a2mp3  debian/rules ??
<nixternal> happy birthday \sh!
<\sh> nixternal: thx buddy :)
<allee> \sh: ah, didn't know.  Happy birthday!!!
* allee baks a virtual cake
* allee send it to \sh
* \sh thx all MOTUs :)
<white> \sh: happy birthday
<neutrinomass> are packages in dapper going to receive updates? 
<Lutin> motus: this package depends on lame, which is in mutiverse : https://bugs.launchpad.net/ubuntu/+source/a2mp3
<Lutin> should it go in multiverse as well ?
<neutrinomass> Lutin: (I submitted the report) Ubuntu policy doesn't allow packages in universe to depend in multiverse.... bug 77159 is a similar case
<Ubugtu> Malone bug 77159 in singularity "Please move to multiverse [feisty] " [Undecided,Fix released]  https://launchpad.net/bugs/77159
<Lutin> neutrinomass: ok, it's what I was thinking
<neutrinomass> Lutin: It sort of makes sense... if to install it you need to install something from multiverse, it defeats the entire concept of "freedom" 
<Lutin> besides, the 'section' of a2mp3 is kind of weird in edgy
<Lutin> neutrinomass: maybe you could bug dholbach about that, as he uploaded the package
<neutrinomass> Lutin: Yeah, I guess /sound would be good too , but I don't know the policy regarding the categories (if any).... File a bug report so that somebody takes a look at it with the next upload (a2mp3 is generally unusable at the moment  )
<dholbach> neutrinomass: which one?
<neutrinomass> dholbach: I'm bugging you
<neutrinomass> dholbach: a2mp3
<dholbach> that must have been a mistake - I never intended to
<dholbach> I'm kidding - what's the problem with it?
<neutrinomass> dholbach: Several actually ... https://bugs.launchpad.net/ubuntu/+source/a2mp3/+bugs
<Lutin> dholbach: is in universe ans depends on mutiverse pkg. and wrong section in edgy at least
<dholbach> neutrinomass: could you subscribe ubuntu-archive to the bug explaining the multiverse issue?
<neutrinomass> dholbach: I already did but they are rather busy it seems after the holidays 
<dholbach> I'm not maintainer of the package and too busy to take care of its bugs.
<dholbach> right
<dholbach> but there's nothing I can do - I can't shift it somewhere else
<neutrinomass> ok ok
<dholbach> but it's good you noticed the problem
<dholbach> I didn't realize
<neutrinomass> I'll see if I can prepare an upload to fix it
<neutrinomass> dholbach: Shouldn't it be -0ubuntuX btw ?
<dholbach> I think that's one of the apt-get.org packages
<dholbach> which had a -X already
<neutrinomass> Erm... still, current version is "0.01" and it's not in debian
<dholbach> let me get the source
<dholbach> I didn't upload it
<dholbach> it was synced
<dholbach> (not from Debian, but from the repository in question)
<neutrinomass> Ok, I wasn't quite aware of this. If I make an update to it, it should be "0.01-0ubuntu1"/"feisty" right ?
<dholbach> 0.01ubuntu1
<dholbach> just add ubuntu1
<dholbach> but yeah, that's fine
<neutrinomass> dholbach: ok thanks... :) you're free to go :p
<dholbach> I had my turn in the meeting already, so I had some time anyway ;-)
<gpocentek> dholbach: will the MOTU Council be on the next TB Agenda?
<gpocentek> dholbach: hello BTW ;)
<dholbach> gpocentek: we should make sure it's on there
<dholbach> gpocentek: with all the open questions we have
<dholbach> gpocentek: and ask sabdfl to make sure he can make it :)
<gpocentek> :)
<ScottK> Good afternoon everyone.  
<cypher1> crimsun, hi
<cypher1> crimsun, can we discuss regarding the comment you had put for bug #76483 ?
<Ubugtu> Malone bug 76483 in ipac-ng "Merge ipac-ng 1.31-3 from Debian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/76483
<crimsun> cypher1: ignore it; I'll process it 
<cypher1> crimsun, thanks !
<cypher1> crimsun, thank you .. say your comment now :)
<gnomefreak> who deals with flash package?
<\sh> anyone :)
<Toadstool> the only package that is maintained by only one person in universe is wine ;)
<Toadstool> hi everybody
<hub> macromedia/adobe deal with flash
<bddebian> Heya Toadstool
<Toadstool> hey bddebian 
<\sh> Toadstool:lol :)
<\sh> Toadstool: it's because nobody else wants to fck around with this strange emulator
* \sh runs
<Toadstool> heh
<\sh> and, tbh, I'm dealing with sles9 at work..so I'm a bit masochistic and can deal with it =|>
<Toadstool> rofl
<Toadstool> sles9, at least your working in a linux environment... :/
<Toadstool> *you're
<\sh> Toadstool: and how happy I was yesterday, when I heard, that I'm allowed to install ubuntu on all our servers from now on
<\sh> only the oracle servers will be still sles9
<Toadstool> lucky guy, I have to struggle with xp, office, visual studio and clearcase, it drives me crazy sometimes
<\sh> Toadstool:well on my company laptop I have also xp running and on the desktop machine...just because of our *censored* token authentication, which doesn't work under linux :(
<ScottK> bddebian: While you are busy cleaning up the REVU queue, would you mind taking a look and and (hopefully) re-advocating http://revu.tauware.de/details.py?upid=4038.  After somerville32 got through thrashing me here last night (for me anyway), I had a little work to do...
<bddebian> ScottK: OK, I'll try to take a look in a few
<ScottK> Thanks.
<crimsun> gnomefreak: essentially, me.
<gnomefreak> crimsun: crap i lost the bug. ill find it. 
<gnomefreak> crimsun: is this bug something we can do anything with? https://launchpad.net/ubuntu/+source/firefox/+bug/14911 it seems flash 9 fixes the issue but we cant put flash9 in repos other than the backports and they arent really supported
<Ubugtu> Malone bug 14911 in firefox "Flash plugin problem with ARGB visuals causes crash" [Unknown,Confirmed]  
<gnomefreak> is this something flash upstream can patch for flash 7 or just something people have to live with.
<crimsun> the latter for sure
<crimsun> I can't dictate what upstream will or won't do, so I can't answer the former
<gnomefreak> i figured as much. 
<crimsun> it's not a Firefox bug per se
<gnomefreak> just wondering if we can close it but its been sent upstream already
<gnomefreak> yeah i know its flash. i was in a meeting about mozilla bugs/team and this bug poped up and not sure what the hell do to with it
<crimsun> talk with iwj in -devel; if he agrees to allow it to be reassigned to flashplugin-nonfree, then do so and you have my blessing to mark it Fix Released.
<crimsun> off to lecture.
<gnomefreak> ok ty
<ScottK> If there's a package that's been orphaned in Debian, is there a way I can 'adopt' it so it won't fall out of Ubuntu?
<zorglu_> debian has doc spefically for this
<zorglu_> dont remember the url, just saw it in the past
<ScottK> OK.  Will go look.
<ScottK> I've got no relationship with Debian, so I was wondering about something Ubuntu specific for MOTU.
<ScottK> bddebian: Thanks for looking at it.  Your comment hits a question I was unsure about.  Do I leave the upstream INSTALL file intact and then put a new INSTALL file in /debian and then have my rules install the /debian one?
<bddebian> ScottK: I don't think you should install the INSTALL file at all, should you?
<ScottK> The problem I am trying to solve is that there is some manual configuration of Postfix required to intgrate this after the installation is complete.
<ScottK> intgrate/integrate.
<ScottK> What you have to do with the Debian/Ubuntu package is different than what you would have to to with the upstream version because the path is different.
<ScottK> Where do I document that?
<ScottK> That's the point I'm struggling with...
<ScottK> I'd love suggestions.
<geser> README.Debian perhaps
<bddebian> ScottK: You probably need to add something to debian/  and then display that on postinst
<ScottK> geser: It was in README.Debian and somerville32 pointed out that that is for packaging stuff.  A user would never see it.
* ScottK has yet another thing to go learn about packaging...
<ScottK> That sounds right.
<ScottK> If anyone knows of a simple package that uses postinst to display stuff that I can learn from, I'd appreciate a pointer.
<gnomefreak> crimsun: i went and added flashplugin-nonfree to it and confirmed it since well alot of people having the issue
<geser> ScottK: http://www.debian.org/doc/manuals/maint-guide/ch-dother.en.html , point 5.1
<geser> sounds like the right place to document the different path
<geser> if you do that instead in your postinst you must use debconf (or similar)
<geser> ScottK: see also http://merkel.debian.org/~ballombe/lintian-etch-i386/reports/Tpossible-debconf-note-abuse.html
<ScottK> geser: Thanks (was AFK dealing with a coffee emergncy)
<somerville32> ScottK: Btw, make sure to double check the things I told you last night. I've only ever done one package, lol
<somerville32> But I'm pretty confident we're on the right track
<ScottK> OK.
<ScottK> Thanks.
<ScottK> I'm reviewing the changes with the guy that was helping with packaging it on another channel right now.
* somerville32 nods.
<Le_Vert> hi motus
<LaserJock> hi Le_Vert 
<LaserJock> any Java people about?
<somerville32> maybe
<zorglu_> i have a "deamon" run for a given user, more like a background process, and i would like it to be started when the compute boot (aka not when the user login), is there a typical/recomended way to do this ? (currently i doing something like "put this script in /etc/rc.local" and the script starts the deamon)
<LaserJock> I think /etc/rc.local is the normal thing to do, but I'm not positive
<zorglu_> ok thanks
<Adri2000> do you think bug 62346 needs a SRU?
<Ubugtu> Malone bug 62346 in obconf "Missing libobrender.so.1 -> unable to launch obconf" [Unknown,Fix released]  https://launchpad.net/bugs/62346
<somerville32> Adri2000: Does it meet the requirements on the SRU page?
<Adri2000> obconf: error while loading shared libraries: libobrender.so.1: cannot open shared object file: No such file or directory
<Adri2000> it makes the package unusuable
<Adri2000> but there is an easy workaround
<Adri2000> and the fix is only a rebuild
<somerville32> cjwatson might approve it but you'd most likely have better luck with a backport
<mr_pouit> Adri2000, ping a member of the SRU team ^^
<LaserJock> yeah, that's sort of tough
<somerville32> Have you read this? https://wiki.ubuntu.com/StableReleaseUpdates
<LaserJock> it's obvious regression, and easy fix
<LaserJock> but it's also a big pain in the butt :-)
* somerville32 nods.
<Adri2000> somerville32: isn't it https://wiki.ubuntu.com/MOTU/SRU ?
<mr_pouit> https://wiki.ubuntu.com/MOTU/SRU
<somerville32> Adri2000: Oh, the package is in Universe?
<mr_pouit> Adri2000, oops, I came too late, as usual ^^
<somerville32> Adri2000: Propose it ;] 
<Adri2000> ping crimsun siretart StevenK: I would like your opinion about a SRU for bug 62346
<Ubugtu> Malone bug 62346 in obconf "Missing libobrender.so.1 -> unable to launch obconf" [Unknown,Fix released]  https://launchpad.net/bugs/62346
<Adri2000> version should be ubuntuX.1~proposed1, right?
<Adri2000> I don't see that on MOTU/SRU
<somerville32> Looks about right
<Adri2000> hmm but for rebuild, it should be build, not ubuntu
<Adri2000> (this package has no ubuntu change)
<LaserJock> hmm, that might take somethinking
<LaserJock> what's the version right now?
<Adri2000> 1.5-3
<Adri2000> for a SRU, I'd say use ubuntu0.1, not build
<LaserJock> well, you might do 1.5-3~proposed
<Adri2000> because we don't care of the automatic sync
<LaserJock> but I'm not sure about that
<LaserJock> you might do some dpkg --compare-versions to see
<geser> 1.5-3~proposed should be smaller than 1.5-3
<lifeless> 1.5-3~ is lower
<lifeless> theres a policy on SRU versioning
<lifeless> its the same one used for security updates
<LaserJock> lifeless: yes, but I don't know what it would be for a non-ubuntuX versioned package
<lifeless> LaserJock: huh?
<Adri2000> ubuntu0.1 no?
<Adri2000> lifeless: for a package with no ubuntu change
<LaserJock> lifeless: normaly it woudl be a build1
<LaserJock> so build1~proposed1?
<lifeless> https://wiki.ubuntu.com/SecurityUpdateProcedures
<lifeless> 2.0-2                  2.0-2ubuntu0.1
<Adri2000> 0.1, like the new upstream version NMUs in debian
<keescook> I need to fix the dpkg patch to handle the "." style... it doesn't like SRU/security versions.  :)
<LaserJock> hmm, I don't really like that though
<lifeless> LaserJock: its not a matter of like... thats the current policy - feel free to raise it on ubuntu-devel for review if you dont like it.
<LaserJock> that'll mean we have to merge the bugger for Feisty+1
<keescook> LaserJock: shouldn't it just be build1 for -proposed, and then build2 for -updates?
<lifeless> LaserJock: huh, the SRU is not going into feisty, its going into edgy
<lifeless> LaserJock: it has no impact on feisty or feisty + 1
<LaserJock> lifeless: true :/
<LaserJock> forgot that, went to the dentist this morning, my brain's not quite all there ;-)
<LaserJock> keescook: I think putting ~proposed or ~prop is a good thing
<LaserJock> just to keep track of things
<keescook> LaserJock: yeah, probably right.
<LaserJock> I'm having  a hard enough time as it is
* Adri2000 would do 1.5-3ubuntu0.1~proposed1 for -proposed and then 1.5-3ubuntu0.1 for -updates, will wait for SRU team opinion
<LaserJock> I can't see my uploads
<LaserJock> so I have to go trolling in Sources files to see if it's actually there or not
<keescook> Adri2000: yeah, that seems right.
* enyc is waiting for archive admininistrator people to put -proposed packages in http://archive.ubuntu.com/ubuntu/pool/universe/q/qpsmtpd/ -- ?am I looking in the wrong place?
<LaserJock> enyc: if it's for qpsmtpd then that's right, although LP should show it too
<enyc> LaserJock: ??LP??
<LaserJock> Launchpad
<enyc> LaserJock: coo... how do I see the testing version etc.?
<LaserJock> well, once it's accepted it should show up on launchpad.net/distros/ubuntu/+source/<packagename>
<tsmithe> could i ask the favour of revu'age?
<somerville32> What do you want tsmithe? :)
<tsmithe> http://revu.tauware.de/details.py?upid=3902 <= alsa-firmware
<tsmithe> and...
<geser> LaserJock: afaik the archive is still frozen, uploads to universe have to accepted by hand
<tsmithe> http://revu.tauware.de/details.py?upid=3892 <= alsa-tools
<tsmithe> ;)
<enyc> LaserJock: well thats odd... https://launchpad.net/ubuntu/+source/qpsmtpd does not show the packages yet...
<enyc> LaserJock: they have both been 'approved' with enuogh +1 's by universe team etc.
<LaserJock> geser: right, that's fine
<enyc> LaserJock: as ~proposed etc.
<LaserJock> enyc: yes but it's not in -proposed yet
<LaserJock> that's what I'm talking about
<LaserJock> it has to be approved by the archive admins
<LaserJock> we seem to be having approval bottlenecks again
<enyc> LaserJock: bah! is this a problem
<somerville32> tsmithe: ok, I'll review
<tsmithe> kk
<tsmithe> thanks cody
<enyc> LaserJock: bah, erm... is this a common problem ?
<LaserJock> sort of
<enyc> LaserJock: does this happen at certain times in release-cycles etc.?
<LaserJock> we always have times where the archive admins have a backlog
<enyc> LaserJock: I see
<enyc> LaserJock: what do they need to check about the upload?
<LaserJock> as it gets closer to release time and they get busier it does
<LaserJock> enyc: they just have to approve it (flip the switch or whatever) as far as I know
<LaserJock> enyc: the good news is you've done all you're supposed to do :-)
<LaserJock> you just gotta wait now
<enyc> LaserJock: thats fine then ;-)  Im not trying to be impatient... but I do like to understand problems like this
<somerville32> tsmite: It'll be a second but I will review it
<ScottK> somerville32: I have a question about last night's (for me) advice...  You said I need a copyright statement for /debian.  I looked in http://www.debian.org/doc/manuals/maint-guide/ch-dreq.en.html#s-copyright and I don't find such a requirement.
<somerville32> Not for /debian, the entire debian package
<siretart> bug #62346
<Ubugtu> Malone bug 62346 in obconf "Missing libobrender.so.1 -> unable to launch obconf" [Unknown,Fix released]  https://launchpad.net/bugs/62346
<chillywilly> um, quick question...how do I see the init script messages in edgy but not the noise from the kernel?
<chillywilly> this is on a server machine
<chillywilly> I'd like to see what is booting up when, etc. but not he kernel messages on the console
<Adri2000> siretart: so? :)
<siretart> Adri2000: hi
<Adri2000> hello siretart 
<tsmithe> who's gonna make my day and revu my alsa-* packages?
<Adri2000> siretart: what do you think of a SRU for this bug?
<siretart> I'm currently testbuilding it on my amd64 box
<siretart> the debdiff is IMO quite big, and I'm not familiar with these glade changes
<siretart> I have no problem with approving it in -backports, though
<Adri2000> siretart: the debdiff between what and what? I thought that only a rebuild was needed to fix this bug
<siretart> Adri2000: according to the buglog, it seems that version 1.6-1 is needed
<Lutin> tsmithe: the diff of alsa-firmware is huge. wht did tou include the configure files in it ?
<Adri2000> "A fix has been provided in debian version 1.5-4."
<siretart> Adri2000: this makes a diff from 1.5-3/-4 to 1.6-1
<siretart> the only change between -3 and -4 was to orphan to package
<siretart> Adri2000: do you use that package on your workstation?
<Adri2000> no, and I haven't got edgy anymore on my desktop
<tsmithe> Lutin, i will remove them. unless its not necessary...
<Lutin> tsmithe: the bigger diff, the worst (if you can avoid it of course)
<tsmithe> ok
<tsmithe> it seems i changed the files through carelessness...
<tsmithe> ill rebuild it...
<Lutin> :)
<siretart> Adri2000: well, as said, I don't think a mere rebuild will fix the version. the diff to the next upstream version isn't that big, however.. 
<siretart> this leaves me somewhat undecided
<Adri2000> according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385464;msg=15 and a comment on malone, a rebuild is sufficient
<Ubugtu> Debian bug 385464 in obconf "obconf: does not run with new openbox version" [Important,Closed]  
<siretart> Adri2000: oh. fascinating.
<siretart> Adri2000: in this case, I'd approve the rebuild, of course. 
<Adri2000> ok, I'll do that tomorrow
<Adri2000> siretart: can you approve the "Nomination  for Edgy" of the bug please
<Adri2000> maybe it's not called "nomination" for core-devs, I don't remember
<Adri2000> target?
<siretart> Adri2000: please see https://wiki.ubuntu.com/MOTU/SRU for our policy
<siretart> Adri2000: first, subscribe motu-uvf, attach your debdiff, wait for 3 acks and then upload it
<siretart> oh, and assign the bug to you ;)
<Toadstool> motu-uvf for a SRU? :)
<Adri2000> siretart: I know I know, but I wanted to have an edgy task in the same bug (only core-devs can approve these nominations/targets for release), but maybe you want me to file another bug for the SRU?
<tsmithe> Lutin, i've reduced it down to 40KiB - is that ok? it still contains changes in config.guess; but i don't know how acceptable that is
<siretart> argl
<siretart> s/motu-uvf/motu-sru/
<Adri2000> eheh
<siretart> sry
<Toadstool> heh
<siretart> Adri2000: honstely, I still don't get this nomination stuff. I'm not sure if implements the requirement that we need 3 acks
<Lutin> tsmithe: config.{guess,sub} are useless in the diff
<tsmithe> hmm
<tsmithe> ok 
<tsmithe> i'll fix that then
<Adri2000> siretart: look at this bug https://bugs.launchpad.net/ubuntu/+source/k3d/+bug/64848 which uses that for a SRU
<Ubugtu> Malone bug 64848 in k3d "[SRU: EDGY]   packaging typo - k3d does not install" [High,Fix committed]  
<siretart> aha?
<siretart> hm. I think then its safe to approve the nomination, since it 'just' creates a new bugtask
<siretart> aah, now I think I got the point of these nominations..
<Adri2000> :)
<siretart> Adri2000: okay, I think you can proceed now with the 'normal' protocol :)
<tsmithe> Lutin, i've fixed that and it looks quite clean now (although it's still uploading). if you could take another look soon when it's done that would be fantatstic. (stoopid slow upload speeds)
<Adri2000> yep, just added a comment to the bug
<Lutin> tsmithe: ok
<tsmithe> thanks - the upload was quicker than i thought - so it should be ready soon
<Lutin> tsmithe: i'm not a motu though :)
<tsmithe> doesn't matter! i appreciate it anyway of course.
<tsmithe> more eyes the better ;)
<Lutin> hehe, indeed
#ubuntu-motu 2007-01-12
<tsmithe> k Lutin; it's up; and i'm going to sleep - the proxy is always on though, so if you have any comments just pm me. thanks
<Lutin> ok, g'night tsmithe
<tsmithe> kthxbi
<Lutin> tsmithe: the notice you put in copyright to say you removed korg1212 would be better in README.Debian imo (if you want to provide info, because a line in the changelog could be enough)
<tsmithe> ok
<tsmithe> i've left it in the changelog, and added a not to README.Debian
<Lutin> tsmithe: to make lintian happy, you can also remove the '.' at the end of your short description ^^
<tsmithe> ok
* tsmithe wonders why uploads are sometimes quick and sometimes slow
<LaserJock> tsmithe: how do you mean?
<tsmithe> and whenever he looks away they finish
<tsmithe> LaserJock, meh - /me just being impatient :P
<Lutin> tsmithe: in general it's also good to say what patches does what in the changelog, eg. foo1.patch: <whatitdoes>. makes life easier
<persia> tsmithe: Uploads follow the same temporal rules as boiling water :)
<tsmithe> persia, and broth ;)
<tsmithe> Lutin, ok
<tsmithe> i thought the names were rather self-explanatory, but ok
<Lutin> tsmithe: when you put the names in the changelog you can track the changes on the package then
<tsmithe> yes
<Lutin> eg.oh yeah, patch foo was added at revision xxx
<tsmithe> Lutin, ahh ok
<LaserJock> hi teer2 :-)
<teer2> LaserJock: ah, hello again.
<teer2> LaserJock: Should I explain it again?
<LaserJock> teer2: nah
<LaserJock> we have a system for reviewing and including packages called REVU
<LaserJock> !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
<LaserJock> teer2: the thing we need is for the games to be freely distributable
<teer2> LaserJock: That's what I'm looking for, right there.  Thank you for the web link.
<LaserJock> teer2: they don't have to be open source (although we would certainly like it if they were) but we *have* to be able to legaly distribute them on our servers
<teer2> LaserJock: Now, do they need to create builds for each Ubuntu disto version?
<LaserJock> teer2: not unless something changes where they need to
<teer2> LaserJock: Do they have to be source code, or can they distribute binaries?
<LaserJock> they can be in binary form, we'll still make up a source package to build a .deb out of it
<LaserJock> obviously we would prefer source code
<LaserJock> as we can fix bugs, do security, etc.
<teer2> LaserJock: Right... but, well, I can check the temperature on that one.
<LaserJock> basically it comes down to, if it's closed source but we can distribute it then it goes to Multiverse
<teer2> LaserJock: And they can ask questions about that in hee, right?
<teer2> LaserJock: *here
<LaserJock> if it's free (as in freedom) with source code, etc. we can put it into Universe
<LaserJock> teer2: sure
<teer2> LaserJock: So -- what if it was a (let's make something up) a 200 MB binary, proprietary, freely distributable game demo.  Are you saying they could go through this process and get it hosted?
<LaserJock> teer2: I would think so
<teer2> LaserJock: or do they provide the hosting and the Ubuntu universe would just point to the file location?
<LaserJock> no
<LaserJock> we put everything in our mirrors
<teer2> LaserJock: Okay, so all the hosting would be done through the mirrors.  Interesting.
<teer2> LaserJock: Very interesting.
<LaserJock> although, with something that big, it might be better to point to a file
<LaserJock> I'm not sure
<tsmithe> Lutin, it's up: http://revu.tauware.de/details.py?upid=4049
<tsmithe> :)
<LaserJock> but we have games that are at least 50MB in
<LaserJock> I believe
<teer2> LaserJock: Started a linux gaming advocacy site, linuxgamingworld.com  --  trying to get new life in the commercial, professionally linux-supported gaming scene.
<LaserJock> teer2: we do have a gaming team
<LaserJock> they might be the best to talk with
<LaserJock> I'm not really up on that
<teer2> LaserJock: How so?  How can I contact them?
<persia> teer2: There does seem to be a limit in size.  The uqm package has a large separate hosting for some optional portions of the game (around 200MB), and only has about 50MB in the repositories.
<LaserJock> ah, that makes sense
<LaserJock> teer2: https://wiki.ubuntu.com/MOTU/Teams/Games
<teer2> LaserJock: I am so there.
<teer2> Thanks for your help persia and LaserJock.  Any other suggestions for me?
<LaserJock> teer2: learn how to package and join the team ;-)
<teer2> If you think of anything, my contact info is on the site.
<teer2> LaserJock: I will try!
<teer2> Cheers -- Have Fun!!!
<Lutin> tsmithe: my limits are here ;). (just a note, to make lintian happy you r long desc in control should with only one space instead of two)
<keescook> crimsun: thanks for getting acroread updated.
<keescook> I was looking at the acroread libs, and there's nothing stopping us from changing the packaging to let acroread run on amd64...
<ajmitch> all the bits are there?
<keescook> ajmitch: yup.  it's how I uncovered the ia32-libs-gtk issues
<keescook> I'm running it right now (and uploaded a fixed ia32-libs-gtk too)
<keescook> The only part I'm unsure about is the sanity of my Depends: line.
<keescook> Depends: ${shlibs:Depends}, libldap2, libcupsys2, libstdc++5 [!amd64] , ia32-libs-gtk [!i386] 
<keescook> Debian Policy seems to imply that [] 's are only valid in build-deps...
<ajmitch> and mixing shlibs:Depends with explicit dependencies
<ajmitch> worst case, you could generate depends from rules & use misc:Depends :)
<ajmitch> but I don't think that'd be nice
<keescook> the rules is already a little ugly because I need to NOT include mozilla-acroread ...
<ajmitch> maybe checkout vmware-player
* keescook slaps his forehead
<ajmitch> as I thought
<ajmitch> it sets ARCH_DEPS in debian/rules
<keescook>     dh_gencontrol -- -Varchdeps="$(ARCH_DEPS)"
<keescook> yeah
<LaserJock> ajmitch is da man ;-)
<ajmitch> that's quite nasty still, since it requires hard-coding all those libs in debian/rules
<keescook> seems like overkill, can't it to both?
<ajmitch> it's just avoiding the use of shlibs, since it needs the 32-bit libs on amd64
<ajmitch> LaserJock: ha, very funny
<plugwash__> surely the real soloution is to fix shlibs to properly handle 32 bit binaries in 64 bit packages
<persia> When I modify the Maintainer field to Ubuntu defaults, does this belong in the changelog, or should it be assumed by the -ubuntu versioning scheme?
<LaserJock> persia: what?
<LaserJock> you shouldn't need to mess with Maintainer:
<LaserJock> unless you are packaging from scratch
<persia> LaserJock: https://wiki.ubuntu.com/FeistyReleasePlan, and https://wiki.ubuntu.com/DebianMaintainerField.
<LaserJock> persia: you should check with mdz to see if we are really doing that
<Adri2000> persia: that is done automatically by the buildds
<persia> Adri2000: For binary packages, but for source?
<persia> LaserJock: Is he usually on #ubuntu-devel?
<LaserJock> persia: yeah
<LaserJock> I don't know that I've ever seen anybody change the source package yet
<Adri2000> we shouldn't change the maintainer field, buildds do it:
<Adri2000> pkgmaintainermangler: Maintainer field overridden to "Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>"
<LaserJock> Adri2000: but according to the spec we will be
<LaserJock> not sure if that's in place yet or not
* persia grumbles about not being able to check the source for Launchpad to find out.
<Adri2000> the maintainer field can be different between the source and the binary package?
<LaserJock> yeah
<LaserJock> hence the "mangler"
<persia> Adri2000: I think that's what pkgmaintainermangler does.
* Adri2000 doesn't know what mangler means
<sistpoty> hi folks
<persia> Adri2000: A mangler is something or someone that mangles.  To mangle to to render unrecognisable through random changes (fold, spindle, and mutilate).
<LaserJock> hi sistpoty 
<sistpoty> hi LaserJock
<Sp4rKy> gd night guys
<sistpoty> gn8 Sp4rKy
<Adri2000> ok persia :)
<somerville32> Whens the next MOTU meeting?
<somerville32> Err..
<LaserJock> whenever it is
<somerville32> s/MOTU/MOTU Council
<LaserJock> well, we need a Council first
<LaserJock> then we can have a meeting :-)
<somerville32> I think we should allow commenting on packages by non MOTU, lol
<ajmitch> and the council needs the TB to meet first
<Adri2000> TB meeting next week
<Adri2000> friday
<somerville32> Wee
<crimsun> keescook: sorry for the delay, busy with work. I have a couple others (gxine, vlc) on the table, too.
<Adri2000> tuesday*
<LaserJock> did we miss a TB meeting?
<Adri2000> :p
<LaserJock> this has taken forever to get a Council approved
<somerville32> LaserJock, There was one just the other day
<ajmitch> LaserJock: probably due to holidays
<keescook> crimsun: cool.
<LaserJock> we had pretty much everything together in November
<ajmitch> LaserJock: oh, UDS wasn't *that* long ago ;)
<keescook> crimsun: I have a patch I'd like others to look at before I upload it, but it'd let acroread run on amd64.
<sistpoty> crimsun, Nafallo, keescook: we should announce motu-swat on the mailing list ;)
<LaserJock> we are going to have most of the useful part of the release cycle done with before we have a Council :(
<somerville32> What is motu-swat?
<LaserJock> MOTU Security
<keescook> sistpoty: yes please!  I'm sorry I haven't mentioned it anywhere, I've been totally swamped
<sistpoty> somerville32: security team for universe
<crimsun> keescook: mm!
<ajmitch> LaserJock: sure, but that shouldn't stop people from doing work
<somerville32> OoOoOO :)
<ajmitch> sistpoty: finally!
<LaserJock> ajmitch: but I believe it is
<sistpoty> keescook: ok, I'll write a mail...
<ajmitch> yay, another team I could join
<sistpoty> ajmitch: please do ;)
<somerville32> I read that there were efforts to modify revu to allow for non-motu to comment on uploads. I think this is an excellent idea :)
<crimsun> LaserJock is a deity; it's not like he needs to do work ;)
<LaserJock> somerville32: I don't
<somerville32> LaserJock: Why?
<LaserJock> somerville32: because people rely on the quality of those comments
<LaserJock> it should be a 2 way communication between the people contributing and the MOTUs who are approving
<LaserJock> not that giving advice is a bad idea
<ajmitch> sistpoty: nah, I don't think I'll join any more teams
<LaserJock> but a contributor should be able to have a level of expectation that the comments are acurate
<somerville32> LaserJock: Whats the difference between asking someone here in the chatroom and on revu?
<LaserJock> crimsun: bah, dieties are supposed to do 2x as much work ;-)
* ajmitch is glad he's a mere mortal
<LaserJock> somerville32: because REVU is our "official" method of contribution review
<somerville32> LaserJock: Then maybe we need an intermediate unofficial method
<LaserJock> I think this channel and the mailing list would probably suffice, but perhaps
<persia> somerville32: Here is probably good.  Non-MOTUs who comment can be corrected by MOTUs when they make mistakes.
<LaserJock> this comes up fairly regularly
<somerville32> Right but the issue is if people aren't here
<somerville32> I'd love to be able to take the list and work my way through it and share my wisdom where I can
<somerville32> And lighten up the load for real MOTUs
<geser> is uploading to revu the only way to get an account which is necessary to be able to comment?
<LaserJock> we have allowed a few exceptions where a person that has demonstrated are good reviewers they can be given reviewing rights
<somerville32> LaserJock: Thats an excellent idea!
<somerville32> Maybe we should document a process in which to be granted reviewing rights
<LaserJock> geser: you have to be a MOTU (or exception) to comment on other people's uploads
<LaserJock> somerville32: I think not, IMO, it should be a rare thing
<somerville32> LaserJock: Alrighty then. Just more work for you ;] 
<LaserJock> if it's really bugging you, become a MOTU and start reviewing :-)
<somerville32> lol
<LaserJock> you can also review-by-proxy
<somerville32> Maybe I'll do just that
<ajmitch> bddebian is always willing to help out, I'm sure :)
<crimsun> :)
<geser> LaserJock: I'm a MOTU :) but doesn't have an account on revu
<LaserJock> geser: then get one :-)
<geser> by uploading to revu?
<LaserJock> geser: no, by asking a revu admin
<crimsun> on another note, I'm surprised at how often people "just want stuff packaged for Ubuntu" but don't put in any work
<LaserJock> like the Candidates list? :-)
<somerville32> hehe
<ajmitch> because they don't understand how contributing to free software works..
* somerville32 closes his eyes and twirls around in a circle to pick something to do.
<crimsun> "I want my Claws Mail now zomgponies!"
<LaserJock> crimsun: well, I got an upstream author to start packaging some chemistry stuff for Debian/Ubuntu today
* ajmitch just wants sleep
<LaserJock> crimsun: hehe
<LaserJock> that was interesting
<geser> http://tiber.tauware.de/~lucas/versions/unimultiverse-all.html lists nearly 650 packages which are in Ubuntu but not in Debian
<persia> I was under the impression that Candidates was actually useful.  There is a package in debian-mentors (alephone), that I would like to see in Ubuntu.  How should I proceed to get it in?
<LaserJock> do people actually look at Candidates?
<Adri2000> persia: once it is in debian, sync request
<LaserJock> I'd never go there to find something to package ;-)
<Adri2000> LaserJock: yes :)
<persia> Adri2000: It's been a couple years :)
* ajmitch usually doesn't bother listening to what users want anyway
<LaserJock> a wiki page for that sort of thing is bordering on insane :-)
<LaserJock> and he's not bitter ;-)
<Adri2000> persia: that it is in debian-mentors?
<ajmitch> our job would be much easier if we didn't have users
<ajmitch> far less bugreports, for one
<LaserJock> ajmitch: agreed
<somerville32> How do you distinguish between a user and a contributor?
<persia> Adri2000: I've been downloading it from there.  I put a link up in Candidates.
* somerville32 contemplates fixing up the MOTU wiki pages sometime soon.
<LaserJock> somerville32: a contributor is somebody who contributes :-)
<somerville32> LaserJock, Is a user not contributing by giving feedback? ;] 
<LaserJock> usually no
* ajmitch contemplates working on debian
<LaserJock> sometimes yes
<persia> For those that are curious, official word is that the Maintainer should be manually mangled in the source package during merges, and the change documented in the changelog.
<Adri2000> :-|
<ajmitch> yay, more rules
* ajmitch gives up
<superm1> crimsun, i looked at the branch for mythplugins, and i noticed that some things were indeed missing on what was on bzr.  i apparently they were committing to my own branch for my user name not to ubuntu-mythtv.  i've got everything properly setup now
<sistpoty> geser: I can make you a revu account... just tell me the email you want to use
<geser> sistpoty: geser@ubuntu.com
<LaserJock> hmm, so I "get" to send the email to -announce?
<ajmitch> yep
<Adri2000> :
<LaserJock> persia: well, thanks for bringing it up, I guess ;-)
<ajmitch> you're a superstar, you can do it!
<LaserJock> bah
<LaserJock> I still don't get done 1/10th of what I want to
* ajmitch gets < 1/1000th done
<persia> LaserJock: Sorry to cause you extra work, but credit really belongs to ScottK, who mentioned it ~15 hours ago.
<ajmitch> so you're doing 100x better than I am :)
<geser> LaserJock: get used to it
<sistpoty> geser: hm... I can't find a gpg key for that email, so pw recovery will fail. 
<crimsun> superm1: ok, thanks for investigating.
<geser> sistpoty: I haven't add that address as uid to key yet
<geser> sistpoty: use michael@vorlon.ping.de instead (0x968BD587)
<sistpoty> geser: ok, I was just about to write you your pw ;)
<superm1> crimsun, mythtv should be good though, i just checked out from the branch made made sure
<sistpoty> geser: ok, updated... you should be able to recover your pw now ;)
<geser> sistpoty: thanks
<sistpoty> np
<Toadstool> wow, never heard of this maintainer thing before... good to know
<bddebian> Heya gang
<persia> hi bddebian
<bddebian> Heya persia
<sistpoty> hi bddebian
<bddebian> Hi sistpoty
<LaserJock> oh darn, should ubuntu-devel be the contact now that it's moderated?
<LaserJock> I remember Matt talking with somebody about that
<bddebian> Heya LaserJock
<LaserJock> hi bddebian 
<LaserJock> ah, found it on -devel :-)
<crimsun> *light bulb*
<crimsun> I just realized I can resolve this headache once and for all by having _backport_ crack addicts do subsystem maintenance work!
<bddebian> heh
<bddebian> crimsun: Have you (or can you) look at murrine now?
<bddebian> Well, not right now, but I mean now that he updated it.
<crimsun> he updated COPYING to use the correct FSF address?
<bddebian> Oh, is that new?
<crimsun> (that's the last issue about which I spoke with Andrew)
<crimsun> afaik he's waiting on upstream to address that
<bddebian> Was that today?
<keescook> crimsun: I gotta run, but I think the amd64 on acroread patch looks like this: http://people.ubuntu.com/~kees/acroread-amd64.patch
<keescook> I haven't tested that patch against your 7.0.9 package, though.
<crimsun> bddebian: approx 16 hrs ago
<crimsun> keescook: ok, thanks
<bddebian> crimsun: Ah, OK
<LaserJock> man, I hate email :/
<LaserJock> it always takes forever and is way to wordy
<sistpoty> hehe, yep
<crimsun> amusing, isn't it then, that status updates for bugs occur via email?
<LaserJock> yeah, I hate that
<LaserJock> I hardly ever read bugmail
* persia had a job once that was only writing email.  Expected productivity was ~30 per day.
* LaserJock would die
<crimsun> you're a deity; you don't have to read bugmail
<LaserJock> crimsun: I prefer +subscribedbugs pages but I do use the email to get the URL of what's going on
<LaserJock> maybe that's why Debian's BTS and I don't get along :-)
<crimsun> I love lp.net/bugs/foo and bugs.debian.org/foo
<ajmitch> crimsun doesn't read bug mail, he knows with a single glance all the bugs that are, have been, or are yet to be
<LaserJock> mhm
<crimsun> that would be so sweet
<LaserJock> the omiscient, omnipotent, and nice guy MOTU
<persia> For a patch to dpkg, should I upload the file patch or a debdiff?
<crimsun> same practice as usual (debdiff) won't hurt
<persia> crimsun: Thanks.
<LaserJock> persia: I'd do a file patch if you think it might involve the sponsor doing other work on it
<LaserJock> but mostly debdiffs work as crimsun beat me to
<persia> LaserJock: It's only to add support for Original-Maintainer, and is pretty clean.
<LaserJock> oh, I don't know that I'd do a patch just for that
<LaserJock> or are you meaning support for dpkg to work with X-Original-Maintainer?
<persia> LaserJock: No, "Original-Maintainer".  See https://wiki.ubuntu.com/FeistyReleasePlan.
<persia> more verbosely, so that dpkg-deb doesn't complain when the Original-Maintainer field is added to debian/control (bug 78879).
<Ubugtu> Malone bug 78879 in dpkg "dpkg doesn't support the Original-Maintainer field" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78879
<LaserJock> persia: the spec says X-Original-Maintainer
<LaserJock> bah, but .debs seem to have Original-Maintainer
<LaserJock> darn it
<LaserJock> well, I knew my email was going to suck
<persia> OK.  Now to whom should I subscribe the bug to get it uploaded?
<LaserJock> ubuntu-sponsors
<persia> LaserJock: Thanks.
<ajmitch> there's a new team? :)
<LaserJock> no, never
<persia> LaserJock: Apparently that's ubuntu-main-sponsors :)
* ajmitch can't keep up
<LaserJock> persia: ah, I thought it was originally ubuntu-sponsors, my mistake
<LaserJock> it's impossible to keep up with all of this
<crimsun> note: u-m-s isn't going to do anything until the maintainer signs off on it, so it'd be premature to sub u-m-s
<persia> LaserJock: It probably was.  Teams seem to change frequently.
<bddebian> No kidding it is
<LaserJock> the only thing to do let crimsun do it all
<persia> OK.  Unsubscribing.
<persia> Nevermind.  I can't.
<LaserJock> crimsun: then what's the point of u-m-s? I thought the whole idea was that the u-m-s team would upload for you
<LaserJock> although I can see needing a MOTU ack or something
<ajmitch> pfft
<persia> LaserJock: What does a MOTU ack do for main?
<ajmitch> s/u-*-s/crimsun/
<crimsun> LaserJock: it's dpkg, which is core, and you don't want that touched without a sign-off
<ajmitch> why do we bother with teams when we have crimsun?
<LaserJock> crimsun: again, then what's the point?
<persia> ajmitch: crimsun sleeps (on alternate Tuesdays)
<ajmitch> there are plenty of things in main that wouldn't need special sign-off
<LaserJock> if you have to go through the maintainer anyway why use u-m-s
<LaserJock> ajmitch: true
<crimsun> LaserJock: u-m-s is for uploads, of course. It just makes for a bit less email spam to wait imo.
<LaserJock> and that makes sense if this is a special case
<persia> LaserJock: I'd consider dpkg a *very* special case.
<ajmitch> there are things that you don't want everyone handlign u-m-s to touch
<ajmitch> like the kernel, X, dpkg, etc
<LaserJock> well, sure
<ajmitch> since I wouldn't trust every sponsor to know the ramifications of a change
<ajmitch> and I'd trust myself even less
<LaserJock> but then it still seems like we should be going to the maintainers in the first place
<LaserJock> it just seems like people have to go through so many layers to get things done :/
<persia> LaserJock: Malone autosubscribes anyone who wants to be a bug contact for the package.  If the maintainer likes bugmail, they get subscribed.
<LaserJock> persia: of course
<LaserJock> my point is, if the maintainer needs to ack it anyway, why wouldn't they upload it too
<ajmitch> of course
<ajmitch> we *love* layers
<LaserJock> hence why we are ogres ;-)
<ajmitch> they probably would upload it
* persia actually appreciates the review of my patches.
<ajmitch> or they may not have time
<ajmitch> impressive seeing how many bugs motu-swat is subscribed to that are php web apps :)
<LaserJock> yeah, who was it, maybe sistpoty, that said we should just remove php from Ubuntu and security would be done :-)
<sistpoty> LaserJock: I just grumbled a little bit about php *g*
* ajmitch does php for a day job
* sistpoty has been programming php for quite some time...
<ScottK> Good evening (here anyway) everyone.
<sistpoty> hi ScottK
* ScottK really appreciates all the time people have put into helping with his packages.
<ScottK> hi sistpoty
<ScottK> I think I'm ready this time...
<ScottK> http://revu.tauware.de/details.py?upid=4050
* ScottK learned about writing and installing man pages today :-)
<persia> ScottK: You'll want the Maintainer to be Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com> (bare email addresses are unfriendly).
<ScottK> OK.  Thanks.  I'll go fix that.  That's what I get for copying direct from the spec without putting my brain in the middle.
<LaserJock> persia: I think he can have his address if he wants
<persia> ScottK: I should thank you.  Your mention of that yesterday has caused interesting results.
<LaserJock> although it'd be fine to put ubuntu-motu too
<ScottK> Yeah.
<persia> LaserJock: I'd agree to that, but the current value is just the MOTU email address.
<LaserJock> persia: that's no good ;-)
<ScottK> Changed that here locally.  I'll upload again momentarily.
<ScottK> Anything else before I fire off debuild or are you still looking?
<persia> ScottK: There's some vim cruft in README.Debian.
<ScottK> I got it that way from upstream.  The upstream has /debian in it.  Is that worth increasing the size of the diff for?
<ScottK> hi Hobbsee
<persia> ScottK: Your changelog says you deleted upstream /debian.  If you changed "deleted" to "modified", it would be fine.
<ScottK> Ah.  Good point.
<ScottK> I
<ScottK> l'll remove the cruft.
<Hobbsee> hey ScottK 
<ScottK> cruft excised...
<persia> ScottK: Is there a difference between INSTALL and README.Debian?  I'm not sure you need both.
<ScottK> The differences are small, but real.  The main difference is that the path you put in your Postfix config is different since Debian installs in a different place.
<persia> ScottK: Then you need both.  Sorry I missed that.
<ScottK> No problem.
<ScottK> Appreciate the help.
<persia> ScottK: I don't see anything else, but you'll want real reviewers to check it.
* ScottK does want real reviewers to check it, but will fix your comments first...
<ScottK> Thanks.
<ScottK> Updated and uploaded: http://revu.tauware.de/details.py?upid=4052
* ajmitch waves to Hobbsee 
<ScottK> persia: thanks again.
<Hobbsee> hey ajmitch!
<sistpoty> wow, that's just so cool... executing arbitrary shell commands from the browser
* sistpoty is just testing if my patch indeed fixes a security bug
<ScottK> Then I hope you were executing the shell commands before you applied the patch...
<sistpoty> ScottK: sure... I first test with the old version and then the same with the patched version
<sistpoty> however this time I somehow broke s.th. :(
<ScottK> :(
<LaserJock> cool
<LaserJock> ubugtu changed his/her/its name
<theCore> LaserJock: I updated squeak-image, would you like to review it?
<LaserJock> theCore: sure
<theCore> LaserJock: just give it a sec to test it before upload it to REVU 
<theCore> ah, a bug 
<theCore> it seems I will have to update squeak-vm too
<LaserJock> :-)
<LaserJock> theCore: where are you getting your packages from?
<theCore> apt-get
<theCore> do you mean the upstream one?
<LaserJock> yeah
<theCore> http://ftp.squeak.org/3.9/
<LaserJock> theCore: so you kept the packaging the same?
<theCore> yep
<LaserJock> hmm
<LaserJock> I was actually going to replace the whole thing
<theCore> do you know that they got packages for Debian?
<theCore> http://ftp.squeak.org/debian/dists/etch/main/source/devel/
<LaserJock> theCore: that's what I'm talking about
<theCore> so, should I merge then?
* sistpoty is off to bed
<sistpoty> gn8 everyone
<LaserJock> well, I'm guessing we can grab then directly
<LaserJock> I'd have to check
<theCore> LaserJock: their packaging is quite different from our
<LaserJock> yep
<LaserJock> we got ours from another distro
<theCore> LaserJock: I think I like their package better
<theCore> LaserJock: the big plus is it doesn't create a directory in my home dir 
<LaserJock> yeah, that's why I was planning on changing to it :-)
<LaserJock> theCore: well, perhaps. I added in the stuff to in ~/
<theCore> LaserJock: do you use Squeak?
<LaserJock> no
<LaserJock> I just got into it one day
<theCore> I started to learn Smalltalk today. It's a pretty sweet language 
<LaserJock> and worked with upstream for a little bit
<crimsun> < DanaG> beryl-manager is 0.1.5+svn20070101-r2202+3v1ubuntu1
<crimsun> < crimsun> god that is the ugliest versioning ever.
<LaserJock> :-)
<LaserJock> theCore: the reason I added a script was because we need a way to run it from the menu
<LaserJock> theCore: have you tried those packages Matej Kosik did?
<theCore> LaserJock: not yet
<theCore> LaserJock: I am still reviewing it
<theCore> LaserJock: yep, it works
<theCore> LaserJock: but, it will need a little of reworking
<theCore> little bit* 
<theCore> bed time for me 
<Nafallo> morning
<keescook> hiya Nafallo 
<Nafallo> hi kees :-)
<persia> I've been processing merges, but I'm beginning to get the feeling there is a reason there are so many outstanding.  Should some merges not be performed?  I'm especially curious in the cases where MoM reports no problems with the merge.
<Nafallo> we have some that have there own packaging in Ubuntu. gajim being one :-)
<Hobbsee> persia: ask the person who last did the merge first.  there's usually a reason they havent done it.  and we're waiting on a lot of syncs.  also, main is frozen for herd 1 - dont know how easily universe uploads are getting thru, as they're not automatic, due to forementioned freeze
<persia> Nafallo: Well, yes, but for example, adasockets is 1.8.4.7-5 in sid, and 1.8.4.7-4ubuntu1 in feisty.  The most recent Ubuntu upload was a merge, and MoM reports no errors.  It being first in the alphabet, I would expect it to be a popular target.
<Hobbsee> persia: i think that came up later
<persia> Hobbsee: Uploads aren't getting through, but I'd expect to see merge or sync bugs.  Launchpad is building, and the new versions are visible (just not linked).  I could start chasing last uploaders, but that would considerably slow.
<Hobbsee> persia: may be a result of soyuz being broken, or having been broken
<Hobbsee> persia: they're usually on irc
<persia> Hobbsee: perhaps my first experience chasing tonio_ wasn't a good example.  Thanks.
<Hobbsee> persia: true.  he's on less at the moment
<persia> Hobbsee: And not responding to email in a hurry :)
<Hobbsee> yeah...personal issues
<Hobbsee> persia: you can always ask in here if people know abotu the merge's status - people will tend to talk about what they're doing
* StevenK is also looking for a merge
<persia> Hobbsee: You seem good with IRC.  How do I see if a user not in the channel is online?
<StevenK> persia: /wii <nick>
<persia> StevenK: LaserJock indicated that http://tiber.tauware.de/~laserjock/motutodo/universe.html was a good list, but see Hobbsee's comments above.
<persia> StevenK: Thanks.
<Nafallo> ehh
<Nafallo> why do I have a wii that is whois? :-P
<StevenK>  /wii gives more information than /whois, and is Freenode-specific
<persia> /wii doesn't work for me
<persia> whois does fine (if it doesn't find the people I seek)
<StevenK> persia: /wii persia works for me
<Nafallo> StevenK: ah. so /wii is what /whois is on other nets?
<Nafallo> how.. stupid ;-)
<StevenK> Nafallo: Yup :-)
<persia> gpocentek: I was looking at processing the merge for blogtk.  Do you have any comments or advice before I begin?
* persia is disenchanted with this workflow
<Hobbsee> persia: take it
<persia> Hobbsee: Um..  the workflow, or the package?
<Hobbsee> persia: the people here can tell you if people have particular packages, or if particular people are in control of their own merges
<Hobbsee> the package
* StevenK is looking at a neat bug.
<Hobbsee> persia: basically, avoiding the "i've had to do all this backwork, to make all this stuff work, and someone just yoinks the easy bit" - which is kinda annoying after it happens for the third time or so...
<persia> Hobbsee: OK.  Thanks.  On the other hand, it's only 8:30 in France, perhaps I should ask people likely to be active :)
<Hobbsee> persia: hehe.  usually, if you havent heard someone who's got attachment with a particular package, ie, has uploaded it multiple times or something....you're probably OK
<Hobbsee> or has mentioned it in here
<persia> Hobbsee: I understand.  I'll try to avoid that.
<Hobbsee> :)
<persia> Hobbsee: So if the changelog shows one person doing all the work, or making significant changes, I should make an effort to check when they are likely to be present, but if all uploads are different, it's probably safe just to do it?
<Hobbsee> persia: yeah
<persia> Hobbsee: Thanks for the detail.  That's definitely a workflow I can follow.
<Hobbsee> persia: by now, they usually either 1) dont have time to do it.  or 2) will do it, but have had to make other changes to make that bit work
<Hobbsee> persia: ie, contact them.  in the case of 1) feel free to take any and all their merges, unless they ask you not to touch one, (often one deliberately left because it doesnt work).  in the case of 2), respect their wishes
<persia> Hobbsee: I've also encountered a case where the Debian and Ubuntu maintainer were the same, and they thought it could sync, but it broke :)
<Hobbsee> ie, i'm ignoring ktrack because the tarballs are different, so i'm waiting till the next upstream version ot sync from debian
<Hobbsee> ah yep.  fake syncing..
<StevenK> Hobbsee: ktrack can be fixed. :-)
* StevenK waves his Clue of Evilness[tm] 
<StevenK> Ah ha!
* StevenK thinks he has this build sorted out
<StevenK> Hrm, maybe not.
<persia> zakame: I was looking at a merge of boa-constructor.  I noticed your bug 75220 for sync, and wanted to check with you before processing the merge.
<Ubug2> Malone bug 75220 in boa-constructor "Please sync boa-constructor (universe) from unstable (main)" [Undecided,Rejected]  https://launchpad.net/bugs/75220
<Hobbsee> StevenK: hrm?
<Hobbsee> persia: has the sync happened?  not sure if zakame is active - probably safe to take it
<StevenK> I bet it hasn't, given the Rejected
<StevenK> Hobbsee: Trying to fix a python-xlib bug
<persia> Hobbsee: sync rejected: .desktop file not adopted by Debian.  It needs a merge.
<persia> Hobbsee: Thanks again for the guidance.
<Hobbsee> persia: ah.  merge it, and file a bug in debian about the .desktop, i guess
<Hobbsee> if they havent actually taken the bug
<Hobbsee> email to the maintainer also seems to work pretty well
<persia> Hobbsee: bug exists, but I'll update it with the actual file :)
<Hobbsee> persia: ah :)
<enyc> meep moop
<siretart> persia: I got response from the glibc maintainers in debian, the problem is in oops. I'm on it, see debian bug #406491
<Ubug2> Debian bug 406491 in glibc "Build failure of oops 1.5.23.cvs-3" [Unknown,Open]  http://bugs.debian.org/406491
<persia> siretart: Great.  Let me know if I can be of further help.
<Hobbsee> persia: :)
<persia> When performing merges, may I also fix the .desktop when it doesn't validate?
<Hobbsee> persia: of course.  note it in the changelog though :)
<persia> Hobbsee: of course.  My changelogs are growing...
<Hobbsee> persia: yay :)
<Hobbsee> persia: that means you're doing mroe stuff - which is good ;)
<persia> Hobbsee: Well, to fewer packages (volume of work remains about the same).
<Hobbsee> persia: you can change that :P
<persia> Hobbsee: I need to sleep all the hours I do, and the rest of the time is spent here.  I'm not sure how to raise the volume :(
<Hobbsee> persia: hehe, fair enough :)  i get that problme too
* persia realises the definition of 'here' above is perhaps a bit vague
<Hobbsee> hehe
<persia> Does anyone know how to convince pysupport *not* to byte-compile things in certain directories?
<gpocentek> persia: feel free to grab my merges
<persia> gpocentek: Thanks.
<persia> man dh?pysupport
* persia needs to watch focus :)
<siretart> persia: puh. there is quite some more maintenance work left in oops ;) (mostly policy changes, make init script LSB compliant, etc)
<persia> siretart: Would you like me to look at that?  I'm presuming you'd prefer this done in the sid chroot, for upload to Debian.
<siretart> persia: if you want to look and try it before I upload it to debian, sure!
<siretart> at least, I got it lintian clean now! :)
<siretart> bah, linda is unhappy :/
<persia> siretart: I'm limited to simple functionality testing, but I could do that if it helps.
<persia> siretart: Congrats!
<Hobbsee> siretart: thump it's maker
<siretart> Hobbsee: yes, the problem is that upstream seemed quite dead the last time I looked for them :/
<Hobbsee> siretart: ah
<Hobbsee> siretart: i meant the maker of linda actually, but that too
<siretart> ah, :)
<ajmitch> Hobbsee: you're in a better position to thump its maker
<Hobbsee> ajmitch: true....so's everyone at LCA
<Lathiat> ajmitch: are you comign to LCA?
<ajmitch> no, I'm not
<Lathiat> wimp!
* ajmitch looks for someone to kick Lathiat 
<ajmitch> some of us have to work
<Lathiat> less ubuntu conference, more LCA :P
<Lathiat> who uses ubuntu anyway ;)
<ajmitch> not I
<ajmitch> I use windows
* elkbuntu bwahaha's at Lathiat
<siretart> persia: http://siretart.tauware.de/upload-queue/ here is my current oops upload - if you want, give me a short works/doesn't work
<siretart> (on feisty would be great, since I test on debian/experimental
<ajmitch> \sh: you pinged me a couple of days ago?
<ajmitch> hello dholbach 
<dholbach> good morning
<dholbach> hey ajmitch
<siretart> hey dholbach 
<\sh> moins
<\sh> ajmitch: jepp...
<elkbuntu> Lathiat, mind you, jono is coming, so it'll probably turn into one big jokosher conference
<elkbuntu> hi dholbach :)
<\sh> ajmitch: zope/plone questions...why depends plone 2.1.2 on zope 2.8 and not on zope 2.9 in dapper?
* elkbuntu hugs dholbach
* dholbach hugs elkbuntu
<ajmitch> \sh: dapper questions...
<ajmitch> probably because that was what was current & tested back then
<\sh> ajmitch: edgy delivers zope2.9 with plone 2.1.x*
<ajmitch> and I can't really go & fix up dapper's plone now, can I? :)
<\sh> ajmitch: I need to replace an old zope/plone fck server on sles9 with dapper or edgy
<ajmitch> and you're not allowed to make trivial packaging changes yourself?
<\sh> ajmitch: actually I don't want :) I want standards ;)
<ajmitch> you should just be able to change the dzproduct file in zope-cmfplone
<ajmitch> well dapper is released, so I can't do much - it's always been a rush to get things done
<ajmitch> plus they were synced from debian
<\sh> ajmitch: and what about edgy? are the edgy packages depending on 2.9? I could upgrade to edgy ;)
<ajmitch> edgy probably does, I can't check
<ajmitch> upgrading to edgy just because of that is a bit desperate :)
<\sh> it's just a server which is quite useless...but I have to do that..
<ajmitch>  Tested with   Zope 2.8, Zope 2.7
<ajmitch> the other *major* thing about it, is that zope2.9 was the first to require python >= 2.4
<ajmitch> before that, python2.3 was the only officially supported version
<siretart> persia: okay, oops works for me so far.
<ajmitch> \sh: anything else? :)
<persia> siretart: Sorry.  I was pulled away.  It works fine for me as well (on feisty).
<siretart> okay, will upload then shortly
<Hobbsee> StevenK: @ putting it in the system menu, just ask persia to submit a patch to it
<Hobbsee> persia's the expert on desktop files and menu items
<persia> StevenK: What about a menu item?  How can I help?
<Hobbsee> :)
<StevenK> persia: Will you be around in a little while? I don't want to context-switch to another problem just yet.
<persia> StevenK: Sure.  With brief interruptions, I should be here for the next 5 hours or so.
<StevenK> persia: Cool. Thanks for the offer of help
<persia> StevenK: No worries.
<persia> I'm looking at Debian bug #399276, in hopes of finding a solution to support the merge of boa-constructor.  Historically, three was a postinst to block compilation of the ZopeLib modules.  Is it acceptable to pass --noscripts to dh_pysupport, and provide manual maintainer scripts, or does this violate the policy?  http://www.debian.org/doc/packaging-manuals/python-policy/ Doesn't make this clear to me.
<Ubug2> Debian bug 399276 in boa-constructor "SyntaxError installing after python transition" [Important,Open]  http://bugs.debian.org/399276
<\sh> ajmitch: edgies zope gives me errors in events.log ... e.g. Products.ATContentTypes "Import Error: no module named CMFCore"
<\sh> but it's in the Products directory of the zope instance
* imbrandon yawns
<imbrandon> 
<persia> Syncs are processing again.  Does that mean the freeze is over?
<StevenK> And that the archive admins found some time.
<StevenK> Mainly what I said.
<Nafallo> yes
<Nafallo> herd is out
<persia> StevenK: It's the "And" that is especially interesting to me: I need to go check the build and release status for a few things.
<persia> Someone with access should modify https://launchpad.net/~motu, such that packages with the maintainer set to Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com> list the correct team when inspected in Launchpad (it currently reads MOTU-Media).
<Lutin> what's the right way to deal with this kind of bugs ? https://launchpad.net/ubuntu/+source/evolution-jescs/+bug/77977
<Ubug2> Malone bug 77977 in evolution-jescs "[ftbfs]  typo in evolution-jescs-2.8.2/debian/rules" [Undecided,In progress]  
<Lutin> assuming it's a fix for edgt
<Lutin> edgy*
<crimsun> Lutin: first establish that it is in fact a typo. Have you verified using stock edgy evolution-jescs source and an edgy pbuilder/sbuild?
<persia> crimsun: Sorry about pulseaudio.  Feel free to ignore my changes as you proceed: I'm looking forward to your improvements.
<crimsun> persia: no need to apologise, you did nothing wrong. The note there is simply for information.
<crimsun> Lutin: it looks like you could file an SRU for it
<crimsun> Lutin: the change is unintrusive and eyeball-able
<persia> Would someone be willing to ACK three sync requests?
* persia goes off to subscribe u-u-s
<persia> ScottK: I'm feeling tired earlier than usual today.  If you're still not ready for my help with your menu/.desktop questions, can we look at them tomorrow?
<ScottK> I think that was StevenK you meant...
<StevenK> persia: Certainly, I was about to head off to bed myself.
<persia> ScottK: Sorry - I need to check the backlog, rather than my brain :)
<ScottK> But I do aprreciate your help yesterday.
<ScottK> Heh.
<persia> StevenK: Thanks.
<zul> hi
<ScottK> If there is anyone around who has time for a REVU, I believe that http://revu.tauware.de/details.py?upid=4052 is ready.
<geser> ScottK: is there a reason why you modify INSTALL? it doesn't look like it gets installed
<ScottK> Good question.
<ScottK> I had modified it in a previous rev of the package.  I'm guessing I wasn't as careful in reverting the change as I thought.
* ScottK is looking.
<ScottK> Urgh.  Thanks.  Will reupload.
<geser> ScottK: README.Debian mentions /usr/lib/postfix/policyd-spf-perl but it gets installed in /usr/sbin
<ScottK> Thanks.  
* ScottK must have been tired last night.
<ScottK> I just found the same error in the man page.  I'll fix them both.
<geser> ScottK: a really minor bug: capitalize the D in README.Debian in the description of the package
<ScottK> Thanks.  I'll get it while I'm in that file.  Fixing the man page right now.
<ScottK> That's all fixed up.  Anything else?
<geser> I didn't find anything else
<ScottK> Thanks.
<ScottK> Update uploaded....
<ScottK> Thanks again geser.  http://revu.tauware.de/details.py?upid=4054
<ScottK> Anyone else?
<geser> ScottK: the diff.gz still modifying INSTALL. Didn't you revert it?
* ScottK checks.
<ScottK> There are days I really hate computers.  Stand by.
<_MMA_> Sad news: http://ardour.org/
<FactTech> Question: How does one go about adding a new program/package to the repository, or update an existing one?
* ScottK looked at the diff.gz before uploading this time.
<ScottK> FactTech: https://wiki.ubuntu.com/MOTU/Packages/New
<FactTech> ScottK Much obliged, I'll look there.
<ScottK> Here we go again... http://revu.tauware.de/details.py?upid=4055  INSTALL is definitely reverted this time.
<bddebian> Heya gang
<gpocentek> hello bddebian 
<bddebian> Heya gpocentek
<ScottK> Heya bbdebian
<geser> ScottK: the last upload looks ok but I'm not quite sure about the copyright file
<ScottK> What about it?
<ScottK> I tried to emulate the one in the Debian New Maintainer's Guide very closely.
<ScottK> http://www.debian.org/doc/manuals/maint-guide/ch-dreq.en.html#s-copyright
<ScottK> Did I miss something?
<geser> README mentions als you at (C) so you should add yourself also to copyright
<ScottK> Ah.
<ScottK> That would be something I missed.
<ScottK> On it's way...
<geser> ScottK: some packages have a additional paragraph about the GPL (incl the address of FSF) (see the copyright file for lsb-base)
<geser> but I'm not sure if this is mandatory
<geser> you might want to ask someone more experienced
<ScottK> The sample didn't have it.  I wonder if that's related to the FSF address change, i.e. if the LICENSE file has the old address, you mention the new address in the copyright file.  I know lintian will throw a warning if your LICENSE file has the old address.
<ScottK> Thanks again for looking at the package so carefully.
<ScottK> http://www.debian.org/doc/manuals/maint-guide/ch-dreq.en.html#s-copyright
<ScottK> Nevermind.  Wrong url...
<ScottK> It's uploaded again: http://revu.tauware.de/details.py?upid=4056
<geser> since you are setting Maintainer to MOTU I assume it would be ok if you set yourself as Original-Maintainer
<geser> besides this the package looks ok to me
<ScottK> Thanks.  I should have never been in the Maintainer spot to begin with since the package isn't in Debian.
<ScottK> Now that I'm the upstream (as of a couple of days ago) once I get through here, I'm going to work on doing a new upstream that straightens all this out.
<ScottK> Once again, appreciate you looking.
<geser> but you are maintaining the package in Ubuntu, so it would be ok to set Maintainer to yourself
<ScottK> I guess.  I don't mind it being the MOTUs.  It'll still show up as a package I uploaded so it's easy enough to keep track of on LP.  Eventually this will also be in Debian and I won't be the Debian maintainer (am not a DD and am extremely unlikely to become one), so I expect this will be less confusing in the long run.
<ScottK> Thanks again.
<Toadstool> g'morning everybody
<bddebian> Heya Toadstool
<Toadstool> hey bddebian 
<stdin> Hi, I hope this is the right place to ask this but, anyone know why mplayer/mencoder is in multiverse not universe ?
<Toadstool> stdin: 'cause of patent issues on codecs afaik
<stdin> ins't the app itself gpl tho? or are the codecs included in the package?
<azeem> Debian ships it in main now, Ubuntu hasn't revisit its decision yet I guess
<Toadstool> stdin: http://lists.debian.org/debian-legal/2005/02/msg00175.html <-- a good summary
<stdin> thanks, I'll give it a read :)
<siretart> azeem: debian ships mplayer without mencoder, ubuntu's mplayer includes mencoder
<stdin> why is mencoder in a separate package then?
<geser> stdin: mencoder is a seperate binary package but it is build from the same source package as mplayer
<stdin> geser: yes, but you can have mplayer in main, but mencoder in multiverse, can't you?
<geser> no, because than you also need to have the source in main (incl mencoder source)
<stdin> hmm, yeah
<Lutin> crimsun: for evolution-jesc: I downloaded the source, checked that it actually ftbfs
<siretart> it would already be an great improvement, if mplayer could/would enter universe
<Lutin> crimsun: I added a 'ls' in the rules to make sure the folder wa wrong, and it was
<medoc92> newbie question: what distribution name should I use in the debian/changelog for uploading to REVU?
<Laser_away> medoc92: feisty
<medoc92> Laser_away: I tried this and I got a reject message saying I had no right to upload to feisty
<Adri2000> medoc92: do you upload to revu and not to ubuntu? are you in the revu keyring? (have you joined the universe contributors team on Launchpad?)
<medoc92> Adri2000: I am in the keyring and contributor team as far as I know. But I may be trying to upload to the bad host, checking, thank you.
<Adri2000> dput revu *.changes
<medoc92> Adri2000: was definitely trying to upload to ubuntu. But now it tells me that it cant upload to revu because one of the files already exists (recoll_1.7.4-0ubuntu1.dsc). But the package still doesn't appear on the web page.
<zul> dput -f
<medoc92> zul: same result. Isnt -f for overriding local log? I'm getting an ftp error: Error '553 Could not create file.'
<siretart> medoc92: I just cleaned revu incoming for you
<medoc92> Thanks, trying again.
<medoc92> siretart: thanks, it worked.
<tsmithe> hi all! so who's up for - guess what! - revu'age? http://revu.tauware.de/details.py?upid=4049 or http://revu.tauware.de/details.py?upid=3892 should anyone be so kind
<Adri2000> SRU guys: I have #62346 for you :)
<cypherbios> Hello there! Anyone else here agree that this package is ready? http://revu.tauware.de/details.py?upid=4015
<LaserJock> \o/
* LaserJock does a happy dance
<LaserJock> do people really use sparcs for desktops?
<Adri2000> LaserJock: you're a superstar!
<LaserJock> me?!?
<LaserJock> I don't think so
<Adri2000> yes, I receive emails from you via ubuntu-devel-announce :
<LaserJock> umm
<LaserJock> they're probably all wrong too
<LaserJock> I finally got the lab's color laserjet working after like 3 months
<LaserJock> I'm so happy
<tsmithe> yay! now tell me about syncs :P
<LaserJock> what do you want to know?
<tsmithe> all
<ivoks> grab a chair
<LaserJock> you request them, and then at somepoint ubuntu-archive processes them
<LaserJock> the end
<tsmithe> ok
<tsmithe> ivoks, that wasn't too bad...  can i go back to standing up now?
<ivoks> :)
<LaserJock> well
<LaserJock> do you want more detail?
<tsmithe> yes ;)
<Adri2000> if you are not a MOTU, don't subscribe u-a, subscribe u-u-s
<LaserJock> tsmithe: basically, look at the Syncs section of https://wiki.ubuntu.com/DeveloperResources
<LaserJock> and as Adri2000 said
<tsmithe> k thanks
<LaserJock> tsmithe: make sure to follow it closely or crimsun will get out his whip
<LaserJock> :-)
<tsmithe> LaserJock, i will ... /me doesn't want to suffer crimsun's whip
<siretart> bug #62346
<Ubug2> Malone bug 62346 in obconf "[SRU]  Missing libobrender.so.1 -> unable to launch obconf" [Unknown,Fix released]  https://launchpad.net/bugs/62346
<Nafallo> oh. crimsun has whips to? ;-)
<tsmithe> obviously...
<LaserJock> ScottK: you still around?
<LaserJock> bddebian: gotta keep the archive gods appeased
<bddebian> Aye :-)
<neutrinomass> There are a few -dbg packages in feisty's universe that fail because of exact deps ... should they be removed? (from what I understand they are obsolete because of apport)
<neutrinomass> oh, and hi everyone :)
<Nafallo> neutrinomass: hi :-). I think a cleaner approach would be to tell the buildds to throw them away.
<neutrinomass> Nafallo: erm, how do I do that ? (subscribe -archive ? )
<Nafallo> neutrinomass: talk to pitti and infinity :-)
<neutrinomass> Nafallo: Ok, I'll make a bug report out of them and subscribe them - thanks !
<Nafallo> neutrinomass: np :-)
<tsmithe> so anyone available to review my alsa-firmware and related packages? we at UbuntuStudio would really like to see them in
<Nafallo> tsmithe: crimsun should have special interest :-)
<tsmithe> crimsun, you available?
<tsmithe> Nafallo, he's often busy, but i'd always be glad of anyone's help
<Nafallo> tsmithe: yes he is :-/
<tsmithe> Nafallo, you gonna help out then? :P
<Nafallo> tsmithe: busy and running wine IRL :-P
<tsmithe> tsk tsk
<ScottK> LaserJock: I'm around now
<LaserJock> ScottK: I was just going to say, you don't have to be a DD or MOTU to maintain your package in Debian or Ubuntu
<ScottK> Ah.
<LaserJock> and there's really no reason you can't be in Maintainer:
<LaserJock> the spec is too address Debian packages
<ScottK> I expect to be doing the actual maintenance work regardless of who is in the maintainer field
<Q-FUNK> I _does_ make it easier, though, if someone doesn't constantly have to wait for a sponsor to upload.
<LaserJock> Q-FUNK: sure, but you *can* do it
<Q-FUNK> but true, one can simply routinely submit patches and ping the maintainer to merge them.
<Q-FUNK> or maintain their own package and wait for sponsors.
<ScottK> I'm more about getting the package into Ubuntu than I am about getting my name in lights.
<Q-FUNK> I guess for that, MOTU formalized the process of peer reviews and sponsoring.  
<LaserJock> sure
<ScottK> Regardless of maintainer or not, I still need to wait for a MOTU to REVU anyway.
<Q-FUNK> at Debian, the mentoring is much more lax.
<Q-FUNK> I keep on cursing at how many days it's gonna take for an upload to take place, whenever my AM is unavailable. :(
<LaserJock> ScottK: that's fine, I just wanted to say that you have that option if you want. It's always nice to be able to see who I can go to for issues with the package
<ScottK> Sure.  My assumption is that being in the changelog will do it for that.
<ScottK> Thanks.
<ScottK> Speaking of getting my packagin into Ubuntu, LaserJock, would you be up for REVUing it? http://revu.tauware.de/details.py?upid=4056
<tsmithe> sorry - connection died. did anyone offer to review my packages? ;)
<ScottK> No.  Sorry.
<tsmithe> awh
<tsmithe> ScottK, does that mean you volunteer?
<ScottK> I wouldn't do you much good.  I'm pretty new around here.
* tsmithe too
<tsmithe> these would be my second and third packages
<tsmithe> out of 7 i've done
<tsmithe> and the UbuntuStudio folks would really appreciate if anyone would. :P
<ScottK> You've done more than me.  So far I've done upstream updates for 2.  This is my first new one (I hope) to get accepted.
* tsmithe has had one accepted: asoundconf-gtk
<tsmithe> it's in feisty universe! yay!
<keescook> crimsun: did I miss something?  what's happening with acroread in feisty?
<crimsun> keescook: I presume it's going through NEW
<crimsun> keescook: although I do find it alarming that it no longer appears to be a valid source package according to ``apt-cache madison'' ...
<keescook> yeah... I wanted to do the amd64 thingy to it... but it vanished.  :P
<crimsun> err
<crimsun> "PendingRemoval"
<crimsun> well, the source no longer exists period.
* crimsun checks his inbox
<bddebian> Later gang
<philluk86> hi does anyone know the policy for packaging python applications, specifically pygtk ones?
<ScottK> Did you look at the Debian Python Policy?
<ScottK> http://www.debian.org/doc/packaging-manuals/python-policy/
<philluk86> yes, there isnt much specifically on python programs. Install the modules into /usr/share/modulename. I dont know where I am allowed to put glade files, can I put them under modulename/ui ?
<LaserJock> philluk86: you can put the glade files pretty much wherever you want in /usr/share/<packagname>
<LaserJock> and where you install the .py files depends on what kind of app and wheither you want to use python-support of python-central (I recommend the later, but it's up to you)
<somerville32> Whats the difference between the two?
<philluk86> well atm im using a standard makefile which will precompile the py files and then copy to the destdir
<somerville32> philluk86, What are you packaging?
<LaserJock> philluk86: don't precompile them
<LaserJock> just install the .py files
<LaserJock> oh, man, that really stinks (WRT acroread)
<somerville32> philluk86, You'll need to patch the makefile to not to compile them and ot make sure the .py files are installed.
<somerville32> philluk86, python-support/python-central will compile them for you if you install them to the correct location
<somerville32> If you install them to a weird location, you'll need to specify it manually
<philluk86> ok.. so whats the best way to tell people about my app?
<LaserJock> what do you mean?
<crimsun> LaserJock: yeah, it sucks (Ubuntu doesn't have it), but it doesn't suck (less work for us; I can still pbuild modified debian-multimedia.org's)
<LaserJock> crimsun: yeah, it's just that it's like the 2nd app I install on every Ubuntu box
<crimsun> and less bug mail for me Wins.
<LaserJock> yeah, for sure it's easier maintainence wise
<LaserJock> but people will complain profusely
<crimsun> let 'em.
<crimsun> I'll happily post my diff.gz and dsc
<philluk86> i meant if i want people to try my app should i post about it on the forums?
<LaserJock> philluk86: yeah, having a website and the app in Universe will help as well
<LaserJock> philluk86: maybe blog about it somewhere
<LaserJock> things like that
<crimsun> wow, oldschool rocking the house with sru and swat
<LaserJock> mhm
<crimsun> stefan, reinhard, and I account for some ridiculous percent of motu email ;p
<LaserJock> 99.9%
#ubuntu-motu 2007-01-13
<tsmithe> crimsun, are you available to do revuage for my alsa packages?
<Adri2000> thanks crimsun for uploading obconf
<LaserJock> uggg, 184 MOTU Science bugs :(
<Adri2000> do *all* python apps need a rebuild?
<LaserJock> probably  not
<Adri2000> !info giplet
<ubotu> giplet: GNOME IP display applet. In component universe, is optional. Version 0.1.2-0ubuntu1 (edgy), package size 8 kB, installed size 112 kB
<Adri2000> what do you think of this one?
<LaserJock> Adri2000: what about it?
<Adri2000> does it need a rebuild? how can I know?
<LaserJock> I'm guessing Matthais already rebuilt the ones that needed to
<LaserJock> *Matthias
<Adri2000> ok
<LaserJock> generally if there is a transition like that he just does it en-mass
<geser> Adri2000: only those python apps need a rebuild which depend on python < 2.5
<LaserJock> we shouldn't have to many of those I wouldn't think
<gnomefreak> LaserJock: most of gnome but universe not too many
<gnomefreak> sure there is alot any way you look at it but from what i can see on my system not too many uni/multi are affected
<LaserJock> looks like some of the he removed the hard dependency
<dakira> Hi.. I just tried to build Vidalia with pbuilder and get some errors I can't make any sense of. Specifically when it tries to install vidalia the make install throws some "permission denied" errors inside the pbuilder environment..
<dakira> maybe someone knows this problem.. here's the relevant part of the output: http://pastebin.ca/314767
<LaserJock> dakira: it's becuase it's trying to install to /usr/bin/
<LaserJock> it needs to install to $(CURDIR)/<packagename/usr/bin
<dakira> LaserJock: okay.. so I need to change the "rules"-file, right?
<LaserJock> yeah
<dakira> LaserJock: wow.. thanks A LOT! This happened to me before with something else and I never figured it out.. so now I get it..
<dakira> I just didn't get the concept of pbuilder completely right
<LaserJock> well, it's the way packaging works
<LaserJock> the .deb is built from inside the debian/ directory
<LaserJock> so you need to install files in there
<LaserJock> and then it gets compressed up into a .deb with the right paths
<LaserJock> that way you aren't *actually* installing to /usr/bin/ everytime you build a package
<LaserJock> that would make things pretty messy
<dakira> yeah.. I see that now.. I can't believe how blind I was towards this :-)
<LaserJock> np, took me a while too ;-)
<dakira> well.. it never gets messy since I work inside a pbuilder environment.. but still.. I just got it wrong
<somerville32> LaserJock: When I first tried, I tried to install directly to /usr/bin/ too but my thinking (or understanding) was that pbuidler created a chroot and so what ever I did was happening actually in some pesudo file system
<somerville32> *pseudo 
<dakira> LaserJock: one more question.. do I have to set the --prefix of the configure part in "rules" to $(CURDIR)/<packagename>/usr, too?
<LaserJock> I guess that's one of the prices we pay for telling everybody to use pbuilder first off
<LaserJock> dakira: no, because that'
<LaserJock> that's telling the package where things will be at runtime (i.e. when the .deb is unpacked on the users machine)
<dakira> LaserJock: okay.. than the problem is that the vidalia dev hardcoded the install paths and doesn't use --prefix directive
<LaserJock> dakira: wahoo, sounds like patch time :-)
<dakira> *g*
<LaserJock> I've gotta run right now
<LaserJock> I might be on later
<dakira> thanks for the help and clearing things up!
<LaserJock> but there is some patching material in the packaging guide
<LaserJock> and on wiki.ubuntu.com/MOTU/School
<somerville32> dakira: dpatch is awesome :)
<Toadstool> yay! openoffice preventing me from dist-upgrading :)
<somerville32> Toadstool: Just remove the packages :)
<Toadstool> I can wait 
<somerville32> I wouldn't dist-upgrade right now anyhow
<somerville32> Now with the python fallout :)
<somerville32> *Not
<somerville32> Gah, I can't type today :(
<Toadstool> heh
<dakira> somerville32: i'll have a look at dpatch as soon as a figure out what the dev has done wrongly ;)
<persia> What's the policy on applying patches to fix Debian bugs that haven't been reported in Ubuntu?  Should an Ubuntu bug be created that links to the Debian bug with the patch?  The bug is certainly present in Ubuntu.
<somerville32> Sounds good to me
* persia proceeds to create such a bug.
<Toadstool> persia: link it to the Debian bug too
<persia> Toadstool: Of course.  The patch is actually from the Debian bug.
<Toadstool> persia: if you could prepare a debdiff fixing as many bugs as possible and poke a MOTU to sponsor your fixes, it would be even better ;)
* Toadstool hides
<persia> Toadstool: That's basically what I do all day, every day (until I have to work again), but I usually only upload one debdiff per bug.  I should really fix my gpg configuration and attend the next meeting to become a member :)
<Toadstool> great! and then try to become a MOTU, we need more manpower
<persia> Toadstool: The main issue is that I will fail to check my email for months at a time when working (cf. my LP page).  Perhaps I'll become a MOTU at some point, but this usually requires two months of effort (and I rarely have that long a break).
* somerville32 wants to become a MOTU someday soon.
<Toadstool> persia: oh my bad, I know you... I have seen your real name so many times in changelogs but didn't link it to your nick and thought you were some kind of newcomer :)
* Toadstool is useless
<persia> Toadstool: No worries :)
<somerville32> hehe
<somerville32> Should we only package stables releases or are betas good too?
<persia> somerville32: betas are only good if they fix known bugs that cause problems.
<somerville32> This is for a new package
<persia> somerville32: Still, is the beta less buggy?
<Toadstool> somerville32: what I usually do is package stable releases and extract patches from development branches
<somerville32> k
<Toadstool> but of course, if you feel like the beta would be better (let's say you tested thoroughly, no regressions, bug fixes, whatever) then you can package the beta
<somerville32> kk
<somerville32> Whats the magic tar command to gzip and untar w/o modifying the checksum again?
<persia> somerville32: tar xzf works for me.
<Hobbsee> somerville32: bunzip2 <tar> gzip -9 resulting tar
<somerville32> persia: thanks
<somerville32> Hobbsee, :)
* somerville32 just notices that his package, pyNeighborhood, was approved by the archive admins and now in Feisty repositories.
<somerville32> Woot! :)
<Toadstool> somerville32: congrats' :)
<Hobbsee> somerville32: yay!
<Toadstool> hey Hobbsee!
<Hobbsee> hey Toadstool!!!!
<Toadstool> how is it going?
<Hobbsee> good, and yourself?
<Toadstool> alright, lot of work, lot of time with my girlfriend so not as much time as before for Ubuntu
<somerville32> ...
<somerville32> Umm...
<somerville32> somethings wrong
<somerville32> They changed the maintainer field to use my personal e-mail instead of my ubuntu one
<somerville32> :(
<Toadstool> "they"?
<somerville32> Somewhere along the way it got changed by someone or something
<somerville32> And I can't install the package...
<somerville32> How odd
<somerville32> E: Package pyneighborhood has no installation candidate
<somerville32> And the depends weren't set properly
<somerville32> guh...
<somerville32> Is it possible I have something in my cache?
<persia> somerville32: https://launchpad.net/ubuntu/+source/pyneighborhood reports no package published yet.  Wait a bit.
<somerville32> Ok
<somerville32> It must be in my cache
<Toadstool> somerville32: pyneighborhood is still waiting for approval in new
<somerville32> doh
<somerville32> Ok
<somerville32> Must be in my cache
<Toadstool> https://launchpad.net/ubuntu/feisty/+queue?start=20 <-- here
<somerville32> How can I clear my cache?
<persia> somerville32: Try `sudo aptitude clean`
<somerville32> apt-cache show pyneighborhood 
<somerville32> Package: pyneighborhood
<somerville32> Status: deinstall ok config-files
<somerville32> What does that mean?
<persia> somerville32: It's uninstalled, but not purged.  You can fix that with `sudo aptitude purge pyneighborhood`
<somerville32> Thanks :)
* somerville32 hugs persia.
<StevenK> Or 'dpkg -P pyneighborhood'
<StevenK> With a sudo prepended...
<bddebian> Heya gang
<Toadstool> hey bddebian!
<bddebian> Hi Toadstool
<cypherbios> heya bddebian :)
<bddebian> Hi cypherbios
<cypherbios> bddebian: http://revu.tauware.de/details.py?upid=4015 >> any problem in keep uploading and updating this package on REVU when it isn't archived?
<bddebian> cypherbios: Even when packages are archived, you can upload new/updated versions.  It will automagically un-archive them
* somerville32 hugs bddebian 
<bddebian> For what? :-)
<somerville32> For being such a good person! :)
<somerville32> And because I know you'll review my package here in a second
* somerville32 grins.
<Toadstool> bddebian: don't ask why, you deserve it! :)
<somerville32> It's true
<bddebian> Hah, I knew there was an alterior motive :-)
<somerville32> Is the section util or utils?
<StevenK> utils
<bddebian> Heya LaserJock
<cypherbios> hobbsee ops, wrong channel :)
<cypherbios> Hobbsee: can you take a look when you have some time? http://revu.tauware.de/details.py?upid=4015
<Hobbsee> lol
<somerville32> If a package depends on gtk+, what package do I use?
<somerville32> libgtk2.0-0 ?
<LaserJock> build-time or run-time?
<somerville32> run-time
* ajmitch so tired
<LaserJock> ajmitch: but aren't you relaxing on a weekend?
<manchicken> Anybody well versed in dh_install?
<persia> manchicken: What are you looking to accomplish?
<manchicken> persia: I'm trying to build adept from bzr.
<manchicken> http://bazaar.launchpad.net/~jr/adept/ubuntu/ <-- That bzr repo
* persia doesn't know bzr
<LaserJock> persia: you don't?
<LaserJock> just bzr branch that url
<manchicken> could somebody verify that adept won't build from bzr?
<manchicken> Just build?
<manchicken> (you'll have to build-dep adept first though I suppose, but that should be trivial to do in a pbuilder)
<persia> LaserJock: Thanks.
<persia> manchicken: Hold on a bit, and I'll verify.
<manchicken> If you just `bzr co http://bazaar.launchpad.net/~jr/adept/ubuntu/ ./` it'll check it out.
<LaserJock> yeah, bzr co would be faster then actually branching it
* persia switches from branch to co...
<manchicken> It's so nice to be able to play DVDs on my machine again.
* Hobbsee wondres if she'd be missing anything in getting off devel-discuss
<persia> manchicken: It doesn't build for me.  Looks like an automake issue.
<manchicken> persia: What error are you getting?
<manchicken> (just to make sure it's the same issue)
<persia> manchicken: config.status: error: cannot find input file: adept/kubuntu_upgrader/Makefile.in
<manchicken> Yeah...
<LaserJock> mine is still downloading deps
<manchicken> run `make -f ./admin/Makefile.common` and then debuild again.
<persia> manchicken: It looks like Makefile.am isn't being used to generate Makefile.in.  I'm too annoyed about m4 recursion in autom4te right now to want to look into it deeper.
<TheMuso> Hobbsee: I was glad when -devel quieted down.
<TheMuso> I am not on -discuss.
<manchicken> Persia: run `make -f ./admin/Makefile.common` and then debuild again.  That will get past that issue.
<Hobbsee> TheMuso: yeah, exactly.  -discuss is worse than the previous devel
<somerville32> I'm on -discuss and I hardly get anything
<persia> manchicken: It gets to the compiling now.
<somerville32> Or I think I'm on -discuss
<manchicken> persia: I'm having ussues when it does the dh_install -padept-manager
<Hobbsee> somerville32: likely on -devel then - there's usually heaps on devel-discuss
<LaserJock> Hobbsee: it still doesn't look that bad to me
<manchicken> w00t, feisty upgrades.
<persia> Hobbsee: Are you sure you're not subscribed to devel-discuss-annoy-hobbsee?
<LaserJock> hehe
<bddebian> heh
<ajmitch> LaserJock: the number of useless & unproductive threads has grown
<LaserJock> ajmitch: it still seems better than the original -devel to me
<ajmitch> I wouldn't say so
<Hobbsee> persia: haha
* LaserJock is confused
<LaserJock> it seems like a lot of dev types on there
* ajmitch is always confused
<LaserJock> I'm not seeing all the noise
<teer2> Hi, my email was forwarded to the distribution list yesterday, about packaging commercial game demos.
<manchicken> Non-free game demos?
<teer2> I did not get back a response that addressed my questions.  Anyone able to hellp?  I did not get a to see the distribution list mail address.
<teer2> manchicken: Yes.
<manchicken> Why?
<teer2> manchicken: Not sure what you mean by non-free actually.
<manchicken> teer2: Restricts freedom.
<persia> manchicken: A rebuild (after `make -f ./admin/Makefile.common`), didn't have any errors for me.  Is something you want not getting installed?
<teer2> manchicken: They are freely distributable, but they are not free software.
<manchicken> teer2: That's unfortunate.
<persia> teer2: Those are just costless.  Not free.
<manchicken> IIRC, Ubuntu has a position that favors free software.
<ajmitch> if they are freely redistributable, it may be possible to put them in multiverse
<teer2> These are guys trying to make a living making entertainment software for linux, and supporting the software full-time.  Don't you think we should help them out?
<manchicken> teer2: Package the newly GPL'ed SecondLife client.  That'd be nice ^_^
<manchicken> teer2: They should try to do so without trying to limit the freedom of others.  I do not think we should help others restrict the freedom of others for the sake of their own profit.  But that's just me.  I'm certainly no official voice.
<persia> teer2: You'll get a better response from your mailing list post.  People who are responsible for balancing marketing and politics are more likely to be there.  The apps could go in multiverse, or perhaps commercial, depending.
<teer2> persia: So what I am seeking is instructions on how these developers can create and submit a package for official (universe/metaverse/commercial) ubuntu distribution.
<LaserJock> teer2: where did you email?
<manchicken> teer2: If these people wanted to make free software, and earn their living supporting it, I'd support that whole-heartedly.  I just have this bias against fascism ^_^
<LaserJock> teer2: I gave you some instructions yesterday didn't I?
<persia> teer2: Most Ubuntu list archives are publically accessible from https://lists.ubuntu.com/mailman/listinfo/.  If you mailed one of these lists, you can probably find responses there (although you would likely have been cc'd).
<teer2> manchicken: Second life will be a good example to others on how to make games open source commercially, WHEN they finally make it open source (which it isn't now).
<manchicken> teer2: It's a beautiful thing that SecondLife is GPL'ed now... but until a program's licensing respects freedom, it should be avoided.
<manchicken> teer2: Before it was GPL'ed, I said SecondLife should be avoided.
<manchicken> teer2: Now that it is GPL'ed, it should be embraced and used in a manner that suits each user's purpose ^_^
<teer2> LaserJock: Yes, thanks for your help, I emailed the games team, and Stefan Potyra emailed me back and said he wasforwarding it to the ubuntu-devel-discuss mailing list.  However, I did not hear a response in the last day.
<teer2> manchicken: Commercial software can also produce open-source engines to be shared, also, their full-time support engages them in improving Linux UIs and smoothing out rough edges in distributions.  We have more to gain by being inclusive than exclusive.
<manchicken> teer2: No, we don't.  If we embrace companies that seek to restrict our freedom we lose our freedom, and encourage fascism.
<manchicken> teer2: We should demand that software licensing respects our freedom.  Anything short of freedom is unacceptable.
<teer2> LaserJock: Actually mikecorn responded from the mailing list regarding packaging for a specific ubuntu versions, but not regarding packaging in general.
<manchicken> teer2: I'm more than willing to include companies who are willing to respect freedom.
<teer2> LaserJock: What I'm seeking is instructions on how these devs can do their packages and submit them - easy step-by-step instructions
<teer2> manchicken: Games take months of time to make, usually by one developer working full time.  Unless we can establish a way for them to get compensated financially, then I think we should support the existing compensation model, since no others exist.  It's not like other software where people buy support packages.
<manchicken> teer2: If they can't figure out how to make money, it's hardly the users' fault.  Why should people lose freedom because others can't figure out how to make money?
<manchicken> teer2: I would even pay for a game if it respected my freedom.
<joejaxx> bddebian: are you around?
<teer2> manchicken: Because users demand the entertainment, and they will use consoles or windows which restrict their freedom entirely if they cannot find games on Linux.  Either way, they should have the choice between free and non-free software.
<manchicken> teer2: non-free is non-free.  It doesn't matter what system it is on.  People should not package, distribute, or otherwise perpetuate this usury of freedom.  It is never okay to restrict another human being's freedom for the sake of profit.  Ever.
<somerville32> Interesting conversation going on here
<somerville32> However, I think it would be better suited somewhere else.
<teer2> manchicken: You propose to restrict their freedom by not allowing them to choose non-free software
<bddebian> joejaxx: Sure
<teer2> somerville32: I'm just here looking for distribution package instructions.  I realize the room for arguements is down the hall.  Sorry!
<manchicken> teer2: Nope.  I say that the software should always be free.  Shame on those developers for releasing non-free software.  They should be able to choose whatever software they want without having to worry about someone trying to steal their freedom.
<somerville32> :)
<joejaxx> bddebian: i know this might sound stupid but please forgive my ignorance
<teer2> manchicken: I will let you have the last word on the subject.
<joejaxx> bddebian: where can i download gnu/hurd the os that is
<manchicken> teer2: That's fine.  I just hope you don't expect me to keep my mouth shut when you try to subversively distribute software that restricts freedom.
<manchicken> ^_^
<manchicken> somerville32: I've never been very good at staying on topic.
<manchicken> And I still can't build this bloody adept package.
<somerville32> Hobbsee, Whats the command syntax for creating a new patch with dpatch again?
<manchicken> persia: Yo, could you pastebin your `dpkg -l | sort` for me?
<manchicken> somerville32: Are you talking about cdbs-edit-patch?
<persia> manchicken: Which pastebin is your favorite?
<somerville32> no
<somerville32> dpatch
<manchicken> Righto.
<manchicken> http://paste.ubuntu-nl.org/
<Hobbsee> somerville32: dpatch-edit-patch or something
<Hobbsee> somerville32: i dont remember, i never use dpatch
<somerville32> What do you use?
<ajmitch> Hobbsee doesn't need to use tools
<joejaxx> bddebian: or is there not a gnu/hurd compilation yet
<Hobbsee> somerville32: their converstaion only needs to stop when someoen else asks a question.  it probably is a vaguely relevant conversation.
<ajmitch> she creates patches from the editor, knowing all the necessary context
<Hobbsee> ajmitch: you're right, actually :P
<somerville32> Hobbsee, I just asked a question :P
<Hobbsee> hah
<bddebian> joejaxx: You can get the Debian K14 install CDs here:  http://www.debian.org/ports/hurd/hurd-cd
<bddebian> Well links from there anyway
<manchicken> I think HURD can install next to your linux kernel.
<joejaxx> bddebian: oh alright thank you :)
<manchicken> That'd be neat.
* Hobbsee usually patches manually
<manchicken> "Which kernel do I feel like using today?"
<Hobbsee> and LONG LIVE CDBS!!!
<ajmitch> manchicken: nice, but there's a completely different ABI, so apps can't be shared :)
<manchicken> ajmitch: I suspect you'd merely have to recompile things.
<ajmitch> sure, 'merely' recompiling the entire distro isn't much of a hassle, is it?
<bddebian> heh
<ajmitch> you just have things on separate partitions
<manchicken> ajmitch: Details, details.
<ajmitch> "Oooh, I feel like dual-booting today - let's start a full recompile!"
<Hobbsee> ajmitch: like the python transition and worse :P
<ajmitch> Hobbsee: far, *far* worse
<Hobbsee> haha
<manchicken> ajmitch: Recompiling with apt-get is easy ^_^
<ajmitch> imagine recompiling firefox or OOo everytime you want to use it
<bddebian> And glibc only takes about a day and a half to compile on GNU/Hurd ;-P
<ajmitch> talk to bddebian about the fun of portability & GNU/Hurd
<ajmitch> his sanity hasn't returned yet
<bddebian> All I have to say is: MAXPATHLEN :-)
<manchicken> ajmitch: If I had an extra disk to work on, I wouldn't mind trying some stuff out on it ^_^
<ajmitch> at least you have pthreads now!
<persia> manchicken: dpkg -l is far too long and the process appears manual (I'm not sure how to paste a file).  Could you paste your error?  That's probably an easier way for me to help.
<ajmitch> manchicken: yeah, you're sick
<bddebian> heh
<Hobbsee> manchicken: keep fixing adept :P
<Hobbsee> manchicken: and the rest of kubuntu :P
<manchicken> ajmitch: No, I got this 64-bit processor and it LOVES to compile _^^
<ajmitch> shame that it'd be wasted with GNU/Hurd
<manchicken> Hobbsee: Did I tell you that I got the DVD player working as a DIRECT result of your mailing list responses to someone else's question?
<ajmitch> bddebian: what's the current memory limit with gnumach?
<manchicken> persia: Gimme a second, I'll get the error for you.
<bddebian> ajmitch: Hush up you traitor ;-P
<bddebian> ajmitch: 1Gb
<bddebian> Well a little less than 1Gb actually
* somerville32 is sad because imbrandon still hasn't fixed his build boxes! :(
<ajmitch> bddebian: I preferred to spend my time where it would be more useful
<manchicken> ajmitch: I actually don't like the linux kernel.
* ajmitch sees a critique of the Hurd by neal
<ajmitch> should be interesting reading to see where it sucks
<manchicken> I don't necessarily like Hurd either though.
<manchicken> persia...
<manchicken> dh_install -padept-manager
<manchicken> cp: cannot stat `./debian/tmp/usr/bin/adept_manager': No such file or directory
<manchicken> dh_install: command returned error code 256
<manchicken> make: *** [binary-install/adept-manager]  Error 1
<bddebian> adept_manager or adept-manager?
<ScottK> bddebian: Would you be up for another look at my package? I got the documentation stuff all worked out: http://revu.tauware.de/details.py?upid=4056
<bddebian> ScottK: I'll try.  I'm busy playing my NON-FREE game atm ;-P
* bddebian hides
<joejaxx> bddebian: is there a channel for hurd?
<bddebian> joejaxx: #hurd
<Hobbsee> manchicken: nope?  cool!
<persia> manchicken: Oh.  I'm really not sure why it worked for me then.  Looking briefly at debian/dirs, I suspect you need to replace "usr" with "usr/bin".
<ScottK> Thanks.  It'd be cool if you did, I have a couple of others and I think I'm ready to get this one behind me.
<manchicken> persia: But these files are the same for me as they are for you....
<persia> manchicken: That's why I'm not sure why it worked for me :)
<manchicken> I'm thinking you have something installed that I don't...
<persia> manchicken: I probably do, but your Build-depends looks fine to me, and I'm guessing you are building with newest feisty, so I shouldn't have newer cdbs or debhelper.
<bddebian> ScottK: Don't shoot me :-)
<bddebian> W: postfix-policyd-spf-perl: manpage-has-errors-from-man usr/share/man/man8/postfix-policyd-spf-perl.8p.gz 167: warning: can't find numbered character 194
<manchicken> persia: Could you give me the versions of those two packages?
<manchicken> I've got 0.4.46ubuntu7
<persia> manchicken: debhelper 5.0.42ubuntu1 and cdbs 0.4.46ubuntu7.
<ScottK> Any suggestion on where I look to find out what numbered character 194 is and what I do about it?
<ScottK> bddebian: No shooting.  It's my job to get it right and you job to find it when I don't.
<manchicken> I got the same versions.
<persia> ScottK: Try vim -b on the file.  One of the characters should be \194.  Delete this.  Edit the file in a UTF-8 environment.  Add the correct character.
<bddebian> N:   "can't find numbered character" usually means latin1 etc in the input,
<bddebian> N:   and this warning indicates characters will be missing from the output.
<bddebian> N:   You can change to escapes like \[:a]  described on the groff_char man
<bddebian> N:   page.
<manchicken> persia: What version of devscripts do you have?
<persia> manchicken: 2.9.27ubuntu2
* ScottK is learning something new every day...
<manchicken> Hmm....
<ScottK> Does Kate count as a UTF-8 environment?
<persia> ScottK: If KDE is in a UTF-8 locale (I think it is by default for Kubuntu).
<ScottK> Thanks.  I'll go double check that.
<ScottK> Is en-us UTF-8?
<Laser_away> teer2: still there?
<ScottK> Ironically enough txt2man has no man page.
<bddebian> heh
<LaserJock> ScottK: really?
<LaserJock> does it have a txt? :-)
<ScottK> txt2man -h
<ScottK> It has a man page, it's just blank, at least here.
* somerville32 sighs.
<somerville32> My dpatches aren't being applied.
<LaserJock> you have the right stuff in debian/rules?
<somerville32> Yup
<crimsun> are they listed in debian/patches/00list ?
<somerville32> yes
<crimsun> and the dpkg-buildpackage log?
<somerville32>  debian/rules build
<somerville32> test -d debian/patched || install -d debian/patched
<somerville32> dpatch  apply-all  
<somerville32> dpatch  cat-all  >>patch-stampT
<crimsun> it will enumerate each dpatch as it is applied and report success or failure (ftbfs) on the same line
* somerville32 nods.
<somerville32> It doesn't
<somerville32> so I know my patch isn't being applied
<crimsun> url to source package?
<somerville32> It isn't uploaded
* somerville32 uploads.
<LaserJock> Hobbsee: is the u-u-s mailing list up and running?
<crimsun> yes, it is.
<LaserJock> that should be on -motu
<somerville32> ultra-ubuntu-secret mailing list?
<somerville32> http://revu.tauware.de/details.py?upid=4061
<Toadstool> or ubuntu-universe-sponsors iirc
<Toadstool> re
<somerville32> ah
<Hobbsee> LaserJock: yes
<crimsun> that source package does not contain a debian/patches/00list and thus no dpatches would be applied.
<LaserJock> Hobbsee: excellent, thank you very much. :-)
<Hobbsee> LaserJock: :)
<LaserJock> I was sad for those emails to go
<somerville32> lmao
<LaserJock> because navigating +subscribed bugs on that one is a little tough
<somerville32> I forgot to debuild -S -sa it again
<crimsun> well if it's bug emails you seek, I can send you the six thousand unread I have.
<somerville32> thanks crimsun
<LaserJock> and I *must* get better at email
<LaserJock> crimsun: 6k? dude, how long will it take you to get through that?
<crimsun> 30 mins.
<somerville32> crimsun == machine
<LaserJock> lots of trashing, I'm guessing
<somerville32> true
<LaserJock> I just get information overload and stare at my screen for a while thinking "Oh my gosh, how can I get anything done"
<LaserJock> apparently that's what sets the losers from the crimsuns :-)
* bddebian == loser :-(
<LaserJock> bddebian!
<somerville32> false
<LaserJock> boy, have I a job for you, mwuahaha ;-)
<bddebian> Uh oh
* LaserJock brings out his Science whip
<LaserJock> according to http://tiber.tauware.de/~laserjock/motuscience/bugs.html we have 184 open science bugs
<LaserJock> you wanna have a go at some?
<bddebian> Sure
<bddebian> Gads, still tetex stuff eh :-(
<LaserJock> I'm guessing there are quite a few sync/merge bugs in there
<LaserJock> yeah, tetex and gnumeric are the big ones, but they're also in Main so they get more attention I think
<bddebian> :-(
<manchicken> Do you guys do development in pbuilder?
<LaserJock> yes
<manchicken> Or do you develop in your normal environment and build and test in pbuilder?
<LaserJock> well, we build in pbuilder
<bddebian> yes
<manchicken> I've never really used pbuilder before.
<manchicken> I've just been doing stuff in chroot.
<bddebian> I typically only use pbuilder for building
<LaserJock> it's good
<LaserJock> yeah
<LaserJock> I use it occasionally for other things
<LaserJock> manchicken: it's small then a chroot when packed (like 50-100MB)
<LaserJock> it also makes sure your deps are right
<LaserJock> at it's basically the closed we have to the buildd environments
<LaserJock> as
<LaserJock> *as I meant
<LaserJock> shesh
<LaserJock> ^^ the Hobbsee shell
<Hobbsee> LaserJock: hrm?
<Hobbsee> haha
<manchicken> I've just been using a chroot and building and installing debs.
<manchicken> It's like pbuilder, except I actually do my development in the chroot.
<LaserJock> yeah, I know
* Hobbsee --> work
<LaserJock> we just generally prefer using pbuilder before uploading because it's a clean chroot
<LaserJock> so deps and stray files aren't a problem
<Toadstool> well, most of the time :)
<LaserJock> heh, there are always exceptions, it seems
<Toadstool> I've once been bitten by a package not build-depending on procps although it needs it iirc (don't ask me why...)
<Toadstool> procps is installed in a pbuilder but not on the buildds
<Toadstool> or something like that :p
<LaserJock> well, we had a case the other day where a package failed to find pkg-config on the buildd
<LaserJock> but it worked fine in pbuilder
<Toadstool> yup, things happen
* Toadstool hides
* LaserJock wonders why Toadstool is always hiding
<LaserJock> I think it must be his gf
<Toadstool> heh
<Toadstool> visas suck by the way, I don't want to go back to France :p
<LaserJock> it seems like REVU has been fairly busy since we did the REVU Sprint
<LaserJock> or is it just me?
<crimsun> it's you, baby.
<crimsun> you're the motu supastar!!!
<somerville32> 0_0
* somerville32 sneezes.
<LaserJock> crimsun: well, I thought it might have been because I was paying attention to it more
<LaserJock> but it really does seem like there is more activity
<duluu> what does python (<< 2.5) mean?
<crimsun> it means strictly les than 2.5
<crimsun> less, even
<crimsun> LaserJock: of course, you're the motu superstar.
<LaserJock> bah
<LaserJock> crimsun: stop it before I turn into bddebian ;-)
<crimsun> you two are already motu deities
<LaserJock> motu dummies perhaps
<bddebian> Hey, I resemble that remark!
<duluu> i'm having problem to install ubuntu-desktop on my system 
<duluu> because packages that have python (<< 2.5) dependency failing to install
<duluu> I use feisty
<somerville32> Can someone motu supastar themselves over to http://revu.tauware.de/details.py?upid=4063 ?
<LaserJock> duluu: I think that might be just a temporary problem
<duluu> but I want to understand the problem, and help 
<LaserJock> somerville32: sorry, not today. I'm trying to put plastic over windows and work on the packaging guide
<LaserJock> duluu: well, we are switching to python 2.5 as the default python version
<somerville32> bddebian, :)
<crimsun> duluu: you can't help, really. It's a transition; all the packages are being rebuilt.
<duluu> ok 
<duluu> thanks
<somerville32> Toadstool, :)
<duluu> how long it will take, approximately?
<LaserJock> not long I don't think
<crimsun> a couple more business days max
<LaserJock> Matthias uploaded a whole bunch of packages for rebuilding over 12 hrs ago
<ScottK> That's done at last.  http://revu.tauware.de/details.py?upid=4064 is free of unexpected lintian errors if any MOTU would please take a look.  
<palski> is config.guess meant to be changed during debuild?
<LaserJock> it's better to not be in clean:
<LaserJock> but otherwise
<palski> problem is that I'm trying to merge one package and before dbuild diffs are good but after debuild debdiff has lots of diffs in config.guess
<crimsun> right, so either use filterdiff(1), or remove autotools-dev
<palski> ok, i'll try
<ScottK> 'night all.  I'm off to bed.
* somerville32 has an issue.
<somerville32> nvm
<somerville32> hehe
* somerville32 has no issue
<palski> Merges should always be marked as wishlist?
<persia> palski: Unless they fix some known larger issue, I think so.
<palski> persia: ok, thanks
<Simon80> so, um, I just packaged logitech_applet, it's got no maintainer, but it's small and doesn't really need one
<Simon80> is that a bad enough reason to reject it?
<persia> Simon80: If you packaged it, you get to be the maintainer:)
<Simon80> yay!
<Simon80> alright, someone revu it, easiest revu ever.. the only gripe you may have is no manpage
<Simon80> I suppose it's a legitimate gripe
<somerville32> Simon80: Has to have a manpage
<somerville32> Please make one and reupload :)
<tsmithe> could a MOTU please take a look at my two packages for UbuntuStudio? http://revu.tauware.de/details.py?upid=4049
<Simon80> lol, somerville, cmon :(
<Simon80> bah
<persia> Simon80: no manpage will cause a lintian error, which is grounds for further REVU.
<somerville32> tsmithe: Did you fix the errors that bddebian listed?
<Simon80> it's not an error
<Simon80> it's a warning
<tsmithe> somerville32, they are unfixable
<somerville32> tsmithe, wrong.
<tsmithe> err...
<tsmithe> how so?
<somerville32> W: alsa-firmware: extra-license-file lib/firmware/emagic/license.txt 
<tsmithe> oh yeah
<somerville32> Remove license.txt from being installed
<tsmithe> i thought you mean the errors
<somerville32> W: alsa-firmware: old-fsf-address-in-copyright-file 
<somerville32> Update the copyright file
<somerville32> W: alsa-firmware: description-synopsis-might-not-be-phrased-properly 
<somerville32> remove period from end of synopsis
<tsmithe> ok
<somerville32> W: alsa-firmware: description-starts-with-leading-spaces 
<somerville32> Should be able to figure that one out
<somerville32> As for the errors, run lintian with verbose enabled
<tsmithe> ok
<tsmithe> can i use dh_install to uninstall a file, or will it have to be done with a manual rm in the rules?
<somerville32> What is installing it? The makefile?
<somerville32> Does this package exist in Debian?
<tsmithe> yes no
<somerville32> Elaborate, please :)
<tsmithe> ok
<tsmithe> the makefile is installing it
<tsmithe> it does not exist in debian
<tsmithe> (at least it didn't last time i checked)
<tsmithe> well it seems to now
<persia> tsmithe: The easiest way to mask the emagic license is probably to delete it with a patch prior to build.
<tsmithe> but it's an old version
<somerville32> tsmithe: Then you need to download the package and update it
<somerville32> Not make your own
<tsmithe> to be honest, i thought it didn't exist in debian
<somerville32> Thats ok
<somerville32> but you still versioned the package wrong then
<tsmithe> somerville32, hmm?
<somerville32> alsa-firmware_1.0.14rc1-1ubuntu1
<somerville32> If it is a new package that doesn't exist in debian, it would be: lsa-firmware_1.0.14rc1-0ubuntu1
<somerville32> with the a on front of course
<tsmithe> ok
* tsmithe changes it
<somerville32> Also
<somerville32> I would have seperate binary packages for the different blobs
<tsmithe> hmm
<tsmithe> that's might be a bit confusing
<tsmithe> we have alsa-firmware-loaders
<tsmithe> as 1 package for many loaders
<somerville32> Hmm.. sure
<somerville32> w/e works
<tsmithe> i'm also updating that to fit with the new alsa-firmware package, upid 3892
<somerville32> rm -f $(CURDIR)/debian/alsa-firmware/lib/firmware/*.bin
<somerville32> That is in build
<somerville32> What does that do?
<somerville32> Does that remove the binary you aren't allowed to distribute?
<tsmithe> no
<somerville32> What does it do?
<somerville32> Or sorry, what is it for?
<tsmithe> it's left over from when i had troubles with hdsploader
<somerville32> Please fix it then
<tsmithe> but now it does nothing (as theres nothing there)
<somerville32> I also notice you use different e-mails all over the place
<somerville32> You also must use a @ubuntu.com e-mail for the maintainer field
<somerville32> Anyhows, I don't think your package will get approved since it already exists in Debian
<somerville32> I also think that config.* are supposed to be deleted in clean
<somerville32> I hope thats helpful to you tsmithe
<somerville32> Anyhows, I need sleep :)
<tsmithe> it is - very
<tsmithe> thanks
<tsmithe> night
* somerville32 waves.
<somerville32> That is... lol
<tsmithe> huh?
<somerville32> unless someone else needs a review :)
<Simon80> it can wait
<tsmithe> somerville32, you still around
<tsmithe> ?
<somerville32> Yup
<tsmithe> i was being stupid
<tsmithe> when i searched for alsa-firmware in the debian packages, it came up with alsa-firmware-loaders
<tsmithe> i didn't read -loaders
<tsmithe> it's not in debian
<somerville32> ah, k :] 
<somerville32> Simon80, Want me to review?
<tsmithe> somerville32, one last thing
<somerville32> dh_fixperms seems to be very much broken :(
<tsmithe> at upid 3892, i have updated ubuntu's alsa-tools package to support my new alsa-firmware... however bddebian complains about manpages. the current ubuntu package doesn't have manpages...
<Simon80> how do I incorporate docbook xml processing into my cdbs rules file?
<somerville32> tsmithe, It must have a manpage.
<tsmithe> must? the existing package doesn't - otherwise it would be in mine
<somerville32> tsmithe, Write your own
<tsmithe> hmm
<tsmithe> that's a bummer
<lifeless> somerville32: there is not MUST for man pages.
<lifeless> somerville32: its preferred, not required.
<Simon80> indeed
<lifeless> that said, writing a small one is easy, and a good idea
<manchicken> Anybody know if k9copy is main or universe?
<somerville32> lifeless: Ther other MOTUs make me have one in all of mine, lol
<lifeless> manchicken: apt-cache show k9copy
<Simon80> but how do I process it?
<lifeless> somerville32: a reviewer can do that ;)
<Simon80> someone who's used a manpage.xml, just tell me
<manchicken> Beautiful.  Thanks.
<lifeless> Simon80: if its a man page, surely patch the package source, as you'll want to feed it upstream
<manchicken> I'm learning all sorts of things about dpkg.
<Simon80> err... lifeless, no
<manchicken> Like, yesterday I learned `dpkg-query -S /usr/bin/perl` will tell you what package /usr/bin/perl was installed by.
<manchicken> mmm... dpkg...
<tsmithe> tee hee somerville32: my asoundconf-gtk got in ages ago :P
<somerville32> tsmithe, I know.
<tsmithe> :)
<tsmithe> poor poor cody
<Simon80> manchicken dpkg -l - lise all packages, dpkg-deb -c *.deb, list files in a deb, dpkg-query -L package, list files in installed package
<somerville32> tsmithe, Why am I poor?
<Simon80> list*
<tsmithe> somerville32, cos you haven't donated to the venezuela fund! :P
<lifeless> Simon80: why no ? manpages generally wont be distro specific
<somerville32> tsmithe, and I won't ;] 
<Simon80> lifeless: I mean, what's the simplest thing to add to my cdbs rules file to get it to build my manpage from manpage.xml
<tsmithe> somerville32, so you'l
<lifeless> Simon80: so the upstream author will want it
<tsmithe> hmm
<tsmithe> somerville32, so you'll stay poor
<tsmithe> :P
<somerville32> tsmithe, But really... why am I poor?
<lifeless> Simon80: the simplest thing is not to build man pages from within the distro *packaging rules*, but to build them from within the *source code building rules*
<tsmithe> somerville32, cos your app's not in
<tsmithe> and monday's a long time away
<Simon80> err..
<somerville32> tsmithe, https://launchpad.net/~cody-somerville/+packages
<Simon80> lifeless: it's inconsequential, there's NO upstream
<lifeless> what package is this ? :)
<Simon80> logitech_applet
<Simon80> it's very small, doesn't even need a manpage, so I'm kind of wanting to get this over with
<lifeless> Simon80: is there a configure, and Makefile.am etc ?
<Simon80> yeah
<lifeless> then thats the place to put the manpage generation
<lifeless> as autoconf and automake have a tonne of machinery for doing that
<Simon80> oh
<lifeless> your debian/ directory should be exclusively for doing 'package the software' tasks - its not geared for doing general software building
<Simon80> um, no
<lifeless> and trying to do general software builds within it will just generate metric amounts of cruft.
<Simon80> debian has to build the software
<Simon80> ah
<Simon80> well, not really, this is a one time deal
<Simon80> and I mean, what you're saying is contrary to what dh_make does, which is put a manpage into debian/
<LaserJock> heh, it wouldn't be the first time dh_make does something we generally don't want to do
<lifeless> dh_make takes the built manpage and packages it
<Simon80> lol
<lifeless> it does not *build* the manpage in the first place
<LaserJock> it converts it from sgml to man
<Simon80> no, dh_make generates a debian directory
<LaserJock> which is sort of building
<Simon80> you're confusing debhelper with dh_make
<LaserJock> no
<Simon80> not you
<lifeless> later all
<Simon80> and I know, dh_make is part of debhelper
<LaserJock> I don't think it is
<somerville32> I have a file that is not a binary nor a script with perms 0755 in the original tarball from upstream. dh_fixperms does not seem to address the issue so is it ok for me to manually modify the permissions before running make? :)
<LaserJock> and lifeless is right in the sense that packaging isn't meant to do a bunch of building, patching, and adding files
<Simon80> hrm
<LaserJock> it's meant to just "guide" the build process along and make sure things get packaged up into a .deb properly
<LaserJock> *normally* things should go upstream
<LaserJock> but as you've said there is no upstream
<LaserJock> so you need to take vare of it
<siretart> LaserJock: you were talking about acroread removed from ubuntu before, no?
<somerville32> LaserJock: ^^
<LaserJock> yeah
<LaserJock> I'm sad to see it go
<LaserJock> but I read the bug, it seems difficult
<Simon80> from my point of view, this is a tiny package, NO upstream, I've been using a checkinstalled copy for ever, and I don't even care if there's a manpage in it
<LaserJock> somerville32: I guess you could but I don't know why you would exactly
<Simon80> all I wanted to know is what one liner to add to my rules to get this manpage file taken care of
<tsmithe> LaserJock, are you free to review?
<somerville32> LaserJock, Because lintian and linda complain
<LaserJock> tsmithe: nope
<tsmithe> ok
<LaserJock> somerville32: ah, then there you go
<somerville32> W: catfish; Executable /usr/share/catfish/catfish.glade with perms 0755 is not an ELF file or script.
<LaserJock> tsmithe: sorry dude, trying to get to bed
<tsmithe> ahh
<tsmithe> i'll let you rest then
<LaserJock> Simon80: dh_make provides you with the line
<Simon80> hasn't seemed to.. I genned a cdbs package
<LaserJock> ah, that would be why
<LaserJock> just do a quick one in a tmp dir
<somerville32> LaserJock: I did chmod -x but it still complains : (
<LaserJock> single binary
<LaserJock> somerville32: hmm
<somerville32> LaserJock: Can I add an override?
<somerville32> Actually, no
<somerville32> Best just to fix it
<slomo> LaserJock: why should acoread be removed?
<LaserJock> slomo: apparently the license makes it undistributable
<LaserJock> it has been removed from Feisty by tollef
<somerville32> LaserJock, What permissions should the gladefile have?
<somerville32> I'll just patch the Makefile to set the permissions with install
<LaserJock> somerville32: just normal
<somerville32> Whats "normal"?
<slomo> LaserJock: oh... well, i don't use it anyway ;) maybe this gets more people to use and improve evince/poppler ;)
<LaserJock> 660? perhaps
<LaserJock> slomo: unfortunately it is a "must have" app for me
<crimsun> somerville32: 644
<slomo> LaserJock: why?
<LaserJock> slomo: all the vast number of university forms
<LaserJock> acroread is the only thing that will do the filling out of them properly
<crimsun> many of our pdfs are encrypted with forms
<slomo> LaserJock: right... but this should change in the near future, people were working on form support for evince and the screenshots looked good already...
<LaserJock> for the most part our uni no longer takes hand done forms
<LaserJock> slomo: we'll see, Linux acroread barely gets by as it is
<LaserJock> I almost have to use wine+acroread
<somerville32> What is acroread do?
<somerville32> heh
<somerville32> What does acroread do?
<LaserJock> the acrobat pdf reader
<somerville32> Interesting
<LaserJock> we get into trouble a fair amount as it is because we us Linux acroread
<StevenK> acroread was killed from Feisty, if I recall?
<crimsun> yesterday, yes
<crimsun> immediately after being ACCEPTed, ironically
<slomo> LaserJock: does your university pay you windows licenses? seems that this is the only correct way then for them to fill the forms ;)
<Simon80> http://revu.tauware.de/details.py?upid=4065
<StevenK> crimsun: Hah
<Simon80> perhaps someone would like to just review it, it's just a manpage, NOBODY who is using this utility needs me to copy its --help output into a manpage
<tsmithe> somerville32, that rm line is needed
<somerville32> tsmithe, Why?
<tsmithe> cos otherwise i get two copies of the files it removes
<siretart> hm. perhaps we can do something like 'http://debian-unofficial.org' - think of http://ubuntu-unofficial.org or something
<LaserJock> slomo: they pay for windows, and office, and full adobe acrobat if I want
<somerville32> tsmite: What do you mean?
<siretart> who would be interested in helping out maintaining such an repo?
<LaserJock> siretart: what would it have in it?
<LaserJock> I'm not hugely familiar with debian-unofficial.org
<somerville32> siretart: Sure. More practise the better :)
<crimsun> I'm still holding out hope for evince (and possibly acroread in feisty-commercial)
* somerville32 nods.
<somerville32> crimsun: My thoughts exactly :re feisty-commercial
<tsmithe> somerville32, otherwise, i get files in /lib/firmware and /lib/firmware/hdsploader
<StevenK> crimsun: What about evince?
<somerville32> tsmithe, But why?
<crimsun> StevenK: hoping that its form-filling capabilities mature
<siretart> LaserJock: look at http://debian-unofficial.org/packages.html for getting an idea
<StevenK> Ahhh.
<tsmithe> cos they are copied by dh_install, but not removed
<siretart> perhaps libdvdcss as well
<somerville32> tsmithe: Then fix dh_install?
<somerville32> Why would dh_install copy it over twice?
<tsmithe> it doesn't... the makefile puts it in /lib/firmware, and dh_install copies it to /lib/firmware/hdsploader, leaving the old files... bah; i'll just patch the makefile
<somerville32> Good idea! :)
<somerville32> But it is best to use the Makefile instead of dh_install
<tsmithe> of course
<somerville32> crimsun: I have a package that I just uploaded to revu that I'm 99% ready for upload unless I've done something stupid :) Could you review quickly? (the package is small so should be quick too)
<somerville32> *sure is
<somerville32> Xubuntu related (if thats a motivator ;] )
<crimsun> unfortunately it's quarter past 4, and I'm about to collapse. I'll review some later this noon.
<tsmithe> in the morning?
<somerville32> crimsun: 5am here ;] 
<tsmithe> you should sleep!
<tsmithe> both of you!
<Laser_away> me too, even though it's only 1:00am
<somerville32> siretart: How about you? :)
<tsmithe> it's 0915 here
* somerville32 wishes he was a MOTU.
* tsmithe too
<Laser_away> don't, your brain will rot
<Laser_away> ;-)
<Laser_away> good night everybody
<tsmithe> :)
<tsmithe> night
<somerville32> Welp, http://revu.tauware.de/details.py?upid=4066 <-- If anyone wants to review :)
<tsmithe> welp? you really should go to sleep
<somerville32> I should
<somerville32> tsmithe: Why don't you review my package for me?
<tsmithe> ok
<somerville32> Maybe I've done something stupid because I'm sleepy
<tsmithe> i'll try
<somerville32> ok :)
<somerville32> Simon80, You still around?
<somerville32> Simon80, You need to rebuild the source package
<somerville32> debuild -S -sa
<somerville32> And then reupload
<siretart> somerville32: well, I would talk and arrange things with the debian-unofficial guy, but I don't think I can maintain the repo alone
<somerville32> siretart: Awesome.
<somerville32> siretart: Review me package and it's a deal ;] 
<somerville32> Simon80, However, looking through the diff, it appears that there is some issues.
<Lutin> hay there
<tsmithe> somerville32, that package looks fine and dandy to me
<somerville32> tsmithe, Awesome :) Thanks.
<Lutin> siretart: could you have a look at this SRU proposal ? https://bugs.launchpad.net/ubuntu/+source/evolution-jescs/+bug/77977
<Ubugtu> Malone bug 77977 in evolution-jescs "[SRU] [ftbfs]  typo in evolution-jescs-2.8.2/debian/rules" [Medium,In progress]  
<siretart> somerville32: which package?
<somerville32> siretart, http://revu.tauware.de/details.py?upid=4066
<somerville32> Siretart: If you're reviewing it, just let me know cause I'm waiting for you to finish before I goto bed ;] 
* somerville32 also notes that he is currently listening to the spice girls.
<siretart> puh, python stuff. with pysupport :/
<somerville32> It is easy!
<somerville32> :)
<somerville32> Siretart, if I wanted to become a MOTU, would you help me? :)
* tsmithe too!
<tsmithe> i want to become a motu - but i need to be a member first...
<siretart> somerville32: I've seen you hanging around here for some time, I think you'd make a good ubuntu-dev
<somerville32> siretart: Should I get some more experience under my belt before applying with the TB though?
<siretart> somerville32: I've just looked at this one package, and I think it is fine. Who did sponsor your previous uploads?
<somerville32> siretart: Crimsun and LaserJock
<somerville32> Crimsun did my two SRUs and LaserJock did pyNeighborhood
<tsmithe> how much does one have to have done to get membership, even?
<somerville32> tsmithe: Your not a member yet?
<tsmithe> nope
<somerville32> *You're
<siretart> do you *feel* yourself ready for ubuntu-dev?
<somerville32> siretart: Well, I've never done a merge yet, lol
<tsmithe> am i ready for membership?
<somerville32> tsmithe: Yes.
<tsmithe> ok
<somerville32> tsmithe, Whats the link to your wiki page?
<tsmithe> hang on
<siretart> somerville32: well, then just do some. there are plenty left, I think ;)
<somerville32> hehe
<somerville32> Ok
<somerville32> I'll do some after work tomorrow
<somerville32> But I really need to goto bed
<siretart> sleep well!
<somerville32> It is 5:40am now and I have to go into work @ 11am
<persia> somerville32: Better hurry.  At current processing rates, there are only three or four days worth of merges left :)
<tsmithe> https://wiki.ubuntu.com/TobySmithe
<somerville32> persia: I shall do a whole bunch tomorrow :)
<somerville32> persia, siretart: Just upload to revu like normal?
<somerville32> (if they are in universe)
<siretart> somerville32: catfish looks really lovely
<Sp4rKy> hi
<persia> somerville32: I open a merge bug, make the merge, post a debdiff to the bug, and subscribe u-u-s.  If you are less confident, REVU also works.
<tsmithe> Sp4rKy, hi
<somerville32> persia: k
<Sp4rKy> i'm trying to use ant.mk, and i don't understand how JAVA_HOME var should be set ?
<siretart> somerville32: interested in having it in debian?
<somerville32> siretart: Yes, please. It is already in Fedora Core so we gotta get caught up ;] 
<somerville32> siretart: The program is actually programmed by a member of the Xubuntu Community too :)
<somerville32> I picked the name, haha
<siretart> somerville32: are you familiar with the debian new maintainers guide, could you file an ITP for catfish? 
<somerville32> siretart: I have never done any work with Debian at all
<siretart> somerville32: debian coordinates new packages via bugs. to indicate the intend to package new software, we use so called ITP bugs
<somerville32> siretart: Alrighty.
<somerville32> I'll look into it after work :)
<siretart> somerville32: okay, I installed to package on my debian/etch notebook, seems to work fine
<somerville32> Awesome :)
<siretart> somerville32: your next step is to file an ITP in the debian bug tracker
<gpocentek> somerville32: this tool is the same as the zenwalk one, I am wrong?
<somerville32> Yup
<somerville32> Search4Files is catfish
<gpocentek> why don't we keep the name ?
<somerville32> gpocentek, upstream renamed it
<gpocentek> ah, ok
<somerville32> It is interesting that the 15th most used word in this room is my nick, hehe
<Lutin> somerville32: according to the new python policy, you should build-dep-indep on python-support (=> 0.5.3), and not (>= 0.3)
<somerville32> link?
<somerville32> Because I put 0.3 for pyNeighborhood
<somerville32> and it is already uploaded to new
<Lutin> somerville32: tou also need a XB-Python-Version: ${python:Versions} field for your binary package
<Lutin> somerville32: http://wiki.debian.org/DebianPython/NewPolicy
<somerville32> Hmm...
<somerville32> What should I do about pyNeighborhood?
<persia> somerville32: Upload -0ubuntu2 (if it is indeed broken).  Ad a note in the changelog explaining why.
<Sp4rKy> does anyone can say me how i have to set JAVA_HOME in debian/rules ?
<somerville32> persia: Isn't broken. Just doesn't comply with policy.
<persia> somerville32: There is a difference?
<somerville32> persia: The package works regardless ;] 
<somerville32> Can't I just ask an archive admin to reject it?
<tsmithe> right /me out
<persia> Sp4rKy: Take a look at some other Java packages.  If you can find one that builds with Ant even better.  That is probably your best guide.
<Sp4rKy> ok
<persia> crimsun: You're getting faster every day!  Thanks.
<crimsun> the whole sleep thing is overrated when I still have 4000 emails to read
<somerville32> Lutin, Ok, re-uploaded catfish :)
<persia> crimsun: :)
<Lutin> somerville32: great 
<somerville32> Wahts with all the extra files?
<somerville32> Looks like a build log and stuff
* crimsun taps his foot waiting for the merge for 79052
<somerville32> http://revu.tauware.de/details.py?upid=4066
* persia was distracted by webcomics.  Getting back to it...
<somerville32> New upload:
<somerville32> http://revu.tauware.de/details.py?upid=4068
<somerville32> 4068 should be python policy compliant :)
<somerville32> Siretart: ping
<crimsun> contentless ping warning.
<somerville32> Siretart: ping. ^^
<crimsun> contentless ping warning.
<siretart> somerville32: manual contentless pong
<somerville32> lol
<somerville32> siretart: Can you take a look at 4068?
<somerville32> I just made a few quick mods to make it python policy compliant
<siretart> oh, even better
<somerville32> :] 
<siretart> I admit that I didn't follow the python policy that close after joss turned into such an moron :/
<somerville32> lol
<somerville32> Who is joss?
<gpocentek> somerville32: you have 2 dh_installman calls in debian/rules :)
<siretart> the author of python-support
<somerville32> Oh noes :(
<gpocentek> somerville32: not a big problem, but... only 1 is nicer
* somerville32 nods.
<gpocentek> somerville32: FYI CDBS rocks :)
<somerville32> haha
<somerville32> I'm liking debhelper
<somerville32> But I'll have to try CDBS sometime soon
<persia> somerville32: Then you haven't played enough with cdbs.  It does it for you (yes, all of it).
* somerville32 knows.
<somerville32> But I figure if I want to become a dev, I should know debhelper too
<gpocentek> somerville32: and it seems that fishcat has several command line option, it'd be nice to have them listed in the manpage
<siretart> somerville32: rather get used to debhelper than to cdbs.
<gpocentek> options*
<somerville32> gpocentek, I just uploaded to revu, lol
<somerville32> I guess I could add them but I need to get to bed
<siretart> somerville32: cdbs is great for packages with a 'standard' build system. if you need to customize things, cdbs gets a hell quickly
* somerville32 nods.
<siretart> since there is nearly zero real dokumentation
<gpocentek> oops s/fishcat/catfish
<somerville32> hehe
<somerville32> Is there any funky manpage magic I should use?
<somerville32> Or can I just plop it in
<persia> I've never seen MoM get it so wrong.  aqsis available.
<crimsun> bah, over 2 minutes.
* persia is pentitent about slothly behaviour
<crimsun> nah, I'm referring to my lag time
<crimsun> I don't think I can break 2 minutes between the debdiff posting and the dput
<persia> crimsun: I think you'd need a script.
<crimsun> unfortunately doesn't seem scriptable due to LP lag time
<crimsun> meaning "yes, it's certainly scriptable, but it won't break 2 minutes"
<persia> How long does LP sit on it before allowing others to download it?
<crimsun> not very long, but I'd still have to poll the page or wait for an email
<persia> crimsun: Right, I forgot about the email.  With that duration included, 2 minutes astonishes me - I often have to wait 5 or more minutes for notice.
<crimsun> oh geez, that was a bad misparse (for some reason I misread < as << on the page, which is my cue to go to bed)
<persia> crimsun: Sleep well.
<zorglu_> q. when i do "dpkg --build debian/tmp ../debian_package" in one of my 'rules', i got "dpkg-genchanges: failure: cannot open upload file ../mypackage.deb for reading: No such file or directory"
<zorglu_> but i could swear my package building script worked before. (how many time i have heard that from other :)
<StevenK> Why not just use dh_builddeb?
<zorglu_> any suggestion on a fix ?
<zorglu_> because i failed to understand what they do when i looked. sparse doc and unable to find the code, are the reasons i remember
<StevenK> Change it to dpkg-deb -b debian/tmp, it should figure out the archive name on it's own, and double check everything is installing into debian/tmp
<zorglu_> how do i specify the destination directory of the built pacakge ?
<StevenK> Just put .. then
<StevenK> dpkg-deb -b|--build directory [archive|directory] 
<zorglu_> it is what i have in fact :)
<zorglu_> the weird thing is that the ../debian_package/mypackage.deb got created
<zorglu_> only the dpkg-genchanges fails to find it
<zorglu_> maybe dpkg-deb --build fails to give it the destination directory ?
<zorglu_> dpkg-genchanges: failure: cannot open upload file ../mypackage.deb <- it does get the "debian_package" direcotry specified in the dpkg-dev
<zorglu_> b
<StevenK> Hrm
<zorglu_> and if i put "dpkg-deb --build debian/tmp .." it works ok
<StevenK> Neat .
<zorglu_> but not if i put "dpkg-deb --build debian/tmp ../debian_package", i mean, genchanges fails vbut the .deb is created
<highvoltage> 4
<StevenK> More than likely, you're not making a .deb that genchanges is expecting.
<zorglu_> yep, genchanges make this clear :)
<zorglu_> dpkg-gencontrol may be my mistake
<zorglu_> i dunno :)
* StevenK idly notes how much easier debhelper makes this. :-)
<zorglu_> well i found it very hard to use when i tried :)
<StevenK> debhelper so isn't very hard. :-)
<zorglu_> lack of documentation forces me to try to analyse their source to understand what they did and i failed to find the source :)
<StevenK> All of the debhelper commands are in /usr/bin
<zorglu_> ok the dpkg-deb produces a simple "dpkg-genchanges -B" wihtout my destination directory
<StevenK> dpkg -L debhelper would have told you that
<zorglu_> this is the cause of the trouble, dpkg-genchanges assume a ".." destination directory
<zorglu_> well it was my first packaging, so i may have done a lot of mistake :)
<StevenK> There's a debhelper tutorial around, that should have gotten you through it
<StevenK> Oh, and examples: /usr/share/doc/debhelper/examples/rules.indep 
<persia> zorglu_: man dh_<whatever> can also be very helpful.
<zorglu_> ok trying to fix with debhelper :)
<zorglu_> which doesnt do much good :)
<zorglu_> dpkg-genchanges -B <- it is exactly the same genchanges which is outputed
<zorglu_> so the destination directory is not really supported ?
<StevenK> A destination directory of .. the default
<StevenK> s/the/is the/
<zorglu_> yep, with ".." it works, with "../debian_package" the .deb is created but genchanges still assume ".."
<zorglu_> what i dont understand is how come this script worked before :)
<zorglu_> well anyway i need to modify the script to get a workaround
<StevenK> dpkg-genchanges -u
<StevenK> Reading the manual page for dpkg-genchanges could have told you that.
<StevenK> dpkg-genchanges -u<dir>
<zorglu_> i got like 6 .deb to generate, i didnt want to put them in the ".." because i didnt want to put them all in the ".." and have this directory "bloated" will all my .deb/.changes of all version, hence my creation of a "../debian_package" for that
<zorglu_> StevenK: i saw this one, but how to set this in the dpkg-deb or dh_buildeb ?
<zorglu_> oh builddeb allow some, lets try :)
<zorglu_> ok lets give up this idea of destination directory :)
<zorglu_> btw dh_builddeb allows to send option to dpkg-deb but dpkg-deb doesnt allow to send option to dpkg-genchanges
<persia> zorglu_: dpkg-genchanges doesn't support the option.
<StevenK> dpkg-genchanges does
<StevenK> dpkg-deb doesn't pass it on, as it were
* persia needs to read the backscroll more carefully
<zorglu_> so how do you guys handle this ?
<zorglu_> you put everything in ".." and got a ".." with many .deb/.changes ?
<StevenK> I use ppbuilder, annd that puts everythhing in /var/cache/pbuilder/result
<StevenK> s/ppbuilder/pbuilder/
<Amaranth> Some people have a build dir
<zorglu_> pbuilder was on my todo list :)
<zorglu_> Amaranth: ahhh :)
<StevenK> Heh
* Amaranth just has Projects
* StevenK builds things under ~/debian or ~/ubuntu
<zorglu_> and this ~/debian got a lot of .deb/.changes in it
<zorglu_> and you dont care as it is all handled by pbuilder :)
<zorglu_> ok so i need a workaround and the ".." will do it for now :)
<Amaranth> you have to build it once to get a dsc file to run through pbuilder
<zorglu_> well im a beginer and i dunno what the .dsc file is :)
<zorglu_> nor the .changes file :)
<zorglu_> nor a lot of other things :)
<StevenK> Amaranth: Or use pdebuild
<Amaranth> StevenK: ooh
<Amaranth> learn something new every day
<StevenK> And generating a .dsc is a matter of dpkg-source -b
<Amaranth> yeah but i build it once anyway
<Amaranth> no need to waste a pbuilder run if it's not going to compile
<Amaranth> pbuilder is slow to setup/teardown
<zorglu_> oh i got one solution :) "copy all my script and directory in a temporary dir, have it built there, and then copy only the .deb in my destination directory" :)
<StevenK> Not with a local miirror. :-)
<zorglu_> maouaouaoua
<geser> some packages started to mangle the Maintainer field in the source package. shouldn't the Original-Maintainer field be visible when doing apt-cache showsrc?
<StevenK> geser: If Launchpad exports it to the Sources.gz
<persia> geser: That's an excellent reason to process this field.  Please update bug 78879 with your reasoning.  I'd be happy to make a patch for your desired behaviour (if you could describe it in some length).
<Ubugtu> Malone bug 78879 in dpkg "dpkg doesn't support the Original-Maintainer field" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78879
<Sp4rKy> is there anyone who know what i have to include in control/rules files to avoid getting this error "java.lang.NoClassDefFoundError: com.sun.tools.xjc.reader.xmlschema.parser.SchemaConstraintChecker" during build ?
<StevenK> A Build-Depend?
<Sp4rKy> StevenK: i think, but i really don't know what
<persia> siretart: I was planning a merge of debian-reference (to 1.10).  Do you have any comments or suggestions before I begin?
<white> this mail might be of some interest, at least I would appreciate some feedback from ubuntu folks
<white> http://lists.alioth.debian.org/pipermail/utnubu-discuss/2007-January/000539.html
<azeem> white: good idea
<persia> white: I'm not authoritative, but if the Utnubu team would be willing to support and assist Ubuntu developers working with Debian, it may well be a better contact point to put on the Wiki, etc.  MOTU topics are generally discussed on ubuntu-motu@lists.ubuntu.com, although Ubuntu doesn't use mail nearly as much as Debian (IRC, the Wiki, and Launchpad are primary communication media).
<white> persia: yes i thought about that, i am not quite sure about the rest of the team, so i am waiting for some feedback and i do not have any clue about how many MOTUs would want to write to that
<white> because if there are 100 MOTUs writing there, but only 2 DDs helping out it might be a bit of a problem :)
<white> though it is worth trying it out i guess
<geser> StevenK: isn't the Sources-file generated from the .dsc files? if so the Original-Maintainer should also be there and we should add XS-Original-Maintainer to the contol file?
<zorglu_> btw is there one of those distro agnostic packaging system (e.g. klick or autopackage or other) which is accepted by default on ubuntu ?
<Adri2000> geser: I'm not really conviced of the way to handle that Maintainer field problem, isn't it possible to do that (move Maintainer to Debian-Maintainer and put Ubuntu Developers as Maintainer) automatically, just after the upload and before it hits archive.u.c?
<geser> not in the .dsc file as this would break the signature
<Adri2000> s/Debian-Maintainer/Original-Maintainer/
<Adri2000> hmm
<persia> geser: Why XS-Original-Maintainer?
<geser> persia: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7
<geser> if I understand it correctly
<geser> Adri2000: for binary packages this is already done on package build
<Adri2000> I know
<Adri2000> and I was wondering why it was not possible to do the same for source packages
<azeem> is it really important to have this for source packages?
<persia> geser: Your understanding matches mine, but I was told to follow https://wiki.ubuntu.com/FeistyReleasePlan ("Original-Maintainer") when I asked mdz if the packages should be changed,  and https://wiki.ubuntu.com/DebianMaintainerField calls for "X-Original-Maintainer".
* persia has been patching with "Original-Maintainer" for the past two days
<geser> Adri2000: because of the .dsc file which is gpg signed by the uploader, if you modify the .dsc file you either break the gpg signature or have to re-sign it
<Adri2000> geser: ok, I understand now
<geser> persia: do you know if X-O-M ends in the .dsc? IMHO if we preserve it in a extra-field it should be visible in the .dsc
<persia> geser: Building now to check...
<persia> geser: No (although this might be another reason to parse the field).
<persia> geser: Nevermind.  That was O-M.  Hold on...
<persia> geser: Neither O-M nor X-O-M are passed to the .dsc.
<zorglu_> btw is there one of those distro agnostic packaging system (e.g. klick or autopackage or other) which is accepted by default on ubuntu ?
<azeem> what do you mean "by default"?
<Lathiat> zorglu_: if you mean into the ubuntu archives, then no
<persia> geser: XS-O-M does the right thing for .dsc (are my patches then incorrect?).
<zorglu_> Lathiat: nope, i mean as in installed by default, so user can install those package easily
<zorglu_> azeem: by default as in i install the cd and i got the support for this packaging system
<persia> geser: Furthermore, should we use XBS-O-M, as pkgmaintainermangler will likely ignore the package due to the @ubuntu,com in the maintainer field?
<geser> persia: yes, you are right, it should be XBS-O-M
<persia> Well then, I'm glad I had a slow couple days.  There are only a few packages in which I put the wrong value.  What's the best way to provide a reference for this?  Update the spec?  Add a new wiki page?
<geser> persia: I would suggest to ask mdz about it and update the wiki page than and perhaps an e-mail with the updated info to u-d-a
<persia> geser: I can at least take care of the first two.  Thanks for the guidance.  I'll stop patching for a while :)
<siretart> persia: IIRC, there was a (build-)dependency missing when I was about to merge it. otherwise I *think* a sync should be fine.
<persia> siretart: I think Debian still doesn't have a .desktop file (checking now).
<Adri2000> does someone plan to write an update-maintainer-field script?
<persia> Adri2000: Hold on :)  The correct values for use remain uncertain...
<StevenK> And it's a one liner in sed ...
<persia> siretart: It still waits for latex-cjk-chinese-arphic-bsmi00lp, and needs a merge for the .desktop file.
<Adri2000> StevenK: with check to see if it's an ubuntu package (check if the version contains ubuntu)? check to see if it's main or universe? etc... maybe a long line :)
<Adri2000> also check if the original maintainer has an @ubuntu.com email
<persia> dh_maintainermangle could do all that (and more).
<siretart> persia: ah, that'll be it
<StevenK> persia: Why would a debhelper program play with the source?
<geser> and why on every package build?
<persia> siretart: Sorry to bother you then: I'm just trying to ping last uploaders when I see them online before I download and start the merge.  Thanks for saving me the effort of discovering this on my own (halfway through).
<persia> StevenK: You're right.  I misread "common tasks related to building debian packages" as "common tasks related to debian packages".
<siretart> persia: you are perfectly right doing this!
<geser> Adri2000: you could patch pkgmaintainermangler (from pkgbinarymangler) to modify debian/control
<Adri2000> Lutin is writing something
<Lutin> he means, a quick hack ^^
<geser> Lutin: I shouldn't be to hard to modify pkgmaintainermangler to modify debian/control
<geser> or at least look at the overrides file from it
<Lutin> geser: I don't have much time to dig this, but maybe you're right
<somerville32> http://revu.tauware.de/details.py?upid=4069 <-- :)
<persia> StevenK: As I'm postponing more merges until I have instructions, I don't support you'd like to discuss your .desktop/menu issue?
<StevenK> persia: No, sorry, I'm just about to go sleep
<persia> s/support/suppose/
<persia> StevenK: No worries.
<persia> somerville32: Your menu file doesn't have an icon.  For some reason, I am forbidden to view the ,desktop, but from the directory listings, I'm guessing there's not one there either.  Does upstream not provide anything?  Even something from which an icon could be cut or cropped?
<somerville32> persia: I do have an icon I could use but it isn't from upstream. Furthermore, the .desktop does use an icon.
* persia downloads, now distrusting the REVU directory browser
<persia> somerville32: I found it (I like icons in /usr/share/pixmaps),  You may still want to make a local catish.xpm (installed into /usr/share/pixmaps) by converting system-search.png (32x32) for reference in the menu file (Add Icon="full-path").
<persia> s/catish/catfish/
<Adri2000> Lutin's script is here! http://pastebin.ca/315348
<Lutin> and Lutin's script has a typo
<persia> Lutin: Nice.
<Lutin> persia: here it is actually: http://pastebin.ca/315356
<persia> Lutin: Ah.  That actually replaces :).  I'm adding this to ~/bin.  Thanks.
<geser> Lutin: there are some more exceptions for the mangling
<Lutin> geser: for sure. I'd be happy to know them, so I can add them
<geser> Lutin: see http://pastebin.ca/315363 for the config file for the maintainer mangler
<geser> you are at least missing canonical.com and ubuntu.com.au
<bddebian> Heya gang
* persia patched lamont's xdelta extra wrong :(
<persia> hi bddebian.
<bddebian> Heya persia
<ScottK> heya bddebian
<ScottK> I think I'm ready for you to look at the package again, but after last night's fun I'm (almost) afraid to ask. http://revu.tauware.de/details.py?upid=4064
<bddebian> Heh
<bddebian> ScottK: Yeah, give me a bit
<ScottK> Thanks.
<persia> ScottK: Just for fun, you may want to change "This may be to short..." to "This may be too short..." in the manpage :)
<Lutin> geser: is adding the exceptions worth it, I mean if there are plans to handle it on buildd for ex, I won't bother with it
<Lutin> ?
<geser> Lutin: it's not that straightforward to modify the maintainer of a source package on the builds, as this breaks the gpg signature in the .dsc file
<Lutin> geser: hum, you're right
<ScottK> persia: This leads to a philosphical question...  I made the man page from the upstream README.  That same spelling error is present there.  Should I fix the spelling error both places for enhanced correctness, fix it only in the man page to keep the diff small, or fix it not at all for consistency with upstream documentation?
<persia> ScottK: For myself, I'd fix the spelling, and send a bug to upstream.
<geser> Lutin: if it would be possible, I'd assume it would be already happening for source packages also
<persia> Lutin: I've added the exceptions locally, if you have yet to do so.
<Lutin> geser: ya, think so
<Lutin> persia: can you pastebin the changes, so I can add them to the script ?
<persia> Lutin: patch at http://pastebin.ca/315380
<Lutin> ok persia, thanks :)
<persia> I'm fairly certain that will also catch lists.*
<ScottK> bddebian: I'm going to fix persia's typo, so on the off chance you are going to advocate my package, I'd prefer you do it to the next rev.  I'll post the url here when it's up.
<ScottK> persia: Your reviews have been very helpful.  The next package I am working on is http://revu.tauware.de/details.py?upid=4053.  In this one the upstream mentions the licenses and gave urls, but didn't include license text.  It was bounced from NEW because of this.  The advice I got from Tollef was to rebuild orig.tar.gz adding the text since upstream declined to do a new release for this.  If you have time, I'd appreciate
<ScottK> aming right when I rebuilt the orig.tar.gz.
<bddebian> ScottK: OK
<ScottK> bddebian: Here it is. http://revu.tauware.de/details.py?upid=4070
<persia> ScottK: These are extremely long package names.  Users are going to hate typing them :)
<ScottK> They should never have to type it.
<ScottK> This is a dependency for another package that comes later.
<Lutin> geser: does it look ok to you: http://dunnewind.net/~lutin/resource/update-maintainer ?
<ScottK> Upstream put it out as a separate package only because it may be useful for other things.
<ScottK> The upstream is also working on getting this into Debian and that's the package name he's using there, so I think it's important to be consistent.
<ScottK> But, I agree.  It's an extremely long package name.
<persia> ScottK: Your first changelog doesn't need to be so specific.  Intiial release is likely sufficient, although it doesn't hurt to follow the practice of documenting everything.
<ScottK> Thanks.  Another philosphical question: Upstream provides a /debian directory and most of that is from the upstream.  Is it better to delete it or leave it when it's not necessary?
<ScottK> Given I'd already rebuilt orig.tar.gz for this package I decided to change as little else as possible.
<persia> ScottK: To reduce confusion, I'd change the license paragraph to "This is free software.  You may use, modify, and distribute it under the terms of either the GNU General Public License (version 2 or later) or the Artistic License.", as the terms don't really match perl's (except in spirit).  On the other hand, I've never written a copyright file, so I'm probably weakest here.
<ScottK> Which file are you in?  That shows up more than one place?
<persia> ScottK: If the upstream debian/ helps you, leave it.  If it doesn't, remove it.  From my memory of old mailing list discussions, it is generally annoying a few versions down, when upstream makes some change you didn't expect.
<geser> Lutin: looks ok for a quick hack :)
<Lutin> geser: feel free to test it extensively, I don't really have the time to do it
<Lutin> geser: espacially the ignore list and the multi-domains selections
<persia> ScottK: I was looking at debian/copyright.  LICENSE seems to indicate these are the same terms as perl, which I don't think is true.
<ScottK> No, it's not the same terms.  PERL is GPL v1 too.
<geser> Lutin: will do, once it's clear if the field should be Original-Maintainer, XBS-O-M or something else
<persia> Lutin: You may wish to move the domains to a variable as well, for improved readability.
<ScottK> The feedback I got from Tollef indicated to me that once the actual licenses that were applicable were added, he was OK with that.
<Lutin> persia: true, but I'd like to be sure it actually works before cleaning up ^^
<Lutin> 1/ make it work flawlessly, make it really clean is extra for the moment :] 
<persia> ScottK: That's the person to convince, so if you have already received word that that language is correct, ignore me.
<persia> Lutin: understood.  I'll start testing as soon as the decision is published, and let you if I encounter any issues.
<ScottK> It was more like didn't object to the revised wording when I e-mailed him back after he bounced it the first time.
<Lutin> persia: ok, tested the ignore domains regexp, seems to be ok so moving to a var :)
<persia> ScottK: The contents of README.Debian do not appear useful to the average administrator.  I know I at least look at that file whenever I want to understand what something does.  I might move that to README.Packaging, and make sure it didn't get included in the binary deps.
* persia grabs the new update-maintainer
<Lutin> persia: have a look at http://dunnewind.net/~lutin/resource/update-maintainer and tell me if it's ok for ya :)
<ScottK> Here: http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz is says README.Debian-source (I didn't find this before).  Does that sound right?
<persia> Lutin: You might use main|restricted) and universe|multiverse) to make it even shorter, but it looks nice.  I'm just not sure about the 3rd from last line.  Thanks a lot for this, it should make things easier.
<persia> ScottK: That sounds exactly right.
<ScottK> persia: BTW, for the perl-policy thingy I have upstream commit rights for the svn, so I didn't write I bug, I just fixed it.
<ScottK> Thanks.  I'll go do that.
<Lutin> persia: the line that actually replaces the maintainer .
<Lutin> ?
<persia> ScottK: When you're upstream, you get all the fun :)
<ScottK> Yeah.  The fun part on that is I'm upstream only after the last release (for about 4 days now).
<persia> Lutin: Yes, it's whether it should be "...\nOriginal...", "...\nXBS-Original..." or something else.
<ScottK> When I was working on packaging I whined about some stuff and the response I got was, OK, then you maintain it...
<Lutin> persia: yep, but as far as we don't know, I can't put voodoo in the script to determine it :] 
<persia> Lutin: My apologies.  I didn't mean that.  To rephrase, except for the part for which the requirements have yet to be defined, it appears that this application meets current expectations for the user community :)
<ScottK> I'm going to clarify debian/copyright too while I'm at it.
<Lutin> persia: hehe, np. thanks :)
<ScottK> persia: Thanks for the help.  Is there anything else before I upload again or are you still looking?
<persia> ScottK: still looking
<ScottK> OK.  Thanks.
<persia> ScottK: README (not Debian) could use some grammar help.  I'm guessing you don't want to take that upstream?
<ScottK> Not today.  English is not the first language of the upstream.
<ScottK> His English is very good (far better than my German, so I shouldn't complain).
<persia> ScottK: In that case, better to leave as-is: carrying that in a dpatch would be unpleasant :)
<ScottK> I will work on that with him for the next release though.
<Lutin> geser: when will know what field we have to use for the debian maintainer ?
<persia> ScottK: TODO seems fairly useless in this version.  Are you sure you want to include it in debian/docs?
<ScottK> Agreed.  I'll remove it.
<geser> Lutin: when mdz answered persia's inquiry
<persia> ScottK: debian/control: s/virtual DNS/virtual DNS server/ (Domain Name Service).  s/the real DNS/a real DNS server/. (Short description is fine).
<persia> ScottK: That's all I see.
<Lutin> geser: ok
<persia> geser: Are you in a timezone where you are up for a while?  I'd like to sleep, and I think my query will not be answered soon :(
<geser> persia: I'm in Europe, do you know which timezone mdz is in?
<Adri2000> Timezone:  America/Los_Angeles
<persia> geser: No.  He seems to move around.  If he responds before I am active again, would you mind confirming anything that remains vague?  I'll check the backlog when I come back, but don't want to miss the opportunity to find sufficient answers that I can resume merging without further embarassment.
<geser> persia: sure, will do
<persia> geser: Thanks.
* persia sleeps
<Lutin> hehe, g'night persia
<ScottK> Thanks persia.
<Lutin> ajmitch: are you around ?
<synic> where can I see a list of packages that will be in fiesty?
<synic> ... or are already in 
<geser> in the Packages file for feisty
<synic> there's no list in launchpad somewhere?
<Lure> when packaging new upstream, are you supposed to recompress the orig.tar.gz with --best or should we leave it as original?
<fdoving> don't touch it, if you don't need to.
<geser> Lutin: I've modified the pkgmaintainermangler to modify source packages: http://members.ping.de/~mb/srcmaintainermangler/
<Lutin> geser: what's the pkgmaintainermangler used for ?
<geser> that's the script the buildds are running to modify the maintainer in the binary debs
<Lutin> uh ok
<Lutin> geser: cool nice job
<Lutin> geser: so, the field will be XBS-Original-Maintainer, or you chose for lack of an actual name ?
<geser> Lutin: I chose it until a decision is made
<geser> this way O-M will end in the dsc and the debs
<Lutin> geser: cool
<Lutin> geser: just curious, why did rewrite a whole script ?
<geser> most parts where there already
<Lutin> ok
<geser> all I had to add was to modify the correct file (debian/control instead of DEBIAN/control) and termine the component
<geser> and also modify control.in if it exists
<Lutin> oh, ok :). I didn't even know pkgmangler existed until today :)
<geser> if I would check if the first changelog entry is already for ubuntu I could determine the correct distribution and lookup the correct component (it might have changed between edgy and feisty)
<Laser_away> geser: what is it creating? Original-Maintainer: ?
<Lutin> geser: quite easy to do :)
<geser> Laser_away: it writes XBS-Original-Maintainer into the control file which results in Original-Maintainer in the dsc and debs
<geser> Lutin: already working on it :)
<Laser_away> geser: where did you get the XBS part from?
<Lutin> hehe, kewl
<geser> Laser_away: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7
<Laser_away> geser: ah, awesome. I always wondered how they chose those
<geser> Laser_away: when you look at "apt-cache showsrc xdelta" you will see that O-M is missing
<geser> but is in the control file as O-M (without the XBS)
<geser> do you know if O-M should also appear in the dsc files?
<Laser_away> geser: xdelta has O-M in debian/control?
<geser> Laser_away: yes, see http://librarian.launchpad.net/5722532/M79021.patch or the complete diff.gz
<Laser_away> geser: bah, this is getting sort of messed up
<Laser_away> geser: they should have gotten that spec implementation down better before expecting us to do it
<Laser_away> on thousands of source packages
<geser> Laser_away: persia tried to ask mdz if O-M is correct or if it should be XBS-O-M, X-O-M or something else
<geser> but apparently he wont get an answer before monday
<ScottK> If there is a MOTU available and willing, I'd appreciate REVU on two packages, especially http://revu.tauware.de/details.py?upid=4070 and perhaps http://revu.tauware.de/details.py?upid=4071.
<vil> hi, i am experimenting with bzr maintained packaging and have question regarding it
<vil> i am trying to get rid of precompiled jars from the source so i replace the original file with a symlink
<vil> however then dpkg-source complains about unrepresentable change to the source.
<Lutin> ajmitch: ping -> could you have a lokk at bug 65894 ?
<Ubugtu> Malone bug 65894 in lablgtk "FTBFS in edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/65894
<vil> is there any chance to get pass this?
<mr_pouit> ScottK, I am not a MOTU, but it seems that libnet-dns-resolver-programmable-perl orig tarball ships a debian/ dir. You should ask upstream to remove it (diff.gz will be more clear and it is easier for you to maintain)
<ScottK> I've asked.  They said no.
<mr_pouit> oh :/
<ScottK> They are open to feedback, so I have hope...
<Laser_away> geser: I think we better not do any Original-Maintainer uploads until we get that resolved
<bddebian> Laser_away: I think felt is going to need to be dropped from the archive :(
<Laser_away> bddebian: how come?
<ScottK> bddebian: Did you ever get a chance to look at http://revu.tauware.de/details.py?upid=4070?
<bddebian> Laser_away: It's been dropped from Debian, hasn't been updated upstream since 2000 and doesn't build with libglu1-mesa-dev
<bddebian> ScottK: Not yet, sorry.  I started to look at it then I saw you and persia talking back and forth so I stopped
<Lutin> ScottK: maybe you should move the upstream/ debian to debian.upstream and put your packaging in debian/
<ScottK> No problem.  It's ready whenever you are.
<ScottK> Lutin: The upstream is working on getting the packages into Debian, so there is value, I think, in keeping his and pushing the changes back up to him.  Less suprise once Debian adopts it.
<Lutin> ScottK: oh, indeed
<neutrinomass> https://launchpad.net/ubuntu/feisty/+source/libzrtpcpp shows that libzrtpcpp has not been built on i386, which contradicts https://launchpad.net/+builds/+build/274428 . libzrtpcpp is needed as build-deps to twinkle and it doesn't seem to exist for i386
<crimsun> neutrinomass: there's no contradiction
<crimsun> the UI on the first link doesn't make it immediately obvious that it /has/ built, but there's no contradiction
<neutrinomass> crimsun: well, yes, it doesn't state that it has not built... any ideas as to why I can't see it in the repos then? 
<crimsun> hmm, possible soname issue?
<crimsun> please file a sync request for libzrtpcpp and let me know the bug #
<crimsun> you may need to walk the stack for http://packages.qa.debian.org/libz/libzrtpcpp/news/20070107T084703Z.html
<neutrinomass> Ok. Sync for 0.9.0-3 ... 
<crimsun> in any case, you'll need ubuntu-archive's involvement (whether it's to further debug why the i386 deb doesn't appear and/or the sync req)
<neutrinomass> crimsun: How does the sync make a difference? (besides being an attempt to rebuild)
<crimsun> there's no way to tell until you try it
<crimsun> if it sbuilds fine, then it's an archive problem
<ajmitch> morning
<Lutin> morning ajmitch
<crimsun> morning
<ScottK> Good morning.
<zul> hey ajmitch 
<bddebian> Heya ajmitch, crimsun
<crimsun> 'lo bddebian 
<ScottK> bddebian: Thanks for the REVU.  re your comment: http://revu.tauware.de/details.py?upid=4070 I don't think the package is contentious as much as I've made a number of small mistakes along the way (my inexperience is showing).  I think it's finally good and so now all I need is one more...
<bddebian> ScottK: Well you have been beaten up more than most I think for some reason
<ScottK> It's OK.  It's been a good learning experience.
<ScottK> I plan to do more of this, so it's all good.
<ScottK> Anyone availble to look to be a second advocate?
<lritter> hello there
<lritter> where do i request inclusion of llvm-1.9?
<ScottK> bddebian: If you are still up for more REVU, I believe that http://revu.tauware.de/details.py?upid=4071 is ready for a look.  Appreciate all the help so far.
<neutrinomass> crimsun: bug 79126
<Ubugtu> Malone bug 79126 in libzrtpcpp "Please sync libzrtpcpp 0.9.0-3 from Debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79126
<bddebian> ScottK: I'll probably be doing quite a bit tonight during the Eagles game
<Lutin> ajmitch: could you have a llok at bug 65894 ?
<Ubugtu> Malone bug 65894 in lablgtk "FTBFS in edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/65894
<crimsun> neutrinomass: please do not subscribe ubuntu-archive yourself
<ScottK> OK.  I'd appreciate it if you put that one on your list.  It's got a rebuilt orig.tar.gz in response to Tollef bouncing it from NEW because of no LICENSE file.  I think I did it right, but...
<neutrinomass> crimsun: sorry, I thought it was standard practice
<ScottK> bddebian: I did get feedback from Tollef saying I should rebuild orig.tar.gz.  My concern is did I do it right.
<Toadstool> heya everybody!
<bddebian> ScottK: NP
<bddebian> Heya Toadstool
<Toadstool> hey bddebian 
<crimsun> neutrinomass: no, a member of ubuntu-dev will ACK your sync request and then sub u-a
<crimsun> neutrinomass: for instances such as this one where the Debian component was missing, it helps prevent additional notifications from spamming the inboxes of u-a members
<crimsun> hmm, where is Stefan?
<neutrinomass> crimsun: Yes, sorry, I was blindly following https://wiki.ubuntu.com/DeveloperResources which doesn't really mention it. Thanks for catching it.
<Adri2000> sharms: can I merge lighttpd?
<Adri2000> erkkk
<Adri2000> shawarma: can I merge lighttpd?
<crimsun> hmm, n/m wrt Stefan; reading Debian 402715 clarified.
<Ubugtu> Debian bug 402715 in gnome-hearts "gnome-hearts crashes on startup" [Grave,Closed]  http://bugs.debian.org/402715
<somerville32> crimsun: Can you review http://revu.tauware.de/details.py?upid=4069 for me? :)
<crimsun> < crimsun> ok, I'll look when I finish my alsa triaging work.
<crimsun> < crimsun> ETA: a couple hours
<crimsun> nixternal: conexant patches merged into BenC's tree
<somerville32> Toadstool: Are you available? :)
<Toadstool> somerville32: yep
<somerville32> Toadstool, http://revu.tauware.de/details.py?upid=4069 :)
<Toadstool> ok
* somerville32 pokes Toadstool
<Lure> any motu around to check and upload new upstream version of soundkonverter: http://revu.tauware.de/details.py?upid=4072
<geser> Lure: I'm seeing it right that it doesn't need two advocates?
<bddebian> Not if it's already in the archive
<Lure> geser: it is in archive, just new upstream
<persia> good morning
<geser> hello persia 
<persia> Monday, eh?  Oh well.
<geser> just a guess
<geser> if you are interested: I've modified the pkgmaintainermangler script used by the buildds to work on source packages: http://members.ping.de/~mb/srcmaintainermangler/
<persia> geser: That looks more robust, but it's definitely a lot wordier and harder to grasp in a glance than Lutin's.
<persia> geser: Lutin: What about adding `dch Modified Maintainer values to match Debian-Maintainer-Field spec` to the script to save that step as well?
<Lutin> persia: the point is, the script assumes it was already dch'ed
<Lutin> because in case you're modifying a synced package, you need to dch before running the script so that the ubuntu field in changelog can be detected
<persia> Lutin: I'm just imagining the case where hundreds of -*ubuntu* packages need to be modified to suit in late April or early May, but I suppose it can be a two step process (like dh_iconcache was), which ensures the appropriate human oversight.
<Lutin> persia: yes, I think it'd be better to do it in two steps
<Lutin> persia: all the pkges will have to be changed for feisty +1 ?
<persia> Lutin: https://wiki.ubuntu.com/FeistyReleasePlan indicates that all the packages will have to be changed for feisty.
<persia> Lutin: That's modified packages only.  Sync packages stay the same.
<Lutin> persia:ok
<Lutin> persia: but if you fix a bug in a sync package, you'll also have to do it, right ?
<persia> Lutin: My understanding is that everything with an *ubuntu* version needs it.  Depends how the bug is fixed, but usually.
<Lutin> ok
<geser> Lure: uploaded soundkonverter
<Lutin> persia: what do you mean by 'robust' btw ?
<persia> Lutin: Less prone to failure due to user error.  The big difference is that srcmaintainermangler works whether you are in the package root or in the debian folder.
<geser> Lutin: have you checked what happens if someone has more Sources lines (e.g. edgy+feisty or feisty+sid)?
<Lure> geser: thanks
<Lutin> btw, geser; persia: new maintianer field is now in the wiki it seemd
<Lutin> -d +s
<Lutin> f the Maintainer field is modified, the old value will be saved in a field named X-Original-Maintainer
<Lutin> geser: yeah, checked, that works
<Lutin> geser: actually the script searches for the firsr distro-specific line
<persia> Lutin: That's from July.  It has all the negative effects of both O-M and XBS-O-M, and none of the benefits of either.
<Lutin> persia: ah, ok, sorry
<geser> some packages use control.in from which debian/rules builds the control file, so you want also modify that file
<geser> Lutin: looking how you determine the component it depends on the order in which apt-cache madison prints the Sources lines
<geser> so you may end using the edgy line (a package may moved in feisty) or the one from Debian
<Lutin> geser: how could that happen ?
<Lutin> basically, i take the distro from the changelog
<Lutin> and grep -m 1 $distro*sources the result of apt-cache madison
<Lutin> can't see how a debian line could be selected
<geser> than I have an outdated version of your script
<geser> sorry, I was looking at an outdated version
<Lutin> np :)
<Lutin> updated version is at the same place
<persia> Lutin: I realised why adding dch was useful: presumably the script is run after the changelog is updated, but the updater may not know if the maintainer needs to be mangled prior to running the script (due to exceptions, etc.), and may need to update the changelog again, depending on the script output.
<Lutin> persia: this way, that would cause the ubuntu revision tu be bumped twice
<Lutin> to*
<persia> Lutin: Not `dch -i`, just `dch Modified Maintainer values to match Debian-Maintainer-Field spec`, which should add a comment within the same revision.
<Lutin> ahhh ok
<Lutin> np then
<Lutin> adding it right now
<Lutin> persia: ok,added
<persia> Lutin: Why -m?
<Lutin> persia: preserve maintainer name
#ubuntu-motu 2007-01-14
<Lutin> persia: otherwise, dch will take your current username
<geser> Lutin: export DEBEMAIL DEBFULLNAME :)
* persia thought that was what .devscripts was for...
<Lutin> geser: you're right, I also forget those^^
<crimsun> I should start signing my uploads as "disgruntled peon"
<Lutin> persia: I meant, if the var geser tells about are not set, the new name and adress are yourlogin@yourmachine
<persia> persia: I understand.  I use .devscriots to set the variables, but either works.  I presume that regular updaters either set the variables or check the changelogs before updating.
<persia> Bleh s/persia/Lutin/
<Lutin> hehe
<Lutin> persia: is that ok ,
<Lutin> ?
<persia> Lutin: That should work, but man dch for more discussion related to $NAME and $EMAIL.
<Lutin> yep, was reading that :)
<Lutin> persia: maybe just assuming the vars are set should be enough
<crimsun> Laser_away: (answering scrollback) sure, let me know more details RE: motu school
<persia> Lutin: That seems easiest to me.  A case where an uploader would want to use -m for this type of update doesn't spring to mind.
<Lutin> yep
<Lutin> persia: done. now it has to run in the sourcefolder too
<ScottK> bddebian: Thanks for REVUing http://revu.tauware.de/details.py?upid=4071 - Now to find MOTU #2...
<persia> Lutin: I missed the reasoning behind adding the special $mail handlers.  Is there a reason these shouldn't be in IGNORE_MAINTAINER?  Also, what about the case where the user runs this in their home directory, which has a debian/ subdirectory containing their packages?  You might want to verify that the current directory name matches the package and version in the changelog.
<Lutin> persia: ignore_maintainer exit without doing anythin
<persia> Lutin: You're right: no need.
<Lutin> persia: the mail handler is to replace debian emails by their ubuntu ones for adconrad and mpitt
<Lutin> persia: thus have to be changed
<Lutin> if I understand correctly
<persia> Hobbsee: The sparc kdelibs issue was fixed by a give-back.  Thanks again.
<Hobbsee> persia: yay :)
<persia> Lutin: Ah.  I understand now.  Thanks for the explanation.
<Lutin> persia: at leat it's what I understood from the pkgmangler overrides files geser pointed me to
<Lutin> and the help of Adri2000 ;)
<Lutin> persia: you said
<Lutin> Also, what about the case where the user runs this in their home directory, which has a debian/ subdirectory containing their packages?  You might want to verify that the current directory name matches the package and version in the changelog
<Lutin> that assume you have actually a valid changelog, which is the thing you try to determinate
<Nafallo> !info sun-java5-bin
<ubotu> sun-java5-bin: Sun Java(TM) Runtime Environment (JRE) 5.0. In component multiverse, is optional. Version 1.5.0-08-0ubuntu1 (edgy), package size 21811 kB, installed size 65084 kB
<persia> Lutin: Right.  My mistake.  There's no need to check, as if both debian/changelog and debian/control exist, it's likely to be a package base directory.
<geser> Lutin: you don't need to escape the email addresses when you assign 'email'  as they are only used as a replacement and the echo looks better
<Lutin> geser: i'm a sed parano ^^. had so much problems with that that I always escape :)
<Lutin> thanks for that, I'll remember it =)
<Lutin> well, time to sleep
<Lutin> g'night guys, and thanks a lot persia & geser
<geser> night Lutin 
<persia> Good night Lutin
<_Enchained> bddebian: here ?
<bddebian> Maybe
<_Enchained> ^
<_Enchained> can I show you my manpage for dvd95 and see if ok ?
<bddebian> Sure
<shawarma> Adri2000: Re merging lighttpd: Sure, knock yourself out.
<_Enchained> http://paste.ubuntu-nl.org/1490/
<_Enchained> I'm not a crazy "manpager" yet ^^
<bddebian> Are there any command line switches, etc for it?
<_Enchained> no
<bddebian> Does it have a gnome help page?
<_Enchained> ?
<_Enchained> there is a special extension for that ?
<bddebian> No, just thinking you should mention it if it had one
<bddebian> It looks fine
<_Enchained> How can I know if there's one ?
<_Enchained> (sorry my english is a little bad :s)
<bddebian> _Enchained: Inside app, if it has like Help->Foo
<_Enchained> hm ok
<_Enchained> I'll look at
<somerville32> bddebian, Can you review me package?
<bddebian> somerville32: Which one?
<_Enchained> bddebian has the reiewing fever tonight :p
<somerville32> You already did it, lol
<bddebian> somerville32: I wondered, that's why I was asking :)
<somerville32> "Looks OK to me.." ... pfft! siretart said it was beautiful :P
<bddebian> Well I'm not as cool as siretart :)
<somerville32> crimsun: Can you review (and hopefully then upload) for me?
<_Enchained> in a file "README" there is only the text : "TODO ;-)" I can remove it from debian/docs ?...
<somerville32> Anyone want me to review their package? :)
<cypherbios> Hobbsee: around?
<Hobbsee> cypherbios: contentless ping
<somerville32> Grr... 
<Hobbsee> somerville32: hrm?
<somerville32> The whole contentless ping thing is annoying. If I have information I can just leave the info, I'll send them a pm
<somerville32> If I ping someone, it is because I want to know if they are there or when they'll get there
<somerville32> A lot of the time it isn't worth my effort to leave a message for them to get back to me because I can just ask/talk to someone else.
<Hobbsee> somerville32: heh, fair enough
<Hobbsee> cypherbios: what's up?
<cypherbios> hobbsee: can you advocate this upload, if +1 from you http://revu.tauware.de/details.py?upid=4015
<Hobbsee> somerville32: i'm contentless ping warning, because i'm here at the moment, and may not be for very long
<crimsun> somerville32: and that's precisely what's so damned annoying to those of us who HATE being pinged with NO CONTENT.
<crimsun> if you're going to ping me, give me details, don't ping with no comment, else you're wasting my time
<cypherbios> hobbsee if doesn't, please leave some comments there :)
* Hobbsee hates people who start querying her, just to pick her up!
<Hobbsee> gah!!!
<Toadstool> somerville32: catfish uploaded
<somerville32> Toadstool: thanks :)
* Hobbsee needs to konversation-ify the contentless ping script
<Hobbsee> ARGH!!!!!1
<Toadstool> this thing is script-able? :p
<Hobbsee> Toadstool: dunno, maybe :P
<Toadstool> heh
<somerville32> Ok
<somerville32> I'm going to do one merge then sleep :)
<somerville32> What do the different colours on MoM mean?
<bddebian> Just to confuse you :-)
<somerville32> Oh, ok
<bddebian> I've never figured it out either :-)
<somerville32> lol
<somerville32> Red looks dangerous
* somerville32 aboids.
<somerville32> :D
<somerville32> So there are only ~60 merges left for Universe?
<bddebian> Only?
<somerville32> Ubuntu Merge-o-Matic: universe
<somerville32> 51 outstanding merges
<somerville32> 71 updated merges
<somerville32> Does 71 mean done?
<somerville32> crimsun: Can I merge beep-media-player?
<Hobbsee> somerville32: i thinkj persia already has
<crimsun> I'll handle it.
<crimsun> people who haven't followed my previous merges probably aren't aware that the stock artwork for b-m-p is different for Ubuntu, which is why there are "unrepresentable changes"
<somerville32> hehe
<somerville32> Can I do blam?
<crimsun> ask him
<crimsun> (he'll probably allow it)
<Toadstool> somerville32: you can do initrd-tools :)
<crimsun> and grub2!
<somerville32> Lol
<somerville32> ok
* somerville32 is going to do initrd-tools.
<bluefoxicy> 00:0b.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
<bluefoxicy> bluefox@icebox:~$ sudo modprobe atheros
<bluefoxicy> FATAL: Module atheros not found.
<bluefoxicy> Linux icebox 2.6.20-4-lowlatency #2 SMP PREEMPT Fri Jan 5 04:34:15 UTC 2007 i686 GNU/Linux
<bluefoxicy> ^^^ This thing worked on umm... I think it was like... hoary...
<somerville32> How does grab-merge.sh work?
<Hobbsee> bluefoxicy: are you supposed to modprobe atheros or madwifi?
<Hobbsee> somerville32: in an empty dir, run grab-merge.sh <packagename>
<bddebian> pfft, grab-merge
<somerville32> grab-merge.sh initrd <-- does nothing
<somerville32> oh wait
<somerville32> haha
<somerville32> there we go
<crimsun> bddebian: yeah, deities do it by hand, eh?
<crimsun> once again proving I'm a peon :)
<bddebian> No, just people to stupid/lazy to use scripts
* somerville32 wonders if he is stupid or lazy.
* somerville32 figures he is both.
* bddebian wonders why crimsun always has to mock him :'-(
<crimsun> I ain't mockin nobody
<bluefoxicy> hobbsee:  Hmm, I don't know.  It's not auto-probing though.
<bluefoxicy> not madwifi..
<bluefoxicy> aha
<bluefoxicy> it's missing from -4 only (of generic AND lowlat)
<bluefoxicy> but -5 oopses/bugs/crashes
<bluefoxicy> in the Via DRI driver in the kernel or something, I guess.. I don't know, it causes X to die.
<bluefoxicy> so I am just going to wait for -6
<somerville32> So...
<somerville32> If I understand this correctly
<somerville32> I've used this script which has downloaded the packages
<somerville32> and merged them
<somerville32> and then I have to resolve any conflicts
<somerville32> and create a debdiff
<somerville32> and attach to my bug report
<crimsun> well, almost.
<crimsun> you've used a script that downloads the already-merged source package
<crimsun> the already-merged source package may contain conflicts; if there are, REPORT lists them (as does grab-merge)
<crimsun> but yes, you would edit debian/changelog regardless, generate a debdiff, attach said debdiff to a bug report, and subscribe u-u-s
<somerville32> and the working copy that is extracted is the ubuntu version?
<crimsun> more context?
<crimsun> and you may find http://people.ubuntu.com/~pitti/scripts/requestsponsor useful.
* somerville32 nods.
<somerville32> I have that installed
<somerville32> The script, it unpackaged it
<somerville32> I assume it is the ubuntu version unpackaged?
<somerville32> s/unpackaged/extracted
<crimsun> it's the merged one
<crimsun> so in a sense, yes, "the ubuntu version"
<somerville32> The debian version replaces a dependency in initrd-tools with another one
<somerville32> lsb-base (>= 1.3-9ubuntu3) for libdevmapper1.02 (>= 2:1.02.02-2)
<somerville32> (or they never had lsb-base and just added libdevmapper)
<somerville32> We don't seem to have a libdevmapper package
<somerville32> From the changelog:
<somerville32>   * Use libdevmapper1.02 and add versioned depend on it. closes: 395181
<somerville32>     initrd-tools is needed in etch for the upgrade path from sarge.
<somerville32> debian bug #395181
<Ubugtu> Debian bug 395181 in kernel-image-2.6.8-3-686 "missing dependency on libdevmapper1.01" [Serious,Closed]  http://bugs.debian.org/395181
<somerville32> !find libdevmapper
<ubotu> Found: libdevmapper-dev, libdevmapper1.02
<crimsun> then you need to merge in that change
<somerville32> So just add libdevmapper1.02 as a dependency, ok
<somerville32> Should I leave the changelog as by MoM?
<crimsun> no
<crimsun> you worked on it and thus to blame ;)
<somerville32> lol, k
<LaserJock> crimsun: what I think would be cool is just a general session where you go over requesting merges/syncs, how to be a good sponsor/sponsoree, etc.
<LaserJock> crimsun: if you have a particular day/time that is good for you let me know
<bddebian> LaserJock: He's a machine and thus needs no sleep :)
<LaserJock> I doubt that, even though it's very plausible
<bddebian> LaserJock: Should I ask for Felt to be removed or do you think someone will want to try to fix it?
<LaserJock> hmm, let me do a quick check
<crimsun> who needs sleep when there are BUG EMAILS
<somerville32> hehe
<LaserJock> crimsun: I'm sure at some point I would be totally useless for bug fixing
<LaserJock> I'm pretty useless as it is with full sleep
* bddebian is useless too :-(
<somerville32> So what should I change to the control file (besides merge stuff)?
<LaserJock> somerville32: make minimal changes
<somerville32> Sokk
<LaserJock> bddebian: please file a removal bug, thanks
<somerville32> Do I just ignore these since this is a merge?: 
<somerville32> <somerville32> tonyyarusso, hmm?
<somerville32> <tonyyarusso> somerville32: It's this "also" thing still
<somerville32> <tonyyarusso> See https://wiki.ubuntu.com/UbuntuBots and https://launchpad.net/ubuntu-bots/+bug/77045, and try to do it for something.
<somerville32> <somerville32> !somerville32 is <reply> somerville32 is the coolest kid on the block!
<somerville32> <ubotu> I'll remember that, somerville32
<somerville32> <somerville32> !somerville32 is also ...or not!
<somerville32> <ubotu> somerville32 is already known
<somerville32> <somerville32> !somerville32 is <also> ...or not!
<somerville32> <ubotu> somerville32 is already known
<somerville32> <tonyyarusso> See what I mean?
<somerville32> <somerville32> !somerville32 is also xubuntu
<somerville32> <ubotu> somerville32 is already known
<somerville32> <somerville32> !somerville32 is <also> xubuntu
<somerville32> <ubotu> somerville32 is already known
<somerville32> <somerville32> heh
<crimsun> um
<somerville32> * somerville32 nods.
<somerville32> <somerville32> !forget somerville32
<somerville32> <ubotu> I'll remember that, somerville32
<somerville32> <somerville32> !foo
<somerville32> <ubotu> foo is barr
<somerville32> <somerville32> !bar
<somerville32> gah
<somerville32> Sorry :(
<LaserJock> turn him off! ;-)
<somerville32> Do I just ignore these since this is a merge?: 
<somerville32> W: initrd-tools source: package-uses-deprecated-debhelper-compat-version 3
<somerville32> W: initrd-tools source: out-of-date-standards-version 3.6.1 (current is 3.7.2)
<somerville32> W: initrd-tools source: changelog-should-mention-nmu
<somerville32> W: initrd-tools source: source-nmu-has-incorrect-version-number 0.1.84.2ubuntu1
<crimsun> yes
<crimsun> you can safely ignore changelog-should-mention-nmu and source-nmu-has-incorrect-version-number fooubuntu anyhow
<bddebian> foobuntu? :-)
<LaserJock> that's crimsun's derivative
<crimsun> ok, barrybuntu
<crimsun> or jordanbuntu
<LaserJock> yucky
<LaserJock> laserbuntu
<crimsun> not my fault you're a deity
<LaserJock> yes it IS!
<LaserJock> I never claimed it :-)
* Hobbsee blames ajmitch 
<somerville32> :] 
<somerville32> Ok
<LaserJock> Hobbsee: could you check the u-u-s mailing list and see if I'm subscribed?
<somerville32> so I've rebuilt the source package
<Hobbsee> LaserJock: try commenting on a bug?
<LaserJock> Hobbsee: well, I don't remember getting a confirmation email
<Hobbsee> LaserJock: ahh
<Hobbsee> LaserJock: if you do, and it comes back that you're not on the list, then we'll get a message
<zul> Hobbsee: you took the easy way out of blaming
<Hobbsee> there's probably some way i cna manually check though
<Hobbsee> zul: hrm?
<zul> 22:07  * Hobbsee blames ajmitch
<somerville32> initrd-tools_0.1.84.1.dsc         initrd-tools_0.1.84.2.dsc
<somerville32> initrd-tools_0.1.84.1ubuntu1.dsc  initrd-tools_0.1.84.2ubuntu1.dsc
<somerville32> Which dsc's do I debdiff against?
<crimsun> current Debian to merged Ubuntu
<Hobbsee> zul: :)
<somerville32> Current debian being initrd-tools_0.1.84.2.dsc
<crimsun> yes
<zul> i wouldnt touch initrd-tools
<somerville32> debdiff initrd-tools_0.1.84.2.dsc initrd-tools_0.1.84.2ubuntu1.dsc ?
<somerville32> zul: Why?
<crimsun> cos zul's sane.
<LaserJock> :-)
<LaserJock> crimsun: I'm not sure we can say that
<crimsun> (or insane. It depends whether you snarf xen patches in your sleep like he does.)
<zul> somerville32: because there are alot of ubuntu specific changes that you might not be aware of
<zul> crimsun: you missed the "in" bit
<somerville32> zul: Is not aware of very many! :)
* somerville32 is not aware of very many.
* somerville32 deletes.
<somerville32> Hmm..
<somerville32> I already filed the bug though :P
<zul> somerville32: and if you mis a bit there would be alot of pissed off users
<somerville32> zul: I probably purged them all, lol
<somerville32> http://revu.tauware.de/details.py?upid=3618 <-- appears to be an upload of the debian package or something.
<somerville32> nvm
<somerville32> They modified the original source tarball
<somerville32> zul: Canadian?
<zul> yep
<somerville32> Moncton?
<zul> er...no ottawa
<somerville32> lol
* somerville32 tried to guess from your IP address.
<somerville32> or sorry, hostname
<LaserJock> bah, Hobbsee took off :/
<Simon80> http://revu.tauware.de/details.py?upid=4065 :D
<Simon80> once again
<LaserJock> sweet, marble made it in
<bddebian> LaserJock: Your science bugs list, is it static?
<LaserJock> bddebian: updated daily
<LaserJock> bddebian: you watch colts vs ravens?
<bddebian> No but my frickin' Eagles just lost :'-(
<LaserJock> no way!
<bddebian> 24 27 New Orleans
<LaserJock> bddebian: I just read about the colts winning without either team scoring a touchdown
<LaserJock> 5 field goals!
<bddebian> Yeah I saw the scores on NFL.com and was like WTF? :)
<LaserJock> well bummer, I kinda wanted the Eagles to win that one
<Toadstool> guys, forget about your teams, Chargers are going to win the Superbowl :)
<LaserJock> puke
<Toadstool> heh
<bddebian> Damn I'm getting my ass kicked :-(
<LaserJock> bddebian: in real life? or just by packages? ;-)
<bddebian> NeverWinterNights 2 :-)
<LaserJock> bddebian: how much did that cost?
<bddebian> Dunno got it for Christmas but I think like 39.99
<LaserJock> I played a little wesnoth on my mac the other day
<bddebian> Hah, no comparison ;-P
<jsgotangco> lol
<Toadstool> xmoto? :P
<bddebian> heh
<jsgotangco> i bought some old gamecube games for the wii
<jsgotangco> mostly the hits
<LaserJock> I guess I'm too cheap for gaming
<LaserJock> I've never owned a video game console
<LaserJock> and I don't by games over $20
<bddebian> I don't play a lot but I love RPG games
<LaserJock> *buy
<bddebian> consoles r t3h suXX0r ;-P
<LaserJock> every Christmas I do get a week of gaming at my parents house
<Burgundavia_> hey jsgotangco
<LaserJock> my brother introduced me to halo last christmas
<jsgotangco> Burgundavia_: hey dude
<jsgotangco> bddebian: :P
<jsgotangco> Halo was pretty good
<LaserJock> this christmas was a Star Wars game that was pretty cool
<jsgotangco> but I bought the back catalog for the scary resident evil games
<LaserJock> I just don't have patience for RPG
<LaserJock> or many games
<LaserJock> I just want to blow things up
<LaserJock> I was really addicted to UT2004 and America's Army for a while
<bddebian> LaserJock: Which one?  Jedi Knights: Jedi Academy is cool.  And the Knights of the Old Republic ones are awesome
<LaserJock> bddebian: hmm, I can't remember exactly, but it was number II of whatever it was
<bddebian> Gah, could have been KoToR or BattleFronts
<LaserJock> oh my goodness
<bddebian> Have you played Medal of Honor?
<LaserJock> bddebian: ah, BattleFronts shoulds familar
<LaserJock> bddebian: yeah, I have it
<LaserJock> don't really play it much
<bddebian> That's a cool one
<LaserJock> got stuck after a few months
<LaserJock> and haven't had any time (Ubuntu keeps me more than busy)
<bddebian> Sorry, not Medal of Honor, I mean Call of Duty
<LaserJock> I just got an email that I'm supposed to teach 2 labs of General Chemistry this semester :/
<jsgotangco> heh
<jsgotangco> show 'em tiger!
<bddebian> w00t
<LaserJock> I haven't taught that in like 4 years
<jsgotangco> chemisty doesn't change no?
<LaserJock> I haven't taught *anything* for at least 2 years
<LaserJock> well no, but I'm supposed to be doing research
<LaserJock> not grading
<jsgotangco> hehehe
<LaserJock> I'll have to talk to my boss Tuesday
<LaserJock> I think this must be a mistake
<LaserJock> oh well, I guess
<LaserJock> I don't mind teaching, I just find it odd
<LaserJock> hmm, maybe I'd get a raise too ;-)
<bddebian> heh
<tonyyarusso> Hey, I need bazaar help.  I'm trying to download the ubotu/Ubugtu code, and don't know how.  See https://code.launchpad.net/~dennis/+branch/ubuntu-bots/main.
<joejaxx> tonyyarusso: bzr co urlhere?
<lifeless> bzr branch https://code.launchpad.net/~dennis/+branch/ubuntu-bots/main
<joejaxx> tonyyarusso: try that
<tonyyarusso> k
<joejaxx> tonyyarusso: bzr co urlhere
* tonyyarusso looks up co vs branch
<tonyyarusso> Thanks joejaxx, lifeless :)
<joejaxx> tonyyarusso: you are most welcome :)
<bddebian> Gnight gang
<Jerub> okay! I've made progress with ipsets, which I discussed here briefly the other day
<Jerub> I have a kernel that supports iptables.
<Jerub> er ipsets.
<Jerub> but iptables in ubuntu does not support ipset rules.
<ScottK> If there is a MOTU in the house who is available and willing, I'd appreciate a look at http://revu.tauware.de/details.py?upid=4070.  It's looking for a second sponsor.  
<imbrandon> 
<manchicken> Anybody here done any work on adept before?
<manchicken> persia: I figured out what the build issue was.
<persia> manchicken: congratulations.  What was it?
<manchicken> I had unsermake installed.  Riddell took a look at my build logs and was like "yeah, uninstall unsermake."
<persia> manchicken: Ah.  Autotools is one of those mysteries best left unreplaced, in my opinion :)
<manchicken> heh
<manchicken> I don't know why/how it got installed.
<manchicken> Either way, it builds.
<manchicken> Now I'm just trying to follow this code.
<manchicken> It's not working well.
<manchicken> I'm probably going to have to step through it to figure it out.
<Jerub> okay, this is giving me the shits :/
<Jerub> basically the 'ipset' module is in universe, but is completely useless
<Jerub> because neither the kernel or the iptables packages support ipsets
<Simon80> is it valid to request syncing a package from debian unstable?
<Simon80> (openarena)
<Simon80> anybody?
<persia> Simon80: Feisty has passed the DebianImportFreeze at this point, so new packages are not imported lightly.  If you want this, I would recommend checking with MOTU-Games first.
<Simon80> is that a channel? and when was this deadline?
<Simon80> thanks for a response, btw
<ScottK> Dec 21 was the deadline: https://wiki.ubuntu.com/FeistyReleaseSchedule
<persia> Simon80: The deadline was 21st December (openarena missed it by a week).  Motu-Games is a team.
<Simon80> err... I phrased that badly, I should have said, do they have a channel, cause now I look stupid
<Simon80> so when you say check with motu-games first, what do you mean, send a message to their leader?
<persia> Simon80: The team is small.  I don't think they have a channel.  It's a weekend, but you might email them (email is available from LP profiles for registered users).
<Simon80> and ask if it's possible to sync it?
<Simon80> yay for these deadlines
<Simon80> I mean, I'm extra cynical around now, cause edgy is bug-ridden
<persia> Simon80: The deadlines are intended to help reduce that.  Edgy was done very quickly, and there was not as much time to fix bugs.
<Simon80> yeah, I know
<Simon80> what I don't get is why they don't get fixed post-release
<ScottK> Good night all.
<Simon80> it makes me want to vent
<slytherin> I have a question. If I am using automake1.9 while maintaining my program, is it advised to include it as build-dependency in control file?
<persia> slytherin: Does your package fail to build with automake1.7?  If you're version-agnostic, it is safe to omit.  If you need a specific version, it is better to include.
<slytherin> persia: We developers were having problem since we were using different versions of automake. So one of the developer final change Makefile* and configure* using automake1.9. And probably it will fail to build with 1.7
<persia> slytherin: If you need a specific version, it's good to add to build-depends.  Ubuntu defaults to 1.10 today, and is expected to advance the default as new versions are introduced.
<slytherin> persia: Ok. I will do so. Thanks.
<slytherin> persia: One more question. How much time does it generally takes to get a package accepted as non maintainer upload when added to REVU?
<persia> slytherin: It depends on the quality of the packaging, the availability of MOTU reviewers, and the responsiveness of the packager.  Some packages are approved in a few days, and some take weeks.
<slytherin> persia: If I am a developer who is working on debian packaging for my own app which is supposed to have a new version 1 week before UVF, What do you suggest? Upload to REVU or file a bug for new version?
<Lutin> hay there
<persia> slytherin: There are too many variables for an easy answer to that question.  If you are available to support comments/suggestions, an upload to REVU may take less MOTU time.
<slytherin> persia: Ok. I will upload to REVU, One last question. Can you please tell me what is cause of this, http://paste.ubuntu-nl.org/1533/
<persia> slytherin: Do you use seahorse-agent?  If so, you need to call debuild with --preserve-envvar DISPLAY.  If not, I don't know.
<Lutin> slytherin: this might happen because debuild is unable to run the agent. You try to prevent this (if your agent is configured to remember password) by running echo | gpg --sign first
<slytherin> Lutin: persia: Let me try both things one by one.
<zakame> persia: thanks, please go ahead merging :-)
<persia> zakame: Thanks.  It's become more interesting with the python2.5 transition :)
<zakame> persia: no prob.  I'm still restricted to help out for the moment due to my location's limited bandwidth :/
<persia> zakame: Perfectly understood.  May it improve soon.
<zakame> thanks
<persia> I've uploaded patches as bugs 79212 and 79214 so that telepathy-gnome can be installed again, if anyone is interested.
<Ubugtu> Malone bug 79212 in pymsn "Unsatisfiable depends on python-ctypes" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79212
<Ubugtu> Malone bug 79214 in telepathy-butterfly "Unsatisfiable depends on python-ctypes" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79214
<crimsun> this sleep is way overrated
<geser> crimsun: are you going to upload the last two debdiffs or should I?
<crimsun> I'm working on them
<crimsun> (pymsn already uploaded)
<imbrandon> sudo nano /etc/crontab
<imbrandon> err
<persia> crimsun: Thanks.  I'm close to not having any notes on the transition :)
<crimsun> imbrandon: I'm wondering if a simple no-change rebuild of your beryl 0.1.2 sources will resolve the "white screen o' death" issue that has appeared post-Herd-2
<persia> crimsun: How should the versioned dependency on python-central read?  I've a third (quodlibet), and I'd like to not cause you the extra work yet again.
<crimsun> (>= 0.5.6)
<persia> crimsun: Thanks.
<crimsun> I actually had quodlibet done, but go ahead and do it
<persia> crimsun: If you've done it, I should again?
<crimsun> persia: I haven't uploaded
<crimsun> so, go ahead, and I'll sponsor :)
<imbrandon> crimsun, pissibly
<persia> crimsun: I can't upload, but generating a bug.  Thanks.
<imbrandon> err
<crimsun> persia: (wrt to tightening, I'm following http://wiki.debian.org/DebianPython/NewPolicy )
* persia should keep that open: it keeps getting referenced.
<imbrandon> crimsun, i'd actualy like to update it to 0.1.4 but i've been on my 4 day strech ( i'm off for 3 days after 12pm )
<imbrandon> heh
<geser> imbrandon: how should beryl bugs be answered for packages from beryl-project? e.g. bug #79216
<Ubugtu> Malone bug 79216 in beryl-manager "beryl manager's crash" [Low,Needs info]  https://launchpad.net/bugs/79216
<imbrandon> geser, politely tell them to use the upsteam bug tracker ( or if you are feeling nice you  can report it upstream and link the bugs )
<geser> and reject it?
<imbrandon> depends on the action you take, the former yes, the later no
<crimsun> imbrandon: np
<imbrandon> hrm 
<persia> How important is matching the New Python Policy?  Is it worth causing errors on install?  Alternately, is it worth switching from python-support (used by Debian) to python-central?
<crimsun> persia: the policy doesn't mandate the use of one over the other
<crimsun> that said, one should be used
<persia> crimsun: I've been playing with boa-constructor.  The Debian maintainer chose python-support, and deleted the postinst and prerm scripts, causing #399276.  python-central supports excluding directories with -x, and would allow the restoration of the postinst and prerm.  This wouldn't quite be a merge, and I'm not sure about making the alternate choice from the Debian maintainer, given the interest in absorbing Debian improveme
<crimsun> bug 399276
<crimsun> debian 399276
<Ubugtu> Debian bug 399276 in boa-constructor "SyntaxError installing after python transition" [Important,Open]  http://bugs.debian.org/399276
<luks> hi, can somebody please take a look at https://launchpad.net/ubuntu/+bug/78549
<Ubugtu> Malone bug 78549 in Ubuntu "Please sync libdiscid (0.1.0-1) from Debian unstable main" [Undecided,Unconfirmed]  
<luks> auto-syncing from debian managed to break a package, and it seems I need a motu to review the new debian package
<luks> the package actually was made on feisty, so it works just fine
<_Enchained> Hi
<persia> luks: Subscribe ubuntu-universe-sponsors@tauware.de to automatically email those MOTUs that have volunteered to review non-MOTU assistance about the SYNC request.  One of them will likely ACK it when they have time.
<crimsun> persia: sorry about quodlibet; tollef already did that one
<persia> crimsun: No worries.  It was his comments on -devel that led to my understanding of how to restore the installation of the packages removed by the transition.  I'm not worried about karma (I think I have enough), just trying to help.
<crimsun> off to work
<Adri2000> !seen neutrinomass
<ubotu> neutrinomass is on IRC right now!
<_Enchained> anyone to a little review ?...
<_Enchained> s/to/for
<imbrandon> dont work too hard crimsun , l8tr
<nixternal> crimsun: woohoo! so I shall have "better" sound soon then :)
<nixternal> heya imbrandon 
<imbrandon> heya nixternal 
<zakame> hi all
<nixternal> hiya zakame 
<nixternal> imbrandon: how's the job going?
<_Enchained> I have a lintian error how can I fix it : W: alltray: non-dev-pkg-with-shlib-symlink usr/lib/liballtray.so.0.0.0 usr/lib/liballtray.so W: alltray: package-name-doesnt-match-sonames liballtray0
<imbrandon> nixternal, good good
<imbrandon> ;)
<nixternal> good to hear, my job ended and it is back to school for me this week...yay! 
<imbrandon> ahh
<nixternal> bah is more like it :)
<imbrandon> heh
<white> hmm is there a way to get subscribed to new packages which are added to universe (or even better new packages for universe which are not in debian)
<stgraber> white: there is the feisty-changes mailinglist, but you'll receive a message every update of a package in feisty, not only universe ones and not only new ones
<white> bah, that means tons of mails :(
<stgraber> depends of the day, but for your case it means 90% of useless mails yes
<white> hmm i thought there might be a special way as the information are parsed somehow to the packages.ubuntu.com side
<imbrandon> p.u.c is outdated alot, you could probably do a custom search on LP or use mdt to make a script for you
<lakin> Where can I find changelogs for certain packages?
<imbrandon> changelogs.ubuntu.com
<lakin> thx
<white> imbrandon: hmm yeah, i will try to nudge frank as he should have such a script for p.u.c, thanks :)
<imbrandon> white, actualy like i said you would be better using mdt , not the scripts from p.u.c
<imbrandon> as thats what it was designed for
<white> mdt?
<imbrandon> multi distro tool
<imbrandon> check revu for the source/package 
<imbrandon> ;)
<white> right, i'll look into it
<white> ta
<imbrandon> http://voyager.imbrandon.com/mdt/feisty/all.html
<imbrandon> output like this ^^
<imbrandon> although you probably only want the output from http://voyager.imbrandon.com/mdt/feisty/all.html#notinA or http://voyager.imbrandon.com/mdt/feisty/all.html#notinB
<white> ah yeah that is the stuff i looked into (on the utnubu page) and wrote some mails
<imbrandon> https://wiki.ubuntu.com/MultiDistroTools
<imbrandon> there ya go
<white> ta
<ScottK> If there is a MOTU here that is available and willing, I'd appreciate a look at http://revu.tauware.de/details.py?upid=4070.  It's looking for a second sponsor.  
<palski> why carpatunnel is in merges list? Only difference between debian and ubuntu packages in changelog 
<palski> patches.ubuntu.com diffs ubuntu version against debian stable version?
<imbrandon> patches isnt a diff from anywhere, its the patches that are included in the /debian folder of uploads
<palski> "These patches are generated daily and contain the differences between an Ubuntu source package and the equivalent version of the same source in Debian."?
<palski> it seems that carpaltunnel version number is 0.0.9ubuntu2 and it is synced from debian unstable 0.0.9-0.1 so patches.ubuntu.com still contains differences against debian 0.0.9 because of versio number weirdned
<tsmithe> if i'm the author of a package, why is it unwise to include the debian/ dir in the .orig?
<jonake112> hoi mense
<jonake112> kan iemand mij misschien helpe 
<bddebian> Heya gang
<Lutin> heya bddebian
<ScottK> Heay
<ScottK> heya
<bddebian> Hi Lutin, ScottK
* ScottK would like to harass bddebian to advocate his packages, but unfortunately one person advocating twice doesn't count.
<bddebian> heh
<ScottK> Thanks again.
<bddebian> Actually and my reviews are probably only worth about 1/4 of an MOTU so.. ;-P
<tsmithe> if i'm the author of a package, why is it unwise to include the debian/ dir in the .orig?
<siretart> tsmithe: why should you do that? keep the packaging in the .diff.gz and upstream work in the orig.tar.gz. that makes reviewing easier
<bddebian> tsmithe: Debian thinks it's bad form :)
<tsmithe> ah ok
<tsmithe> i was just being lazy
<siretart> it makes a package headaches when he tries to review the .diff.gz
<tsmithe> ah ok
<siretart> a packager
<tsmithe> :)
<tsmithe> siretart, bddebian; either of you free for revuage?
<ajmitch> morning
<siretart> later
* ajmitch is at work, monday morning here
<bddebian> Heya ajmitch
<ScottK> Where is here?
<ajmitch> where in the world would it be monday morning? :)
<bddebian> tsmithe: Possibly in a bit
<tsmithe> bddebian, thanks
<ScottK> siretart: If you would add these to your list for later, I'd appreciate a look when you have the time - http://revu.tauware.de/details.py?upid=4070 and http://revu.tauware.de/details.py?upid=4071
<ScottK> ajmitch: Australia or NZ, I would guess, but there are other possibitlies too.
* ScottK goes off to investigate timezones...
<ajmitch> new zealand
<tsmithe> bddebian, oh yeah - guess you want upids, 4067 and 3892 please
<ScottK> It could have been Fiji - http://www.worldtimezone.com/time/wtzresult.php?CiID=12953&forma=24h
* ScottK resumes working on another new package...
<bddebian> Yes, because God knows we don't have enough broken shit in the archive yet :)
<ScottK> bddebian: I think this is the last new one for a while and it won't be broken.  Promise.
<AstralJava> bddebian: It
<AstralJava> sorry
<AstralJava> It's gonna get some more soon. :)
<bddebian> tsmithe: Give me package names please
<tsmithe> alsa-tools
<tsmithe> alsa-firmware
<tsmithe> thanks
<bddebian> tsmithe: No way man, if it says "alsa", I ph3ar crimsun :)
<tsmithe> meh
<tsmithe> crimsun, ?
<tsmithe> bddebian, you could give it a go anyway?
<ScottK> tsmithe: Take it easy on bddebian, he's probably exhausted from all the old package archiving he's been doing (It was a lot).
<bddebian> tsmithe: I'll take a look, I'm just messing with ya
* tsmithe hugs bddebian
<tsmithe> ScottK, ;)
<Lutin> bddebian: I uploaded a new version of kayali. could you have a look  at it when you'll have some time ?
<Adri2000> persia: here?
<Adri2000> persia: file a bug report in Debian for flpsed's .desktop file please
<Lutin> ajmitch: are you there ?
<ajmitch> nope
<ajmitch> if you have a question, ask it
<Adri2000> Keybuk is the author of MoM, right?
<Nafallo> yes
<Nafallo> he made his mom
* ajmitch gives up & goes back to ignoring irc :)
<Adri2000> :D
<Lutin> thanks bddebian :)
<bddebian> np
#ubuntu-motu 2008-01-07
<cyberix> dget -x http://com/file.dsc
<Kmos> crimsun: i'll try it =) thanks for the tip
<crimsun> cyberix: you could just backport devscripts from edgy.
<cyberix> Already got it done by looking at the script
<cyberix> Thanks anyway
<StevenK> crimsun: Did you see my upload of libsdl?
<crimsun> StevenK: noted, yes.
<crimsun> I closed the associated bug yesterday.
<StevenK> Great.
<crimsun> thanks, BTW!
<StevenK> No problem, any time. :-)
<imbrandon> ScottK: not sure if the key still needed syncing or not , so i'm running it now to be sure
<imbrandon> ( just fyi )
<imbrandon> moins crimsun StevenK and all
<crimsun> 'lo imbrandon
<imbrandon> TheMuso: i got an "broken" xbox -given- to me today , that i fixed by sodering the points and reflashing the TSOP , so soonish ( when i get time after work durring the week ) we'll have a "dev" xbox
<imbrandon> :)
<bddebian> And for what? :-)
<imbrandon> bddebian: the port of ubuntu to the xbox we;re working on :)
<StevenK> Hey imbrandon
<imbrandon> port , not deriv
<imbrandon> :)
<bddebian> imbrandon: Again, for what? :-)
<imbrandon> bddebian: a $69 USD 733mhx workstation :)
<imbrandon> or similar
<crimsun> oh, only to take over bddebian's house.  Nothing more.
<imbrandon> bddebian: we figured if the ps3 can get a cd rolled ( unsupported of course ) we can roll one for the xbox with only a few ( about 15 ) patches to the kernel and X ( both of witch will eventualy be upstream upstream )
<imbrandon> which*
<bddebian> :-)
<bddebian> crimsun: No xboxen in this house :-)
<imbrandon> so really for minial work we can support the xbox, and the only other distro that does this is xebian ( debian deriv ) and its 2.4 kernel based
<crimsun> bddebian: no no, it's like X10, but you won't even see/hear it coming
<bddebian> crimsun: Ah :)
<imbrandon> support == installing and questions awnserd on the forums etc etc etc when possible, you know, not canonical ( other than possible hosting the cd's on cdimage.u.c )
<psicus78> hi!
<martoss> have fun guys... cu
<imbrandon> sides , theres something satisfying about installing linux/ubuntu on a MS product :)
<psicus78> Is this the place where to ask to re-sync the REVU uploaders keyring? :)
<imbrandon> psicus78: i have one in progress, one moment
<imbrandon> ahh infact it JUST finished
<psicus78> it's ok
<psicus78> .
<crimsun> (yes?)
<TheMuso> imbrandon: Cool. Did you by chance see my message about apt-mirror?
<LaserJock> anybody around who is familiar with SbuildLVMHowto?
<soren> Sort of.
<soren> As in: I'm sort of around, and I'm sort of familiar with that howto :)
<soren> LaserJock: ^^
<LaserJock> do you need to have already set up LVM before running the script?
<Fujitsu> LaserJock: It's not going to create the LVM partitions for you.
<Fujitsu> That would be more than mildly dangerous.
<LaserJock> that's what I was thinking
<LaserJock> but there wasn't any instructions or links
<Fujitsu> So yes, you need to have a VG set up.
<LaserJock> but down on the bottom under "Previous Instructions" there was some
<Fujitsu> 'It assumes a passing understanding of LVM, and having an available VG to work with.'
<LaserJock> oh ...
<LaserJock> darn ;-)
<imbrandon> TheMuso: nope , i dont think so
<imbrandon> was it on irc ?
<LaserJock> and do you really need 5GB per chroot?!
<Fujitsu> LaserJock: Not really.
<Fujitsu> I use 3 normally.
<Fujitsu> OOo will want more, but you'd be silly to try to touch OOo.
<LaserJock> # Allocate the "golden" chroot LV
<LaserJock> sudo lvcreate -n "$CHROOT_LV" -L 5G "$VG"
<LaserJock> I think if I run the script it's gonna give me 5GB
<Fujitsu> Modify the script, then :)
<Fujitsu> Note that there's no point having an initial chroot that's smaller than the snapshots.
<TheMuso> imbrandon: Yes.
<TheMuso> imbrandon: One sec, I'll see if I can dig it up.
<imbrandon> TheMuso: then no , sorry i dident get it
<imbrandon> ok
<LaserJock> hmm, I just don't know how much space this is all gonna take
<LaserJock> I have a 12GB partition
<LaserJock> how much do I have to account for?
<Fujitsu> Oh dear.
<TheMuso> imbrandon: I seem to be having a problem with apt-mirror. The error I get is: http://www.pastebin.ca/841988  My mirror.list file is: http://www.pastebin.ca/841990
<Fujitsu> Where did you get a 12GB disk?
 * imbrandon looks
<LaserJock> Fujitsu: no, 12GB partition for sbuild/LVM
<Fujitsu> Ah, so your system isn't on LVM?
<LaserJock> heck no
<LaserJock> I dislike LVM
<Fujitsu> Why not?
<Fujitsu> Why?
<LaserJock> it eats things
<Fujitsu> Never done so for me.
<LaserJock> or rather my ability to control it causes me great pain ;-)
<LaserJock> *inability
<LaserJock> I just kept losing partitions and things
<Fujitsu> Heh.
<LaserJock> I fell much better in general with have a nice big ext3 /
 * TheMuso doesn't think he'll touch luks encryption for a while at least, after having his laptop battery die, and the whole root filesystem going caboom.
<imbrandon> TheMuso: it seems to ( rightfully , i cant seem to get it manualy either )  getting a 404 on http://mirror.internode.on.net/pub2/ubuntu/ubuntu//dists/gutsy/multiverse/source/Sources.gz
<Vorian> i am getting a 404 error too
<Fujitsu> TheMuso: I have been running LVM on LUKS on my laptop for several months now.
<TheMuso> imbrandon: change pub2 to pub
<Fujitsu> (and yes, the battery has died a couple of times, without ill effect)
<TheMuso> pub2 is for internode customers only
<TheMuso> so /pub/ubuntu/ubuntu works
<TheMuso> s/works/should work/
<imbrandon> right that works
<TheMuso> imbrandon: Note that this is apt-mirror from svn
<TheMuso> Well I tried my config file with s/pub2/pub/ and got the same result.
<LaserJock> Fujitsu: my pbuilders (5 different ones) only take up 400MB, are you telling me that'd take up 25GB with sbuild/LVM?
<TheMuso> Fujitsu: Hrm interesting.
<Fujitsu> I'm sure there must be a way to avoid that, but I haven't found it yet.
<TheMuso> Funny how one experience like mine burns you.
<Fujitsu> TheMuso: I had to hard-reset it a couple of times a day for weeks too, while X was being dodgy in early Hardy.
<TheMuso> Fujitsu: Right.
<TheMuso> Good afternoon Hobbsee.
<imbrandon> right, svn should be stableized ( just not tarred, 1.4.6 is whats current svn )
<imbrandon> hum, try to change your mirror.list to s/pub2/pub/ and see if it works
<imbrandon> ( not a full run, once it gets past the preceed indexes is fine to tell if its gonna work )
<imbrandon> something strange might be going on with http headers or something, but it just uses normal wget
<imbrandon> do you use a http proxy or anything ?
<Fujitsu> O_o
<Fujitsu> imbrandon can type quickly.
<imbrandon> also it would be nice for internode to redirect non internode customers to pub/ :)
 * Hobbsee waves
<TheMuso> imbrandon: not afaik. If so, its transparent, but I doubt it since I'm within internode's network.
<imbrandon> heya Hobbsee
<imbrandon> hrm
<Fujitsu> LaserJock: Ideally, one should be able to create a snapshot of an LVM volume, and grow the snapshot of the volume. But I don't think LVM can do that at the moment.
<imbrandon> Fujitsu: ??
<imbrandon> heh
<TheMuso> imbrandon: I'm running it again now.
<imbrandon> TheMuso: ok
<Fujitsu> imbrandon: 5 of your messages appeared at the same time.
<imbrandon> if it fails again, try to just normaly run wget
 * Fujitsu heads to lunch.
<imbrandon> Fujitsu: ahh , i must have lagged
<LaserJock> Fujitsu: so what's the advantage of sbuild/lvm again .... :-)
<imbrandon> TheMuso: if it fails again , try to just run wget on the file it fails on , to soo if its a possible problem with wget and that mirror
<imbrandon> s/soo/see
<TheMuso> imbrandon: Yeah will do.
<Vorian> i am getting this error http://paste.ubuntu-nl.org/51031/
<imbrandon> on your box, or a chroot, or pbuilder
<Vorian> pbuilder
<Vorian> sorry
<imbrandon> run "sudo pbuilder update" ( where pbuilder == how you normaly call pbuilder , e.g. pbuilder-dist hardy or pbuilder-hardy or pbuilder
<imbrandon> )
<Vorian> alrighty
<Vorian> :)
<imbrandon> :)
<Vorian> imbrandon: that did the trick :)
<Vorian> how often should pbuilder be updated?
<LaserJock> I do it once a day that I'm working
<TheMuso> Yeah once a day is good. I update my sbuild chroots once a day.
<imbrandon> Vorian: i do it once a day or so, but it really depends on how new the packages in the archive you need are, its the equiv of running "apt-get update" localy
<Vorian> that makes sense
<TheMuso> c
<TheMuso> ugh
 * TheMuso thinsk this keyboard needs replacing
<LaserJock> well, I guess since I wiped out my 12GB partition I should at least give this sbuild thing a go
<cyberix> What does "Depends: ${shlibs:Depends}" actually do?
<nenolod> cyberix, replaces Depends: with all of the depends it detects during dh_makeshlibs
<LaserJock> replaces ${shlibs:Depends} specifically
<nenolod> there's also ${misc:Depends} which you should add, but it's not yet used
<TheMuso> imbrandon: One problem with apt-mirror is that it fails if a file can't be retrieved, however the way my mirror.list file is set up, its asking apt-mirror to check for paths that may not be there now, but could be there when packages get updated in the future. Any ideas?
<TheMuso> SO for example, gutsy-updates/multiverse/debian-installer may not exist now, but if a package that places content in that dir gets updated in gutsy-updates, that path will exist.
<LaserJock> nenolod: it is used
<LaserJock> nenolod: misc:Depends is used by debhelper to insert and additional dependencies that come from the dh_*
<TheMuso> So far, I'm thinking of going back to debmirror.
<cyberix> LaserJock: So which one should I prefer?
<LaserJock> cyberix: prefer?
<cyberix> ${misc:Depends} is ok for dh_makeshlibs too as it falls into dh_*
<cyberix> So should I always use ${misc:Depends} then?
<LaserJock> no, no
<cyberix> instead of ${shlibs:Depends}.
<LaserJock> they are different things
<cyberix> ok
<LaserJock> let me try to find an example
<nenolod> LaserJock, it is now? well, that's good.
<LaserJock> nenolod: has been as long as I've been around I think
<nenolod> LaserJock, dpkg-buildpackage was warning about it being an unrecognised subst a few months ago
<LaserJock> yes, that is correct
<nenolod> which lead me to believe it wasn't used yet ;)
<LaserJock> it's used for debhelper, not dpkg
<LaserJock> I think dh_gconf may be an example for misc:Depends
<cyberix> Oh. It is used only by some dh_*
<LaserJock> basically, some dh_* scripts need additional dependencies
<LaserJock> I think there are some more
<StevenK> ${shlibs:Depends} is for shared library dependancies, ${misc:Depends} is used for example, by debconf
<StevenK> dh_installdebconf will put debconf into ${misc:Depends}
<StevenK> dh_installdefoma same sort of thing
<imbrandon> is there an easy way in bash to make all files in a dir have a lowercase ext
<imbrandon> like mass rename .TXT to .txt
<imbrandon> s/rename/mv
<StevenK> imbrandon: Install renameutils
<imbrandon> k
<StevenK> imbrandon: Run 'qmv -f do' which drops you into vi with a filename on each line
<StevenK> Other than that:
<imbrandon> killer, thanks
<StevenK> for i in * ; do j=$(echo $i | tr 'A-Z' 'a-z') ; mv "$i" "$j" ; done
<Fujitsu>  /win 48
<Fujitsu> Bah.
<imbrandon> cool, thanks StevenK
<imbrandon> btw it must use the default editor , because it was s/vi{,m}/nano
<imbrandon> :)
<StevenK> It probably calls sensible-editor
<StevenK> Actually, nano shouldn't be in that list. :-P
 * Fujitsu agrees with StevenK
<imbrandon> hahah
 * StevenK high fives Fujitsu
<imbrandon> that for loop will do the whole filename wont it ?
<StevenK> It ought to
<minghua> How is nano not sensible?
<StevenK> If it doesn't, use qmv
<StevenK> minghua: In many ways
<Hobbsee> no delete line
<imbrandon> ^K
<minghua> StevenK: Okay, I'm not arguing.  But the best hacker I know in real life uses nano.
<cyberix> I'm looking after first advocate for my package malbolge. I've fixed all problems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
<Chipzz> minghua: it's just seriously underpowered/underfeatured
<justin_> is this the development team channel?
<pwnguin> for Universe
<LaserJock> hmm, sbuild wants to install exim4 :/
<RAOF> LaserJock: You don't already have a mta?
<LaserJock> RAOF: no
<LaserJock> I don't like having mta's if I don't need them
<RAOF> Well, sbuild will want to email you the buildlogs.
<LaserJock> but I don't want it to :-)
<lifeless> you don't need an mta
<lifeless> you can just have local delivery
<LaserJock> seems odd that it'd be a dep and not a Recommends
<LaserJock> hmm, is there an easy way to see what provides m-t-a?
<blueyed> LaserJock: aptitude search "~Pm-t-a"
<LaserJock> I just found synaptic has it :-)
 * RAOF wanders through the monodevelop 0.18 dependency stack
<jdong> hola everyone
<jdong> I'm alive... I think :)
<jdong> upgrading my macbook to Hardy at the moment for kicks
<TheMuso> jdong: Heh have fun watching everything break.
<LaserJock> oh my ;-)
<TheMuso> :)
<jdong> TheMuso: ooh what's scheduled to break?
<jdong> other than the stuff I have scheduled ready to break :D
<TheMuso> jdong: I don't know.
 * jdong tries to play a quicktime mp4
<jdong> look at that, it still works
<jdong> well... can't have that happening!
<RAOF> jdong: Thanks for reminding me.  Wavpack playback has broken; I need to file that bug :)
<jdong> lol
<jdong> are we under any freezes yet or soon?
<RAOF> Alpha 3 freeze is either now or soon.
 * jdong takes a look at that libmp4v2 stuff that he left off on...
<jdong> grumble I hate circular dependencies
<bddebian> aye...
<bddebian> fuuuuuuuuuuck
<jdong> would anyone cry if at this point I upload a new faac that may break AAC encoding in mencoder, avidemux, and/or gst-plugins-bad-multiverse till I upload rebuilds of those? :)
 * bddebian wouldn't
<jdong> nobody likes aac anyway right ;-)
<bddebian> I have been working on building newpki-client with wx2.6 for over a week now and there's all kinds of shit in my diff... :'-(
<RAOF> If you can get that all done by the alpha 3 freeze tomorrow... :)
<jdong> lol well I'll wait for alpha3 to finish then, meanwhile I'll just re-test this build order locally... again.
<jdong> I'm not sure I trust these tomboy notes dated on the 17th of december
<minghua> I though universe/multiverse wouldn't be affected by alpha freezes?
<minghua> thought*
<RAOF> Oh, yeah.  We had this discussion before, didn't we.
 * TheMuso won't be using hardy full-time till around the last alpha/beta.
<TheMuso> Universe/multiverse will be free rain as usual.
<somerville32> Does anybody know if bazaar has already been proposed for backport?
<bddebian> persia: You about?
<ScottK2> somerville32: Look for a bug in gutsy-backports
<bddebian> Anyone have a clue how I get rid of cruft from a diff that I don't even know how it got there?  In almost every file I touched I'm getting the complete copyright statement re-generated
<Fujitsu> bddebian: You look for the script that is regenerating it.
<bddebian> Hmm, I think it's because the files were in MS-DOS format so had extra CR on them :_(
<Mattva01> why do I get this error from soyuz ? i don't quite understand it :dpkg-genchanges: failure: cannot read files list file: No such file or directory
<jdong> GRR fscking....
<somerville32> bddebian, You can user filterdiff
<jdong> yay lovely, that's why... libmp4v2 is removed from the archive
<somerville32> bddebian, or if the cruft is isolated, you can just remove it from the patch manually
<ion_> Could i get a second advocation for http://revu.tauware.de/details.py?package=hardware-connected (a program that checks whether given hardware is connected to the system, nice for scripting)? Thanks
<jdong> LucidFox: hey sup?
<jdong> oooooh shiny new x264!
<jdong> must upload crack!
<bddebian> somerville32: Unfortunately I don't know what showed up :-(
<bddebian> Isn't there some utility to strip carraige returns from files?
<somerville32> bddebian, Can you pastebin your diff?
<bddebian> It would be HUGE :-)
<cyberix> Help to increase the amount of public domain in Ubuntu. Review my package malbolge, now! Right here on R-E-V-U. http://revu.tauware.de/details.py?package=malbolge
<cyberix> Enough syrup in my speech?
<Fujitsu> Public domain isn't always good.
<bddebian> Aha, dos2unix saves the day!!
<LucidFox> jdong> I was wondering about mpeg4ip
<jdong> LucidFox: uploaded 7 seconds ago
<LucidFox> Ooh.
<LucidFox> Awesome.
<jdong> :)
<jdong> now I'm wrangling faac then going to queue rebuilds of the libmp4v2-0 dep chain
<cyberix> Fujitsu: The software  or  the "license" (or lack of it)
<LucidFox> cyberix> I think it's better to add a disclaimer for legislatures with no concept of public domain
<LucidFox> like Wikipedia does
<LucidFox> "
<LucidFox> I, the copyright holder of this work, hereby release it into the public domain. This applies worldwide.
<LucidFox> In case this is not legally possible,
<LucidFox> I grant any entity the right to use this work for any purpose, without any conditions, unless such conditions are required by law.
<LucidFox> "
<cyberix> But I'm not the copyright holder of all the stuff in the package.
<LucidFox> Ah. Sorry then.
<cyberix> And using multiple licenses would be far too complicated.
<cyberix> Of course I might have the right to "relicense" it because it is public domain.
<cyberix> But then again I'd ask a US citizen to do that.
<cyberix> And then again the spirit is what matter most.
<LucidFox> cyberix> You don't need to.
<cyberix> I'm way too technical to work with these concepts anyway.
<LucidFox> And now we'll have to wait until mpeg4ip passes NEW... *sigh*
<jdong> LucidFox: yep :)
<jdong> LucidFox: then I got another mpeg4ip I need to upload after the first one and faac build.
<jdong> LucidFox: had a circular uninstallable chain, the mpeg4ip I uploaded is crippled faac-less, which frankly I don't think all but 3 people on the planet care.
<jdong> lol but oh well I keep everyone happy ;-)
 * cyberix found speed-game (currently in revu) to be lots of fun.
<LucidFox> On the plus side, it will finally be possible to get rid of gtkpod-aac patches.
<jdong> LucidFox: yep, that's what I'm currently removing :)
<LucidFox> In 0.99.12, I hope? ;)
<jdong> LucidFox: did debian release the new one?
<jdong> ep I see it
<jdong> grumble well merge time :)
<jdong> LucidFox: you wanna do it? :D
<jdong> I feel like catching up on some sleep tonight ;-)
<LucidFox> Well, I have already uploaded an interdiff for 0.99.12, so I might as well remove the patches
<jdong> LucidFox: ah, awesome, looks like you've got that under control then
<Vorian> jdong!
<jdong> looks like just exfalso needs rebuilding then
<jdong> Vorian!
<Vorian> welcome back
<jdong> thanks, doing laundry tonight and got bored
<jdong> otherwise I was ENJOYING my VACATION....
 * Fujitsu sends jdong away again.
<bddebian> heh
<jdong> ok, looks like I've hit a dead end for the night, time to wait for FTBFS-mail :D
<jdong> oh wait libx264 is asking to be broken
<jdong> ok, x264 is all happy now
<jdong> snoozing time
<Fujitsu> Night jdong.
<jdong> night Fujitsu
<LaserJock> I don't suppose I could interest anybody in some grub recovery help?
<LaserJock> I'm trying to reinstall grub by chrooting off the LiveCD
<LaserJock> but grub-install is not working
<Fujitsu> What is the problem?
<Fujitsu> !doesn't work
<ubotu> Doesn't work is a strong statement. Does it sit on the couch all day? Does it want more money? Is it on IRC all the time? Please be specific! Examples of what doesn't work tend to help too.
<Fujitsu> I love that factoid.
 * StevenK too
<LaserJock> root@ubuntu:/# grub-install /dev/sda
<LaserJock> Could not find device for /boot: Not found or not a block device.
<bddebian> hehe, that's funny
<Fujitsu> Have you bind-mounted /proc, /dev inside the chroot?
<LaserJock> Fujitsu: yep
<LaserJock> I can go to /boot and I see it in /dev
<StevenK> What about /sys?
<LaserJock> I didn't bindmount /sys
<Fujitsu> I haven't historically needed /sys, I don't think, but you never know.
<LaserJock> I've never had to do that  before
<StevenK> I'm not quite sure how grub-install enumerates devices
<Fujitsu> Neither.
<LaserJock> no go
<LaserJock> can I tell it manually?
<StevenK> strace it?
<Fujitsu> Hmmm.
<Fujitsu> You might need to ask it to regenerate its maps.
<Fujitsu> Have you moved drives/partitions around?
<LaserJock> just tried that
<LaserJock> Fujitsu: nope
<StevenK> Remove /boot/grub/device.map ?
<StevenK> I think that's what it's called.
<LaserJock> nada
<LaserJock> grr, my wife needs some files :/
<LaserJock> stupid sbuild
<Fujitsu> sbuild doesn't eat boot records.
<Fujitsu> Neither does mk-sbuild-lv.
<StevenK> Carbon unit problem?
<LaserJock> Fujitsu: no, but the partition I wiped to do it had my previous grub install
<LaserJock> ok, so in grub running find /boot/grub/stage1 says it can't find the file
<LaserJock> man, I'd really hate to have to re-install this laptop :(
<Fujitsu> Er, why would you consider reinstalling?
<Fujitsu> Does /boot contain the appropriate GRUB files?
<LaserJock> yep
<LaserJock> Fujitsu: well, I can't boot
<LaserJock> I'm getting off what I need for now via LiveCD
<Fujitsu> What was on the partition? Just the boot sector?
<LaserJock> I have a separate partition for /boot
<Fujitsu> You copied all the stuff from there to /boot on your root partition before obliterating it?
<LaserJock> no, I didn't obliterate /boot
<LaserJock> I had an openSUSE install on another partition
<LaserJock> and of course it installed it's grub
<LaserJock> so today I wiped that out
<LaserJock> I think I may have just gotten it
<LaserJock> I started up grub itself
<LaserJock> and ran:
<LaserJock> root (hd0,2)
<LaserJock> setup (hd0)
<LaserJock> and it said it worked
<Fujitsu> Aha, good.
<LaserJock> ok, rebooting
 * Fujitsu shakes his head in dismay.
<Fujitsu> One probably shouldn't consider reinstalling because the bootloader is broken.
<ant1> man-di: hello, how's the icedtea package ?
<ant1> man-di: I got bad news, I just installed icedtea-java7-jre on my system, when I attemped to run JOSM, it crashed
<ant1> Hello, I was building one of my packages under hardy amd64 using pbuilder, and I got this: http://pastebin.com/m461bd24
<jscinoz> hey persia
<jscinoz> you mentioned on my package that "15) uscan --report-status reports no matching files, which is often an indication that the watch file doesnât work properly." i just ran it again, it returns up-to date for me... can you try it again?
<jscinoz> where can i find the information on the policy change in debian/menu in hardy?
<LucidFox> jscinoz> sudo apt-get install menu
<LucidFox> :)
<LucidFox> the Hardy version, of course
<jscinoz> how would i get the hardy version rather than the gutsy version (im assuming it'll ge the one for the dist im currently on)
<LucidFox> Well, you can download the source package
<LucidFox> https://launchpad.net/ubuntu/+source/menu/2.1.36
<jscinoz> thanks
<ant1> Hello, I was building one of my packages under hardy amd64 using pbuilder, and I got this: http://pastebin.com/m461bd24 , can anyone help on this ? I'm pretty sure that there's nothing wrong with the package because Debian has an amd64 binary for it
<mattva01> sorry about all the Soyuz questions,but is there a way to find the build log of your project if it never shows up (it publishes, but never comes up with a deb package )
<ant1> actually Ubuntu too has and amd64 binary for it
<ant1> http://packages.ubuntu.com/hardy/misc/acon
<Fujitsu> mattva01: Ho long ago was it uploaded?
<Fujitsu> *How
<StevenK> ant1: https://edge.launchpad.net/ubuntu/+source/acon/1.0.5-4
<jscinoz> there we go got what i needed from that, games/arcade is games/action in hardy.
<StevenK>     * Published on 2007-10-24
<mattva01> about 45 minutes ago , but it shows it as published , but with no build failed or success log
<Fujitsu> mattva01: Wait a while. The builds probably won't have been created yet.
<ant1> StevenK: so why I can't build it ?
<Fujitsu> mattva01: You should be watching https://launchpad.net/people/+me/+archive/+builds?build_state=all
<ion_> ant1: You probably should find the package that contains the missing file and investigate why it hasnât been installed.
<jscinoz> hey guys, im creating a package of the game urbanterror which contains non-gpl code but allowed to distribute, i need to make it display a prompt to allow the user to review the license and accept or decline it, i've seen this done in the sun-java packages but i cannot figure out how its done from that source package. how would i accomplish this?
<ant1> jscinoz: use debconf
<jscinoz> thakns
<jscinoz> ant1, the short description line in debian/templates should be limited to 80 characters correct?
<mattva01> what does this even mean? dpkg-genchanges: failure: cannot read files list file: No such file or directory
<Amaranth> ugh, i hate it when people abuse nominations
<Amaranth> we're not even half way though the hardy cycle and people are already nonimating bugs to be fixed in hardy
<Amaranth> uh, duh?
<ant1> jscinoz: not sure
<ant1> jscinoz: dunno about that
<jscinoz> hmm
<ant1> man-di: hmmm, it didn't work with sun java either, I think it's a problem under AMD64 arch.
<jscinoz> argh the documentation on debconf is confusion
<jscinoz> confusing*
<jscinoz> you wouldnt think it so hard to simply display some text and a true/false prompt, continue installation if true and exit if false.
<StevenK> Can someone remember a package that does something different on say amd64?
 * StevenK can't remember the magical dpkg-architecture runes in debian/rules
<ant1> jscinoz: http://64.233.183.104/search?q=cache:0uKuMO_uzYIJ:www.fifi.org/doc/debconf-doc/tutorial.html+debconf+tutorial+fifi&hl=en&ct=clnk&cd=1&ie=UTF-8
<jscinoz> thats the one im looking at
<jscinoz> ive got the templates file
<jscinoz> cant figure out how im supposed to call it
<jscinoz> in debian/config?
<ant1> jscinoz: debian/config is for dh_input mostly
<ant1> jscinoz: postinst is for dh_get
<ant1> db_* sorry
<jscinoz> well it has to be shown and the license accepted *before* the package is installed
<jscinoz> so i assumed config would be a good place
<ant1> jscinoz: the preinst
<ant1> jscinoz: then preinst maybe ?
<jscinoz> hmm alright..
<jscinoz> is there any way to test it works without compiling the package and such?
<ant1> dunno
<dholbach> good morning
<ant1> dholbach: hello
<dholbach> hey ant1
<dholbach> how are you doing?
<TheMuso> Hey dholbach!
<ant1> dholbach: I'm fine thanks,  can you review this package: http://revu.tauware.de/details.py?package=ubuntume-themes , one of the themes is based on a theme you worked on (Human theme)
<dholbach> heya TheMuso
<ant1> dholbach: particularly I'd hope you check the copyright file
<dholbach> ant1: not right now - I'm just catching up with myriads of emails - if you'd drop me an email with the link I'd do it later on and not forget it
<ant1> k
<psicus78> Hi!  Is this the place where to ask to re-sync the REVU uploaders keyring? :)
<dholbach> thanks ant1
<ant1> np
<Fujitsu> psicus78: It is.
<psicus78> thanks
<Fujitsu> You would like it synced, then?
<jscinoz> is this script valid for calling debconf to ask a boolean question and continue package installation if true, and cancel installation if false? http://pastebin.ubuntu-nl.org/51060/
<jscinoz> alright...
<psicus78> Fujitsu: it looks like already synced, I just tried to get my password and it worked, thanks!
<slangasek> jscinoz: no, "exit" doesn't cause the maintainer script to return an error
<jscinoz> if i want a debconf script to present a boolean question, and cancel package installation if the result is False, can i do this straight from debian/rules (in the install-indep section)
<jscinoz> ugh
<jscinoz> this is confusing
<ant1> dholbach: can I ask a review for another couple of artwork packages too ?
<dholbach> ant1: just add the links to that email
<ant1> dholbach: ok, thanks
<ant1> how can I use dpkg to search for which package provides the file X ?
<StevenK> dpkg -S
<ant1> StevenK: aha, the file posix_types_64.h is provided by linux-headers-2.6.24-2-generic, does linux-headers package get installed in pbuilder's base.tgz ?
<ant1> hmmm, could that be a bug that posix_types_64.h is provided by linux-headers-2.6.24-2-generic and NOT linux-libc-dev ?
<ant1> wierd, it is provided by linux-libc-dev
<ant1> ok, I think I found the problem
<ant1> posix_types_64.h is in /usr/include/asm
<jscinoz> slangasek, what about "exit 2"
<jscinoz> slangasek, i've updated my script, would this work: http://pastebin.ubuntu-nl.org/51064/
<ant1> can someone confirm this with me, I think there's a problem with asm/posix_types.h that comes with hardy
<ant1> in hardy it has #include "posix_types_64.h"
<StevenK> Why are you including asm/posix_types.h at all? It's a kernel header.
<ant1> in gutsy it was #include <asm-x86_64/posix_types.h>
<ant1> StevenK: I am including linux/kd.h
<ant1> StevenK: which in turn includes linux/posix_types.ht
<ant1> StevenK: which in turn includes linux/posix_types.h
<ant1> StevenK: and the last one includes asm/posix_types.h
<StevenK> It changed because the kernel in Hardy is 2.6.24, which pulled i386 and x86_64 into one arch.
<ant1> StevenK: here's the compile error: http://pastebin.com/m461bd24
<ant1> StevenK: yes, but should the new asm/posix_types.h read something like:
<ant1> #include <asm/posix_types_64.h> , instead of #include "posix_types_64.h" ?
<StevenK> Maybe your source should I changed to include -I/usr/include/asm
<ant1> StevenK: I wonder how acon got compiled on Ubuntu's hardy ?
<ant1> StevenK: isn't this -I/usr/include/asm a bad workaround ?
<StevenK> I'm not sure.
<jscinoz> persia are you here?
<slangasek> jscinoz: yes, that looks like it should work as you describe
<LucidFox> Aren't packages that automatically update debian/control forbidden?
<dholbach> LucidFox: no - the pkg-gnome team for example makes use of debian/control.in a lot
<dholbach> but they just update the maintainer automatically in there
<dholbach> congratulations pochu! :-)
 * StevenK twitches, getting used to using quilt
 * Fujitsu sews some patches onto StevenK.
 * StevenK doesn't need patching
 * Fujitsu shrugs, and continues patching.
<huats> moring dear MOTUs
<Fujitsu> Hi huats.
<huats> Hi Fujitsu
<jscinoz> slangasek thanks
<jscinoz> where should i call it from?
<slangasek> jscinoz: typically you would do that in a package preinst, if it's some kind of license that the user has to agree t
<slangasek> o
<slytherin> is anyone planning to update classpath packages? Or should I file a sync bug?
<jscinoz> slangasek, are preisnt scripts automatically executed if they have the right name? or do they need to be executed from debian/rules?
<chazco> Hi... does anyone know how I can set the default application for a mime type without using defaults.list?
<amarillion> jscinoz, afaik it just depends on the name of the script
<amarillion> you don't need to run them from debian/rules
<amarillion> debian/rules is run at package build time, the preinst & postinst etc at package install time
<jscinoz_> what is the preinst called by?
<jscinoz_> or is it run automatically if it has the right filename?
<amarillion> It's run automatically
<amarillion> by dpkg
<amarillion> It needs to be executable too, of course
<chazco> Is it resonable to have echo "application/tmd.textmaker=tm.desktop" >> /usr/share/applications/defaults.list inside the postinst script?
<amarillion> won't that lead to a lot of cruft when you upgrade the package?
<amarillion> maybe you can grep defaults.list first to see if that line is already present
<chazco> The trouble is I cant think of any other way to do it... one of the rm scripts has some sed magic to remove it
<chazco> It seems odd since everything else I've needed to do is done with .desktop's and an .xml, which seems like a clean way to do it... then this (KDE appears to use another .desktop so avoids the issue, but i'm after Gnome as well)
<amarillion> Yeah, i see. It might work but it seems like there should be a better way
<chazco> Thats what I was thinking (i'm new to this so may be missing something)
<Ng> I have a comment on my REVU upload that the .desktop doesn't validate in Hardy, something about "Encoding=UTF-8" being wrong - where can I find out what it should be, and if at all possible, validate it myself?
<chazco> I've got /usr/share/applications/tm.desktop (a menu entry), /usr/share/icons/... for the icons, /usr/share/mime/packages/tm.xml to define the mime type, /usr/share/mimelnk/applications/tmd.desktop (for KDE file assosiations)... now i'm stuck :D
<chazco> Judging by the gnome documentation it seems like defaults.list must be modified though, so cant see any other way to do than in postinst
<jussi01> Hi all, could someone point me to a tutorial for making a debdiff?
<ChrisGibbs> gday all
<chazco> Anyone know the correct way to set a default application for a mimetype in Gnome?
<geser> good morning
<warp10> persia: may I request the merge for sympa?
<persia> warp10: Go ahead.
<persia> jussi01: https://wiki.ubuntu.com/MOTU/Contributing
<persia> chazco: look into dh_installmime
<warp10> persia: Ok. I'll take care of sending that patch to Debian too
 * persia thanks those who answered previous questions
<persia> warp10: Thanks.
<persia> warp10: Wait, isn't that a python 2.4 -> python 2.5 change?  Debian likely doesn't want it.
<warp10> persia: mmm... no. It's about verifying /var/run/sympa on startup.
<persia> warp10: Ah.  Then Debian likely does want it.  Thanks :)
<warp10> :)
 * amarillion is learning dpatch
<amarillion> Somehow I keep getting unwanted changes in my patches after dpatch-edit-patch
<amarillion> and then I have to go through a lot of trouble to get it clean again
<jpatrick> amarillion: my personal preference is simple-patchsys
<persia> amarillion: Are you running build inside dpatch-edit-patch?
<amarillion> persia, yes, how else to test the changes?
<persia> jpatrick: No comments, only works for CDBS, and doesn't allow selective enablement of patches (but I agree).
<persia> amarillion: Exit dpatch-edit-patch.  Do your testing.  dpatch-edit-patch the patch again, etc.
<amarillion> ah right
<DaveMorris> if a source release produces 5 shared libraries, which depend on each other quite heavily.  Should I separate them into separate packages or just 1 package
<persia> DaveMorris: It's generally advised to separate them early, so you can avoid the pain of separating them later (in case a client only uses some of the features), but there are exceptions in the archive.
<geser> DaveMorris: can each be used without the others?
<DaveMorris> ok atm I have libs a, b, c, d, e.
<DaveMorris> a is useless on it's own.  b depends on a. c/d/e all depend on a,b but are independent of each other
<Kmos> dholbach: welcome back =)
<dholbach> hi Kmos :)
<TheMuso> dholbach: Oh lovely. Seems that LP is somewhat late in changing that wordpress bug you just closed. :p
<persia> DaveMorris: In that case, I'd suggest at least splitting into four packages (a,b), c, d, and e.
<DaveMorris> and 4 dev packages ?
<persia> DaveMorris: Err.  Right.  Eight.  Sorry.
<dholbach> TheMuso: was there a LP: #xxxxx in the changelog?
<DaveMorris> thanks, whilst I'm here.  My small package http://revu.tauware.de/details.py?package=libserial is looking for a revu.
<TheMuso> dholbach: Yes. Soyuz even indicated as such with the launchpad-bugs-fixed field in changes
<dholbach> TheMuso: weird
<TheMuso> Indeed.
<liri> could someone check if daloradius-0.9.5-1 uploaded successfully to revu?
<liri> ahh nevermind, I see it now
<TheMuso> c
<TheMuso> ugh wrong tab
<dannioni> Hello, hope you don't mind answering a question. https://bugs.launchpad.net/ubuntu/+source/flightgear/+bug/177615 states that a new version of flightgear has been released and that no debian package exists. We are currently at 0.9.10-2ubuntu2 should the new version number be 1.0.0-0ubuntu1 ?
<ubotu> Launchpad bug 177615 in flightgear "New upstream version: 1.00" [Wishlist,Confirmed]
<dannioni> I'm new to this packaging stuff, as you might have guessed, but keen to learn.
<persia> dannioni: 1.0.0-0ubuntu1 would indeed be the correct version for a first upload to hardy.  However debian has 1.0.0-1, so you might do better to test that, and consider either a sync or a 1.0.0-1ubuntu1 for a merge.
<imbrandon> dannioni: possibly, more likely 1.00 vs 1.0.0 if the bug title is correct
<imbrandon> e.g. 1.00-0ubuntu1
<persia> imbrandon: It's 1.0.0-1 in Debian, so we really want 1.0.0-$revision
<imbrandon> ahh he said it wasent in debian
 * persia is paranoid, and doesn't trust anyone :)
<dannioni> rather the bug report in debian said there was no package
<imbrandon> dannioni: did you look?
<dannioni> no, just at the bug report :P
<imbrandon> ahh, well persia is correct on all accounts here, personaly if its 1.00 upstream then imho debian botched the version number, but its not a big deal nor something that should be fixed at this point
<imbrandon> base the merge or sync on 1.0.0-1 :)
<dannioni> great, thank for the help
<persia> dannioni: When testing, please be sure to also look at simgear and fgfs-base, as these packages are all fairly tightly integrated.
<persia> Oops. fgfs-atlas too.
<asac> RAOF: hey! about miro ... would like to talk about moving miro to xul 1.9 ... just ping me when avail
<amarillion> Ah I see. games should be chown root:games with chmod g+s so they can write to /var/games.
<amarillion> Is there a way to do that in debian/rules, or do I need a postinst script for that?
<persia> amarillion: You need to do it in postinst
<amarillion> ok
<RAOF> asac: Hi!
<RAOF> asac: I've tried the PPA miro, and it seems fine to me.
<mruiz> hi all
<jpatrick> hi mruiz
<RAOF> We don't want to preserve PPA entries in the Ubuntu changelogs, do we.
<RAOF> s/./?/
<dannioni> persia: will do
<dannioni> flightgear depends on them, right?
<Hobbsee> RAOF: not unless there's a really good reason to, no
<RAOF> Hobbsee: Thanks, just checking.
<sladen> Removing information from changelogs seems excessive
<RAOF> Is anyone looking into the new monodevelop packages in Debian?
<jscinoz__> persia!
<sladen> perhaps it can be "zipped up", like a new upstream version pull-in from DEbian
<jscinoz> hey guys, ive got a script in debian/preinst am i correct to assume this is automatically called pre-installation?
<persia> sladen: We drop ~ppa revisions because as Ubuntu, we consider that all part of the preparation process.  Similarly, Debian drops all Ubuntu changelogs when importing, as a part of the preparation process.
<persia> jscinoz: http://women.debian.org/wiki/English/MaintainerScripts has all the secrets of how and when for maintainer scripts.
 * RAOF checks out this new link he hasn't read before
<chazco> Can anyone point me in the direction of a package which creates a totally new mimetype, registers a default open application for it as well as icons etc and works on KDE and Gnome? I'm not having much luck currently writing my own deb to do this for an app...
<chazco> I'll leave KDE users out for now then, at least it works for Gnome
<persia> chazco: Does dh_installmime not do it for you?
<chazco> I'm doing most of it manually currently...
<persia> Oh, and you'll also need the .desktop file for the MIME type, and dh_desktop
<jscinoz> thank you persia
<chazco> But ive found very little documentation which helps with this
<slytherin> Please give me an advice, I filed a bug that fixes FTBFS and attached debdiff. In the meanwhile I also forwarded bug to debian where it was fixed. So do I wait for my debdiff to be accepted in Ubuntu or file a sync request? There are no other significant changes in Debian
<Hobbsee> slytherin: sync request.
<Hobbsee> slytherin: saves you the effort of merging, and/or requesting the sync then
<slytherin> Hobbsee: There were no other changes in Ubuntu. Do I still file sync request?
<Hobbsee> slytherin: yes, as the autosync is off (and has been since debian import freeze)
<jscinoz> persia, but is debian/preinst automatically called or does it need to be referenced somewhere
<persia> jscinoz: dpkg calls the scripts at the times and with the arguments explained on the Debian Women wiki.
<persia> DktrKranz: Please mention the package and the issue when mailing the BTS: there is no context in notifications.
<Hobbsee> dholbach: ping
<DktrKranz> persia, oh. right. It isn't in the subject or in the body. Thanks.
<Hobbsee> dholbach: didn't the MC violate point #1 of https://wiki.ubuntu.com/CommunityCouncil/Delegation ?
 * nenolod wonders why dholbach pinged somebody who is entirely unrelated to the audacious package on the audacious merge bug and ponders idly if he meant to do it on some other bug instead
<Hobbsee> dholbach: and why is that the opposite to the bottom of https://wiki.ubuntu.com/MOTU/Council ?
<jscinoz> persia, can i request you try uscan --report-status again for my two packages, i tried it a few minutes ago after seeing your comments, and it works fine for me.
<persia> jscinoz: I don't have time to download them before I go to sleep?  I'll give it a shot when I have time again.
<chazco> persia - Still cant get KDE to work (testing on a liveCD)... thanks anyway :)
<persia> chazco: Where are you installing the .desktop file?
<nenolod> also out of curiosity, would packages one maintains in debian which do not require ubuntu changes count as collateral reference should someone choose to join MOTU?
<chazco> I've created /usr/share/applications/tm.desktop (which is a menu entry type one) and /usr/share/mimelnk/tmd.desktop which is the mimetype one
<nenolod> isn't it mimelink, not mimelnk ?
<nenolod> hmm, it is mimelnk
<jscinoz> persia, i thought you'd already downloaded it since you've commentedo n the new ones
<persia> chazco: Put the MIME .desktop in /usr/share/applications, or dh_desktop won't do the right thing.
<nenolod> go figure.
<persia> jscinoz: I delete after reviewing: I don't have infinite disk space :)
<jscinoz> >_<
<chazco> So I should have two .desktops in /usr/share/applications
<nenolod> chazco, also, generally speaking, you can combine mime and launcher into a single .desktop
<jscinoz> one quick thing... idk if you can answer it with out the package
<nenolod> chazco, so probably, you only need one
<jscinoz> "11) The manpages say they are GPLv2, but provide a reference to GPLv3. Please either narrow the reference, or change the license." I cant find any references to GPLv3 in either man page.
<chazco> hmm, ok... will have a look
<dholbach> Hobbsee: that's a proposal
<dholbach> Hobbsee: it'll be discussed in the next CC meeting
<chazco> How can you combine the two .desktops? One has a type of mimetype and one has application...?
<Hobbsee> dholbach: which is?
 * persia notes that one needs two .desktop files when there is one icon for the application and a different icon for the files.
<dholbach> nenolod: I asked somebody to review the packages
<dholbach> Hobbsee: what do you mean?
<nenolod> dholbach, oh. ok.
<Hobbsee> dholbach: when's the next CC meeting?
<dholbach> Hobbsee: I proposed a few meetings times to the members, but didn't get replies yet
<chazco> I'm getting the impression this just isnt going to work... it sounds simple but I just cant get it to go
<dholbach> Hobbsee: we'll announce the new meeting time asap
<nenolod> chazco, what's your .desktop ?
<chazco> Which one? Application or mime?
<persia> chazco: Please pastebin both of those.
<nenolod> chazco, you really should have all of it in one file
<chazco> Oki, one moment
<chazco> No idea how to merge them though (really new to this)
<persia> chazco: Also your debian/package.sharedmimeinfo file
<chazco> Ive got what i have so far by looking at other packages
<persia> nenolod: Only if there is only one icon.
<chazco> persia - I dont have one of those...
<persia> chazco: That might be why dh_installmime isn't working :)
<nenolod> persia, hmm. afaik desktops can provide more than one mimeicon.
<chazco> Would I be better off trying to start the mime type stuff from scratch? (trying to pastebin desktops)
<persia> nenolod: Really?  That's different than my understanding, but would be a nice feature.  I hope you are correct.
<nenolod> persia, i believe i have seen it before. but i could be mistaken.
<zul> ,prmomg
<jscinoz> Why is it bad to include the upstream changelog in /usr/share/docs/packagename/
<chazco> persia - http://paste.ubuntu-nl.org/51079/
<jscinoz> *confused*
<DaveMorris> linda gives me an error about no man page for a binary I'm installing into /usr/bin  The binary is GUI only with no paramaters to be passed in, so does it need a man page?
<jscinoz> how does one differentiate between hypens and minus in a man page.
<imbrandon> DaveMorris: any binary in /usr/bin must have a man page
<persia> DaveMorris: Yes it does.  The manpage might only explain what the command does, that it is a GUI app, and that it takes no arguments, but it should be there.
<persia> jscinoz: \- vs. \(hy
<nenolod> persia, there are several duplicates to our bug, for what it's worth. i'm going to list them now. ;)
<jscinoz> hmm
<persia> nenolod: Don't list them.  Just mark them dupes.
<nenolod> persia, that'll do.
<persia> nenolod: Anyway, unless it gets rejected upstream, it will likely be applied later.
<jscinoz> persia, so youre saying in every argument listed in the man page i need to change -- to \-\-?
<jscinoz> ie change --help to \-\-help
<persia> chazco: Small notes: you don't want an absolute path for the executable, shouldn't have an extension for the icon, and Encoding is deprecated (non UTF-8 isn't supported anymore).  Other than that, looks relatively sane.
<Ng> persia: aha, that answers one of my questions about the comments you left for my upload :)
<chazco> Tried removing the icon extension, didnt help (but thanks)... app is relative for now because it clashes with something else i'm testing, but wont be in the final... didnt know about encoding, thanks :)
<persia> Ng: Ah.  I thought you had an answer.  Also try lintian and desktop-file-validate from hardy to check against the latest standards.
<guest22> Any MOTUs here willing to review package photoml (http://revu.tauware.de/details.py?package=photoml)? It's already been advocated once (the previous upload, at least), so it should be very close to being acceptable.
<chazco> This debian/package.sharedmimeinfo file... i have an xml file in usr/share/mime/packages which looks similar to what ive seen...
<persia> chazco: Removing the icon extension won't help, but it means that themes are supported (which is a good thing).  Please do remove it, while also trying to sort your other issue.  Also, consider debian/package.mime, which tends to be helpful.
<chazco> I'm totally lost tbh now... it works on Gnome, but KDE doesnt do anythign (the menu entry doesnt show, file assosiations dont work). Its probably something simple since I built it by trial and error.
<Ng> persia: you've just answered my next question with desktop-file-validate. thanks :)
<persia> chazco: You might ask for someone to comment in #kubuntu-devel (although they may be focused on actually developing kubuntu and not have time to answer).
<nenolod> persia, 4 duplicates ;)
<chazco> For now i'll probably leave KDE out, its difficult to test without a KDE machine
<persia> nenolod: Thanks for helping triage :)
<nenolod> persia, well, it also demonstrates to sebastian that there are indeed duplicates
<nenolod> the problem is that my bug is the only one which had a clean backtrace...
<nenolod> i think it's related to having amd64
<persia> nenolod: Maybe it's an SMP thing?
<nenolod> maybe
<chazco> So... i have a .desktop in /usr/share/applications (menu entry), an xml in /usr/share/mime/packages which defines the glob patten for the mime type, icons in usr/share/icons/gnome/scalable/mimetypes for files which match, and postinst which updates defaults.list and runs the update-* commands... does that sound correct?
<nenolod> i finally got my memory issue worked out too
<nenolod> turns out the motherboard's firmware is on crack and set up the memory with a ridiculous CAS timing
<nenolod> :D
<persia> chazco: Sounds right.  Does it work?
<chazco> It does for gnome... most of it is reverse-engineered, so im not sure its the correct way to do it
<nenolod> persia, that's what i'm thinking
<persia> chazco: As long as you don't do anything especially GNOME-specific, if it doesn't work on KDE, and people want it, you'll get a bug, which might help towards a solution (or at least identify a willing tester).
<chazco> Ok, hopefully it'll get fixed at some point
<chazco> I was unaware of the debhelper stuff... where can I find more info, they could help...
<persia> chazco: debhelper is typically exceedingly helpful.  There are manpages which help some, and the source is fairly readable.
<chazco> Odd... mime wont show any man pages (tried it already)... will try to reinstall it
<nenolod> persia, this is the best backtrace of the bug i've found. it's better than mine. http://launchpadlibrarian.net/11083488/Stacktrace.txt
<DaveMorris> just notice that linda and lintian don't complain about a binary going into /usr/bin with a name of fcdActor even though all the other binaries are all lowercase.  Is it something I should change?
<liri> persia: I'm not being emailed the recovery password, can you check it out please?
<chazco> Just to be totally clear - i can safely remove Encoding=UTF-8 then?
<imbrandon> liri: recovery password for what ?
<imbrandon> REVU ?
<liri> imbrandon: yeah, sorry if I wasn't clear
<persia> liri: Have you uploaded anything?
<imbrandon> liri: it dosent email it to you, you click recovery and follow the instructions
<liri> imbrandon: yeah I uploaded the daloradius package and saw it on the website
<liri> imbrandon: ahh, the documentation on the wiki is a bit unclear on that then
<persia> nenolod: Is there a threadedstacktrace for that bug?
<nenolod> maybe
<nenolod> persia, http://launchpadlibrarian.net/11083489/ThreadStacktrace.txt
<tuxmaniac> Can somone please verify and ack for the sync request in bug 181007?
<ubotu> Launchpad bug 181007 in libitpp "[SYNC] Debian Unstable sync of libitpp 4.0.1-3 requested" [Undecided,New] https://launchpad.net/bugs/181007
<persia> Bah.  Only shows one thread.  I was hoping to see the clearing function running ahead of the populate function.
<nenolod> persia, that happens
<nenolod> persia, because the populate function is asynchronous
<persia> tuxmaniac: subscribe the sponsors queue to ask for review
<nenolod> persia, so it's possible that the clearing function is already called, but there's another populate in the queue
<tuxmaniac> persia, even for sync request from Debian Unstable?
<persia> nenolod: Exactly.  That's why I was hoping for two threads in a threadstacktrace that would demonstrate the issue to actually be the one you fixed.
<nenolod> but since priv->menu and blah blah blah
<persia> tuxmaniac: Yep.  You need approval from a member of ~ubuntu-dev, which is what the sponsors do.
<nenolod> gnome makes me want to headdesk repeatedly.
<nenolod> persia, the only reason why i succeeded in fixing that bug is because i'm quite familiar with the craqery that is gtk+
<nenolod> things like gksudo scare me, knowing just how many bugs just like that in gtk+ haven't been fixed yet
<nenolod> :P
<liri> persia: could you check that the package was uploaded and signed successfully?
<chazco> I'm wondering if it could be a permissions issue now...
<chazco> persia - You know I said it would be something simple....
<persia> which simple thing was it?
<chazco> Log out and back in... which is harder on the live CD :D
<chazco> I cant believe it after all that
<chazco> I was expecting it to be like Gnome, where it updates without restarting
<chazco> Anyway, thanks for your time, it was really appreciated :)
<chazco> Think i'm going to have to setup a duel-boot from now one :)
<pkern> How do rebuild uploads work?  I upload the package sourceful with adapted build-deps and a XbuildY version number?
<persia> pkern: -XbuildY means you only changed the changelog.  If you have to touch control, mangle the maintainer and use -XubuntuY
<pkern> persia: Which kills autosync.  Bah.
<pkern> persia: So if I do build uploads, the deps already need to be built and published?
<persia> pkern: You don't want to autosync if you changed control.  That's why.
<pkern> persia: I do want autosync if I changed control. (:
<pkern> persia: I know what I'm doing.
<persia> pkern: The guidelines assumes you aren't 100% sure, and should check again when hardy+1 opens.  If you're very, very, very certain, and you break the guidelines, such is life.  On the other hand, you ought set an Ubuntu maintainer for an Ubuntu variation.
<pkern> persia: It's my package in Debian. \-:
<pkern> persia: But ok, thanks.  So XbuildY will not prevent autosyncing?
<Whoopie> siretart: hi, the patch from bug report 104332 is missing in the gutsy package. Can I reopen the ticket?
<Whoopie> bug 104332
<ubotu> Launchpad bug 104332 in rdesktop "rdesktop crashes when logging in to windows 2000 (or pressing cancel)" [High,Fix released] https://launchpad.net/bugs/104332
<Kmos> pkern: yes
<siretart> Whoopie: is the patch in the hard package?
<siretart> Whoopie: re the bug: sure, but please reassign to yourself
<Whoopie> siretart: what's a hard package?
<man-di> Whoopie: hardy
<siretart> hardy, right
<Whoopie> siretart: hardy has a CVS version of rdesktop where the bug is fixed.
<Whoopie> siretart: we could just backport it. ;)
 * persia suggests that propagating VCS snapshots can lead to user confusion and complaints, even when bugs are fixed.  Is a new upstream coming soon?
<Whoopie> persia: no idea, sorry
<siretart> Whoopie: which would miss everyone not using backports. an upload to -security would be better, and requesting a backport as well for more adventureous users
<cyberix> I'm looking after first advocate for my package malbolge. I've fixed all problems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
<Whoopie> siretart: I don't know how to add Gutsy to this bug report. It's not "project" nor "distribution/package".
<persia> Whoopie: "Nominate..."
<Kmos> there is a way to enable pkgbinarymangler in pbuilder ?
<RAOF> Kmos: Yes; install it in the pbuilder environment.
<Kmos> RAOF: ah ok =) thank you
<RAOF> Kmos: So, you'd pbuilder login --save-changes (or whatever that switch is), then apt-get install
<geser> and don't forget to enable it
<Kmos> exactly
<Kmos> geser: how to do it ?
<Kmos> it's installed now
<Kmos> in /etc
<Kmos> found it =)
<Whoopie> persia: done, but it's not the same as it's shown for the others (edgy, feisty)
<siretart> Whoopie: I accepted your  nomination and assigned that task to you
<Kmos> geser: thanks
<persia> Whoopie: Moving from Nomination to confirmed needs-fixing for a given release needs confirmation from a developer.
<Whoopie> siretart: so what is my task now? ;)
<siretart> Whoopie: fix the bug
<siretart> e.g. by attaching a debdiff and getting someone to review and upload it for you
<Whoopie> siretart: ok
<Kmos> grep: debian/control: No such file or directory
<Kmos> /usr/bin/pkgstriptranslations: Error: not in source package directory
<Kmos> EtienneG: pbuilder-satisfydepends failed.
<Kmos> not EtienneG but E:
<Whoopie> siretart: what if I want to add the patch to a debian/patches directory? any changes needed for debian/rules. because last time, I think, it got lost because it was applied "inline".
<siretart> Whoopie: please fix the package with minimal intrusion. this mean try to keep the debdiff as small as possible
<Kmos> geser: pbuilder gives me that error now..
<geser> hmm
<Kmos> i've it installed and set enable to true
<Kmos> pbuilder updated
<geser> I've enabled pkgstriptranslations too but pbuilder still works for me
<Whoopie> siretart: f*, please remove gutsy, it's applied. sorry for the inconvenience.
<Kmos> really strange
<siretart> Whoopie: you should be able to do that yourself. please add a meaningful comment for that
<DaveMorris> I'm still looking for someone to revu my package - http://revu.tauware.de/details.py?package=libserial  All previous comments have been adressed
<chazco> Is glibc (>=2.2.5) a valid depend?
<geser> no, as glibc is the source package name
<chazco> Ah ok...
<chazco> Trying to write a Depends line for the vague requirements of: glibc 2.2.5 or higher, X Window system with any Window Manager
<man-di> chazco: forget about that, dh_shlibdeps will generate depends needing newer glibc anyway
<\sh> moins
<\sh> crimsun: what do I had to read on p.u.c. you are stepping down?
<Legendario> hi. is anyone here from both motu and doc teams?
<jpatrick> Legendario: I contribute to both, what's up?
<Legendario> hi. I would like to translate the packaging guide to portuguese
<Legendario> is there a way to do it using launchpad?
<jpatrick> Legendario: yes, sorry, I was doing somethin
<Legendario> it's ok
<Legendario> so. how can i do it?
<bluekuja> Legendario, I'm not really sure it's available for translation in LP
<jpatrick> Legendario: the packguide is maintained at the wiki
 * joejaxx wonders how much work it would be to package kde from scratch
<bluekuja> hellboy195, around?
<bddebian> Heya gang
<joejaxx> bddebian: !
<joejaxx> :D
<bddebian> Hello joejaxx
<joejaxx> anyone know how packaged the kde packages originally?
<joejaxx> bddebian: :)
<broonie> joejaxx: The bottom of the changelo for kdelibs says Adreas Jellinghaus
<joejaxx> oh ok
<joejaxx> hmm
<geser> Hi bddebian
<bddebian> Hi geser
<Hattory> Legendario, the translation of the packaging guide was available with dapper: https://translations.launchpad.net/ubuntu/dapper/+source/ubuntu-docs/+pots/packagingguide/pt/+translate
<geser> broonie: Hi, have you had time to look at the aqsis build failure? Is it a problem with aqsis or scons? (the problem was that it got caught in a loop)
<jpatrick> Hattory: but that's Dapper :p
<Hattory> I know... jpatrick..... just to see that it was on Launchpad
<Hattory> :)
<jpatrick> Hattory: must be so outdated
<Legendario> do you guys know if the version listed on the doc.ubuntu.com as work in progress is to different from the dapper one? Hattory, do you have the link for this one?
<pochu> dholbach: thanks a lot!
<Kmos> pochu: greetingz :)
<pochu> Thank you Kmos :)
<Hattory> jpatrick, why wasn't it update anymore?
<jpatrick> Hattory: it's moved to the wiki
<ScottK2> pochu: Congratulations.
<mruiz> pochu, great news! congrats ;-)
<jdong> pochu: wow congrats, though I thought you were a MOTU for like a year :D
<Hattory> pochu,  congrats ;)
<pochu> Thanks ScottK2 mruiz jdong and Hattory! :)
<tuxmaniac> hi guys. now the package builds on pbuilder hardy base. request someone to please review and comment. http://revu.tauware.de/details.py?package=alliance
<ion_> Could i get a second advocation for http://revu.tauware.de/details.py?package=hardware-connected (a program that checks whether given hardware is connected to the system, useful for scripting)? Thanks.
<pfein> is there anyway to tell debbuild not to sign a package?  Building a local upgrade, don't have my key on the server...
<jdong> pochu: probably by passing in -us -uc
<jdong> oops pfein
<pfein> jdong: yup, thx
<rexbron> If a piece of code is licenced under the lgpl and you compile it with --enable-gpl such that the resulting binaries are gpl, should debian/copyright reference the LGPL, GPL or both?
<mdomsch> I'd think both
<rexbron> Ok, i'll put in a "source licenced under" and "binaries"
<unenough> Hi, I am trying to build the python2.5 package via "debian/rules binary" inside the source, but its running all of the regression tests, and that takes _ages_
<unenough> any way to disable the regression tests?
<azeem> unenough: export DEB_BUILD_OPTIONS=nocheck
<azeem> will still run the benchmarks, though
<slangasek> ScottK2: were you following up with the Debian maintainer about bug #154730 as requested by seb128?
<ubotu> Launchpad bug 154730 in secvpn "Please remove secvpn source and binary from Hardy" [Wishlist,Incomplete] https://launchpad.net/bugs/154730
<unenough> azeem, Thanks!
<unenough> azeem, any way to cancel the benchmarks too?
<azeem> dunno
<azeem> look inside debian/rules, comment it out if it's a seperate command
<unenough> K, I'll hope for now that the benchmarks are not as long as the regression tests
<ScottK> slangasek: It's on my "list", but I haven't actually done it yet.
<slangasek> ScottK: ok
<bddebian> slangasek: newpki-client builds now, I think that just leaves ctsim with wx2.4?
<slangasek> I dunno, I haven't been following the progress
<bddebian> Well you're fired :)
<bddebian> I'd work on the vflib stuff if I really understood the issue :(
<ScottK> bddebian: When has that ever stopped you before? ;-)
<bddebian> ScottK: Never, but thanks for pointing that out :-)
<DaveMorris> my cdbs rules file has 1 big target which is independent (doc from doxygen) of the other targets.  Is there anyway to have it run in a separate thread from the rest of cdbs, thus making use of dual core systems?
<ScottK> No.
<DaveMorris> shame
<ScottK> There is work in progress on parallel builds in Debian, but nothing production ready yet.
<DaveMorris> would save me around an hr
<ScottK> If you look in (I think it was) the debian-devel mail list archives for parallel build, there was a recent thread on the topic.
<Kmos> The package libfontbox-java in hardy shouldn't be in multiverse? it needs checkstyle package that's in multiverse
<Kmos> ?
<man-di> the question is: why is checkstyle in universe when its in main for Debian
<man-di> multiverse I mean, sorry
<Kmos> :)
<man-di> ubuntu names...
<Kmos> man-di: that's also a good question
<man-di> well, checkstyle was moved from contrib to main some long time ago...
<ScottK> And it looks like no one ever touched it in Ubuntu to move after the tarball got repacked
<Kmos> I'll fill a bug about this to move it to universe..
<slangasek> ScottK: well, one can certainly configure one's own package build rules to support parallel building in line with the d-d discussion, and invoke the package build accordingly on one's own system
<slangasek> since he seems to be concerned with saving his own time, not the buildd's :)
<ScottK> True.
<ScottK> DaveMorris: ^^^
<dannioni> I was talking earlier this afternoon of merging our flightgear with debians, should I do this even though we've passed DebianImportFreeze?
<ScottK> Are there any changes in Debian's version we don't have that are worth having?
<dannioni> I havn't gone through that yet, as I wasn't sure of what to do i wanted to check first
<ScottK> Judgement call at this point
<ScottK> Go mok0! (Just saw your Debian ITP for Mustang)
<dannioni> We're at verion 9.10 and they're at 1.0. I went through the changelogs and there's a lot we're missing
<mok0> ScottK: Heh! It's my first try
<ScottK> dannioni: I'd go for it then.
<mok0> ScottK: ... and part of my MOTU training...
<ScottK> Excellent
<dannioni> ok, thanks for the advice, needs to be done sooner or later anyways
<ScottK> slangasek: I'm curious if you saw my perl-module post on ubuntu-devel and if you have an opinion?
<mok0> Started using git-buildpackage today. Pretty nifty, but it has some quirks
<emgent> hi astharot ;)
<mok0> dpatch has the annoying habit of touching the files in debian/patches, which means git thinks they have been modified...
<slangasek> ScottK: yes, seen; I think dropping those modules from perl-modules and making them a dep appears to be the correct course of action, but since this is apparently a MIR I'll leave it to others like pitti to dredge up any concrete objections
<ScottK> K.  Thanks.
<astharot> re
<mok0> Anyone else here has experience with git-buildpackage?
<mok0> s/has/have
<ion_> mok0: Iâm using it.
<ScottK> mok0: I know lamont (on ubuntu-devel/server) uses Git.  Dunno if he uses that.
<mok0> ion_: How do you handle upstream updates?
<jharr> Hello
<ScottK> Hello
<mok0> ion_: Do you untar it on the upstream branch?
<mok0> ion_: or create a new one?
<jharr> Say I have samba-3.0.26a, which is having problems, but I want to do a quick build of 3.0.28, what's the quickest way to swap out the old .orig source for the new?
<ion_> mok0: If upstream doesnât use git in the first place, you should be able to use git-import-orig to import the source to a git repo. Then just merge the changes from the upstream branch to the ubuntu branch, update the packaging and use git-buildpackage as usual.
<AnAnt> Hello
<AnAnt> is Emmit Hikory here ?
<AnAnt> bddebian: hide
<ScottK> AnAnt: He goes by persia
<AnAnt> ah, so he's persia
<mok0> ion_: do you have to be sitting on the upstream branch, or will git-import-orig do that for you?
<AnAnt> persia: Hello, thanks for reviewing the ubuntume artwork packages
<ion_> mok0: Look at its man page.
<mok0> ion_: :-)
<AnAnt> man-di: Hello, I ran josm using icedtea jre under i386, it didn't work so well
 * mok0 feels stupid
<ion_> mok0: It has defaults for the upstream and packaging branches, but you can override them with e.g. a .gbp.conf in the packaging branch root.
<LaserJock> man I love Ubuntu!
<mok0> ion_: might as well stick to the default for now... I have no better scheme anyway
<ion_> For instance, http://gitweb.heh.fi/?p=ion/hardware-connected.git;a=blob;f=.gbp.conf;hb=ubuntu
<jcastro> LaserJock: glad you think so, consider sticking around and getting involved!!
<jcastro> :p
<slangasek> jharr: like grabbing the 3.0.28 package for hardy directly from the Ubuntu archive and rebuilding it with dpkg-buildpackage -B?
<mok0> ion_: cool
<mok0> ion_: I guess you can run pbuilder as well from there
<man-di> AnAnt: file a bug report
<AnAnt> man-di: ok
<LaserJock> jcastro: I just got the uni VPN working with Network Manager
<man-di> AnAnt: note that icedtea is a pre-version of what will be Java7
<ion_> mok0: Perhaps. I havenât checked.
<AnAnt> man-di: btw, did you tried icedtea firefox plugin on an amd64 ubuntu ?
<mok0> ion_: I thought gbp.conf went in .git/
<man-di> AnAnt: no
<ion_> mok0: Again, look at the man page. You can put it in .git if you donât want it to go to the repository.
<ScottK> AnAnt: man-di is a Debian user, not Ubuntu.
<AnAnt> oh
<man-di> well, I have Ubuntu chroots for some testing
<AnAnt> man-di: so, you made an icedtea package for Debian this week ?
<mok0> ion_: ok
<man-di> yes, I work in icedtea package (which is the same as for Ubuntu)
<cyberix> Should I use debian-maintainer field even when the package does not exist in Debian?
<AnAnt> man-di: thanks
<mok0> ion_: Are you in Finland?
<AnAnt> ok, I have a question, I was asked to close a bug for initial release, is there something like ITP bug in Ubuntu ?
<ScottK> cyberix: Yes (generally).
<ion_> mok0: Yep.
<ScottK> AnAnt: bug tagged 'needs-packaging'
<mok0> ion_: Perkele! :-)
<AnAnt> ScottK: ok,  I should file the bug against what ?
<ScottK> Against Ubuntu
<ScottK> i.e. No package
<slangasek> mok0: is this how you greet all Finns?
<AnAnt> ok
<mok0> slangasek: I don't think so :-)
<mok0> slangasek: It's a swearword AFAIK
 * ScottK starts to wonder what that meant.
<slangasek> yes, it is a swear word
<cyberix> ScottK: Is this explained somewhere?
<mok0> slangasek: not rude I hope
<slangasek> so "Are you in Finland?" "yes" "perkele!" is kinda strange
<ScottK> cyberix: I'm sure it's in wiki.ubuntu.com somewhere.  Dunno where as stuff was recently re-arranged.
<mok0> slangasek: It's the only finnish word I know... apart from yksi kaksi kolme
<AnAnt> ScottK: what does X licensed code mean ? it was on a comment on http://revu.tauware.de/details.py?package=usplash-theme-ubuntume
<mok0> slangasek: are you finnish too?
<ScottK> AnAnt: From what it says, I'd say there's a thing call the "X License" and there's code in your package licensed under it and you didn't mention it in debian/copyright.
<ScottK> AnAnt: grep -ir copyright * is your friend.
<slangasek> mok0: no, just a polyglot
<mok0> slangasek: you speak finnish? I'm impressed!
<slangasek> mok0: I only know a few key phrases in Finnish
<AnAnt> ah, ok
<AnAnt> can any LP user have access to LP's Vcs ?
<bddebian> Like "where's the beer?"
<slangasek> like "hyvÃ¤Ã¤ huomenta" and "vittu perkele"
<mok0> slangasek: gonna tell us what that means?
<slangasek> nope :)
<mok0> Google's my friend
<slangasek> indeed
<LucidFox> slangasek> Thanks for moving libhiglayout-java and freecol!
<LucidFox> You are an archive administrator, I presume?
<slangasek> yep
<mok0> slangasek: you are bad!
<mok0> :-)
<slangasek> mok0: I prefer to think of myself as "authentic"
<LucidFox> Do you manage NEW? Because I'd like to get mpeg4ip into Hardy ASAP
<cyberix> I should not use XSBC-Original-Maintainer?
<slangasek> LucidFox: I do, but you'll have to wait your turn :)
<LucidFox> ah
<ion_> Is the NEW queue visible for the public somewhere, btw?
<LucidFox> http://launchpad.net/ubuntu/hardy/+queue
<ion_> Thanks
<mok0> vittu perkele saatana!
<slangasek> not to be confused with the Finno-Latin fusion group, "vittu perkele santana"
<ScottK> cyberix: Generally for packages new to Ubuntu and not in Debian, put yourself in that field if you are packaging it.
<mok0> slangasek: lol
<LaserJock> ScottK: if you have an @ubuntu.com address
<AnAnt> ScottK: so for packages that are not in Debian, I put myself in both Maintainer: & XSBC-Original-Maintainer: fields ?
<LaserJock> AnAnt: no, you wouldn't need XSBC-Original-Mantainer if you're setting yourself as Maintainer
<AnAnt> LaserJock: ok, what does that comment mean "Please use an Ubuntu maintainer. If nobody on the team is an Ubuntu member, consider applying for a mailing list for the team" on http://revu.tauware.de/details.py?package=usplash-theme-ubuntume ?
<LaserJock> well
<LaserJock> Maintainer requires either an @ubuntu.com address *or* an Ubuntu mailing list (ubuntu-motu for Universe)
<slangasek> which is to say, everything should have a *@*ubuntu.com email address as the Maintainer
<AnAnt> ok, so what should I do ?
<LaserJock> AnAnt: do you have an @ubuntu.com email address?
<AnAnt> put myself in Maintainer: and ubuntu-motu list in XSBC .... ?
<AnAnt> LaserJock: nope
<LaserJock> reverse it then
<pochu> AnAnt: the other way round
<LaserJock> ubuntu-motu as Maintainer and yourself as XSBC....
<AnAnt> pochu: ok
<pochu> AnAnt: have you considered uploading this to Debian too?
<AnAnt> pochu: it's Ubuntu specific I think, it's artwork for a distro based on ubuntu, why put that in Debian ?
<pochu> heh, nevermind then :-)
<AnAnt> ok
<AnAnt> thanks for the help guys
<AnAnt> what's the name part of Maintainer: ?
<AnAnt> I mean what's the name part of ubuntu-motu mailing list ?
<jpatrick> Ubuntu MOTU Developers
<LaserJock> https://wiki.ubuntu.com/DebianMaintainerField says Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com> for the field
<AnAnt> thanks
<AnAnt> what's FTBFS stands for ?
<jpatrick> Fails to build from Source
<AnAnt> ok
<AnAnt> ok, one last thing (I hope), I'm doing a usplash theme
<mok0> AnAnt: https://wiki.ubuntu.com/UbuntuDevelopment/Abbreviations
<mok0> AnAnt: I keep that page open when in this channel :-)
<AnAnt> when I look at usplash-theme-ubuntu, I find that the C file is GPL licensed, yet in debian/copyright I only find a CC license
<AnAnt> I did the same with my usplash theme, and the reviewers didn't like that
<wallyweek> hi all! :)
<slangasek> AnAnt: what do you mean, "find" a CC license? it's your package, surely you're responsible for the contents of debian/copyright?
<AnAnt> let me ask this question first, can the .c file of a usplash theme be licensed under CC ?
<AnAnt> slangasek: I'm talking about what I saw in Ubuntu's usplash theme package, hence I did similar in the usplash theme I was packaging
<slangasek> legally, yes; but debian/copyright needs to reflect the actual license of the package (and CC licenses aren't as good for source code as GPL, anyway)
<wallyweek> could anyone review sdlmame? it would be nice to see it in hardy :)
<wallyweek> http://revu.tauware.de/details.py?package=sdlmame
<AnAnt> slangasek: well, in usplash themes, there are image files (.png) and a C file that calls them
<AnAnt> slangasek: so I think in that case, the C source code can be considered some artwork more than it is a software
<slangasek> AnAnt: debian/copyright still needs to reflect the actual license that the software has been placed under by the copyright holders
<AnAnt> slangasek: ok
<AnAnt> thanks for the help
<bddebian> Did libwxgtk-2.4 have a wxgtk-2.4-config that libwxgtk-2.6 doesn't?
<cyberix> Is there a Debian-Maintainer filed which is separate from XSBC-Original-Maintainer ?
<cyberix> field
<cyberix> Even apt uses XSBC-Original-Maintainer
<astharot> is there some ubuntumembers administrators on launchpad?
<astharot> I have a question about my membership
<slangasek> bddebian: how did you put together whatever list you're using of wxgtk2.4 reverse-deps?
<bddebian> slangasek: I've just been using what was sent on the oldlibs e-mail so far
<bddebian> I think gnue might still be an issue too iirc
<slangasek> bddebian: url?
<slangasek> n/m, found it
<wallyweek> anyone to review my package, please? http://revu.tauware.de/details.py?package=sdlmame
<unenough> yay! Almost got a Python2.5 package that puts .pyc's in another cache directory, rather than messing the source dir, and that treats .pyc's as purely cache, does not use them as sources when the .py's not there
<geser> unenough: don't install .pyc files in your package
<bddebian> Grr, I can't get ctsim to even attempt to build with wx2.6 :(
<bddebian> persia: Wake up man.. :)
<unenough> geser, for now its just a temporary local hack for me and friends
<unenough> geser, if it becomes more serious, there are some issues to handle, such as having a system-wide cache dir to search first
<slangasek> bddebian: that's ok, if that's really the last package and the maintainer/upstream is being obstructionist, we can just pull wxwindows2.4 out of unstable out from under him
<geser> unenough: why do you want to have the .pyc file inside the package?
<bddebian> slangasek: Well persia said he got it to build, he just had the sefault issue, which may have been a similar wx-config issue
<bddebian> And, of course, I don't know if the newpki-maintainer is going to accept my patch either
<slangasek> bddebian: then we would have two packages that are SOL in unstable due to daft maintainers. <shrug>
<slangasek> especially when the code has already been written to move to wx2.6, there's no reason at all for us to keep wx2.4 around
<bddebian> You're the boss :-)
<wallyweek> come on, is revu day! no reviewers online? ;)
<amarillion> What does a good get-orig-source rule look like? Would something like this be ok? http://paste.ubuntu-nl.org/51135/
<amarillion> btw, what does SOL mean?
<wallyweek> amarillion: you should also rename the directory before recompressing and delete the .zip and the extracted directory
<wallyweek> after building the tar.gz
<amarillion> I though the name of the directory is ignored by all utilities
<wallyweek> amarillion: well, to be honest, I don't know... :) the packaging guide suggest to normalize the dir name
<amarillion> ok, I'll do it just to be safe
<wallyweek> I also pasted my suggestion on the pastebin... didn't know I could ;)
<amarillion> so I need to add "mv speed speed-game-1.00" and rm "speed.zip", probably "rm -r speed-game-1.00" afterwards as well
<wallyweek> yes
<amarillion> oh I didn't know that either. Do you get a new link for that? I don't see it yet
<wallyweek> should be http://paste.ubuntu-nl.org/51137/
<wallyweek> I didn't notice the link was changed
<amarillion> Ah yes, I could have just have incremented the number twice
<amarillion> thanks for the suggestions
<wallyweek> you're welcome :)
<stgraber> http://revu.ubuntuwire.com/details.py?package=libfprint is ready for a review if someone has time
<wallyweek> and so is http://revu.tauware.de/details.py?package=sdlmame, thanks :)
<guest22> While we're on review requests, let me add one for http://revu.tauware.de/details.py?package=photoml  It's already been advocated once (the previous upload, at least), so it should be very close to being acceptable.
<amarillion> I just updated my package: http://revu.tauware.de/details.py?package=speed-game. All comments made yesterday have been addressed, except the license clarification because I'm still waiting for an answer from upstream
<amarillion> And I learned everything there is to know about hiscore files in the process :)
<persia> bddebian: Sorry.  Slow today :)  There was a wx-2.4-config, but wx-config should replace it.  ctsim worked for me in early gutsy, but segfaulted on execute.  I haven't looked since.
<bddebian> persia: With no changes other than the build deps?
<persia> bddebian: By memory, yes.  I appear to have removed my ctsim working directory, and as I never had a working patch, didn't generate anything for my patch archive.
<wallyweek> persia: I would ask to nuke http://revu.tauware.de/details.py?package=shorten
<wallyweek> as norsetto pointed out, licence is quite uncomfortable and I'd like to stop packaging it
<persia> wallyweek: I seem to be having difficulty nuking lately.  Would archiving meet your needs?
<wallyweek> persia: it doesn't matter to me... ehr... what's the difference, btw? ;)
<persia> wallyweek: Archiving hides it from the default listings.  Nuking removes the package and all comments from REVU entirely.
<persia> In case of later interest, you can recover from an archive with a new upload.
<persia> wallyweek: shorten archived
<amarillion> wallyweek, can that package not be included?
<wallyweek> persia: thanks!
<amarillion> Too bad, after all that work
<persia> amarillion: Since the original packager no longer wishes to continue, feel free to grab it, work with upstream to resolve the licensing issues, and submit a new candidate, if you have interest in the package.
<wallyweek> persia: licence is weird... it says it's free to decode, but permission should be asked for encoding
<persia> wallyweek: Might be related to some of the encoding patents that are floating about. (not that I've investigated)
<minghua> a.k.a. rar license?
<wallyweek> persia: yes. Shorten is not a free codec, even if opensource
<wallyweek> I could patch the source, but I feel this would not be good
<persia> That makes sense then.  I suppose a decoder-only could be packaged, or a use-specific patent grant could be given (which would make it multiverse).  Needs coordination with upstream .
<wallyweek> persia: unfortunately, original upstream maintainer doesn't care about original code
<wallyweek> new releases are carried on by another guy, which has no rights to modify original code licence
<persia> wallyweek: Right.  Needs coordination with the copyright holder / patent controller / whatever, if upstream isn't that party.  Upstream can maybe help with that (although you may not be the person who works with them to achieve the goal).
<wallyweek> amarillion: if you find shorten useful, you can download package from my ppa https://launchpad.net/~c.falco/+archive
<amarillion> wallyweek, oh I don't really have a personal interest, I was just reading the comments page on REVU
<amarillion> Seeing all the comments, a fair bit of work went into it
<wallyweek> amarillion: yes... but that was good learning anyway ;)
<amarillion> true
<persia> Also, it's likely that much less work for someone else, if they pick up the packaging effort.
<wallyweek> persia: true
<amarillion> I was reading a few comments pages on REVU. Some packages go through dozens of revisions
<persia> This is especially true for very complex packages, with lots of upstream problems.  Most reviewers stop looking carefully when reaching some threshold of comments (for me, around 10).
<amarillion> makes you wonder how we ever got to tens of thousands of packages that are in ubuntu now
<wallyweek> amarillion: yes, sometimes it's quite frustrating... sdlmame has been on REVU since feb 2007
<persia> Only about 500 came thorugh REVU.  Most are imported from Debian.
<wallyweek> persia: good answer... I wondered the same :)
<amarillion> true, but I understand the process for inclusion in Debian even longer
<DaveMorris> mine has had loads of revions
 * DaveMorris cruses OpenSG
 * DaveMorris can't spell this evening
<wallyweek> before going to bed, let me call once again for reviews on http://revu.tauware.de/details.py?package=sdlmame
<wallyweek> thanks :)
<LaserJock> anybody familiar with pbuilder-dist around?
<LaserJock> I'm trying to create a pbuilder and I just get:
<LaserJock> E: Type '' is not known on line 1 in the source list /etc/apt/sources.list
<TheMuso> jdong: Have you seen this aac encoder? http://teknoraver.campuslife.it/software/mp4tools/
<nenolod> persia, patch accepted upstream. http://bugzilla.gnome.org/show_bug.cgi?id=507605
<ubotu> Gnome bug 507605 in recent-files "[patch] gtk_recent_files_menu_populate() does not guard properly against recursion" [Critical,Unconfirmed]
<TheMuso> jdong: specifically aacplusenc
<nenolod> TheMuso, that's a new one
<TheMuso> I know
<jdong> TheMuso: yet another mp4 encoder
<TheMuso> Yeah I know. Does anybody know how it compares to faac?
<jdong> TheMuso: pretty sure it uses faac?
<nenolod> jdong, no
<TheMuso> jdong: doesn't appear to.
<nenolod> jdong, it uses it's own encoder
<nenolod> TheMuso, i'll play with aacplusenc tonight
<jdong> lemme grab the sources before opening my mouth...
<nenolod> TheMuso, it'd be nice to have a decent aac encoder in hardy
<wallyweek> g'night everyone! :)
<amarillion> goodnight
<jdong> yeah, looks interesting
<nenolod> hmm
<jdong> would be nice to put it too the test
<nenolod> the ubuntu packages are incorrect
<jdong> to*
<nenolod> they'll have to be redone
<jdong> nenolod: you don't say? ;-)
<TheMuso> aacplusenc doesn't tag however
<nenolod> (they are packaged as a native archive)
<jdong> TheMuso: tagging is trivial via gpac/MP4Box though
<jdong> TheMuso: I'm more interested in its encoding abilities
<nenolod> TheMuso, that's fairly trivial
<TheMuso> jdong: Same.
<nenolod> if you want to tag it, you can always open it in audacious or whatever
<TheMuso> jdong: One thing I found out is that from reading an ubuntuforums thread, it doesn't work properly on amd64.
<nenolod> TheMuso, i can fix that
<jdong> TheMuso: yeah I was seeing that in the makefile
<TheMuso> http://ubuntuforums.org/showthread.php?t=628434&highlight=aac
<nenolod> TheMuso, also passed it onto gentoo-media team, so maybe we can collaborate on it together ;)
<jdong> TheMuso: it looks immature but promising
<TheMuso> Cool.
<TheMuso> jdong: In the makefile?
<nenolod> most amd64 bugs are due to bitwidth oversight
<nenolod> by using stdint.h, it's not a major issue
<nenolod> :P
<TheMuso> heh
 * TheMuso cranks it through powerpc
<TheMuso> compilation that is
<nenolod> (you can also do int foo : 4; to make a 32-bit int)
<jdong> nenolod: looks like this thing uses x86 assembly a bit... afraid it won't be that easy
<nenolod> jdong, yuck
<TheMuso> Great. So PowerPC is out of the question then. :)
 * TheMuso grumbles./
<TheMuso> Userspace apps should not use asm unless they are arch specific IMO.
<jdong> #ifdef __LP64__
<jdong>   if (inputInfo.nChannels > 1) {
<jdong>     fprintf(stderr, "Stereo encoding is not supported in 64 bit builds
<jdong> ");
<jdong> whee!
<jdong> lol
<TheMuso> SOunds like the code is hackish.
<jdong> TheMuso: well IMO media apps have the right to drop down to assembly
<nenolod> jdong, where's the asm?
<jdong> TheMuso: often times their hand-tuned assembly turns in 30% minimum speedi mprovements
<TheMuso> jdong: I doubt that not, but they should get help for other arches then. IMO all arches should benefit.
<TheMuso> I know PowerPC is dying, but many people still use it, myself included/
<nenolod> i don't see any x86 asm
<TheMuso> Hrm ok. It builds on PowerPC.
<nenolod> yeah
<TheMuso> nenolod: You're right, I don't think there is any asm specific stuff.
<nenolod> as i said
<jdong> nenolod: you're right no ASM
<nenolod> "i don't see any x86 asm"
<nenolod> well
<jdong> nenolod: I saw the ADD/MULT/MOVE macros and got worried
<nenolod> jdong, i'll import this into some bzr branch
<jdong> looks like it's just some sort of hackjob profiling
<jdong> eep.
<nenolod> jdong, that's right. i intend to fix it.
<nenolod> :D
<TheMuso> nenolod: gogogogogogo
<nenolod> also, no autoconf = wtf
<TheMuso> Oh, and its built statically.
<TheMuso> nenolod: Not everything needs autotools.
<slangasek> sure it does, just not everything uses autotools ;)
<nenolod> TheMuso, autotools would be good for this ;p
<jdong> I'd rather not see autotools :D
<TheMuso> Well, it would make turning those libs into shared libs easier.
<TheMuso> :)
<jdong> nenolod: also chase through the changelog, I saw a few cases where the author references switching from his own to some GPL'ed routines
<jdong> nenolod: wonder if he is bundling a bunch of unneeded routines or if they'rej ust single functions
<TheMuso> What is the Nero aac encoder like?
<nenolod> it seems to encode stereo just fine on 64-bit
<nenolod> although mplayer is having problems with it
<nenolod> but mplayer has problems with SBR anyway
 * jdong looks at mpeg4ip
<jdong> nope still in NEW
<TheMuso> jdong: What package is mp4box in?
<jdong> TheMuso: gpac
<TheMuso> oh ok
<nenolod> hmm
<nenolod> weird
<nenolod> it does indeed produce crap on amd64
<jdong> yay!
<jdong> I'm surprised the author hasn't just passed -m32 into gcc
<jdong> lol
<nenolod> (crap when done with stereo. so i think it's a bitwidth bug somewhere.)
<nenolod> i imagine sed -i s:unsigned int:uint32_t:g s:int\s:int32_t:g will do.
<nenolod> maybe he uses sizeof
<ScottK> LaserJock: Was it a Debian pbuilder you were making?
<ScottK> If so, I had the same kind of problem.
<ScottK> I just hacked stuff out of the script until it went away.
<jdong> nenolod: unless there's hardcoded bitmasks that are different on x64
<nenolod> jdong, maybe. we'll see.
<jdong> :)
<LaserJock> ScottK: no, hardy
<LaserJock> I just rand pbuilder-dist hardy create
<ScottK> Did you have universe enabled?  When I had the problem on Debian ones it was getting confused about extra repos and then I got that error when I removed them.
<LaserJock> I tried it as both pbuilder-dist hardy allcomp create and pbuilder-dist hardy mainonly create I think
<TheMuso> Ok this encoder also doesn't accept high bitrates.
<joejaxx> anyone else having packaging issues with kde4 packages in gutsy?
<joejaxx> i know kde4 is "beta" but packaging is packaging :P
<LaserJock> joejaxx: where are you getting the packages?
<joejaxx> well the ones that i did today were from backports
<joejaxx> http://pastebin.ca/845932
<joejaxx> looks like fun :D
<joejaxx> does it not?
<joejaxx> :)
<minghua> ScottK: Is Debian affected by the "needed perl module version is higher than the one in perl-modules" problem?
<LaserJock> joejaxx: well, seems somewhat typical :/
#ubuntu-motu 2008-01-08
<joejaxx> LaserJock: why? :\ that violates debian packaging policy does it not?
<ScottK> minghua: I would imagine so, but I haven't looked to see if stuff if failing to build there or not.
<ScottK> minghua: Situation should be identical.
<joejaxx> hello ScottK minghua
<ScottK> In particular, their version of mime-tools doesn't have the same dependency as the newer one that just FTBFS for me.
<minghua> joejaxx: Not necessarily.  What is your kde4base-data version?
 * ScottK runs off to dinner.
<minghua> ScottK: Let me have a look.
<minghua> ScottK: Do you have another example (that builds arch:any packages)?  Mime-tools is arch:all.
<LaserJock> joejaxx: has that stopped people before? ;-)
<joejaxx> LaserJock: transitional packages and conflicts are nice :)
<joejaxx> minghua:   Installed: 3.94.0-0ubuntu1
<TheMuso> jdong, nenolod, first tests with a basic headset and a jazz trio track reveal some mushiness. I need to encode a track with iTunes, faac, and have an uncompressed version as well to do some real testing with my good headphones.
<joejaxx> LaserJock: yeah but it werid to me to see that lol :P
<joejaxx> LaserJock: weird*
<joejaxx> that is one of the reasons i have not uploaded a -settings package
<minghua> joejaxx: I wonder if there is any versioned conflicts/replaces between kde4base-data and other packages.
<joejaxx> because packages are not supposed to do that
<joejaxx> minghua: i wish there was
<joejaxx> but it would want to remove those packages if it did
<minghua> joejaxx: So you checked there wasn't?
<joejaxx> Replaces: kdelibs5-data (<< 3.93.0-0ubuntu1~ppa1), kde4multimedia-data (<< 3.93.0-0ubuntu1~ppa1)
<joejaxx> Conflicts: kde4multimedia-data (<< 3.93.0-0ubuntu1~ppa1)
<joejaxx> wth is ppa doing in there?
<minghua> joejaxx: You are installing an auto-backported package, versioned relations may well be broken.
<minghua> Well...
<joejaxx> stuff in -backports is automatically backported?
<joejaxx> lol wth?
 * minghua checks the hardy version.
 * LaserJock hands joejaxx some wth pills ;-)
<minghua> joejaxx: auto-backported after manual checking/confirming.
<joejaxx> it seems hacky for us to be doing that lol
<joejaxx> minghua: sure :)
<LaserJock> joejaxx: umm, that's backports
<joejaxx> LaserJock: that stinks :\
<minghua> Hah.  There is *no* hardy version of kde4base.  It must have been backported from PPA. :-)
<joejaxx> :(
<joejaxx> i thought that was the whole point of the debian packaging policy
<joejaxx> to stop things like this from happening
<joejaxx> lol
<joejaxx> not to go around it :\
<LaserJock> I get kde4 from ~kubuntu-members-kde4 PPA
<joejaxx> yeah
<LaserJock> but it's got some issues still presently
<joejaxx> the archive should be in a more stable state than a ppa :P
<joejaxx> package wise
<joejaxx> since it is official :D
<LaserJock> well, it's -backports
<LaserJock> there's only like a couple people that work on it
<minghua> joejaxx: I think you need the 3.95.0-0ubuntu1~gutsy1 version of kde4base-data in -backports for everything to work properly.
<minghua> joejaxx: However it currently FTFBS.
<joejaxx> LaserJock: i do not know what to say :(
<minghua> If you don't like the status of -backports, join the team to work on it. :-)
<joejaxx> lol i am not motu :(
 * minghua personally won't touch -backports without a pole.
<LaserJock> joejaxx: it doesn't take being a motu
<minghua> You don't need to be an MOTU to work on -backports.
<minghua> Just ask jdong. :-P
<joejaxx> minghua: i am more worried about the DPP and the state of the archive's integrity
<joejaxx> :\
<minghua> DPP?
<LaserJock> hehe
<joejaxx> debian packaging policy
<LaserJock> there are way bigger issues than a FTBFS and a slightly broken package to worry about
<minghua> Oh.  It's usually called just "Debian Policy".
<joejaxx> oh ok
<LaserJock> it just needs to get fixed, that's all
<LaserJock> happens all the time
<joejaxx> lol
<minghua> We still get "can't install, broken dependencies" bugs against gutsy once in a while, and don't have enough manpower to fix them, let alone gutsy-backcports.
<LaserJock> joejaxx: check out http://qa.ubuntuwire.com/debcheck/ for instance
<Hobbsee> TheMuso: ping
<TheMuso> Hobbsee: pong
<joejaxx> LaserJock: :(
 * Hobbsee wishes they wouldn't automatically crackport kde4.
<joejaxx> Hobbsee: :)
<Hobbsee> heya joejaxx!
<LaserJock> well, there's KDE4 packages flying everywhere
<joejaxx> hi
<LaserJock> it's hard to know what to use
<joejaxx> official repos! :D
<joejaxx> lol
<Hobbsee> LaserJock: not crackports.
<joejaxx> lolol
<Hobbsee> LaserJock: kde4 ppa is better, iirc
<joejaxx> will it fix my broken package system ? :D
<joejaxx> lol
<azeem> huh, I've been reading `crackpot' all the way
<joejaxx> azeem: LOL
<joejaxx> ah interesting
<LaserJock> joejaxx: well, kinda
<joejaxx> the launchpad buildds remove packages
<joejaxx> where is this magically package fixing ppa?
<joejaxx> :(
 * joejaxx is not going to use his ppa until the remove package option is implemented :D
<joejaxx> :P
 * joejaxx is bored
<joejaxx> :(
<LaserJock> joejaxx: what the heck are you talking about?
<joejaxx> the kde4 ppa
<joejaxx> that everyone is talking about
<LaserJock> should be https://launchpad.net/~kubuntu-members-kde4/+archive
<LaserJock> but it's not all the way updated yet, but it does seem to work a bit better
<joejaxx> gah
<LaserJock> joejaxx: what are you wanting to install?
<joejaxx> kde4
<LaserJock> well, how much of it?
<joejaxx> just the DE
<LaserJock> well, you can probably just do kdebase then
<joejaxx> yeah i really do not know what to install package wise i just followed the instructions on the kubuntu website
<LaserJock> http://kubuntu.org/announcements/kde4-rc2.php ?
<joejaxx> i have not used kde since version 1.0
<joejaxx> no not that one there was another one
<LaserJock> I think the link I gave is the latest and probably best to go on
<joejaxx> yeah
<joejaxx> bah
<joejaxx> i need to for apt to remove these packages now
<joejaxx> force*
<joejaxx> fun
<joejaxx> hello minghua
<joejaxx> MatthewV: *
<MatthewV> hi joejaxx
<ScottK> minghua: How about libmail-box-perl
<joejaxx> oh perl
<joejaxx> :)
<joejaxx> perl is fun
<ScottK> minghua: Oops.  That's arch all too
<ScottK> joejaxx: You got the first two letters right.
<joejaxx> LOL
<joejaxx> bah
<joejaxx> this is hacky
<jscinoz_> persia are you here?
<minghua> ScottK: Right. So there were never built in sbuild for Debian.
<ScottK> OK.  So it won't hit Debian until it hits an arch:any package?
<slangasek> in terms of sbuild, yes
<jscinoz_> hmm
<jscinoz_> are any of you guys familiar with the licensing on the quake3 SDK?
<DarkMageZ> didn't the quake 3 engine get gpl'ed?
<joejaxx> that is what i thought
<joejaxx> yeap
<joejaxx> the source for quake 3 is gpl
<joejaxx> joejaxx@venus:~/Desktop$ head -n 2 quake3-1.32b/COPYING.txt
<joejaxx>                     GNU GENERAL PUBLIC LICENSE
<joejaxx>                        Version 2, June 1991
<joejaxx> :)
<jscinoz_> hmm
<jscinoz_> im packaging a supposedly gpl game, UrbanTerror that is based on the quake 3 engine, however it includes a very non-GPL license of the "Quake3 SDK"
<joejaxx> interesting
<jscinoz_> this is what persia said about it
<jscinoz_> "Given that ID licenses this with an explicit prohibition to not "disassemble, reverse engineer, decompile, modify or alter the Software including, without limitation, creating or developing extra or add-on levels for the Software;", Iâm not convinced FrozenSand LLC has the right to distribute this."
<joejaxx> oh ok
<joejaxx> kde4 is installing :)
<jscinoz_> hmm
 * minghua agrees with persia.
<joejaxx> i wonder where they got that from
<joejaxx> jscinoz_: how old is this game?
<jscinoz_> im packaging the release from 20th of dec 2007
<jscinoz_> so not old at all
<joejaxx> bbl going use kde for the first time since 1998
<joejaxx> :)
<jscinoz_> argh
<jscinoz_> what should my preinst script be called to have it automatically executed before installation?
<minghua> preinst is the correct name.
<jscinoz_> thanks
<joejaxx> uh oh
<joejaxx> all i see is a background lol
<zul> heylo
<joejaxx> hello
 * joejaxx is having fun with trying to get the kde4 de to run correctly :)
<bddebian> Heya
<joejaxx> hi
<joejaxx> i got kwin to run :)
<bddebian> Hi joejaxx, congrats :)
<joejaxx> and i used xterm -display :0
<joejaxx> so now i have a terminal
<joejaxx> lol
<joejaxx> and that is it
<joejaxx> X Error: BadDrawable (invalid Pixmap or Window parameter)
<ScottK> But it's a KDE4 terminal, so that makes it totally cool.
<joejaxx> ScottK: :)
<nenolod> jscinoz_, that license is outdated, cause urbanterror runs on ioquake3 now
<jscinoz_> hmm
<jscinoz_> thats what i though
<jscinoz_> do any sections of the game remain under ID softwares copyright?
<jscinoz_> because persia also mentions "9) debian/copyright is fairly comprehensive, but still fails to mention that portions of the code are copyright Id Software. Might also be nice to have explicit licensing for the packaging."
<slangasek> nenolod: why does upse-audiacious only Recommend: audacious instead of depending on it?  Is it somehow useful without the application?
<jscinoz_> what exit code would need to be in my preinst screen to make it cancel the package installation
<slangasek> any non-zero exit code
<jscinoz_> i tried that
<jscinoz_> 1 and 2 both continued installation
<slangasek> then your preinst isn't reaching that exit statement
<jscinoz_> can i pastebin it, its only 16lins
<jscinoz_> lines*
<slangasek> sure
<slangasek> (I don't think there's a line limit on pastebin, anyway?)
<jscinoz_> no, but i wouldnt want someoen to go over a huge amount of script :P
<jscinoz_> http://pastebin.ubuntu-nl.org/51167/
<slangasek> jscinoz_: well, the comparison with "$RET" is going to be case-sensitive; I think it's supposed to be lower case
<slangasek> (I had a doubt about this last time you showed this script, but neglected to comment)
<jscinoz_> hmm
<jscinoz_> one second
<jscinoz_> yep that works
<jscinoz_> one other thing
<jscinoz_> see how it echoes that the user didnt accept the license, if the package is installed via a graphical tool (ie synaptic or gdebi-gtk) is that still going to show up?
<slangasek> it's going to show up wherever the rest of the console output goes
<jscinoz_> would it be better to call an info template?
<slangasek> I don't think so
<slangasek> I think the license prompt, with a clear explanation that refusing the license will abort the installation, is all you should need
<jscinoz_> ok thanks
<Romney08> Launch A New Type Of Marshall Plan Unifying Nonmilitary Sources Of Power To Support Moderate Muslims. As President, Governor Romney will call together our Middle East allies and the major nations of the developed world to establish a "Partnership for Progress and Prosperity."
<Romney08> This Partnership will assemble the resources of all developed nations to assure that threatened Islamic states have public schools, micro-credit and banking, the rule of law, human rights, basic health care, and competitive economic policies. Resources would be drawn from public and private institutions, and from volunteers and NGOs.
<slangasek> !ops | Romney08
<ubotu> Romney08: Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu or PriceChild!
<jscinoz_> in the changelog, is (LP: #179646) the correct format for saying which bug the package closes?
<ScottK> Yes
<Romney08> GOVERNOR ROMNEY: "Are we going to stay ahead of the world, are we going to lead the world, or are we going to instead pull up the drawbridge and try to hang on to everything we've got and say we can't compete with the world?" (Ryan J. Halliday, "Romney Defends His Health-Care Plan," Nashua Telegraph, 6/7/07)
<Romney08> GOVERNOR ROMNEY: "[W]e face a much tougher competitor or group of competitors coming from Asia than we've ever faced before. Asia is tough. There are a lot of Asians. They are hard working people. And theyâre going to give us a run for our money in terms of our economic vitality." (Governor Mitt Romney, Remarks At The Club For Growth, 3/29/07)
<jscinoz_> go away kthn
<jscinoz> slangasek, when i make the install end via the exit status 1 in preinst, do i need to do anything to clean up after that?
<slangasek> jscinoz: nope - if the preinst fails, there's nothing to clean up because that's the first step of installing a package
<slangasek> Hobbsee: hi, you may want to summarily execute Romney08's connection
 * Fujitsu would agree with slangasek.
 * ScottK too
<elkbuntu> cs kb Romney08
<elkbuntu> stupid / key :(
<Fujitsu> Thanks elkbuntu.
<ScottK> elkbuntu: Thanks
<Hobbsee> slangasek: right, sorry.
<slangasek> heh, no worries
<minghua> elkbuntu: Maybe -devel too.  He appeared there as well.
<slangasek> TBH, that's the weirdest bit of political spam I've ever seen
<Hobbsee> nuked
<jscinoz> lol
<slangasek> hum, cheers, whoever that was
<azeem> Romney08 is still in #u, btw
<Hobbsee> you're welcome
<Hobbsee> too slow, apparently
<Hobbsee> elkbuntu: did you get him in there?
<joejaxx> elkbuntu: ! :D
<elkbuntu> hi joejaxx! :)
<joejaxx> :)
<joejaxx> i just wiped my install
<joejaxx> giving kde4 another chance :)
<elkbuntu> heh
<elkbuntu> i'm not even going to bother until at least one point release
<joejaxx> :)
<joejaxx> elkbuntu: i have not used kde since version 1.0
<joejaxx> lol
<elkbuntu> joejaxx, every time i go to use kde, i want to make it work like gnome, so i just give up and go back to the devil i know ;)
<ScottK> joejaxx: KDE 4.0 is not even feature complete.  If you really want to try KDE, either try KDE 3.5 or wait for 4.1.
<joejaxx> lol :)
<joejaxx> ScottK: i do not like 3.5 :\
<ScottK> Then I'd wait unless you just want to play around.
<joejaxx> oh ok
<ScottK> A lot of apps aren't ported or the ports aren't complete.
<Fujitsu> ScottK: What was the rationale for leaving the completeness to a point-release? Just so they could say they got KDE4 out the door early?
<joejaxx> it is installing already so i might as well
<joejaxx> Fujitsu: is it not late? i thought it was supposed to be released in december
<imbrandon> Fujitsu: 4.0 wasent supose to ever be feature complete
<ScottK> Fujitsu: I think it was that the KDE APIs are stable enough to reliably develop on, so call it 4.0 for API stability, but dunno.
<Fujitsu> imbrandon: Well that's silly.
<imbrandon> ( and its late not early )
<imbrandon> Fujitsu: no, api stability for porting apps
<Fujitsu> joejaxx: Well, not *too* late, then.
<minghua> There was a long blog post from a KDE dev talking about this.
<imbrandon> same happened with kde 3 and kde 2
<imbrandon> :)
<minghua> http://aseigo.blogspot.com/2008/01/talking-bluntly.html
<ScottK> Which is why I think this "we have to focus on KDE4 so no Kubuntu LTS" seems really odd to me.
<joejaxx> is that why some of the versioning is still 3.9x?
<ScottK> Since the final isn't released yet
<wolfger> Can somebody help me figure where I went wrong with debhelper?
<minghua> Worth reading, though I'm not sure I agree with their rationale, at least you know what they think about it.
<ScottK> Definitely worth reading.
<ScottK> wolfger: Probably, but we'll need some details.
<Fujitsu> ScottK: It sounds strange that we're dropping LTS because of some incomplete preview.
<wolfger> ScottK: http://paste.ubuntu-nl.org/51169/
<ScottK> Fujitsu: Absolutely.
 * Hobbsee sets a ban on *!*@*!#ubuntu-ops
<joejaxx> yay
<joejaxx> all ban
<Fujitsu> Better to do that in #ubuntu, I think. That would make #ubuntu-ops happy.
<Hobbsee> hehe
<ScottK> wolfger: I'm in the middle of stuff, so don't really have time to look.  I'd suggest also pastebinning your debian/rules
<wolfger> ok, I'll do that, and probably pick back up tomorrow...
<joejaxx> hmm
<joejaxx> kde4 is not dual screen aware
<joejaxx> fun
<StevenK> joejaxx: That's a "feature"
<DarkMageZ> joejaxx, file a bug in the kde bug tracker =D this soon to release would trip them out =D
<joejaxx> lol
<StevenK> "We have spent so long writing KDE 4 all of us lost our jobs and can't afford dual screen setups any more."
 * StevenK hides
<joejaxx> Lol
<ion_> Typical to KDE, somewhere among the thousands of checkboxes thereâs one labeled âdisable multiscreen supportâ and itâs checked by default. ;-)
<joejaxx> the system config for kde4 is not launching  for me
<joejaxx> and plasma looks like it is in 8bit mode
<DarkMageZ> you can launch it from the command line
<StevenK> The system is not configurable in KDE 4.
<DarkMageZ> /usr/lib/kde4/bin/systemsettings
<joejaxx> DarkMageZ: command??
<joejaxx> ok
 * StevenK waits for ScottK to snap.
<joejaxx> wow
<joejaxx> that worked
<DarkMageZ> kde4's rc2 reminds me of microsoft's alpha's.
 * RAOF boggles quietly
<joejaxx> DarkMageZ: it worked when i logged out
<joejaxx> and logged back in
<DarkMageZ> sounds like "restart your computer" as far as i'm concerned.
<joejaxx> yeah
<joejaxx> also when i hit log out on the menu
<joejaxx> it brings up the log out dialog
<joejaxx> which makes no sense to me since the other options are available right under log out on the menu
<joejaxx> i need to find out what resolution this is running in
<joejaxx> xrandr is broken because of Xinerama
<joejaxx> anyone have any suggestions? :)
<joejaxx> :P
<joejaxx> hello Toadstool :D
<joejaxx> hey LaserJock
<LaserJock> hmm
<LaserJock> I can't seem to get pbuilder-dist to work
<LaserJock> has anybody used it lately?
<joejaxx> is packages.debian.org down for anyone else?
<LaserJock> down for me
<nenolod> slangasek, there are other programs which can load audacious plugins and use them
<minghua> packages.d.o is up here, FWIW.
<nenolod> slangasek, however, you are indeed correct, upse-audacious should probably be a Depends:
<nenolod> slangasek, i'll fix it when i upload 0.5
<nenolod> :D
<ion_> Could i get a second advocation for http://revu.tauware.de/details.py?package=hardware-connected (a program that checks whether given hardware is connected to the system, useful for scripting)? Thanks.
<jscinoz> can anyone see any references to GPLv3 on either of these manpages (http://pastebin.ubuntu-nl.org/51174/) (http://pastebin.ubuntu-nl.org/51173/), persia says there is one that i need to change, but i cant see it anywhere in them
<nenolod> ion_, package looks fine. if debian import freeze wasn't in effect, i'd say it might be easier just to submit it to debian
<nenolod> ion_, at any rate, not a motu, so can't advocate ;p
<LaserJock> nenolod: I don't think that DIF should dissuade people from getting packages into Debian
<nenolod> LaserJock, well i mean putting it in debian as a way to put it in ubuntu
<nenolod> LaserJock, although he could do a sync bug
<LaserJock> yep
<nenolod> nobody answered my question though about collateral examples of work when applying to be a MOTU though
<ion_> To submit it to Debian, do i need to get someone to sign up as its maintainer? Iâm not running Debian anywhere.
<nenolod> e.g. does stuff in Debian that is in Ubuntu count as collateral examples of work? ;p
<nenolod> ion_, not really
<nenolod> ion_, it's fully possible to maintain packages in debian and use ubuntu -- all you need to do is make sure they build on sid
<nenolod> ion_, you can make a pbuilder to accomplish that ;)
<ion_> True...
<minghua> nenolod: I would disagree.  I think it's quite irresponsible if the maintainer doesn't use the package (in the intended system) him/herself.
<nenolod> minghua, well, i run a debian desktop on alpha and ubuntu on amd64 for multilib
<nenolod> minghua, it's a pretty nice alpha, and i do test my packages, but the amd64 is much faster ;)
<minghua> nenolod: I am talking about "all you need to do is make sure they build on sid".
<minghua> nenolod: I think it's bad advice.
<nenolod> minghua, hmm, thinking about it, i agree
<nenolod> minghua, i would think testing it somehow is implied though (e.g. pbuilder --login, vmware, etc)
<minghua> nenolod: Yeah, brief testing is good enough for me, as long as you also use it in some similar system (Ubuntu, or Debian stable/testing).
<nenolod> minghua, yeah. of course, i don't use the upse package (i build the upse package using an hg snapshot for local use)
<nenolod> :P
<nenolod> minghua, but i do test the package before i send it off
<minghua> nenolod: Running a newer version can be excused. :-)
<nenolod> once i start packaging my playstation emulator, it'll be the same thing. ;)
<minghua> By "use it", I mean the package, not necessarily the same version.
<wasabi> Hiya! Looking for the help on how to request a merge in this day and age.
<nenolod> minghua, at any rate, i'm still wondering if work in debian counts as evidence of packaging quality in MOTU. ;)
<LaserJock> nenolod: it definitely can be taken into consideration
<nenolod> ok, groovy.
<nenolod> because i maintain some amount of packages (13 at the moment) in debian, and 8 of them are in ubuntu
<nenolod> ;)
<minghua> nenolod: It is.  Debian work was an big part of the reasons in my application to MOTU.
<nenolod>   + pulseaudio support patches for audacious (my only major work in Ubuntu only atm)
<minghua> nenolod: Though the application procedure then was pretty different than what it is now...
<nenolod> minghua, yes, that's why i am wondering
<nenolod> oh well, i'll apply in a couple of months then, as i get more ubuntu-specific work done
<nenolod> i should probably poke somebody to look at fixing ia32-libs again :D
<guest22> I'd like to request a review of http://revu.tauware.de/details.py?package=photoml  It's already been advocated once (the previous upload, at least), so it should be very close to being acceptable.
<ScottK> StevenK: You've missed it by years.
 * StevenK whistles innocently.
<Hobbsee> wha'ts he missed?
<ScottK> [21:55] * StevenK waits for ScottK to snap.
 * ScottK goes to be now.
<ScottK> be/bed
<ScottK> Urgh.
<Fujitsu> There was some nice KDE4 criticisum above.
<Fujitsu> *criticism
<Hobbsee> ah right
<Hobbsee> Fujitsu: well, yeah, tha'ts known
<ScottK> I would say Kubuntu criticism.  I understand why KDE is doing what it's doing.
 * Fujitsu shoots people who still use .htm in this day and age, thus causing the world to explode when one drops index.htm from DirectoryIndex declarations.
 * Hobbsee is looking forward to the final packages being done soon, so that they can actually be fixed to not die when attempting to install.
<ScottK> I don't understand why Kubuntu going out of it's way to hang out a sign that says "For 'enthusiasts' only"
<ScottK> Good night.
<Fujitsu> ScottK: This looked like more general KDE.
<Fujitsu> Night ScottK.
<ion_> fujitsu: A bunch of packages ubuntu-desktop depends on install .jpg files. :-P
<joejaxx> i am back :)
<joejaxx> is anyone else? :D
<parthan> joejaxx, doesn't fluxbuntu support non-free drivers?
<joejaxx> parthan: ?
<joejaxx> sure
<joejaxx> why?
<joejaxx> :)
<joejaxx> :(
<joejaxx> !monologue
<ubotu> Sorry, I don't know anything about monologue - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<parthan> joejaxx, because if i have to use it here, i need help of some non-free divers ;)
<parthan> joejaxx, and also because the website reads "Fluxbuntu is 100% Free Software" ;)
<dholbach> good morning
<Fujitsu> Hi dholbach.
<Fujitsu> Oops.
<Fujitsu> Wrong button.
<dholbach> Fujitsu: you have a "Hi dholbach" button somewhere? :)
<Hobbsee> no, of course not
<Fujitsu> No, I haven't cut my nails in a while, and hit the up button or something similar :P
<Hobbsee> he has a "Hi $last_person_that_entered"
<dholbach> Hobbsee: a "Hi dholbach" button would be much cooler :)
<Fujitsu> Hobbsee: That's a good idea, actually.
<Hobbsee> dholbach: not scalable, though
<wallyweek> g'morning all
<ChrisGibbs> gday all
<wallyweek> g'morning all!
<wallyweek> anyone wishing to review online?
<AnAnt> persia: hello
<AnAnt> persia: thanks for reviewing the ubuntume artwork packages, I need to ask you some questions though
<AnAnt> can anyone help me with gconf ?
<AnAnt> I am doing a gconf-defaults file in debian package, one of the keys I want to modify is of type list
<AnAnt> how do I write it's entry in gconf-defaults ?
<AnAnt> <keyname> ["value"] ?
<huats> morning everyone
<dholbach> AnAnt:
<dholbach> oops
<dholbach>  /desktop/gnome/interface/gtk_theme      Human
<dholbach>  /desktop/gnome/interface/icon_theme     Human
<dholbach>  /desktop/gnome/peripherals/mouse/cursor_theme   Human
<AnAnt> dholbach: thanks for reviewing the packages
<dholbach> from /usr/share/gconf/defaults/16_ubuntu-artwork
<dholbach> heya huats
<dholbach> AnAnt: no problem
<huats> hey dholbach
<AnAnt> dholbach: yes, but all those keys are of string type, not list
<dholbach> ah, hang on
<AnAnt> dholbach: oh, I found it in update-gconf-defaults man page, thanks
<dholbach>  /apps/compiz/plugins/scale/allscreens/options/initiate_edge             []
<dholbach> is the best I found :)
<AnAnt> yeah it's: <key> [value1,value2]
<AnAnt> dholbach: how should I indicated the GPL version for package license ?
<dholbach> AnAnt: You need to refer to whatever license the upstream tarball contains
<dholbach> AnAnt: or do you mean a license for the packaging?
<AnAnt> dholbach: license for packaging indeed
<dholbach> I'm not sure the archive admins want a copy of the GPL shipped just because your packaging is under the GPL
<dholbach> I normally don't license my packaging separately
<AnAnt> ?
<AnAnt> I don't understand
<dholbach> best to ask in #ubuntu-devel (the archive admins will be around there) if you need to ship a copy of $license for your packaging
<dholbach> I never added the "Packaging is licensed under $license" note
<AnAnt> dholbach: GPL is already existing in /usr/share/common-licenses/
<dholbach> normally the archive admins want the upstream tarball to contain a copy of whatever license it is under
<AnAnt> dholbach: I think you got me wrong
<dholbach> ok... maybe you can re-phrase your question
<AnAnt> dholbach: you said in your review "Please specify which version of the GPL applies to the packaging"
<dholbach> AnAnt: do you have the link somewhere?
<AnAnt> dholbach: http://revu.tauware.de/details.py?package=ubuntume-gdm-themes (point #3)
<dholbach> oh http://revu.tauware.de/details.py?package=usplash-theme-ubuntume - I'm not Emmet :)
<dholbach> persia is Emmet Hikory :)
<dholbach> in http://revu.tauware.de/revu1-incoming/usplash-theme-ubuntume-0801071011/usplash-theme-ubuntume-1.1/debian/copyright you say: "The Debian packaging is (C) 2007, Ø£Ø­ÙØ¯ Ø§ÙÙØ­ÙÙØ¯Ù (Ahmed El-Mahmoudy)
<dholbach> <aelmahmoudy@users.sourceforge.net> and is licensed under the GPL, see
<dholbach> `/usr/share/common-licenses/GPL'."
<AnAnt> oh ok
<dholbach> persia wants to know which version of the GPL you are talking about
<AnAnt> -2 or -3 ?
<dholbach> right
<AnAnt> I don't know the difference
<AnAnt> well, I'll ask him about that later
<AnAnt> dholbach: as for your comment on UbuntuME-v0.1, actually the package has several themes
<dholbach> I can't spare you the pain of reading up on those license
<AnAnt> dholbach: 3 themes
<dholbach> AnAnt: what happens if I choose v0.1 and you decide to ship v0.2 in the next release?
<AnAnt> dholbach: in the next release I'm supposed to keep v0.1 too
<dholbach> ok
<AnAnt> dholbach: actually UbuntuME-v0.1 is an old GDM theme indeed
<AnAnt> dholbach: I prefer that the upstream would give them names indeed
<dholbach> ok... I just wanted to know what your thoughts are
<AnAnt> dholbach: but he got a new life (job & marriage), so he's pretty tied up those days
<AnAnt> dholbach: ok, thanks a lot for your help
<AnAnt> I'll be working on the points mentioned
<dholbach> ok great - thanks :)
 * dholbach -> dogwalk
<AnAnt> bye
<\sh> moins
<BugMaN> hi \sh!
<Ng> in relation to the hardy schedule, when is the last realistic point for getting a new little package into universe?
<slangasek> you should plan to have it done prior to feature freeze
<DaveMorris> which is when?
<Ng> slangasek: k, thanks :)
<Ng> DaveMorris: https://wiki.ubuntu.com/HardyReleaseSchedule
<DaveMorris> thanks
<DaveMorris> since it revu day, my package still require revu.  All previous comments have been addressed - http://revu.tauware.de/details.py?package=libserial
<Ng> ah and it's February 14th, so that means hardy stops getting new love on valentine's day ;)
<astharot> good morning :)
<liri> in an attempt to recover the revu password I get "gpg -d <<EOT ; echo 	Now paste the text below, and enter EOT<return>" and nothing else, any ideas?
<geser> good morning
<wallyweek> anyone to review http://revu.tauware.de/details.py?package=sdlmame before revu day ends? thank you! :)
<wallyweek> we should be near advocation, please help me upload it before featurefreeze
 * rzr advertises for this snd app : http://revu.tauware.de/details.py?package=jaaa
 * wallyweek knows is quite annoying but calls once again for reviews on his package http://revu.tauware.de/details.py?package=sdlmame
<slangasek> pochu: hmm, how does installing liboobs-1-4 break gnome-system-tools << 2.21.4, when that version of gnome-system-tools depends on liboobs-1-3?
* persia changed the topic of #ubuntu-motu to: Masters of the Universe: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com
 * persia thanks slangasek for the comprehensive announcement
<Hobbsee> yay, it's not revu day now!
<slangasek> persia: I am occasionally capable of learning from past mistakes
<pochu> slangasek: g-s-t 2.21.3-0ubuntu1 depends on liboobs-1-4 (>= 2.21.2.1) here.
<pochu> slangasek: and there's a typo in the changelog, shold read << 2.6.23:
<pochu> Breaks: gnome-system-tools (<< 2.21.3)
<geser> pochu: Hi, are you going to merge mono-tools from Debian unstable? mono-tools doesn't build on hardy anymore (fixed in Debian)
<pochu> err, 2.21.3 :)
<pochu> geser: I'll do it when I have some time if you don't do it first ;) so please do it yourself if you can
<slangasek> pochu: but 2.21.3-0ubuntu1 is not << 2.21.3 which is what the breaks is; so this appears to force deconfiguration of the old version of gnome-system-tools, which doesn't depend on liboobs-1-4 at all...
<persia> StevenK: Given the imminent promotion to main, does bug #180624 interest you?
<ubotu> Launchpad bug 180624 in cheese "cheese new upstream version 0.3.0" [Undecided,Confirmed] https://launchpad.net/bugs/180624
<StevenK> Hrm, not really.
<jscinoz> RAWR
<jscinoz> hey everyone
<persia> OK.  Kicking for standard reasons then :)
<persia> jscinoz: /usr/share/common-licenses/GPL is GPL 3.
<jscinoz> oh? on gutsy it shows gpl2
<persia> jscinoz: In gutsy is it GPL 2.
<jscinoz> ah
<jscinoz> so i should ref /usr/share/common-licenses/GPL-2 then :P
<StevenK> persia: I'll leave it to lool.
<jscinoz> persia have you had a chance to redownload the package?
<persia> StevenK: Makes sense, just as matter of highlighting it to your attention given the list in your MIR.
<liri> persia: I'm having some troubles recovering the revu website password for my account.
<jscinoz> because im not sure if the ftp server was down when you tried to uscan, because it seems to be working now
<persia> jscinoz: Err..  I was avoiding that :)  I'll grab again and test the watch files.
<jscinoz> :P
<persia> liri: Have you uploaded something to REVU yet?
<jscinoz> i could just pastebin you the watch file itself
<jscinoz> wouldnt that be enough to test the uscan?
<liri> persia: yes I have.
<persia> jscinoz: Actually, I can just grab it from REVU, which means I only have to download it once.  Thanks for reminding me :)
<liri> persia: when recovering the revu password I get "gpg -d <<EOT ; echo 	Now paste the text below, and enter EOT<return>" and nothing else, any ideas?
<jscinoz> ok :P
<jscinoz> "4) debian/copyright fails to mention files copyright Id software" are you wanting me to state specifically which files are copyright ID?
<persia> liri: There is no text?  Hrm.  That bug has appeared before, but I don't happen to remember the cause.  When did you join ubuntu-universe-sponsors?
<liri> uhm, let me check on that
<persia> jscinoz: At least indicate somewhere that they are a copyright holder.  The current debian/copyright isn't an accurate summary of the files in the package.
<liri> persia: I'm a member of                Contributors of packages for ubuntu universe      or is it not enough?
<persia> jscinoz: If you haven't already reviewed http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html, it is definitely worth a read.
<persia> liri: That is supposed to be enough, and that you can upload makes me think it really should be.  It's just that I vaguely remember that another resync helped some people to recover their password, so I wonder when you joined the team, and when you first uploaded.
<liri> persia: well the upload date is there on the packages page, as for the contributors groupI joined on 2007-12-25
<persia> jscinoz: Fails for me right now.
<persia> liri: Which package?
<liri> persia: daloradius
<persia> liri: Well, that's recent.  I'll try syncing again, but no guarantees: you might need a REVU-hacker to sort this out.
<jscinoz> strange.
<persia> jscinoz: What do you get for output?
<liri> persia: ok thanks, tell me after the resync is over I'll give it another shot
<jscinoz> Newest version on remote site is 4.1, local version is 4.1
<persia> jscinoz: OK.  How about with --force-download?  Does it download?
<jscinoz> one sec
<jscinoz> yes
<persia> jscinoz: You'd do best to get someone else to test then.  I have no explanation as to why it might work for you and not for me.
<jscinoz> hmm
<jscinoz> also
<jscinoz> i could have sworn the quake3 sdk is GPL nowadays
<persia> jscinoz: Maybe.  http://revu.ubuntuwire.com/revu1-incoming/urbanterror-data-0801012251/urbanterror-data-4.1/debian/copyright doesn't look like GPL to me.
<jscinoz> i know it isnt stated in the orig or anything...
<persia> I'm not even certain we can distribute that in Ubuntu
<jscinoz> wait
<jscinoz> i think the engine is gpl in the urbanterror package
<jscinoz> its the data that isnt.
<persia> That sounds like what I've heard before about quake3
<jscinoz> brb going to go ask UrT devs in #urbanterror on quakenet
<pochu> slangasek: I'm not sure what is wrong here. liboobs breaks g-s-t << 2.21.3, since g-s-t 2.21.2.1 won't work with liboobs < 2.21.3 IIRC
<pochu> slangasek: and g-s-t 2.21.2.1 depends on liboobs-1-4, see https://edge.launchpad.net/ubuntu/hardy/i386/gnome-system-tools/2.21.2.1-0ubuntu2
<frenchy> How long does it normally take for a source package to get through the build queue ATM?
<persia> frenchy: A few hours to a day (depending on who uploaded a heap of things recently, or whether an archive admin just approved all the sync requests).  me-tv was available for my last aptitude check.
<frenchy> persia: Thanks for info, have I been that much of a pain-in-the-ass that you remember me and my little package :).  It's only available as a source package though right, when does it get built?
<persia> frenchy: It's a binary package for me, and it was more your plight of working on a package that required special hardware to test that remembers you to me.
<frenchy> persia: Ohhh, I've been checking packages.ubuntu.com ... not the authoritative source obviously.
<persia> frenchy: Not at all.  You want https://launchpad.net/ubuntu/+source/me-tv
<persia> liri: Done.  Try again.
<frenchy> persia: Thanks dude, you rock.
<liri> persia: unfortunately this is the same
<persia> liri: Yep.  You need a REVU Hacker then.
<persia> liri: Why were you logging in anyway: was there a specific note you needed to add to your package?
<Hobbsee> liri: which address is on your package?
<liri> persia: not really, not for now.
<liri> Hobbsee: I believe liran@enginx.com
 * Hobbsee thinks it's broken.
<persia> Well, yes, but the question is "How?".  We've seen this bug before, but it usually goes away after a while.
 * Fujitsu pokes a bit.
<Fujitsu> There's no GPG key set on the account...
<Hobbsee> the email is set, and there's a p/w set
<Hobbsee> but the lack fo gpg key is...interesting
 * persia greps sync logs
<Fujitsu> Hobbsee: Did you set the password on it? That looks... decidedly non-random.
<Hobbsee> Fujitsu: yes, i reset it, then set it back
<Hobbsee> :)
<Hobbsee> holy flipping potatoes
 * Hobbsee gets her lart bat.
<Hobbsee> stdin: please don't use dcut on revu.  it doesn't work.
<stdin> Hobbsee: I did once, last year...
<Hobbsee> johan_kiviniemi, pavel_madman2k_net, same thing
 * persia notes that the correct keyID is DB2E67D1, which was just sync'd
<Fujitsu> Very, very few people seem to have OpenPGP keys assigned...
<Hobbsee> stdin: no one's looked on here for a while
<liri> yep
 * Fujitsu adds that to the DB.
<Hobbsee> Fujitsu: dat not good.  those in ~ubuntu-dev, perhpas?
<Fujitsu> Hobbsee: No, only less than a dozen, I think
 * Fujitsu checks.
<Hobbsee> Johan Kiviniemi also gets larted with the cluebat.
<Fujitsu> liri: Can you please try again?
<liri> Fujitsu: the recovery thing?
<persia> Hobbsee: ion_?
<Fujitsu> liri: Correct.
<liri> Fujitsu: still the same.
<Fujitsu> process-upload should be assigning the key when it creates the account, no?
<Hobbsee> ion_: for the love of the green spaghetti monster, please *don't* use dcut, and please *don't* upload binary packages.
<Fujitsu> liri: Completely blank? /me tries.
<Hobbsee> ion_: i don't know where you're finding info about uploading binary packages
<persia> Fujitsu: No.  It assigns the email address, and the key is supposed to be assigned by the key sync.
<Hobbsee> persia: did you just resync?
<Fujitsu> persia: Hm, that's odd.
<persia> Hobbsee: minutes ago.
<Fujitsu> liri: Is that address on your key?
<Hobbsee> cool
<liri> Fujitsu: yeap
 * persia did reverse lookup in the keysync log to pull the keyid
<Fujitsu> If that key is on the keyring, and the address matches...
<Hobbsee> persia: more stuff for you to review :)
 * Hobbsee continues to clean up
<persia> Hobbsee: It's not REVU day anymore :)
<Hobbsee> heh
<Hobbsee> persia: yes, but there's enough of it that ithad better be, for you
 * persia took this one (mostly) off to give others a fair chance, but will look at the packages again next week.
<Hobbsee> sure sure
<persia> Hobbsee: Why?  I did 5 this week.  How many have you done since gutsy opened?
<Hobbsee> i accepted 2.
<persia> See.  We're almost even (as accepting counts double)
<liri> Hobbsee: if you accept mine that will be 3 :-)
 * persia only rejects packages on REVU anyway
<Hobbsee> hehe
<Hobbsee> persia: oh, since gutsy?  lots - but most were translations
<persia> liri: You need to get someone to upload it before Hobbsee can accept it.
<liri> persia: upload it where?
<liri> persia: to universe?
<Fujitsu> Hobbsee: What happens if you run `revu-key encrypt <email>' manually? I don't have privs to do it.
<persia> liri: To the archives (the process is that the second advocate usually uploads, and you can complain here if they don't)
<Hobbsee> hobbsee@sparky:~/incoming% sudo -u revu1 -H ~/revu/bin/revu-key encrypt liran@enginx.com                                            1:22PM
<Hobbsee> gpg: WARNING: unsafe permissions on homedir `/srv/revu-production'
<Hobbsee> gpg: liran@enginx.com: skipped: unusable public key
<Hobbsee> gpg: [stdin]: encryption failed: unusable public key
<Hobbsee> Fujitsu: ^
<liri> persia: can you elaborate on "the second advocate usually uploads" ?
<Hobbsee> revu1@sparky:/home/hobbsee/incoming$ ls
 * Hobbsee wins!
<Fujitsu> Hobbsee: Right, let me try something locally.
<persia> liri: Your key is unusable :(
<Fujitsu> No encrypting part?
<liri> uhm, I wonder how that happens
<liri> is that the key used to sign the package or on the launchpad account?
<Fujitsu> They must be identical.
<persia> liri: The REVU process consists of Ubuntu developers reviewing your package, and either commenting requesting more work, or advocating for upload.  The second person to advocate will typically upload to the archive and mail ubuntu-motu@l.u.c to announce they have done so.
<liri> Fujitsu: how would that happen?
<Fujitsu> Hmm...
<Fujitsu> I don't see any subkeys on that key.
<Fujitsu> It is indeed unusable.
<persia> liri: Rather they must be the same key: LP should have the public key, and you should sign the package with the private key.
 * Hobbsee wonders who is Thomas Butter
 * Hobbsee ponders removing this stuff whcih has multiple errors, and which people haven't asked about
<liri> persia: yeah just wondering if something could have went wrong in the copy&paste on the launchpad website
<persia> Hobbsee: No registered IRC nick reported in LP.
<StevenK> Hobbsee: Thomas Margarine's less spreadable brother
 * StevenK hides
<Hobbsee> haha
<geser> Fujitsu: that key has no encryption capability
<Fujitsu> geser: Exactly. No encrypting bits, so no subkeys.
<Hobbsee> Michael Lamothe here?
<persia> Hobbsee: Removing packages pending review?  Just comment explaining why it's crack.  For random stuff that couldn't get past uploads/, just delete.
<liri> I'll double check
<Hobbsee> persia: it doesn't even make it to the web UI
 * Hobbsee wonders what the heck this guy was on
<persia> Hobbsee: Anything that can't get to the web UI, and didn't get a complaint here may be considered cruft.
<Hobbsee> heh
<Hobbsee> good
<persia> frenchy: Hobbsee seeks you (or I'm confused)
<persia> frenchy: Also, if I'm correct, please add your IRC nick to LP.
<frenchy> persia: Ok.
<geser> Fujitsu: does a RSA key need a sub-key for encryption?
<Fujitsu> geser: I thought all OpenPGP keys did, but I couldn't be quite sure about RSA. I rarely see them in the wild.
<mruiz> hi all
<frenchy> Hobbsee: Here!
<Hobbsee> frenchy: you're michael?
<geser> Fujitsu: DSA/ElGamal keys have a ElGamal encryption subkey as DSA is only for signing
<Hobbsee> frenchy: any reason why me-tv_0.4.8-0ubuntu1_source.changes was an empty file?
<geser> but RSA keys can have SCE
<Fujitsu> geser: Ah, right.
<frenchy> Hobbsee: Yes, that's me ... Ummm none that I can think off.  Where was this?
<Hobbsee> frenchy: to revu
<Hobbsee> frenchy: as in, did you upload it empty, or did revu manage to delete the contents?
<frenchy> Hobbsee: I would not have intentially removed the contents of the changes file.
<frenchy> intentionally
<Hobbsee> frenchy: well, tha't swhat i thought.
<Hobbsee> strange.
 * Hobbsee nuked the upload, anyway
 * persia notes that me-tv is in the archives now, so all is good
<Hobbsee> oh, even better
<frenchy> Hobbsee: I'm still a noob to packaging but I see no reason why I wouldv'e done that ... unless I had a connection dropout.  My wireless sometimes does funny things.  I believe that you're familiar with this.
<Hobbsee> yeah, true
<Hobbsee> i mean, dput wouldn't have even taken that
<frenchy> Hobbsee: Good point.
<Hobbsee> so you'd have to use some form of ftp
<Hobbsee> which makes me wonder why revu is losing data
<frenchy> Only ever used dput.
<Hobbsee> strange.  oh well
<broonie> I've had that happen to me due to a connectivity issue before.
<frenchy> persia: LP updated.
<persia> frenchy: Thanks.
<AnAnt> persia: hello
<persia> AnAnt: Hello.
<AnAnt> persia: thanks for reviewing ubuntume artwork packages
<persia> AnAnt: Thanks for bringing them into Ubuntu.  I like it best why we all work on the same codebase.
<AnAnt> persia: erm, I don't understand what you mean by "I like it best why we all work on the same codebase."
<AnAnt> persia: anyways I got some questions
<AnAnt> persia: you say, GPL cannot be relicensed to CC
<persia> AnAnt: All the different groups making different flavours of Ubuntu all working on the same packages in the same repositories, rather than trying to maintain separate changes, which are hard to keep up-to-date.
<AnAnt> persia: well, that Human Ultra theme is actually based on Human theme that is CC licensed
<persia> AnAnt: As far as I understand it.  That statement does not constitute legal advice, and may not apply in any given jurisdiction.
<AnAnt> persia: huh ?
<persia> AnAnt: Maybe that package has a bug :)  Anyway, some of the code / data was GPL, so I complained.  Better to reference the GPL in debian/copyright, as the GPL tends to require relicensing as GPL (if the work was received under the GPL).
<AnAnt> persia: erm, I don't get it, btw, for the packaging license, what difference does it make between GPL-2 & GPL-3 ?
<persia> AnAnt: http://www.fsf.org/licensing/licenses/rms-why-gplv3.html has a basic overview of the differences.  For a true understanding, you should read and compare the licenses.
<AnAnt> persia: oh, about modifying gdm.conf, I am working on a ubuntume-artwork package, that does modify /etc/gdm/gdm.conf-custom ,it asks the user (using debconf) if he wants the gdm.conf-custom to be modified in order to use the themes, if he/she accepts, then the postinst modifies (not replaces) the gdm.conf-custom (using sed)
<persia> However, my issue with the package was that you referenced /usr/share/common-licenses/GPL (which is GPL3), didn't specify a version, and the only GPL code I found was GPLv2.
<persia> AnAnt: You may or may not be permitted to do that.  Check to see if gdm defines gdm.conf as a conffile.  It is considered bad to modify another packages conffile.  There may be a workaround (or maybe someone will grant a policy violation exception).
<AnAnt> persia: oh
<AnAnt> persia: it is a conffile
<AnAnt> persia: but I'm not replacing the file, just made a script that modifies it
<persia> AnAnt: Then you need to either work with gdm people to figure out how to work around that, or someone needs to grant a policy exception to allow you to do that.
<AnAnt> persia: even if it is done after user is asked wether to do it or not ?
<persia> AnAnt: I don't think you.  You can check the policy from the debian-policy package.  Hardy currently has 3.7.3.0 (and while not everything complies, that is the standard against which new entrants are judged).
<persia> s/you/so/1
<AnAnt> ok
<AnAnt> persia: in the usplash, can the C file be CC licensed ?
<persia> AnAnt: Sure, but only the copyright holder can relicense it.  If you received it (or significant portions of it) under GPL, it needs to stay GPL.
<AnAnt> ok thanks
<ScottK> Significant defined as not very much at all for copyright purposes.
<persia> ScottK: Depends on the jurisdiction, really.  Where you are, having glanced once at a similar source that had part of one line in common might be considered infringement, but not everywhere is that draconian.
<persia> But even there, one cannot copyright "int main(argc, *argv)"
<ScottK> True, but if someone has claimed copyright on something (at least here) the burden is to prove it's not copyrightable.
<persia> Frustratingly true :(  Especially so with automatic grant of copyright.
<ScottK> So assuming something isn't copyrightable is risky at best.
<ScottK> Speaking of which I just had a scam mail land in my inbox that claimed I was due a tax refund and said: "Â© Copyright 2008, Internal Revenue Service U.S.A."
<ScottK> The one entity (in the US) that you know didn't copyright something is the US Government.  They're prohibited from doing it.
<StevenK> Interesting
 * persia notes that under that copyright regime, that government cannot copyright anything at all.
<StevenK> ScottK: How do they protect their forms, then?
<ScottK> If one modifies their form to perpetrate a fraud, there are other laws to deal with that.
<persia> StevenK: Used to be special paper sizes.  Now open (PDF downloads).
<ScottK> Otherwise, why would they care?
<ScottK> The tricky bit is the under some circumstances when they hire a contractor to develop a work, the contractor can retain copyright if the US Government doesn't actually buy the rights.
<broonie> Often some forms are controlled in various ways (for example, blanks some of the more important tax forms in the UK are only allowed to be held by employers)
<persia> Vorian: Would you mind updating bug #179606?  I'm not able to unsubscribe the sponsors team, and it just needs a bit of editorial work.
<ubotu> Launchpad bug 179606 in xdg-utils "xdg-util new upstream needs packaging" [Wishlist,Confirmed] https://launchpad.net/bugs/179606
<broonie> It's crude security, not worth too much these days.
<Vorian> persia: sure thing
<persia> broonie: Seems odd.  How does that help Inland Revenue? (disclaimer: I live in a tax jurisdiction where the laws have been adjusted for ease of computer programs)
<persia> Vorian: Thanks.
<broonie> persia: It makes it a bit easier for employers to pass over tax data when they need to (for a new job, say). It also makes it easier for them to LART anyone doing anything stupid.
<Vorian> not a problem at all
<Vorian> :)
<broonie> I suspect they wouldn't bother if writing the rules today.
<persia> broonie: Hmm.  I guess.  Here there are special red stamps, registered with the government, and if you don't have the appropriate red stamp from your last employer on your handover documentation, it gets rejected.  The forms are available to anyone, but the stamps are hand-constructed to be difficult to duplicate.
<persia> ember: Are you still working on deskscribe?
<broonie> persia: Yes, that's the same sort of idea (the forms are relatively difficult to reproduce).
<persia> broonie: The difference being that they are mass-produced, so it leaves open a gap for unscrupulous HR.  Here if the fancy red stamp is missing, the company has a problem, and reports it within the day.  Anyway, subverting non-computer systems is a far cry from Ubuntu development :)
<liri> Fujitsu: should I upload my key to subkeys.pgp.net for it to be valid on revu?
<bluekuja> liri, nope, use keyserver.ubuntu.com
<bluekuja> liri, the key-sync script updates the keyring using keyserver.u.c atm
 * persia notes that most keyservers (including ks.u.c) sync to each other several times daily
<bluekuja> persia, yes, and does ks.u.c sync from subkeys.pgp.net as well?
<liri> bluekuja: I'm not sure if that would solve the error from gpg: skipped: unusable public key
<ember> persia: yes.
<persia> bluekuja: I believe so.
<bluekuja> persia, ah ok so liri nvm my comment
<bluekuja> :)
<persia> ember: Please upload a new revision soon.  It's been a few weeks, there are only about three weeks left before the deadline.
<ember> will do
<persia> ember: Thanks.
<liri> bluekuja: I sent my key to subkeys.pgp.net
<bluekuja> liri, today?
<bluekuja> liri, key ID?
<liri> bluekuja: a few minutes ago, DB2E67D1, revu rejected with a "skipped: unusable public key" message, actually locally I get the same results for some reason
<bluekuja> liri, it should'nt be available on ks.u.c then
<bluekuja> liri, I don't know how often keys gets synced from other keyrings
<bluekuja> liri, what do you mean with locally?
<bluekuja> liri, e.g signing your package with debsign?
<liri> bluekuja: encrypting a file, like gpg --encrypt --recipient liran@enginx.com <file>
<liri> bluekuja: I think the package signing was successful but I can't remember now (although I can verify it quite easily)
 * persia notes that signing and encrypting are different
<liri> bluekuja: yeah signing asks for passphrase and completes just fine.
<liri> true.
<bluekuja> liri, are you trying to *upload* or to *decrypt* to get your pwd?
<liri> bluekuja: well I'm currently trying to encrypt a file locally on my computer to test my key
<bluekuja> liri, and what's the problem with REVU?
<bluekuja> liri, actually as persia stated signing and encrypting is different...maybe you're doing something wrong? :)
<liri> bluekuja: well no idea then :)
<liri> while before gesser and fujitsu noted: geser: Fujitsu: that key has no encryption capability Fujitsu: geser: Exactly. No encrypting bits, so no subkeys.
<persia> bluekuja: Nothing being done wrong, just that the key is RSA rather than DSA.  Needs more subkeys, or if they were recently added, needs to wait for the keyservers to sync.
<bluekuja> persia, I wasnt sure he was trying to upload to REVU or not
<bluekuja> persia, and I guess liri didnt upload anything to revu yet
<persia> liri: Unless you've lots of signatures you wish to preserve, consider creating a DSA key, and signing it with your RSA key to indicate you know you are you.
<bluekuja> liri, did you upload something to revu yet?
<persia> bluekuja: Uploading works, just not password retrieval (signing works, but not encryption)
 * Hobbsee is not me, just someone else pretending to be me.
<bluekuja> persia, got it
<bluekuja> Hobbsee, heya :D
<Hobbsee> greets!
 * persia sees LongPointyStick and is suspicious of that claim
<Hobbsee> that's on another machine
<liri> persia: I'll just get over with it by creating a new dsa key and that's it.
<bluekuja> Hobbsee, happy new year, sarah!
<Hobbsee> :)
<bluekuja> Hobbsee, everything went fine with your holidays?
<Hobbsee> yeah, mostly :)
<bluekuja> great :)
<bluekuja> persia, someone should promote you to Keys master
<bluekuja> persia, it seems you have a good knowledge about keys
<bluekuja> ;)
<persia> bluekuja: I learned most of it here, or in links posted here.
<bluekuja> cool :)
 * persia found the issue with rhythmbox.  Somehow the "å¤æ" key happens to send the same scancode as the "Media" key on some random internet keyboard.  Bad hardware designers!
<StevenK> I don't have one of those keys
<persia> StevenK: It's people like you who thought it would be a good idea to double-map the keysym :p
 * Hobbsee mutters somethign about how people should all speak english
<persia> (for those unfamiliar with jp106, å¤æ is right next to a very small spacebar)
<StevenK> Hobbsee: Personally, I dislike that attitude.
<Hobbsee> or, all speak some chosen language
<persia> Hobbsee: Even if everyone spoke a common language, why shouldn't they use others too?  Also, it's fun to have nifty characters be easy to type.
<Hobbsee> persia: because they expect me to understand them, when they're speaking in mangled $language_of_country, and getting increasingly pissed off when i can't undersatnd them.
<Hobbsee> s/speaking/mumbling/
 * persia especially likes å¨è§ï¼åè§ for ï½ï½ï½ï½ï½ãï½ï½ï½ï½ characters :)
<Hobbsee> hehe
<rzr> persia: hi
<rzr> persia: just got your email
<persia> rzr: Hello.  Wasn't actually mail :)
<rzr> persia: I'd like to make it enter ubuntu 1st
<persia> rzr: makes sense.
<rzr> persia: just to test the process
<rzr> persia: i have pending ITP in debian
<rzr> i wanted to compare
<rzr> persia: well u're right i'll have to ITP it too
<Hobbsee> dholbach: so what is hte date of doom?
<persia> rzr: Even while you're getting it into Ubuntu, it's best to ITP.  It's frustrating when someone uploads a different tarball the day before it goes into Ubuntu (happened to me once), and you have a very annoying merge later.
<rzr> yea I know that it happended to me once
<persia> rzr: Anyway, your package was selected by the review assigner, so you've just received a special, non-REVU day review.  Please upload a new candidate addressing the points raised in the REVU comment.
<rzr> great
<rzr> thx persia
<dholbach> Hobbsee: what are you referring to?
<Hobbsee> dholbach: mid jan, MC was going to make a decision, yes?
<dholbach> Hobbsee: the MC will wait for the report that is due mid January
<Hobbsee> ...right
<persia> Vorian: Please update the Bug Description with the contents of your last comment.  Makes life easier for the archive-admins.
<Hobbsee> dholbach: which is written by the MC?
<Vorian> persia: will do, thanks again for the tip
<dholbach> Hobbsee: no, norsetto and I will write it
<persia> Hobbsee: Only accidentially.  Written by the supervisors (50% of whom coincidentally are also MC members)
<dholbach> ?
<persia> Hobbsee: Please, keep your pitchforks and torches sharp and dry if you like, but wait, and don't mix things.  There's too much tension already :)
<Hobbsee> right.
<ScottK> Well so far everything I've dealt with that he messed up was in Main.
 * Hobbsee just wants a date to see everything done by, as a vote of confidence that the MC can, and will do what it says, in this matter.
<ion_> hobbsee: Never heard of pavel_madman2k_net. I accidentally uploaded a binary package to REVU ages ago, and immediately reuploaded the source-only package.
<zul> morning
<ion_> hobbsee: I just assumed the cron job there would just remove it. Had i known itâs left lurking there, iâd have requested it to be removed back then.
<ion_> hobbsee: 2007-12-28 05:16:22 < ion_> Oh, i accidentally uploaded a .changes file with both source and binary files. I wonder how REVU handles it?  2007-12-28 05:16:48 < Fujitsu> It won't even see it.  2007-12-28 05:16:59 < Fujitsu> It globs for *_source.changes
<ion_> hobbsee: And that was about it.
<martoss> hi all, i have a ppa repo related questions.
<ion_> ...and now would be a good time to realize sheâs not online. :-P
<martoss> if i upload via dput a ".changes" file, i get an error message that it contains binary parts since the debs are uploaded as well.
<ion_> Build with -S
<martoss> how can i create a changes file without the binary deb files just for the .tar.gz and the desc?
<bluekuja> martoss, debuild -S -sa
<bluekuja> martoss, for revu upload
<bluekuja> martoss, you did something like dpkg-buildpackage -rfakeroot with no other options...so you get the binaries in the .changes as well
<bluekuja> martoss, just use the command above and that's fixed
<martoss> yepp, revu would be the next test, i think my key should be in keychain since resync should be done at least once per day
<persia> martoss: When did you join the group?
<martoss> think it was sunday
<persia> martoss: It's definitely sync'd then.
<persia> (resync doesn't happen every day, just most days)
<mok0> Perlit Rendehest
<martoss> ok, is uploaded
<martoss> revu login is the same as the launchpad account?
<soren> mok0: ?
<amarillion> martoss, fill out your email address and let the login fail, then you can request a new one
<persia> martoss: Not at all.  If you've uploaded to revu, you can recover your password from REVU.
<martoss> ok
<martoss> how long must i wait for the "Recover"  not giving me a message like "No REVU account for martin.hoefling@gmx.de exists yet." :-)
<martoss> kk, got it
<martoss> great, login works now...
<DarkSun88> Hi all
<martoss> ok, first thing would be to fix lintian stuff in eric
<DarkSun88> persia: Ping
<martoss> can someone look at my lintian report of eric? I do not fully understand it's meaning.
<persia> martoss: Pastebin it (with lintian -iIv)
<martoss> http://www.pastebin.org/14549
<Ng> persia: in your review of Terminator you mentioned using DEB_CHANGELOGS_INSTALL_ALL - I'm a little confused in that the package seems to include the upstream and debian changelogs already anyway
<bddebian> Heya gang
<martoss> hi bddebian
<bddebian> Hello martoss
<DarkSun88> Hi bddebian :)
<bddebian> Hi DarkSun88
<DarkSun88> bddebian: Thanks :)
<martoss> can sb look through http://revu.tauware.de/details.py?package=eric and give me comments about the standards error?
<broonie> martoss: It means that your package says that it complies with a newer version of Debian policy than the lintian that is being used supports.
<broonie> Presumably because you are syncing a Debian package more current with policy than the Ubuntu lintian.
<martoss> hmm ok, should i decrease the version then?
<broonie> I'd just ignore it myself unless the policy changes broke something in Ubuntu (which is unlikely)
<martoss> ok, so this is not a problem for accepting a package
<amarillion> I get that problem as well in my package. I think that means lintian on revu needs to be updated
<amarillion> Locally I'm using the latest version of lintian in gutsy backports and it gives the reverse error: if you use standards version 3.7.2 it suggests upgrading to 3.7.3
<geser> Hi bddebian
<bddebian> Heya geser
<ScottK> martoss: 3.7.3 is what you should be using now.
<martoss> yepp, its 3.7.3 in mine as well
<Peaker> hi, how do I skip unit tests when building the python2.5 package?
<tuxmaniac> will tiber ever be back?
<tuxmaniac> how long does it take to get ones revu account activated after first revu upload?
<Ng> tuxmaniac: I did that recently and it didn't email me the password, so I used the revu website's password recovery feature and it worked fine :)
<tuxmaniac> Ng, Neither does the password recovery works for me
<Ng> ah
<martoss> tuxmaniac, several minutes
<martoss> cu later
<saivann> Hi everybody, I worked on bug #131530 and I would need a MOTU to approve and upload my debdiff for package bluez-gnome
<ubotu> Launchpad bug 131530 in bluez-gnome "'Browse device...' in the bluetooth applet is useless without gnome-vfs-obexftp" [Unknown,Fix committed] https://launchpad.net/bugs/131530
<saivann> ( for hardy )
<saivann> This debdiff only adds dependency for gnome-vfs-obexftp which is in main since yesterday, approved by Martin Pitt
<DarkSun88> See you later
<saivann> I will be busy for the next minutes but if someone want to take care of this, here's the debdiff :
<saivann> http://upload.leservicetechnique.com/bugs/bluez-gnome.debdiff
<geser> saivann: you need a core-dev for bluez-gnome, subscribe the ubuntu-main-sponsors team to the bug
<jdong> LucidFox: ok I'm gonna have a look at gtkpod-aac
<jdong> is dh_iconcache now gone for good and dh_icons should be used instead?
<saivann> geser : thanks
<pochu> jdong: yup
<jdong> pochu: ok, thanks.
<slangasek> pochu: no, liboobs-1-4 does not break g-s-t << 2.21.3, because there is no g-s-t << 2.21.3 that will *look* for liboobs-1-4
<slangasek> pochu: so it's a spurious breaks:
<pochu> slangasek: what about g-s-t 2.21.2.1?
<LucidFox> jdong> yes
<LucidFox> in fact, I have an updated version of gtkpod-aac
<pochu> slangasek: it depends on liboobs-1-4
<LucidFox> I'll upload it
<slangasek> pochu: hrm, well, that package doesn't seem to exist anymore :)
<pochu> slangasek: it did before seb128 sponsored g-s-t 2.21.3 ;)
<slangasek> pochu: so if it did exist and had a wrong dep, ok, that would explain it
<pochu> I think it was: we had liboobs-1-4 2.21.2.1 and g-s-t 2.21.2.1 depending on liboobs-1-4. Then with the liboobs 2.21.3 update which broke the api without bumping the soname because it was already bumped and this was an unstable release, we needed to bump the liboobs-1-4's Breaks for g-s-t
<pochu> Otherwise g-s-t 2.21.2.1 would use liboobs-1-4 2.21.3 and would break
<DarkSun88> Hi
<EtienneG> hey gang
<mneptok> everybody look busy! here comes ... oh shit. too late.
<LucidFox> jdong> I have uploaded updated gtkpod-aac interdiffs for the libmp4v2 transition
<EtienneG> any chance a fix for the flashplugin-nonfree ever get an official update through the repo ?
<EtienneG> just wondering if it is only a matter of time ...
<EtienneG> mneptok, dude!
<mneptok> EtienneG: i think the change has been uploaded, but returns 1 even though it actually works.
<mneptok> >:)
<amarillion> Where can I find docs on writing .desktop files?
<amarillion> Googling for "desktop files" gives a lot of false positives
<tuxmaniac> Hello. request a motu to review the package http://revu.tauware.de/details.py?package=alliance and comment/advocate if found ok.
<ScottK> amarillion: I believer that freedesktop.org is the place to look
<amarillion> thx I'll look into it
<\sh> grmpf..does anyone has a clue how to edit a patch from afterstep, which is not applying correctly...well it's the first one..I can't see anything wrong with dbs-edit-patch
<mneptok> amarillion: probably the best way to educate yourself is to take an example of a properly crafted .desktop (gedit may be a good bet) and dissect it.
<amarillion> How do I add binary files to a source package? I've got an icon for my app, and I put it in the debian dir.
<amarillion> But when I try to build the source package, I get
<amarillion> dpkg-source: cannot represent change to debian/alex.png: binary file contents changed
<\sh> amarillion: you should use uuencode/uudecode to push binary stuff inside a source package
<bddebian> amarillion: You cannot add a binary file that way.  You either have to use uuencode or some such, or better yet, use an xpm icon
<amarillion> ok, in this case xpm is easiest I guess
<amarillion> So you can't add binary files at all? I didn't know that
<\sh> amarillion: source package == binary stuff in debian/ dir
<LucidFox> Is it allowed to have a package that's a simple collection of themes under different licenses?
<\sh> hey bddebian btw :)
<bddebian> Hi \sh
<mok0> Suggestion: All MOTUs should have a special character in their nick, for example "@"
<LaserJock> heh
<LaserJock> that would make it more difficult for us to hide ;-)
<mok0> If  that is the first character, ppl can immediately see MOTUs online
<mok0> LaserJock: :-)
<mok0> It took me a while to figure out who in this channel are MOTUs -- there are probably still a lot I don't know...
<amarillion> not a bad suggestion
<mok0> Perhaps I should send a note to u-m
<LaserJock> if you think it'd be a good idea
<LaserJock> I'm not sure many MOTU would like the idea or if it's even possible to do only in #ubuntu-motu, but it may be worth looking at
<mok0> People may not want it, but I will suggest it anyway :-)
<stdin> LaserJock: just give them all an access level of 5 and set the channel AUTOVOICE level to 5 (like how it's done in -ops)
<LaserJock> stdin: yes, but I'm not sure that is a desired thing
<stdin> well you could set CMDVOICE to 5 instead, then they could choose when to be +v and when not
<stdin> (if I understand chanserv that is)
<mok0> stdin: that is also a possibility, but can it be seen in a /who listing?
<zul> its kind of like having a target on your back which alot of people probably dont want
<stdin> mok0: yeah, shows as H+
<mok0> But if you don't want to do MOTU stuff, you just use the ordinary nick
<stdin> you just devoice yourself
<mok0> (or don't set the + option)
<stdin> kind of like how it's done in #freenode
<mok0> stdin: exactly
<jdong> LucidFox: grumble I kinda did that while offline too
<jdong> LucidFox: lol lemme take a look at the new interdiff
<jdong> LucidFox: can you (1) version libmp4v2-dev (>= 1:1.6-0.1) (2) dh_iconcache -> dh_icons in debian/rules (3) put LP: #180406 in the changelog and repost the interdiff?
<LucidFox> jdong> it already has dh_icons
<ScottK> mok0: Back when I needed to know I just looked up the team on LP to see who was in it.
<LucidFox> as for the other two, sure
<jdong> LucidFox: ok you're right, I was looking at the wrong interdiff
<jdong> thanks
 * ScottK wouldn't want to be any more of a target.
<mok0> ScottK: OK, but it doesn't quickly show you who is online
<ScottK> True.
<LucidFox> should I also update Standards-Version to 3.7.3?
<ScottK> LucidFox: Yes
<mok0> Like stdin said, if MOTUs are made IRCops, then you can set the +H option to hide
<ScottK> Sounds like more work then to be in the same place I am now.
<ScottK> I'm not in favor.
<stdin> they don't need to have OP access to just have voice
<mok0> stdin: ok? I've never really used irc modes
<ScottK> My solution would probably be to just be grumpier so people would bother someone else.
<stdin> ChanServ will give them +v if they have access to CMDVOICE on the channel
<mok0> ScottK: You? Grumpy? Naaa
<LucidFox> jdong> reuploaded
<jdong> LucidFox: thanks
<mok0> ScottK: My concern is to make it easier for people to communicate efficiently on IRC.
<ScottK> I understand.  My concern is to be able to idle on the channel and jump in where I care to without getting pinged on to much.
<ScottK> If I can't, I probably won't.
<ScottK> So there may be unintended consequences to your proposal.
<mok0> ScottK: Perhaps there could be a watch schedule
<ScottK> If we were paid to be here, sure.
<mok0> he
<nxvl_work> mok0: what are we talking about?
<stdin> you could set +v when you're "available to help" and leave yourself unvoiced when you're just popping in, up to you
<mok0> stdin: +1
<slangasek> nxvl_work: he's talking about painting targets on the MOTUs
<nxvl_work> why?
<bddebian> easier to hit :-)
<nxvl_work> and its needed because...
<jpatrick> poor us... :(
<nxvl_work> i don't see in which case that would be useful
<jpatrick> nxvl_work: https://lists.ubuntu.com/archives/ubuntu-motu/2008-January/002994.html
<stdin> if you need a mentor or someone to look in revu
<mok0> easier for newbies to become involved & effective
<nxvl_work> because then we are going to need a paint for the MOTUs, one for the u-u-s, one for the main developers, and so one
<jdong> LucidFox: gtkpod-aac uploaded
<nxvl_work> stdin: a MOTU, isn't necessary working on revu
<ScottK> mok0: I'd say easier for motus to get bugged.
<ScottK> Generally I think it's better to ask questions of the channel and let whoever answer.
<nxvl_work> and any contributor with experience will be able to mentor any other, not only a MOTU
<stdin> nxvl_work: I just said look at it, not approve it ;)
<nxvl_work> stdin: i'm just saying what i think :D
<mok0> nxvl_work: true
<stdin> I think what I say, I think... :p
<nxvl_work> ScottK: right
<jpatrick> I don't think a ubuntu/motu/* cloak is possible
<nxvl_work> it isn't a good practice to look for someone to help without a good reason to look for him/her
<mok0> jpatrick: I think there is a mode where you can hide (?)
 * LaserJock suggests we give the new people a target instead ;-)
<nxvl_work> it's better to ask on the channel and the one who can help does it
<LucidFox> jdong> Thanks!
<mok0> nxvl_work: ... ppl can still do that
<nxvl_work> mok0: newbies wont
<nxvl_work> i have been a newbie 3 moths ago, and i'm still kind of it
<amarillion> Why is the ISC license preferred over BSD?
 * ScottK thinks jdong should be the designated target.
<mok0> nxvl_work: I thought you were MOTU ;-)
<nxvl_work> and newbies don't ask on the channels
 * ScottK did when I was new
<nxvl_work> mok0: nop, still not, just contributos
<nxvl_work> contributor*
<LaserJock> amarillion: what are you referring to?
<nxvl_work> i have gone trough the mentor program and i'm not a mentee anymore, but still not a MOTU
<amarillion> Well, a few days ago I was discussing the license of speed-game, the package I'm working on right now
<amarillion> It currently doesn't have a license at all
<nxvl_work> ScottK: did you take a look at the bug i ask?
<mok0> amarillion: then it can't be distributed
<amarillion> somebody here mentioned the ISC licence
<nxvl_work> wrong channel
<amarillion> mok0, no worries
<ScottK> Yes
<amarillion> I contacted the author and he said to go ahead with the ISC license
<ScottK> amarillion: It was persia
<amarillion> right
<amarillion> so the package is in good shape, and I'm ready to put the appropriate licensing text there
<LaserJock> according to wikipedia it's "It is functionally equivalent to the 2-clause BSD licence, with language "made unnecessary by the Berne convention" removed."
<amarillion> and I'm googling for the actual text. It's not in /usr/share/common-licenses
<amarillion> BSD is
<LaserJock> yes, I've never heard of ISC
<amarillion> LaserJock, right. So that made me wonder why persia suggested ISC and not simply BSD
<LaserJock> well, I suppose it's a bit free-er and simpler
<LaserJock> it's not that BSD wouldn't work
<amarillion> So which text should I include in the package? Is it this: http://ictlab.tyict.vtc.edu.hk/pub/tarball/dhcp-3.0b2pl3/ISC-LICENSE?
<jdong> oops some half-asleep idiot forgot to call debuild with -sa... :D
<LaserJock> amarillion: whatever text the author uses
<amarillion> LaserJock, yeah but I have to apply it. The original author told me to go ahead and not bother him :)
<LaserJock> hah
<amarillion> it's a little game that is finished, not some library or other ongoing project
<LaserJock> yeah, well it's completely undistributable legally without a license
<amarillion> Well, here is what he said: http://paste.ubuntu-nl.org/51254/
<jdong> hmm why did I get two Accepted e-mails for the same sponsored pload?
<joejaxx> mok0: are you sure that is not going to become a ping list?
<amarillion> I'll wait to see if persia can clarify
<mok0> joejaxx: Not really
<mok0> joejaxx: but some of the MOTUs seem to .-)
<joejaxx> mok0: :)
<joejaxx> i was just wondering how the symbol would help since we have the queue and revu system
<joejaxx> and mostly everyone here answers questions if they {see it,know the answer}
<joejaxx> :)
<mok0> joejaxx: just so ppl can recognize what MOTUs are online
<joejaxx> so you would only have the +v if you are not idle?
<mok0> joejaxx: yes
<joejaxx> ah ok
<joejaxx> that clears up the confusion :)
<mok0> joejaxx: it's probably better to use the mechanisms that are build into IRC
<mok0> joejaxx: better than a special character in the nick
<joejaxx> i thought you meant like #gentoo-dev where devs/contributors have a mode set all the time
<joejaxx> which is the equivalient to a ping list
<joejaxx> but your suggestion is interesting
<mok0> joejaxx: I guess you can set/unset it as you please
<joejaxx> equivalent*
<mok0> joejaxx: it should be discussed at a motu-meeting I guess
<mok0> joejaxx: ... it could also be voluntary
<joejaxx> oh ok
<mok0> joejaxx: anything is possible :-)
<pochu> mok0: that should be discussed with the IRC council too I guess, since '@' is operator and '+' is voiced.
<mok0> pochu: sure, those characters were just "random" ones
<pochu> oh, is it possible to set others?
<mok0> pochu: I think you can use any ascii character in a nick, right?
<mok0> Another way of doing it is giving MOTUs CMDVOICE rights, stdin said that before
 * RainCT fully agrees with ScottK's reply to mok0's proposal
<mok0> RainCT: no hard feelings :-)
<joejaxx> i keep confusing ScottK and Steve.*K
 * joejaxx keeps forgeting who is who :\
<ion_> Theyâre really the same person.
<mok0> me too
<joejaxx> Toadstool: lol
<joejaxx> gah
<joejaxx> ion_: *
<ScottK> Between the two of us we make up one person who never sleeps, but seems to know a lot less when it's daylight in North America.
<joejaxx> lol :P
 * ion_ tries to figure out how someone could mistype âionâ as âToadstoolâ. :-)
<joejaxx> ion_: haha
<joejaxx> :P
<joejaxx> autotabwhileshiftingfingers ftl
<ScottK> mok0: Just hurry up and get MOTU and then you can change your nick to MOTU-mok0.
<mok0> ScottK: lol
<mok0> ScottK: Still educating myself...
<mok0> ScottK: Trying to get my packages from gutsy -> debian
<ScottK> Sure.  No problem.  By the time you think you are ready, you will have already have been ready for some time.
<mok0> ScottK: You think I should apply now?
<nxvl_work> mok0: you need much to became a MOTU, you only need to hug everyone
 * joejaxx has that problem as well
 * mok0 hugs nxvl_work 
<ScottK> mok0: I haven't been paying close enough attention to what's going on here to have a strong opinion.
<joejaxx> i do not know when i am going for it
<ScottK> It's possible you're ready.
<joejaxx> maybe next release cycle
<joejaxx> lol
<Amaranth> i've been at this since 2005 and only recently tried to become a motu :P
<joejaxx> lol
<mok0> Amaranth: so, either you are lazy or incompetent :-P
<nxvl_work> Amaranth: define "at this"
<ScottK> Or inconsistent.
<Amaranth> packaging and such
 * mok0 hugs Amaranth 
<Amaranth> although since becoming MOTU i haven't uploaded a single thing...
<Amaranth> probably because the only thing i want to has to be uploaded in sync with stuff in main so mvo just does it too :)
<nxvl_work> i plan to become a motu by hardy release
<ScottK> mok0: So why is theseus FTBFS on everything but i386 it's tried so far?
<mok0> ScottK: Beats me. I have looked at the logs and I can't see what's going on
<mok0> ScottK: I have no problems building on amd64, but that fails too
<ScottK> I suspect I know what it is.  Let me have a look at the package...
<mok0> ScottK: Thanks!
<slangasek> looks clear to me, arch: any package and the binary-indep target is populated by mistake
<slangasek> so it builds with dpkg-buildpackage -b and FTBFS with -B
<ScottK> mok0: ^^^
<ScottK> Is it meant to be arch all or arch any?
 * mok0 tries to understand slangasek
<slangasek> it's compiling stuff, so it needs to be arch: any
<mok0> slangasek: I will take a look
<mok0> It's supposed to be "any"
<ScottK> mok0: Look at Debian New Maintainer's Guide section 4.4
<mok0> there isn't even an "indep" target
 * mok0 looks at DNMG
<mok0> ScottK: Still don't understand what you guys mean...
<ScottK> You don't define binary-arch
<mok0> I thought only "install" was mandatory...
<ScottK> Since it's arch:any then you need to define the per-archicture build requirements.
<ScottK> i386 works because that's (by coincidence) where arch all packages get build
<mok0> ScottK: OK...
<mok0> I can introduce the install-arch and install-indep targets
<ScottK> So right now you have an arch:any package with nothing to build for the other archs.  I think, but I'm not an expert on this.
<mok0> ScottK: However, I can't see that explained in DNMG
<ScottK> I was more thinking of the example where on line 51 and on it shows how to set your rules files for arch dependent builds
<mok0> ScottK: Got it. Thanks. I guess I should fix it and re-upload to REVU?
<ScottK> No.  Since it's just a new debian revision, file a bug and attach a debdiff.
<ScottK> Then subscribe UUS
<mok0> ScottK: I'll get right on it
<mok0> ScottK: So, with every arch except i386, it is built with the -B flag?
<ScottK> Yes
<ScottK> That sounds right.
 * mok0 finally gets it
<amarillion> I uploaded a new version of speed-game: http://revu.tauware.de/details.py?package=speed-game
<amarillion> All issues have been addressed, it's ready for a review again
<ScottK> mok0: Then you're one step closer to being ready.  FYI, I broke Spamassassin to learn this.
<mok0> ScottK: yikes
<ScottK> I fixed an arch:any problem in the indep part of debian/rules.  It worked for my on i386.  I uploaded and everything else broke.
<mok0> ScottK: one of the more tricky packaging bugs...
<ScottK> Well now I know.
<mok0> So, in fact, binary-arch should be a mandatory target
 * rzr updated http://revu.tauware.de/details.py?package=jaaa
<ScottK> mok0: It's mandatory for an arch:any package.  Not for an arch:all package
<jpatrick> Perdente: welcome!
 * mok0 has to check up on his reading...
<Perdente> hey!
<ScottK> mok0: Here's an arch:all that's the other way around: http://www.openspf.org/svn/software/postfix-policyd-spf-perl/tags/2.005/debian/rules
<Perdente> I was looking to help programming any way I can, I have taken some classes and I've been running ubuntu for about a year now and I really want to help program any way I can
<mok0> ScottK: thx
<mok0> ScottK: ... and that only builds an "all" binary package. Makes sense to me
<ScottK> Yes.  And that's all there is for that package
<jpatrick> Perdente: prehaps reading the packguide?
<mok0> ScottK: What's XS-DM-Upload-Allowed: yes ?
<pochu> mok0: to allow Debian Maintainers to upload those specific packages if they are the Maintainers
<ScottK> That's a Debian specific thing for Debian Maintainer (which I'm not quite yet) uploading allowed
<mok0> ScottK: ah
<Perdente> jpatrick, I know this sounds really dumb, but I'm a quick learner, where' the packguide again?
<jpatrick> !packguide > Perdente
<TheMuso> !packguide
<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
<TheMuso> ah right. Thought that didn't work.
<pochu> TheMuso: heh, I /msg'ed ubotu too :)
<jpatrick> I forwarded it to him ">"
<pochu> jpatrick: yeah but packguide vs packagingguide :)
<TheMuso> jpatrick: Yeah I saw. Didn't think that was possible either.
<jpatrick> pochu: it's an alias now
<pochu> looks easier to write :)
<RainCT> will Hardy ship with Firefox 2 or 3 by default?
<pochu> 3
<RainCT> nice :)
 * joejaxx is hoping Hardy is not an Edgy-ng :P
<Perdente> jpatrick, well looks like this is a nice read how late will you be here today?
<jpatrick> Perdente: woah, I should of been off ages ago.., but I'm sure someone would be able to help you out from here, and I'll be on later :)
<Perdente> ok, thanks!  I'm just now trying the Debhelper packaging so it will take a little while anyway
<ScottK> Perdente: Generally if you have questions it's better to ask the channel so whoever is here and know can answer.
<Kmos> RainCT: it will be default after alpha 3
<Perdente> ScottK, done and done. :)
<persia> Just for reference, in case anyone wants to answer amarillion next time, ISC is preferred to BSD if you are not the Regents of the University of California because /usr/share/common-licenses/BSD can only be used if the the Regents hold copyright on the source, and ISC is shorter, so wastes less archive space when duplicated.
<persia> Ng: If you see a changelog in your binary package, ignore my complaint about it being missing.  I didn't see one.
<mok0> ScottK: theseus package fixed. I set bug status to "confirmed" but I can't remember if that's the right thing to do.
<ScottK> Confirmed or Triaged are fine.  Did you subscribe UUS?
<mok0> ScottK: yep
<ScottK> Then you should be done except maybe to answer questions.
<mok0> Great
<ScottK> What bug?
<mok0> Bug #181359
<ubotu> Launchpad bug 181359 in theseus "FTBFS error on all archs but i386" [Undecided,Confirmed] https://launchpad.net/bugs/181359
<ScottK> Maybe persia will take pity on you and have a look at it ^^^.  I'm out of here in 2 minutes.
 * persia has very limited time now, and is expected to be deep idle in about 7
<mok0> No rush
<persia> mok0: Looks sane,  I don't have time to build twice right now, but it ought get picked up soon.
<mok0> persia: yeah I think so
<ScottK> See you all later.
<RainCT> good night
<mok0> Goodnight
<Ng> persia: I'll check with a fresh build, but I seem to see changelog.gz and changelog.Debian.gz locally
<persia> Ng: Sorry about that.  My missing-changelog comment was based entirely on linda's checking logic, but that may not be accurate.  Be sure to try a build against hardy.
<Ng> ah that's a good point, I've just been building on gutsy :)
<the_belgain> hello - quick question: what's the version naming convention for packaging software which doesn't have fixed release numbers, but just SVN revisions and dates?
<mok0> http://www.debian.org/doc/debian-policy/ch-binary.html#s-versions
<the_belgain> great, thanks - so the SVN revision isn't appended to the version number
<the_belgain> does the SVN revision usually get mentioned anywhere in particular in the package?
<the_belgain> debian/changelog maybe?
<mok0> the_belgain: doesn't harm to put it theer
<pochu> If it's a svn checkout and not an stable tarball, then yes, in the version string (which is both in the files and in debian/changelog)
<the_belgain> so the directory name (when using dh_make) should be eg. "packagename_20071219-svn578" ? to get the version string picked up correctly
<the_belgain> sorry, i mean packagename-20071219_svn578
<jscinoz> persia you here?
<pochu> the_belgain: is it a new package?
<pochu> or an update?
<the_belgain> new package
<persia> jscinoz: No.  You'll do better to ask your questions generally, rather than asking me, as I'm really not around much right now (and no, this isn't a joking "no", I just happened to see that on my way out).
<pochu> the_belgain: I'd use packagename_0+svn578 then, just in case they release 0.x or 1.x so you don't need to add an epoch
<pochu> some people
<pochu> already get lots of useless pings
<pochu> persia: s/some people/I/ ? ;-)
 * pochu runs
<the_belgain> will do, thanks (that doesn't seem to be inline with the debian policy manual, but I guess that's OK?)
<pochu> the_belgain: why not? If it's a pure svn checkout it does.
<the_belgain> ok, fair enough - thanks for all the quick replies
<pochu> the_belgain: Or does upstream release tarballs as 20071219?
<pochu> In that case it should be 20071219+svn578
<the_belgain> http://fuppes.ulrich-voelkel.de/download/
<the_belgain> the tarballs aren't explicitly dated
<pochu> that's  fuppes-SVN-578.tar.gz, so I'd go with 0+svn578
<jscinoz> :P
<jscinoz> hey guys
<jscinoz> if i have non-free components that cant be included in the source package and are small file size can these be downloaded via the preinst script?
<slangasek> only if the package is in multiverse
<slangasek> if it's in universe, installing it shouldn't pull non-free bits onto the system
<the_belgain> i have a package which has dependencies in multiverse (lame in this case) - does that mean the package should be in multiverse?
<the_belgain> presumably yes?
<ScottK> Yes
<the_belgain> just checking, thanks
#ubuntu-motu 2008-01-09
<the_belgain> another quick question - i'm using debhelper for packaging, and it's not quite calculating all the dependencies i'm expecting
<the_belgain> in particular, i have liblame-dev as a build-depends, but it's not adding liblame or lame as a runtime dependency (which i think it does need) - is this a common gotcha?
<the_belgain> obviously I can add it manually...
<mok0> the_belgain: you don't have to. The -dev package will pull in the other ones
<the_belgain> it does for most of the -dev libraries, but not for lame it seems
<slangasek> the_belgain: you probably want to look at the build log and at the ldd output of your program first, to confirm whether liblame is being pulled into the build the way you're expecting
<mok0> Why do you need lame?
<the_belgain> the program i'm packaging (fuppes) is upnp media server / renderer which does transcoding - it uses lame to transcode audio to mp3
<mok0> the_belgain: so it needs to check for lame during the build, I guess.
<mok0> the_belgain: you have to specify lame in build-depends, then
<slangasek> mok0: he already said that he did
<the_belgain> i've specified liblame-dev in the build depends, yes
<mok0> but if configure (?) checks for the lame binary, then you need to put it in build-depends, and with a Recommends: in the binary package
<the_belgain> is the problem that the packages are called "liblame-dev" and "liblame0", which is confusing debhelper?
<slangasek> the_belgain: there are two overall explanations for not getting the dependency on liblame that you expect: 1) the library isn't being linked in during your program build the way you expect, 2) liblame0 doesn't have a proper shlibs file and therefore the dependency isn't being autocalculated even though the library is used
<mok0> liblame0 contains the shared libraries, if your binary is linked to that, dh_shlibs should find it
<slangasek> I've just verified that liblame0 does have a proper shlibs file, which leaves the other case to examine
<the_belgain> ok, i'll check the compile output to see if it looks like it's being pulled in correctly.  thanks
<the_belgain> pbuilder builds take forever to run... :(
<mok0> the_belgain: use cowbuilder
<zul> evening
<bddebian> Heya gang
<ScottK> Heya bddebian
<bddebian> Heya ScottK
<wolfger> Got a question about my lintian results... How do I resolve the following:
<wolfger> gpg: Can't check signature: public key not found
<ScottK> That's not a lintian result
<ScottK> Don't worry about it.
<wolfger> ok, cool
<wolfger> is that due to pbuilder, that my public key isn't found?\
<Hobbsee> hi wolfger
<Hobbsee> Fujitsu: ping
<wolfger> Hi Hobbsee
<Hobbsee> wolfger: my c-n-f bug really isn't on crack.  you just didn't read it.
<wolfger> Hobbsee: right... I didn't read closely enough the first time to recognize the package assigned was c-n-f.
<wolfger> then when I looked c-n-f up, it said it was for bash, so I assumed it did not apply to zsh. Incorrectly assumed, as it turns out ;-)
<wolfger> live and learn
<Hobbsee> wolfger: readme says it does zsh too.
<leonel> sÊÉoÉ¹ nÊunqn   nice
<wolfger> ???
 * wolfger wonders how the heck leonel did that
<_MMA_> http://www.revfad.com/flip.html
<wolfger> I feel like I am missing something when it comes to building a package. I now have a .dsc that passes linitian with no errors, and I'm done with the guide.... how does this become a .deb?
<bddebian> pbuild it? :)
<wolfger> bddebian: as opposed to the "sudo pbuilder build ../*.dsc" I already ran?
<bddebian> Ah, that should have produced a .deb
<bddebian> DId you look in your results dir?
<bddebian> Or did it possibly fail to build?
<wolfger> maybe I'm just too tired to be doing this right now... It built okay (finally), but I am at a loss for where the "results dir" would be.
<wolfger> hm
<wolfger> dpkg-deb: building package `memaker' in `../memaker_0.1-r134-1_i386.deb'
<Hobbsee> wolfger: wherever you set it in your pbuilderrc
<Hobbsee> usually /var/cache/pbuilder/result/
<wolfger> ah
<wolfger> Thanks, Hobbsee
 * wolfger is getting nervous.... this is taking far too long to install
<wolfger> oh, never mind. It's done. Been done for who knows how long... :-P
<bluefoxicy> siiiigh.
<bluefoxicy> vmware won't do any sound at all
<bluefoxicy> and there's nothing holding /dev/dsp
 * bluefoxicy can rmmod the module but can't insmod it, hrm
<bluefoxicy> er.  Can't write to the device with it insmoded...
<leonel> wolfger: http://www.en.fliptext.net/
<Fujitsu> Hobbsee: Pong.
<_MMA_> Im trying to find the bug about GDM not using the background color set in gdmsetup. Any help?
<_MMA_> Got it.
<LucidFox> Where can I find a plaintext version of CC-BY 2.5?
<alephant> Hi all... is there a well-formatted feed (RSS?) of package updates which I can use to feed my "validate updates before they break production" RHN clone?
<alephant> I'd prefer to parse a machine-friendly format like RSS, than to combine ``apt-get upgrade'' with a screenscrape of Launchpad.
<nxvl_work> if a bug is duplicated it's needed to be marked as invalid, didn't it?
<StevenK> If it's duplicated, mark it as a duplicate?
<Hobbsee> Fujitsu: nvm, i found out.
<LaserJock> hmm, can you tell an app to use a different path for a lib at runtime?
<LaserJock> I've got devel libraries installed to /usr/local/ and normal apps are picking them up ... and crashing
<dholbach> good morning
<gpocentek> hello dholbach
<dholbach> hey gpocentek
 * dholbach hugs gpocentek
 * gpocentek hugs dholbach back
<minghua> LaserJock: Won't LD_LIBRARY_PATH work?
<minghua> LaserJock: If not, maybe LD_PREPLOAD, but I've never used that.
<minghua> LD_PRELOAD, of course.
<jscinoz> hmm
<jscinoz> i'm working on packages for the semifree game UrbanTerror, the game engine is GPL (with some components under other free licenses) and the data files are all free to distribute except for one file which is under the Quake3 SDK license. if i say excluded this file from the source package and had the binary package download it (its only 1.3mb) in the preinst, would this be acceptable?
<liri> morning
 * minghua likes persia's proposal of allowing (Debian's) Original-Maintainer and Uploads to do uploads for main packages. 
<freeflying> anyone would like give any suggestion about Bug #181029
<ubotu> Launchpad bug 181029 in scim-bridge "[FTBFS] scim-bridge (0.4.14-1) fails to build in hardy" [Medium,Confirmed] https://launchpad.net/bugs/181029
<man-di> minghua: I dont follow Ubuntu lists, can you give me a link to persia's proposal?
<slangasek> freeflying: I agree with minghua, removing it is the best way around the error.  Or are you looking for something more?
<minghua> man-di: Sure, https://lists.ubuntu.com/archives/ubuntu-devel/2007-December/024886.html
<freeflying> slangasek: actually, I don't want to maintain two version in Debian and Ubuntu :P
<minghua> man-di: To be precise, it's (MOTU) and (Debian's maintainer and uploaders).
<man-di> minghua: thanks
<slangasek> freeflying: so, why could you not simply remove the .pot file in an upload to Debian, and allow this to propagate to Ubuntu?
<slangasek> freeflying: if the .pot file is empty it doesn't benefit the Debian package either, so removing it at build time also won't hurt Debian
<minghua> slangasek: I think missing POT file will cause FTBFS on Ubuntu buildd as well, though I'm not sure.
<hstraub> Hallo, my name is Herbert Straub and I ask about the re-sync of the REVU uploaders keyring. I followed the instructions MOTU/Packages/REVU. My launchpad account is herbert.
<Fujitsu> hstraub: I'll resync it.
<slytherin> Hi all, is there any way to identify java related packages in universe/multiverse that need fixing (apart from FTBFS)?
<Fujitsu> slytherin: What do you mean by 'fixing'?
<slytherin> Fujitsu: any sort of problems, bugs, watch files, unmet deps. I am looking for an easy way to locate java apps/libs with problems. Because I can only help in that area
<dholbach> slytherin: you should talk to doko (once he's back from Holidays again) and man-di - looks like a Java team is coming up :)
<Fujitsu> It'd be nice to have something like packages.qa.d.o at some point, collating all of the QA information per-package.
<slytherin> dholbach: as of now I have helped fix few FTBFS. But now I am looking for something different. I will still try to fix FTBFS though.
<slytherin> my next target is lucene2
<man-di> slytherin: when you want to fix something in java packages please send the report to Debian BTS, I will look into it, do an upload and then you can sync
<slytherin> man-di: ok
<Fujitsu> hstraub: It's done.
<slytherin> man-di: On 'batik' front, I think it should now compile with GCJ except JPEG and TIFF codecs part. But I think latest version has an additional dependency. Should I file a bug for this in debian?
<huats> morning everyone
<slytherin> oops, bug is there already
<man-di> slytherin: problem is that we have software in the archive that depends on batik providing TIFF codec, and it does only when its compiled with SUN JDK
<man-di> icedtea will probably work too, but I dont checked that yet
<slytherin> man-di: icedtea won't make a difference from gcj. It doesn't have those sun specific classes.
<man-di> so no option to moving to another JVM for building for now
<slytherin> man-di: which software are you referring by the way which depend on codecs? I will take a look if they work with latest version
<man-di> btw: batik is currently actively worked on it debian
<man-di> slytherin: I think it was fop
<man-di> problem was that GCJ built batik fine, but fop dont build with the new batik anymore
<slytherin> hmm. I hope batik developers move away from sun specific apis soon
<man-di> slytherin: I think there is no other API providing that specific feature
 * Fujitsu thinks there is - in languages other than Java.
<Fujitsu> Silly Java.
 * man-di slaps Fujitsu 
 * Fujitsu preempted that.
<man-di> ...we could integrate JRuby or Jython and use Ruby or Python to implement it...
<man-di> there was also some PHP interpreter written in Java...
<slytherin> I wonder why Apache Commons' developer have not developed an alternative yet
<Fujitsu> That sounds worse than normal PHP, and that's pretty bad.
<Fujitsu> No buffer overruns, I guess.
<hstraub> Fujitsu, thank you...
<man-di> slytherin: they dont saw the need, tiff is not so widely used. You need a critical mass of users who need a feature...
<slytherin> hmm
<man-di> Fujitsu: its for cases when you want to run everything in a Java Application Server
<man-di> that has its benefits, but also its troubles
<freeflying> slangasek: its not a dfsg issue, so i don't think it is a best way to remove it directly from upstream tarball
<rzr> talking about java ... what's news about openjdk ?
<rzr> s/what's/what are the/g
<slytherin> rzr: news as in? icedtea is in Ubuntu. Hopefully it will make into Debian soon.
<rzr> great
<rzr> so tuxguitar will quit contrib to main
<slytherin> rzr: depends on it's dependencies. openjdk/icedtea can not fully replace Sun's JDK as of yet
<rzr> that's what i am reading at http://icedtea.classpath.org/wiki/FrequentlyAskedQuestions#Functionality_and_Testing
<rzr> no sound yet ..
<man-di> rzr: we (Debian) are a bit reluctant to move pcakges from contrib to main just because of icedtea, it should better work with another free runtime too.
<man-di> rzr: after all icedtea is i386, amd64 and powerpc only
 * pochu waves
<man-di> and powerpc is limited
<rzr> I plan to make a nativebuild (in debian) of tuxguitar in next upstream release
<man-di> rzr: for what? What do you gain by this?
<geser> good morning
<rzr> then it will not requiere sun jvm
<rzr> and can be in main
<man-di> rzr: I really doubt that
<man-di> rzr: that will only work when it works with GCJ as byteocode too
 * minghua can't believe someone is proposing Ubuntu to adopt Gobolinux's filesystem layout because it "sounds like fun"...
<slytherin> man-di: The problem with lucene2 in Ubuntu is some unit tests for contrib libraries are failing, not the core. Can we bypass this failure? Or how about unit testing only core.
<Fujitsu> minghua: That's what people do...
<Fujitsu> minghua: ubuntuforums?
<rzr> man-di: It will , if we wrap the sound layer to alsa
<minghua> Fujitsu: No, some list, should be -devel-discuss.
<Fujitsu> Oh gawd, they've migrated to there now!?
 * Fujitsu screams.
<Fujitsu> I thought we kept that kind of person in the forums.
<minghua> Heh.
 * Fujitsu is behind on -devel-discuss by several hundred messages, fortunately.
<man-di> rzr: ah, you meant providind an additional JNI library to access also, I thought you meant compiling tha jars to native code with gcj
<minghua> Fujitsu: Me too.  I just browse my inbox through the web interface now and then before I download them via POP3, and such messages always intrigues me.
<rzr> minghua: we do both
 * minghua has been more and more happy about the -devel and -devel-discuss split.
<Fujitsu> Ah, so there is some sanity to it.
<Fujitsu> /Variable/tmp
<pochu> DarkSun88: congrats! :)
<dholbach> DarkSun88: congratulations! :)
<slytherin> man-di: Can you please reply to my question. It is about lucene2. May be you missed it.
<minghua> man-di: I think rzr meant to speak to you a few lines above.
<man-di> slytherin: good question
<man-di> minghua: I guessed that
<man-di> slytherin: so it does FTBFS on Ubuntu?
<slytherin> man-di: Yes.
<man-di> slytherin: do you have a link to a log?
<slytherin> man-di: just a minute
<rzr> man-di: minghua is right
<rzr> :)
<slytherin> man-di: Some problem with my network. Can you please check this page - http://qa.ubuntuwire.com/ftbfs/
<man-di> the host seems down
<slytherin> man-di: I will be back after a coffee break. We will discuss after that.
<man-di> I need to do some customer work here too...
<geser> man-di: http://launchpadlibrarian.net/11125011/buildlog_ubuntu-hardy-i386.lucene2_2.2.0-2_FAILEDTOBUILD.txt.gz
<man-di> geser: thx
<man-di> slytherin: I cant test currently if that fails in Debian too
<man-di> slytherin: if not I would be for an ubuntu-only patch
<man-di> slytherin: if yes we should patch debian and sync
<slytherin> man-di: I am ok with this approach.
<man-di> slytherin: can you work on this? I'm currently on limited time
<amarillion> I'd like to request a REVU review for my package speed-game please: http://revu.tauware.de/details.py?package=speed-game
<slytherin> man-di: I don't have access to any Debian machine. And I am doing all this in my free time in office. No net connection at home presently. :-(
<slytherin> man-di: I can try setting up debian pbuolder chroot. But it will take time
<amarillion> are you all already running hardy on your machines?
<man-di> slytherin: hmm, can test on Debian but not yet, tonite I can
<slytherin> man-di: No problem. I will wait.
<slytherin> amarillion: why are you asking that? :-)
<amarillion> I'm on gutsy, I have to keep remembering to adjust the target distribution to hardy before uploading my package
<amarillion> Which is a pain
<amarillion> also, I'd like to redirect some friends to my ppa to test some of the packages I'm working on
<amarillion> but they are running gutsy of course
<amarillion> so I'm feeling rather schizophrenic about gutsy/hardy
<slytherin> amarillion: You can use dch command to add an entry to changelog and use -r option to set release. You can set an alias as follows 'alias dch="dch -i -r hardy"'
<amarillion> ah that will help, thanks
<amarillion> so which release are you running then? Is hardy too unstable for day to day use?
<Fujitsu> ........
 * Fujitsu looks at KmosReport.
<Fujitsu> Why is #164166 marked as a positive?
<slytherin> amarillion: I am not using it on my office machine. But using it at home.
<man-di> I wonder why people are making such a hard time to Kmos regarding cyphesis-cpp
<man-di> I guess for everyone else it would be synced already
<Fujitsu> dholbach: Can you please clarify why you thought that was a positive?
 * pochu enjoys his first requestsync bug :)
<dholbach> Fujitsu: ok... just read up on the irclogs
<Fujitsu> It could have probably been explained better on KmosReport, sorry.
<minghua> dholbach: Speaking of KmosReport, I don't see any solution proposal in bug 181029.
<ubotu> Launchpad bug 181029 in scim-bridge "[FTBFS] scim-bridge (0.4.14-1) fails to build in hardy" [Medium,Confirmed] https://launchpad.net/bugs/181029
<\sh> moins
<minghua> hello
<minghua> hello \sh.
 * minghua grumbles at his new keyboard that has \ key in a different place.
<dholbach> minghua: the bug report is about a FTBFS - Marco says "It needs a cleanup of empty files in po/ directory."
<dholbach> minghua: if you want to re-word "solution proposal" to something else indicating that he analyzed the problem, that's fine with me
<minghua> dholbach: But how?  And I remember that a missing POT file will cause a similar FTBFS.
<dholbach> minghua: really? most apps ship without .pot files and build OK - we explicitly have to run     cd po; intltool-update -p   for some to get the .pot file for rosetta
 * dholbach -> break
<minghua> Okay, something is seriously wrong with pidgin here...
<minghua> dholbach: I may well be wrong.  I just remember seeing some building problem with missiong POT file before, around the dapper days.
<mok0> minghua: yes I've seen that too...
<minghua> dholbach: I'll change it to "correct analysis" on the wiki, regardless.  I believe that's okay for you?
<minghua> mok0: Pidgin crashing, or build problem with missing POT file? :-P
<mok0> minghua: pidgin randomly crashing
<mok0> minghua: On amd64/gutsy
<persia> mok0: I encountered that from about october 15th to around november 15th.  Might be worth looking at the changelogs.
<mok0> persia: you mean the problem was solved in a newer version?
 * minghua cancels apport crash report sending, seeing there is no usable backtrace.
<minghua> mok0: hardy i386 here.
<persia> mok0: pidgin was remarkably unstable for a while, especially when interacting with IRC.  It seems to have settled now, but my system typically has the unstable and broken bit inverted, so it's not always a good indicator of real issues or real solutions.
<mok0> minghua: what pidgin version?
<minghua> mok0: 1:2.2.2-1ubuntu1
<mok0> persia: the problem we saw was in jabber
<mok0> minghua: same version here
<persia> mok0: See.  That's why I only report bugs when I can reproduce them in sterile environments :)
<mok0> persia: good point :-)
<minghua> mok0: Huh?  But changelog says that's a hardy version.
<minghua> Anyway, pidgin has been stable for the past few weeks until tonight's upgrade.
<mok0> minghua: Ah, sorry, 1:2.2.1 here
<minghua> So I doubt it's pidgin's fault.
<minghua> (pidgin was not in tonight's upgrade)
<mok0> minghua: could be coincedental
<pochu> \o/ My first upload :-)
<persia> Hurrah!
<\sh> pochu: congrats :)
<\sh> btw...pidgin and jabber is aweful...just use gajim as jabber client and search for a jabber server with many transports available ;)
<rzr> i use biltbee
 * persia doesn't think pidgin or gajim integrate with biltbee very well...
<DarkSun88> dholbach: pochu Thanks a lot.
<DarkSun88> :)
<\sh> hmm...I'm searching for someone in germany who wants to have a new job as IT Projectmanager :)
<\sh> Karlsruhe Area ;)
<Nafallo> \sh: naah. using lots of servers is more fun.
<Nafallo> \sh: I use my own server in London for jabber, slomos brothers server (de) for yim, norweigan for icq, swedish and danish for msns :-)
<\sh> Nafallo: lol ;)
<ion_> I use my own server for jabber as well. :-)
<rzr> \sh: bring the job in france and we'll talk
<\sh> rzr: that's a problem :)
<\sh> rzr: come to germany...karlsruhe is next to strassbourgh (sp?)
<dholbach> minghua: sure, that'S ok
<sectech> I wouldn't mind re-packaging gusty applications for hardy, I was wondering if someone out there could walk me though it once first though. I am totally new to packaging
<sectech> I did read the documentation
<sectech> Is there anyone willing to give me a hand?
<persia> sectech: In many cases, the gutsy packages were just reused for hardy entire, unless there had been an update in the meantime.  At this point, we're mostly looking at bugfixes, although there are still a few candidates for consideration for an update.  What sort of thing would you like to do?
<sectech> I'm trying to find a way to contribute... I have enough programming experience just get by... I figured there must be something that I could work on
<sectech> believe me I have plenty of time (I lost my job a while back haha)
<ion_> Note to self: I should check whether sync is enough or a merge is required to get ruby1.9 from sid to hardy.
<persia> sectech: Well, there are basically three classes of work that might be a good introduction to the process.  Finding and fixing bugs (many have patches that just need review & integration), working on some of the QA tasks, and addressing integration issues.  Also, some people like to focus on a specific programming language or set of application functionality.
<sectech> Okay.... How about bug fixes and patching...I could give that a shot
<Kmos> when we've 0ubuntu1 and it mention about the maintainer field spec in changelog, it still needed at 0ubuntu2 revision ?
<Kmos> i need to mention about the spec in 0ubuntu2 changelog
<Kmos> ?
<persia> Kmos: We only rephrase all the "Retained changes" during a merge.  An update just needs new changes.
<\sh> grmpf...never test afterstep in a running gnome desktop session...
<Kmos> persia: ah ok =) thanks
<sectech> Basically I would reproduce the bug, apply the patch and see if it's still there right?
<persia> sectech: https://launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_contact=&field.bug_commenter=&field.subscriber=&field.component
<sectech> k
<persia> That horrid URL will provide a list of all the bugs that have a patch candidate.  Where the patch isn't a debdiff, or the sponsors aren't subscribed, it frequently needs review & testing.
<sectech> ok... I'll look through that and see if I can make sense of it
<persia> Also, you might try https://launchpad.net/ubuntu/+bugs?field.tag=bitesize or https://launchpad.net/ubuntu/+bugs?field.tag=packaging, or even https://launchpad.net/ubuntu/+bugs?field.tag=patch as additional sources of things that tend not to be too hard (and the sort of thing for which  people here may be happy to help if you get stuck)
<\sh> persia: could you do me a favour and catch the debdiff for afterstep from bug #174252 and upload please?
<ubotu> Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252
<persia> \sh: I've promised myself no sponsoring tonight in the hopes of catching up on a couple other things :(
<\sh> persia: ok :) np...
<\sh> pochu: you can do it now ,-)
<persia> Could anyone else please help \sh with this?  I'm guessing it's needed now to resolve some alpha 3 goal.
 * \sh 's fixing emacs21 now
<\sh> but before that..I'll upload the patch to debiqan
<pochu> \sh: looking
<\sh> pochu: thx..
<minghua> \sh: It would be nice if you can avoid those timestamp changes in the patch...
<minghua> \sh: But since pochu is looking now, you can ignore my opinion. :-)
<pochu> minghua: that'd mean more work since those are autogenerated by autofoo, aren't they?
<sectech> What about installing hardy and searching for bugs? just to begin with so I can get used to the QA system?
<\sh> minghua: well, that comes from a simple thing...the afterstep package needs some magic before working with dbs-edit-patch
<\sh> minghua: to use dbs-edit-patch you need to run make -f debian/rules debian/vars and this will introduce those changes
<pochu> sectech: if it's not a critical box and you aren't afraid of breaking it or killing your cat, go for it :)
<\sh> minghua: I talked to robert (the debian maintainer) and it's normal
<pochu> sectech: but keep an stable install somewhere just in case ;)
<sectech> I think I have another hard drive around here.
<\sh> minghua: and yes, you can remove those changes from the diff but it's so trivial we can live with it somehow...
<mruiz> hi all
<minghua> \sh: Ah, I see it's not easily avoidable.
<minghua> \sh: Then I say it's not worth the effort.  I am not the sponsor anyway. :-)
<persia> sectech: Just in case, it's worth reviewing https://wiki.ubuntu.com/MOTU/Contributing.  I'm guessing you've already read it from your earlier statement about documentation, but it might help give some hints about processes.
<sectech> persia Yeah I did read that...
<pochu> \sh: uploading
<\sh> pochu: thx a lot
<\sh> pochu: I'm adding a debdiff for emacs21 just now
<sectech> When I start with horde... what's the URL where I would post the bugs to?
<\sh> sectech: horde bugs or ubuntu bugs?
<persia> sectech: Likely https://bugs.launchpad.net/ubuntu/+source/horde/+fielbug, but I'm just guessing.
<sectech> ubuntu horde
<\sh> sectech: launchpad
<TheMuso> Hey pochu. Whielding the super upload opwers I see. Congratulations!
<TheMuso> powers
<mruiz> hahaha
<TheMuso> DarkSun88: Congratulations!
<DarkSun88> Thanks a lot Luke :)
<DarkSun88> At all my sponsors and not naturally :D
<\sh> DarkSun88: yeah congrats from me too :)
<DarkSun88> :D
<DarkSun88> Thanks
<\sh> well, camlimages, emacs21 and just now driftnet will be fixed too :)
<\sh> good afternoon jono and jdstrand :)
<jdstrand> hi \sh!
<jono> hey \sh
<\sh> grmpf../me should get ready for the gym...
<minghua> Can anyone stop this "Daniel Moyne" person's reporting bugs?
 * minghua points at #181475 (and -76, -77, -81, -82, -83, -84).
<man-di> minghua: he must have done a break at -78, -79, -80...
<persia> minghua: most of the earlier bugs on https://bugs.launchpad.net/~dmoyne/+reportedbugs don't seem quite so egregious.  Perhaps just a multiple submit issue?
<minghua> persia: Yeah, I meant temprarily.  Not a ban.  I assume bona fide here.
<persia> Seems to have stopped, anyway.
 * minghua wonders why persia is so fast at marking duplicates...
 * persia has practice :)
<tuxmaniac> Can somebody please review http://revu.tauware.de/details.py?package=alliance and give their valuable feedback? Thanks in Advance.
<persia> minghua: Simple recipe: go to the submitters +reportedbugs, open all the bugs in tabs, click "Mark as duplicate" in successive tabs, grab the bug number into the X buffer in the last tab, iterate back middle-clicking and submitting.  Reload +reportedbugs to ensure that you caught them all.
<persia> Actually, this works for a package bug page too.
<persia> tuxmaniac: Is it lintian and linda clean, with maxiumum verbosity and hardy versions, for both source and binary?  (these generate >60% of my comments on packages on REVU).
<mok0> persia: did you upload theseus this morning?
<persia> mok0: I don't remember uploading anything this morning.  Why?
<mok0> I patched it last nigth and it is already built. Just wondering who to thank
<minghua> persia: I'm doing similar things here.  But LP is not really very responsive for me...
<persia> mok0: The bug didn't get an assignee when it was sponsored?  You can check the signature on the .dsc or on the mail to -hardy-changes if you like.
<pochu> TheMuso: heh, yeah, and thanks :)
<\sh> pochu: http://launchpadlibrarian.net/11229263/emacs21_21.4a%2B1-5ubuntu5.debdiff http://launchpadlibrarian.net/11229512/camlimages_2.2.0-2ubuntu1.debdiff http://launchpadlibrarian.net/11229790/driftnet_0.1.6-7ubuntu1.debdiff http://launchpadlibrarian.net/11229884/gdal_1.4.4-1ubuntu1.debdiff  ready for review and upload :) (bug #174252)
<ubotu> Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252
<persia> minghua: Interesting.  My packets are going trans-pacific, and then trans-atlantic to get there.  I don't know why I'd have less latency.
<mok0> Ah. dholbach, thanks! :-)
<pochu> \sh: that will have to wait, 'cos I'm off to lunch :)
<\sh> pochu: np ... just not to forget...wmaker just fixed..simage needs more love then I expected
<pochu> \sh: feel free to poke DarkSun88 who is newbie ;)
<\sh> but right now, I'm off to the gym...need to get rid of 10kg ;)
<tuxmaniac> persia, did you get my message?
<persia> tuxmaniac: Not that I noticed.  What did you message me about?
<imbrandon> LaserJock: your behind MOTU post is titled " dholbach "
<bddebian> Heya gang
<imbrandon> looks like that might be incorrect
<imbrandon> heya bddebian
<tuxmaniac> lintian and linda are complaining about newer standards version is that warning ok persia ?
<persia> bddebian: I'm about to be off, but you were looking for me earlier?
<bddebian> Hi imbrandon
<tuxmaniac> bddebian, boo
<imbrandon> heya persia :)
<bddebian> persia: Yeah but I forget why :(
<bddebian> Hi tuxmaniac
<dholbach> imbrandon: I posted it
<geser> Hi bddebian
<bddebian> Heya geser
<emgent> hello there :P
<persia> tuxmaniac: If lintian is complaining, you're not using the latest lintian.  You may ignore linda for now when she says that 3.7.3 is too new.  Also check the binary packages by running against $arch.changes
<slytherin> tuxmaniac: It is fine
<bddebian> persia: Oh I remember.  I'll hit you up "tonight" if you are around
<imbrandon> dholbach: ahh ok, it showed up on planet with the wrong title :)
<slytherin> tuxmaniac: oops, follow persia
<persia> bddebian: Tell me quick, and maybe I'll have a quick answer :)
<dholbach> imbrandon: argl....
<bddebian> persia: Nah it was more about helping my dumb arse with something again
<slytherin> Please give me an advice. I am going to patch source to fix an FTBFS. The problem is due to missing header files from sources. But the function calls that are giving problem are anyway deprecated in latest GTK+. So is it better to replace those call appropriately or should I just go ahead and add header files.
<persia> slytherin: I like updating to the newest API: it means you have longer before the next time the package needs a patch, and upstream is usually happier to receive the update patches (if you do a good job).
<slytherin> persia: Ok. :-)
<slytherin> The functions are deprecated in GTK 2.12. So I guess it will be long before they are actually removed. But I will anyway replace those calls.
<bddebian> What TZ is slangasek in?
<soren> bddebian: He's on the west coast of the US.
<soren> bddebian: I don't know what $TZ that translates into.
<bddebian> soren: Ah that's right, thanks
<soren> bddebian: np :)
<bddebian> A little early yet then :-)
<soren> bddebian: Slightly, yes :)
<dbmood1> hi got a suggestion re a possible fix for the issue of ubuntu (tis not its fault) managing laptop hd in laptop mode
 * rzr updated http://revu.tauware.de/details.py?package=jaaa
<apachelogger> dholbach: mail for you
<dholbach> apachelogger: gracias
<apachelogger> de nada
<apachelogger> I think ;-)
<jpatrick> ja
<apachelogger> jpatrick: trÃ¨s bien
<jpatrick> apachelogger: merci
<slytherin> yay, one more FTBFS sent down the rabbit hole. :-)
<slangasek> bddebian: hi, so two things on the asc upload
<bddebian> Uh oh
<slangasek> bddebian: 1) omg, who prepared this upstream tarball, it's an embarrassment
<bddebian> Uhm, upstream. :)
<tjaalton> jdong: could you change the maintainer to MOTU when you upload the next version of gtkpod-aac? thanks :)
<slangasek> bddebian: 2) I don't know what the procedure is within the Debian games team for adding new comaintainers.  According to the changelog, you added yourself; was this acked by someone who was an existing uploader, or is there a standing debian-games policy I can refer to in this regard?
<slangasek> bddebian: yeah, I know it was upstream, I did compare the tarballs... :)
<jdong> tjaalton: aww you don't want to be scapegoat anymore? :D
<bddebian> slangasek: Hmm, good question, I don't know that we have a set "policy".  I have usually just been adding myself when uploading.
<tjaalton> jdong: right, I don't use it anymore, so.. :)
<tjaalton> banshee is a whole lot easier
<bddebian> slangasek: BTW, I built it with libparagui1.1 on my sid laptop this morning and everything works fine.
<jdong> tjaalton: ok, will do.
<slangasek> bddebian: I'd appreciate a clarification on this, then; I don't assume that just because someone has commit access to a repo, they're empowered to mark themselves as an uploader
<slangasek> (and this would be a blocker for me sponsoring it to Debian)
<bddebian> slangasek: fair enough
<tjaalton> jdong: great, thanks!
<bddebian> I'm thinking I really should have just stuck with porting Hurd packages..
<azeem> there's so many PATH_MAX waiting for you!
<bddebian> hah
<bddebian> Well let's see if I actually get a response from the Games Team ML this time...
<linuxfan> k
<LaserJock> bah, dholbach needs to get some real American hours ;-)
<geser> LaserJock: you could also adjust to european working hours :)
<LaserJock> umm ....
<LaserJock> ;-)
<DaveMorris> Hi, I'm still looking for a revu of http://revu.tauware.de/details.py?package=libserial (it's a small package to build)
<bddebian> LaserJock: Or you can just say screw it like I'm getting closer to doing.. :)
<joejaxx> bddebian: lol
<joejaxx> slangasek: what exactly is a release wizard? :D
<bddebian> I think I'm either going to have to apply for DD or stop trying to work with Debian
<azeem> there's this DM thing now as well
<slangasek> joejaxx: a modal dialog that walks you through releasing an OS
<joejaxx> slangasek: bah :P i mean the contributor position :)
<joejaxx> slangasek: haha :P
<joejaxx> slangasek: based on ncurse library? :)
<joejaxx> azeem: where is the information on DM's?
<slangasek> joejaxx: python-glade
<bddebian> azeem: Aye, but I'm not sure that is enough
 * joejaxx at the developer corner and does not see it
<joejaxx> s/at/is\ at/g
<joejaxx> slangasek: :P
<slangasek> bddebian: if you're talking about asc, I think it would be equally inappropriate for a DD to add themselves to uploaders without consulting the current uploaders (and I have dressed down DDs for this before)
<bddebian> slangasek: No, asc is one small part of the picture
<bddebian> slangasek: For asc, you might have better access to sam than I.  I can't ever get a hold of him
<slangasek> bddebian: did you mail the games team ML then?  I don't see anything in the archive at http://lists.alioth.debian.org/pipermail/pkg-games-devel/2008-January/thread.html, is that not the right list?
<bddebian> slangasek: http://lists.debian.org/debian-devel-games/2008/01/msg00107.html
<slangasek> ah so
<\sh> re
<\sh> phew...first time in my life that I entered a gym...now I know what horror means...
<geser> that bad?
<\sh> geser: if you never did sport for your health...it's that bad, yes :)
<\sh> btw...has anybody time to do some sponsor uploads for libgif transition? :)
<geser> \sh: I could do some in a few hours (if there are any left)
<\sh> geser: yeah there are some...I put them on the bug...
<\sh> I wonder what's the best way to fix simage...
<Ward1983> if i would like to see something packages, where should i suggest the package?
<warp10> I have a weird problem with a .desktop file. It is here: http://revu.ubuntuwire.com/revu1-incoming/tennix-0801042050/tennix-0.5.0/tennix.desktop
<Ward1983> * packages = packaged
<warp10> It shows fine in Ubuntu, but according to pitti it doesn't in Debian, altough it is installed in the proper directory: http://paste.ubuntu-nl.org/51377/
<geser> Ward1983: see https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<Ward1983> geser, ty
<Kmos> warp10: gnome uses "menu" file
<Kmos> ups..
<Kmos> warp10: debian i mean
<geser> Kmos: doesn't gnome in debian uses both?
<Kmos> geser: yes
<Kmos> :)
<warp10> Kmos: I thought they use both... am I wrong?
<Kmos> warp10: nop.. only ubuntu uses .desktop file
<slangasek> do you mean "ubuntu only uses the .desktop file"?  because Debian does use both
<Kmos> slangasek: right
<bddebian> warp10: Do you have a source package somewhere, I'll try it on my unstable machine
<warp10> bddebian: orig, diff and dsc that pitti used are in this tarball: http://colangelo.eu/tennix.tar.gz
<bddebian> warp10: trying now
<bddebian> warp10: One thing.  If you're adding a desktop file you should call dh_desktop in rules
<warp10> bddebian: the .desktop file comes from upstream and is installed by Makefile. Should I add dh_desktop anyway?
<bddebian> warp10: Hmm, probably.  But either way, it works for me on my unstable laptop :-)
<warp10> bddebian: Well, ok. I'll report that to pitti. Thank you so much for your help :)
<bddebian> NP
 * jpatrick wonders if it's a good idea to subscribe to debian-mentors with a @(k)ubuntu address
<bddebian> jpatrick: It shouldn't hurt
<jpatrick> bddebian: here goes
<pochu> jpatrick: I post to a few debian lists and my packages have my @ubuntu.com address in the Maintainer/Uploader and I haven't seen a flame because of that yet :)
<Kmos> warp10: even coming from upstream, you should use dh_desktop
<warp10> Kmos: I'm wondering if this could be the source of the problem, but according to the test bddebian just made, it shouldn't be. Anyway, thanks, I'll modify rules :)
<norsetto> warp10: dh_desktop is pretty much useless now (unless you register a mime type)
<bluekuja> heya norsetto
<db-keen> would anyone be willing to help me make my first package?
<bluekuja> norsetto, would you please un-assign amachu from me? seems to be disappeared since ages now
<bluekuja> :)
<jpatrick_> bluekuja: I saw him today on #kubuntu-devel
<bluekuja> jpatrick_, really?
<norsetto> bluekuja: you tried to get back in contact?
<warp10> norsetto: mmm... so looks like I'll leave rules as it is now.
<bluekuja> norsetto, not really...I answered him on the I was mentoring him with
<jpatrick> bluekuja: /msg seenserv seen amachu
<bluekuja> norsetto, and for something like 2 weeks, I got no answers
<bluekuja> jpatrick, ty
<bluekuja> norsetto, want me to ping him on irc?
<norsetto> bluekuja: please
<bluekuja> norsetto, ok perfect
<bluekuja> :)
<norsetto> bluekuja: let me know
<bluekuja> norsetto, I will
<bluekuja> norsetto, as soon as I get him on irc, seems to be not connected since 2h 12m
<bluekuja> norsetto, so he should be around tomorrow
<bluekuja> ;)
<norsetto> bluekuja: he is in india (or thereabout), so I think he might be gone to bed already
<bluekuja> yep
<bluekuja> norsetto, are reports  from mentors still up?
<norsetto> bluekuja: yes, but nobody bothers and I got tired of reminding
<bluekuja> norsetto, I'm happy about hellboy195's work, he's doing good
<bluekuja> norsetto, *** that was my report :P
<norsetto> bluekuja: glad to hear that
<norsetto> bluekuja: I wish I would get even that from the others .....
<hellboy195> bluekuja: oh man. do not overstate ;)
<norsetto> hellboy195: good is not overstating, he didn't  say exceptionally well ....
<hellboy195> norsetto: good is also overstating ;)
<bluekuja> lol
<hellboy195> let's say it's OK
<bluekuja> hellboy195, step by step
<bluekuja> anyway off for a shower
<bluekuja> bbl
<jpatrick> norsetto: my mentee's gone kernel packaging....
<hellboy195> bluekuja: hf
<bluekuja> hellboy195, ty
<bluekuja> heya apachelogger
<bluekuja> * apachelogger_
<norsetto> jpatrick: good, tell him to package the latest rt2x00 drivers then
<norsetto> jpatrick: oh, and tell him to make sure they actually work .....
<apachelogger_> ahoy bluekuja
<jpatrick> :)
<LaserJock> ah ha! I think I figured out how to fix Planet Ubuntu's messed up Behind MOTU titles
<pochu> It confused me to see dholbach's interview when I saw the tittle :)
<LaserJock> yeah
<pochu> title*
<LaserJock> it seems to either takes the title of an attached pic or  the author
<LaserJock> apparently using Atom instead of RSS fixes it
<LaserJock> I guess it's a wordpress bug but I've only seen it cause problems on Planet
<blueyed> RAOF: thanks for the nouveau packages in your ppa!
<sommer> hey all, if I want to patch a package and I need to change three files, is it better to create 3 patches or 1 patch for all 3 files?
<LaserJock> sommer: might depend on if they are related
<LaserJock> generally it's fine to do just 1 patch
<sommer> LaserJock: gotcha... I don't think you'd apply one patch without the others, if they are in different files that is
<LaserJock> and if the reviewer wants them split up they'll request that
<sommer> LaserJock: cool, thanks
<geser> sommer: one patch or three patch is only relevant if the package uses a patch system
<sommer> geser: ah, I'm thinking one patch to rule them all is fine, probably only 12 lines changed between all 3... heh
<\sh> bah now I'm stucked again..openscenegraph needs gdal..which is not uploaded for the transition :(
 * \sh needs to become a motu again :(
<apachelogger> \sh: you shouldn't have left in the first place :P
<\sh> apachelogger:heheheh..ha found the sponsor I need ,-)
<apachelogger> ohnoes
<\sh> well, then I write my application
 * apachelogger notes that archive.ubuntu.com is far too slow today, or maybe his alpha3 downloads are blocking everything, whatever it is, it's not good
<\sh> apachelogger: it's quite fast for me :)
<apachelogger> so, it's alpha3
 * apachelogger kicks kget
<DarkSun88> Hi all. In debian/changelog there are a Debian old style entries. http://pastebin.ubuntu.com/3419/
<DarkSun88> At line 1201 there is the problem and debuild not works.
<DarkSun88> In this case, what I do?
<soren> DarkSun88: Those don't look like old style entries to me.
<DarkSun88> What are?
<soren> DarkSun88: Anyhow, what does debuild say exactly?
<soren> DarkSun88: I don't understand your question..
<DarkSun88> soren: parsechangelog/debian: error: badly formatted heading line, at file debian/changelog line 1201
<soren> Hm... Maybe there are other old styles that I am not familiar with.
<\sh> DarkSun88: looks like a bug in a newer entry....parsechangelog is not always correct
<soren> DarkSun88: I just fetched linkchecker and added a new changelog entry, and ran debuild -S -uc -us. It works fine.
<DarkSun88> Ok.
<soren> DarkSun88: Hmm... well, I guess those are just old style entries lacking an author field.
<soren> I've never seen that before (but I'm not that old, either).
<DarkSun88> soren: :)
<soren> If a project using python-distutils installs a bunch of stuff in the wrong places, do I edit the setup.py script, or am I supposed to pass a lot of clever arguments to setup.py?
<norsetto> Congrats DarkSun88!
<DarkSun88> norsetto: Thanks. :)
<pochu> soren: if the changes will be accepted upstream you can change it and forward the patch. Otherwise you can pass them with some PYTHON_something variables if you are using CDBS, or in your setup.py call if debhelper
<pochu> soren: but upstream will likely accept it, I guess.
<\sh> cool...end of business for today :)
<soren> pochu: Er, yes, I'm aware of the mechanics of passing arguments, I was just wondering if there was a way to tell it to do this stuff by passing it arguments of if I had to change the script.
<\sh> cu tomorrow
<bddebian> Later \sh
<sladen> win 222
<jpatrick> wow
<pochu> soren: python setup.py --help install will tell you the options for passing the prefix for the modules, data, scripts...
<pochu> soren: is that what you meant? :)
<soren> pochu: Ah, I tried --help and --help-commands, but didn't try --help install..
<soren> pochu: Er.. no, that still doesn't help me much.
<soren> pochu: It sets wwwpath = '/var/www/foobar'. I want to change that to '/usr/share/foobar/www'. How to do?
<LaserJock> hmmpf, alpine doesn't do maildir :(
 * RainCT would like to know if it's easy to create customized ubuntu CD's, as he's thinking about preparing a live CD for himself (with openbox as window manager and a custom selection of applications)
<TheMuso> RainCT: Not really.
<TheMuso> RainCT: It requires a bit of work.
<TheMuso> RainCT: But it depends on how much you want to customize the CD.
<TheMuso> I.e do you want to take an existing image and change, or do you want to build from scratch.
<RainCT> do you know about any good documentation about it?
<RainCT> (would be based on Ubuntu's image)
<TheMuso> RainCT: From scratch, or take existing image?
<RainCT> taking an existing one
<TheMuso> There is reconstructor or whatever its called.
<TheMuso> And I believe there are docs on community.ubuntu.com to help you do what you are wanting to do.
<RainCT> cool, thanks
<TheMuso> np
<Amaranth> anyone feel like handling bug 181604?
<ubotu> Launchpad bug 181604 in lsongs "File sharing and MP3 tag processing are broken" [Undecided,New] https://launchpad.net/bugs/181604
<Amaranth> it's got a debdiff
<Amaranth> oh, but it doesn't use a patch system
<tbf> pochu: thanks for bug report, but what is FTBFS?
<persia> Amaranth: Patch systems aren't mandatory, as long as you stay in line with Debian packaging.  Also, best to subscribe the sponsors queue to request upload.
<persia> tbf: Fails To Build From Source
<Amaranth> apparently he is the official lsongs maintainer now :P
<Amaranth> i mean, upstream
<tbf> persia: thanks
<Amaranth> but he can't do a new release yet, some transition stuff happening
<Amaranth> he wants me to upload it for him but i don't feel comfortable doing it
<Amaranth> eh, I could just blame him if it breaks :)
<slangasek> Amaranth: "handle" it how? seems to specifically fail the maintainer spec?
<persia> Amaranth: Personally, I believe best practice is to use a patch system unless you are maintaining a VCS that derives from upstream.  If upstream releases a patch with no patch system, and is also the Debian maintainer, it's not an issue to not have a patch system :)
<RainCT> Uh.. Now there's something that I don't understand: why are package with "Section: unknown" in debian/control synced successfully but building new Ubuntu revisions of them fails?
<RainCT> bug 181624
<ubotu> Launchpad bug 181624 in icon-slicer "Build of revision 0.3-1ubuntu1 failed" [Undecided,New] https://launchpad.net/bugs/181624
<RainCT> well.. good night all :)
<Amaranth> slangasek: I can't seem to find any documentation about that and I don't really remember what is required there
<slangasek> Amaranth: https://wiki.ubuntu.com/DebianMaintainerField
<pochu> soren: could you point me to the setup.py?
<rexbron>  question. When I am compiling openlibs on amd64, it uses lib64 instead of lib. is there a way I can override that?
<mok0> I've uploaded the perfect package to REVU. I bet you wont find any errors in it: http://revu.ubuntuwire.com/details.py?package=gpp4
<mok0> rexbron: use switch -m32 ?
<rexbron> mok0, could you explain what that does?
<mok0> rexbron: it compiles a 32 bit binary on a 64 bit platform
<rexbron> as well as where to use it
<rexbron> mok0, it compile 64 bit binaries like it should
<mok0> rexbron: gcc
<rexbron> it just installs them to lib64 (which is a symlink, but is not present in the debian build dir)
<mok0> rexbron: ah. That must be hardwired in the Makefile somehow
<rexbron> :(
<mok0> rexbron: grep for it
<mok0> find . -type f |xargs grep lib64
 * Fujitsu wonders how someone managed to file the same bug 7 times.
<ubotu> Launchpad bug 7 in rosetta "Need help for novice translators" [Medium,Confirmed] https://launchpad.net/bugs/7
<mok0> hehe
<mok0> 42
<Fujitsu> 20 minutes from first to last.
<mok0> Fujitsu: weird
<mok0> No takers for my PERFECT package?
<LaserJock> Fujitsu: hmm, impressive. I would've given up after 3 ;-)
<StevenK> LaserJock: Ponies!
<LaserJock> anybody know if there is no mta installed what happens to system mails?
<StevenK> They go nowhere
<LaserJock> or even how system mails are done
<StevenK> Since there is no /usr/sbin/sendmail to call
<LaserJock> I've got msmtp install now
<LaserJock> which would give sendmail
<LaserJock> but it only works for my user, not root
<LaserJock> so do they still go nowhere?
<ion_> Iâve been using ssmtp on my desktop boxes.
<LaserJock> hmm, I think I can create a systemwide msmtp config file
<LaserJock> but how does the system know where to send the email?
#ubuntu-motu 2008-01-10
<imbrandon> LaserJock: its per user in /var/spool/mail/user iirc
<LaserJock> even if /usr/sbin/sendmail exists?
<imbrandon> no, you ask where it was sent too
<imbrandon> s/too/to
<imbrandon> e.g. how does it know, it knows by user@system and delivers to /var/spool/mail
<StevenK> Sendmail (or variant) is what writes to /var/mail/<user> ...
<LaserJock> right
<imbrandon> err yea
<LaserJock> so I think I need to set up msmtp to do that :/
<imbrandon> LaserJock: why not just install postfix?
<LaserJock> bah, maybe I should just install exim4/postfix
<imbrandon> if you want local only, there is very little if any config for postfix
<imbrandon> on install
<LaserJock> well, I want system mail local, but I want to be able to send email out via SMTP
<LaserJock> I was using msmtp for sending out email to the smarthost
<imbrandon> smtp from your local box? most people will make that as spam imediately
<imbrandon> ahh ok
<LaserJock> but I think that meant that system mail got dropped
<imbrandon> smarthost, yea you can config postfix for a smarthost on install via debconf questions
<imbrandon> fairly simply
<LaserJock> yeah, I was just trying to go "lightweight" ;-)
<LaserJock> although I was just messing around with exim4 and I couldn't get it to work with my smarthost
<LaserJock> I'll see if postfix does any better
<imbrandon> :)
<StevenK> LaserJock: ssmtpd
<LaserJock> oh for goodness sakes, postfix is messy
<Fujitsu> LaserJock: Is it?
<StevenK> I don't think it is.
<Fujitsu> For setting up local with smarthost, debconf should do it all.
<Fujitsu> But even so, I find postfix' configuration to be not at all bad.
<LaserJock> my smarthost uses SSL authentication
<Fujitsu> Ahahaha.
<LaserJock> both exim4 and postfix seem to choke when I get to SSl
<LaserJock> I'm just gonna set up a system-wide msmtp config and see if that works
<phomes> is there a reason for gnome-games being stuck at 2.20.1 for gutsy? (and 2.20.0.1 for hardy btw) We are getting a ton of crasher reports from bugs in these old versions
<Burgundavia> phomes: we usually don't update, but talk with seb128
<slangasek> well, practically speaking for hardy things are stuck at 2.20.0.1 because 2.21.4 pulls in a new build-dependency which hasn't gone through the main inclusion process yet
<phomes> Burgundavia: okay, thanks
<slangasek> oh, correction; the problem for hardy now seems to be that the last build attempt happened right while LP was being ornery, and installing all build-deps failed
<phomes> slangasek: ok. No chance to get in alpha 3 then right? Too bad. I get the impression most testing of unstable versions come from people trying the alpha/betas of ubuntu
<slangasek> phomes: not much chance of getting it in alpha 3; depends on me snagging someone who can requeue it
<slangasek> Hobbsee: ping :)
<Burgundavia> slangasek: what needs to be done with the hardy alpha 3 page?
<Burgundavia> what new features need to be added?
<ScottK> For Alpha release notes is it appropriate to mention new stuff that needs testing.
<ScottK> ?
<slangasek> Burgundavia: good question.  the new OOo might be worth a mention, if that sneaks under the wire
<slangasek> Burgundavia: otherwise, it's anything that looks good from -changes :)
<slangasek> ScottK: sure
<ScottK> I ask because we recently did the libclamav2 -> libclamav3 transition and went from 0.91 to 0.92, so anything that uses clamav could use a good workout.
<ScottK> slangasek: That effort made me appreciate the Debian BinNMU process a lot more.
<ScottK> Not that it was a lot of packages, but it was my first library transition.
<Hobbsee> slangasek: pong
<Burgundavia> slangasek: I will poke this evening
<slangasek> Hobbsee: hi; do you want to try to send gnome-games back through the ringer? It looks to me like these build failures were tied to the mirror issue
<Hobbsee> slangasek: done, & reprio'd.
<slangasek> Hobbsee: cheers
<slangasek> ScottK: yes, it's been interesting for me to readjust to not having binNMUs... :)
<phomes> slangasek, Hobbsee: nice, thanks :)
<ScottK> Burgundavia: It'd be nice to get a mention the we've switched to libclamav3 and packages that use it really need some testing to make sure they still work as expected.
<bmm> Hi everybody. I've written a debian file indexing page, and I'm looking for people who would like to comment on it and people who would like to help adding debian archive urls. Any takers?
<ScottK> bmm: What problem are you trying to solve?
<Burgundavia> ScottK: some of that is release notes stuff, but maybe we should merge the release notes and this page, I don't know
<Burgundavia> slangasek: ^
<slangasek> Burgundavia: surely this is the release notes we're talking about?
<bmm> ScottK: My brother asked me if there was a lgenerals-data package somewhere, and how he should get that data on his computer. I couldn't find a way of finding out, so I decided to create an index of debian file urls.
<ScottK> bmm: Asking Google isn't enough?
<Burgundavia> slangasek: are we still doing seperate release notes detailing issues with the release?
<slangasek> Burgundavia: by "the release" do you mean hardy, or hardy alpha 3?
<bmm> ScottK: nope, didn't solve that for me.. but of course asking google is the next best thing.
<slangasek> Burgundavia: https://wiki.ubuntu.com/HardyHeron/Alpha3 is the draft for the alpha 3 release notes.  For final release notes, I'm assuming there's not much point in having anything separate yet since issues will come and go
<bmm> ScottK: I'm not sure google is that good at indexing debian files. Matching on filenames is not easy and knowing that it's a debian file is not really possible. I tried filetype:.deb but it didn't really result in anything ;-)
<ScottK> bmm: While for a data package it probably doesn't matter so much, mixing and matching Debian packages built for different releases can be problematic.
<bmm> ScottK: yes, that's true. It may be a good idea to post that on my page :-)
<bmm> Ok, I've added a notice to the page :-)
<bmm> ScottK: Thanks for you comment!
<ScottK> bmm: You're welcome.
<slangasek> phomes: right, so, on the next round the buildd itself works fine and shows again that one of the build-dependencies is not available in main, so.
<slangasek> nor do I see that anyone's started the process of trying to get it accepted in main
<bmm> Am I reading this correctly: "#!/usr/bin/python or #!/usr/bin/env python (the former is preferred)" means that I should uphold #!/usr/bin/python in favor of the env version right?
<bmm> (I would suspect the env python method being more flexible)
<slangasek> you should use #!/usr/bin/python, yes
<ScottK> bmm: #!/usr/bin/python is preferred
<ScottK> bmm: #!/usr/bin/python is more reliable.
<bddebian> Heya gang
<StevenK> '#!/usr/bin/env python' will search PATH, so could use /usr/local/bin/python leading to unexpected behavior
<slangasek> /usr/bin/env is only more flexible for supporting systems that don't support .deb packages
<bmm> Hihi, every time I start typing a comment, somebody answers it :-D
<bddebian> Ah, I see no response as usual from the games team on asc..
<slangasek> bddebian: er, I saw one response earlier when I looked at the list archive
<ScottK> Heya bddebian.
<bddebian> Hi ScottK
<slangasek> bddebian: anyway, it's come to my attention that the only uploading the current "Uploaders" ever did was to adopt the package into the games team
<bddebian> slangasek: Yeah, just Miriam
<phomes> slangasek: so that person starting that process should be me I guess (co-maintainer of gnome-games) any hints on where I should go to do this?
<phomes> bddebian: asc?
<slangasek> phomes: https://wiki.ubuntu.com/MainInclusionProcess needs to be started for ggz-gtk-client, if gnome-games is going to be using ggz in Ubuntu
<slangasek> bddebian: btw, does asc end up with a binary dep on libboost-regexp with this new upstream version?
<bddebian> phomes: Advanced Strategic Command
<slangasek> or do I dare hope that maybe it just needs a few templates?
<somerville32> I love asc! :D
<bddebian> slangasek: Hmm, good question
<phomes> is the games team a ubuntu team or would that be gnome-games team (me...)? Cause I should read up on asc then :)
<bddebian> Debian Games Team
<bddebian> We have several Ubuntu members :-)
<phomes> good - as long as it's not me not doing what I should :)
<bddebian> slangasek: Depends: asc-data (>= 2.0.1.0), libboost-regex1.34.1 (>= 1.34.1-2.1)  :-(
<slangasek> bddebian: what a horrible thing
<bddebian> I'm sure that's pulled in by shlib deps though, no?
<slangasek> yes
<bddebian> Might not really be necessary?
<slangasek> it's /using/ boost that's the horrible thing
<bddebian> Well...
<slangasek> especially since boost_regexp adds no significant functionality over regcomp() regexec() regfree()
<slangasek> well, ok - it gets you C++ memory management.  I don't think that's a very compelling reason to get one's application tangled up in boost. :)
<bddebian> Heh, aye
<StevenK> slangasek: "C offers you enough rope to hang yourself. C++ offers a fully equipped firing squad, a last cigarette and a blindfold."
<jscinoz> hey again everyone
<slangasek> StevenK: oh, but it gets better
<StevenK> slangasek: Oh?
<jscinoz> My preinst automatically downloads a 1.3mb file, its all working well but obviously it only shows the file download progress in the terminal window (its downloading using wget) is there a way to have it also output it graphically for users installing via synaptic or gdebi-gtk?
<slangasek> what's the one regexp in the whole program that asc uses boost for?
<slangasek> strrchr('.')
 * StevenK sobs
<slangasek> behold, the C++ Way
<slangasek> oh, no, my bad; there are others here that I overlooked
<slangasek> yes, yes - there's also one here that does dirname()
<bddebian> heh
<slangasek> bddebian: well if I were you I would hit your upstream with a shovel for doing this; but it's largely going to be your problem, not mine, that the package depends on boost and will be doomed to eternal pain where Debian testing is concerned, so - uploading
<bddebian> slangasek: Why is boost getting removed?
<slangasek> but the jwz quote is very apt here
<slangasek> bddebian: it's not, it's just constantly undergoing stupid ABI changes
<bddebian> Oh, aye, OK
<slangasek> and it has lots of other large reverse-dependencies which are never ready to go at the same time
<Hobbsee> hey, would the person who keeps feeling the need to smash me over the head with a large hammer every time i get up please stop?
 * bddebian hides the hammer
<Hobbsee> it's YOU!
 * ScottK relaxes
 * Fujitsu sneaks up behind ScottK.
 * ScottK looks in the rear view mirror
<lifeless> boost is not managed for ABI
<lifeless> AFAICT, by upstream
<bddebian> Rock on, thanks slangasek!
<bddebian> slangasek: Wanna join the games team, we NEED DDs? ;-P
<slangasek> bddebian: thanks, I'm on enough teams
<slangasek> lifeless: yes, which means that every time there's a release there's an soname change, which is an ABI change :)
<TheMuso> c
<TheMuso> ugh
<TheMuso> c
<TheMuso> argh orca let go of my keys
<StevenK> I suspect it did, because we saw that.
<rexbron> hmm, this is still troubling me
<rexbron> The configure script changes the lib directory to lib64 on 64bit archs
<rexbron> and makes the install fail
<jscinoz> hey guys, in my package there is a shell script for launching the application "urbanterror" the shellscript is to be placed in /usr/games/urbanterror. However since one of the two binary packages created by this source package is also called urbanterror, dh_install tries to copy the temporary build dir debian/urbanterror rather than the script which is also debian/urbanterror (but a file rather than a directory). any ideas how i can
<jscinoz>  get around this, short of renaming the shellscript or package
<slangasek> Burgundavia: OOo is almost certainly not going to make the cut for alpha3 at this point, since it just ftbfs on amd64.
<Hobbsee> oh goody
<Hobbsee> you can mention kde4, if it actually works though
 * Hobbsee heads to work
<Burgundavia> slangasek: lovely
<jscinoz> anyone know how i can deal with my dh_install problem?
<somerville32> jscinoz, use the -p option
<StevenK> jscinoz: Don't call the script debian/urbanterror
<StevenK> jscinoz: Call it debian/launcher or something, and then install it as debian/urbanterror/usr/games/urbanterror
<jscinoz> i am using the -p option somerville,
<jscinoz> stevenk, i was unware that dh_install would rename files
<StevenK> jscinoz: dh_install can't rename files.
<jscinoz> then how do i get it from srcdir/debian/launcher to usr/games/urbanterror
<slangasek> dh_install copies files, which means it can copy them to arbitrary locations
<jscinoz> i know, but i think what stevenk was suggesting is i have it named one thing in debian/ and another thing when its actually installed, and not sure how that would work
<jscinoz> >_<
<tonyyarusso> Hi, I was wondering why the fix for flash is taking so long still.  Anyone know?
<LaserJock> because nobody has figured out what to do with it?
<LaserJock> tonyyarusso: you know something I don't? :-)
<dholbach> good morning
<boomer> good morning
<TheMuso> Hey dholbach.
<dholbach> hey TheMuso, heya boomer
<LaserJock> dholbach!
<dholbach> hey LaserJock!
<jsgotangco> hello
<LaserJock> dholbach: I sent you an email
<dholbach> LaserJock: I noticed but didn't get to it yet - I'll take a look at it in a bit
<tonyyarusso> LaserJock: Really?  I thought imbrandon said it would only be another day or two - like two weeks ago.  Thought maybe something strange had come up that was unforseen, b/c he sounded like it was under control (and fixed in Hardy already, just not released vers)
<LaserJock> tonyyarusso: yes, I'd say something came up: https://lists.ubuntu.com/archives/ubuntu-devel/2007-December/024877.html
<Fujitsu> Yes, Adobe is silly.
<Fujitsu> And Konqueror doesn't like XEmbed.
<tonyyarusso> LaserJock: ty
<nixternal> BAH!
<nixternal> I wanted to check on getting another domain name, something a bit more professional sounding than 'nixternal.com', so I said hell, let me check johnson.com, and I could do richard@johnson.com, especially since my middle initial is A.
<nixternal> so I go to godaddy.com and enter Johnson.com and it tells me it is already taken, but here are some other options
<nixternal> http://www.nixternal.com/~rj/johnson.png   <-- these are the other options
<nixternal> wtf has this world come to?
<Fujitsu> Hahahahaah.
<LaserJock> lol
<Fujitsu> Nice, nice.
<nixternal> I am just going to change my name
<nixternal> my first name is Richard and my last name is Johnson, so I hear it all of the time, but a damn domain registrant telling me the same
<nixternal> this has gone to far
<LaserJock> I was thinking donjohnson.com but that might date me
<nixternal> you dated don johnson?
 * Fujitsu once knew a Richard Head.
<nixternal> sick
<nixternal> I know a Richard Head
<nixternal> went to high school with one
<Fujitsu> Same.
<nixternal> our football coach even called him dickhead
<Fujitsu> Haha.
 * Fujitsu notes that Firefox 3 is being even safer than IE7 wrt. untrusted certificates.
<Fujitsu> It doesn't even say where to go to add an exception.
<Fujitsu> Well, it does, but it's not right.
<nixternal> and if everyone has seen the old Little Ceasers pizza commercials, they will remember 'Pizza Pizza!'
<nixternal> well my Peurto Rican buddy started 'Pinga Pinga!'
<tonyyarusso> Fujitsu: when is FF3 final btw?
<Fujitsu> tonyyarusso: No idea whatsoever.
 * tonyyarusso remembers Pizza Pizza!
<nixternal> ok, back to bed for me...g'nite all
<Fujitsu> Night nixternal.
<Fujitsu> All I know about FF at the moment is that FF3b3 is actually worth using, unlike earlier FF releases.
<tonyyarusso> "Mozilla is on track to release the final version of Firefox 3 during the first quarter of 2008...we can expect the Beta 3 release sometime in February"
<tonyyarusso> So, quite likely before Hardy is released, but not necessarily by much?
<RAOF> bigon: Ping!  Re: gnome-keyring-sharp.
<bigon> RAOF: mmm I will recontact upstream
<tonyyarusso> what is gnome-keyring-sharp?
<RAOF> bigon: Oh, why?
<RAOF> bigon: I'm just hacking on your packages as found on LP bzr.
<RAOF> Adding a get-orig-source target, updating the versioning, etc.
<tonyyarusso> seems to not be in gutsy, all right
<bigon> svn://svn.debian.org/svn/pkg-cli-libs/packages/gnome-keyring-sharp/trunk
<bigon> actually
<bigon> RAOF: I don't think the bzr branch is uptodate
<RAOF> I thought I went there and found nothing.  Maybe the websvn was lying.
<RAOF> Ok, let's see what's changed...
<RAOF> Right.  Not that much.
<bigon> RAOF: upstream is waiting some feedback before making an official release
<RAOF> bigon: Right.  From whom?
<bigon> somebody who test his software :o
<RAOF> Such as may be garnered by putting a package into Debian Experimental, say? :)
<RAOF> bigon: I don't have write access to pkg-cli-libs svn.  If I supply you a diff would you kindly apply it?
<bigon> RAOF: ok if you could send it by mail
<RAOF> Yup, certainly.
<RAOF> I'll just check that the package as it is currently fails to build current SVN, then fix it :)
<RAOF> Yup.  Good.
<StevenK> RAOF: Finally reached level 60 :-D
<RAOF> StevenK: In not so impressive news, I've hit 30 :P
<StevenK> Heh
<RAOF> bigon: Patch sent.
<bigon> RAOF: thx
<RAOF> bigon: Do you remember offhand what else was required for banter (which is what I was originally interested in g-k-s)?
<bigon> telepathy-sharp(already pkg) gnome-keyring#
<dholbach> apachelogger_: thanks a lot for your mail - you should be on the net in a bit :)
<bigon> and notify@
<bigon> #
<RAOF> Thanks.
<bigon> RAOF: if I remember slomo was working on notify#
<RAOF> As in, libnotify-sharp?
<RAOF> Ah, inotify.
<bigon> no libnotify
<bigon> RAOF: I'm not sure if the .dll must go in /usr/lib/cli or /usr/lib/mono
<bigon> gtk is in /usr/lib/mono
<soren> pochu: http://git.fedorahosted.org/git/cobbler.git/?p=cobbler;a=blob;f=setup.py;h=c8a6b8136e2e6b7ba97290e8321c69defabedd13;hb=HEAD
<RAOF> bigon: Fair enough.
<dholbach> LaserJock: ROCK! BehindMOTU works now!
<LaserJock> ;-)
<RAOF> bigon: Ahhh... that'd be because gtk-sharp has dllmaps to native code, which is mono specific.  gnome-keyring-sharp doesn't, so I think it's meant to go in /cli.
<bigon> asking upstream
<RAOF> bigon: That'd be a #debian-mono question, surely?
<bigon> right :o
<bigon> http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html
<bigon> "The commonly seen /usr/lib/mono/packagename path should only be used for Mono project packages."
<bigon> RAOF: about notify-sharp https://bugs.edge.launchpad.net/ubuntu/+bug/139356
<lucas> hi, is Lukas Fittl around?
<dholbach> lucas: his nick is 'lfittl'
<huats> good morning
<slytherin> man-di: ping
<man-di> slytherin: pong
<man-di> slytherin: please write direct content when pinging me
<man-di> slytherin: I will answer when online or read backlog
<slytherin> man-di: Ok. Did you find any time to build lucene2 on debian?
<man-di> nope, sorry
<DaveMorris> Hi, I'm still looking for a revu of my package - http://revu.tauware.de/details.py?package=libserial - all previous comments have been addressed
<LucidFox> When creating an .orig.tar.gz from SVN, should I remove .svn directories?
<Kmos> LucidFox: yes
<Kmos> lintian gives you an error about that
<TheMuso> Greetings norsetto.
<norsetto> heya TheMuso
<norsetto> themuso: hope to see you soon in the core team ;-)
<TheMuso> norsetto: I hope so too.
<TheMuso> Its a Hobbsee!
<Hobbsee> heya!
<Hobbsee> it is!
<Hobbsee> anything interesting happen?
<TheMuso> No, been rather quiet the last few hours.
<Hobbsee> aww
 * Hobbsee points at http://www.linuxno.de/_data/gallery/nwl7/_medium_DSCN7823.JPG for a bit of amusement
<norsetto> heya hobbsee, long time no see
 * persia questions the safety of such an arrangement, and wonders if a longer lead just wasn't available
<Hobbsee> hiya norsetto, how were your holidays?
<Fujitsu> llery/nwl7/_medium_DSCN7823.JPG for a bit of amusement
<Fujitsu> 22:46:31 < norsetto> heya hobbsee, long time no see
<Fujitsu> llery/nwl7/_medium_DSCN7823.JPG for a bit of amusement
<Fujitsu> 22:46:31 < norsetto> heya hobbsee, long time no see
<Fujitsu> Oops.
<Hobbsee> oookay?
<Fujitsu> Stupid Synaptics.
<Fujitsu> I tried to three-finger click on the link, but missed.
<Hobbsee> heh
<norsetto> I feel pasted :-)
 * Hobbsee reads kmos report
<Hobbsee> LOL!  right then.
<Hobbsee> sync requested but not really checked. Could not provide a justification beside "...it's the only way to get things updated..."
 * Hobbsee notes that dholbach perhaps needs to check his sponsorships more carefully, toto
<norsetto> anyone know of a mouse cursor for kde?
 * Hobbsee updates the wiki page
<norsetto> I mean, a mouse cursor in the shape of a mouse .....
 * Hobbsee hasn't
<pochu> soren: I don't know whether you can change variables from debian/rules, sorry.
<artm> say i want to maintain a package for 2 flavours of ubuntu and for debian unstable, what are common practices for maintainging this? at the moment i just change the release in the top changelog record before making source package for each flavour, but it feels wrong
<persia> If that's your only change, that's likely the best answer for something external to the repositories.  You might define the special release "artm", and just compile it several different ways, but this may make it more difficult for your users to clearly identify against which environment the package they are using was compiled.
<persia> pochu: You can export make variables to shell variables.  If you can get the shell variables into python, you should be all set (unless I have the wrong context).
<pochu> persia: he wants to change some variables without patching the file
<artm> persia: well, so far that is the only change. eventually i would like to get the packages into official distributions, but for now I share them with our little community from my PPA so we can test/polish the package before suggesting it
<persia> pochu: That's harder.  Does python autoset internal variables from specially crafted shell variables or accept them on the command line?  If neither, you're right.
<pochu> i.e. changing  wwwpath  = "/var/www/cobbler/" to "/usr/share/cobbler/www/"
<persia> artm: Then playing with the changelog is your best bet.
<soren> pochu: Well.... If I can do it by passing arguments to setup.py, then I can do it from debian/rules.
<artm> persia: thanks
<pochu> soren: of course, but I don't know whether you can change just one of those variables with an argument to setup.py :)
<soren> pochu: Ok, fair enough :)
<pochu> soren: you can change all of them (or all of data_files), but just one... dunno
<pochu> Maybe it's possible and I don't know it, who knows :)
<persia> If you can change all of them, you can change one: just extract them all from setup.py, adjust the one you want, and change them all to the adjusted values.
<soren> pochu: Ok. Meh.. It's fine to maintain a patch to setup.py. I was just curious is there was a more correct way to do it.
<soren> persia: That's even more of a maintenance burden, though.
<persia> (the writing of the limited python parser is left as an excercise for the make programmer)
<persia> soren: I agree.  I'm a fan of patches, personally.
<persia> The quick & dirty way is to run sed -i against setup.py, but that'd be painful to understand for the next person.
<soren> :)
<promag> hi everyone
<pochu> persia: not if you put a nice comment :)
<promag> not sure if this is the right place, but I have a problem in makefile.am
<persia> pochu: Maybe.  Depends on the package.  I avoid using sed to patch in debian/rules unless there is an active maintainer already doing so.  It makes it hard to meet both the build-twice-in-a-row and the debian/rules-clean-is-really-clean tests.
<promag> what I have: file.xml which will create file.h and file.cpp
<promag> how could I define this in makefile.am
<soren> promag: You can put regular make rules in makefile.am.
<promag> I've tried it but how can I make the dependency work?
<soren> promag: Er... You haven't given nowhere near enough information for that question to make sense (let alone be answered).
<persia> promag: file.h file.cpp: file.xml
<promag> what I put in _SOURCES?
<promag> file.xml?
<promag> or file.xml and file.cpp ?
<soren> Have you tried?
<promag> yes.. the custom target isn't called...
<promag> I have tried this: http://unix.derkeiler.com/Newsgroups/comp.unix.questions/2003-04/0157.html
<soren> I belive #devtools on OFTC is the autotools support channel.
<promag> thanks
<mok0> promag: I've done something similar, hang on
<promag> mok0: great!
<mok0> promag: put the file.cpp in _SOURCES
<promag> it is already
<mok0> promag: and make a rule to generate file.cpp
<promag> .cpp: %.xml
<promag>     echo $@ && touch $@.cpp
<mok0> file.cpp: file.xml
<promag> I have this
<mok0> promag: that rules doesn't do anything?
<promag> no
<mok0> file.cpp: file.xml /n/t xml2cpp < file.xml > file.cpp
<promag> if I specify file.cpp: file.xml then its ok... but if I use %.cpp: %.xml then it fails
<promag> I need a generic rule
<mok0> promag: hm
<promag> otherwise I'll have lots of those
<mok0> promag:  but you are not generating any .cpp files from the .xml (?)
<promag> yes I am... touch file.cpp :)
<mok0> just empty files?
<promag> well it works :P
<promag> later I'll switch touch to the generator
<mok0> promag: what does this program do? :-P
<promag> what?
<promag> what program?
<promag> the generator?
<mok0> promag: it was a joke... a program with null files...
<promag> :P
<promag> well it doens't matter what the .cpp has
<promag> (for now)
<mok0> promag: there may be some restriction on using generic rules inside Makefile.am, I'm not sure
<promag> mok0: yes I think generic makefile rules doens't work in Makefile.am
<promag> if you see /usr/share/automake-1.10/am/yacc.am
<mok0> promag: why don't you make a small script that generates the mass of individual rules
<promag> because automake should be the solution no?
<mok0> promag: just to generate the individual rules to put in Makefile.am
<promag> I'm not happy with that solution
<mok0> promag: I understand. But it would work
<mok0> promag: you may zoom in on a better solution later
<promag> mok0: soren: persia: any idea of a package that could have a similar process?
<soren> promag: What happens to generic rules you put in Makefile.am?
<soren> I wouldn't expect automake to just remove them.
<promag> nothing
<promag> Ill check makefile
<promag> its right after .PHONY
<soren> So it's there?
<soren> Ok, what was the problem again?
<mok0> promag: then it should work
<promag> hoooooooo
<promag> %.cpp fails
<promag> but if I do %Generated.cpp: %.xml then it works
<persia> promag: Don't put anything after .PHONY.  Also, try adjusting %.cpp: %.xml to be $(CPP_FILES_TO_BE_CONSTRUCTED): %.cpp: %.xml
<promag> I'm not putting anything .PHONY... automake is!
 * persia disagrees with automake on this stylistic point, but the important part is $(expression): (variable extraction): (variable replacement) 
<persia> If you don't have both colons, make assumes you are talking about a file called %.cpp
<mok0> promag: http://libre.adacore.com/viewvc/trunk/polyorb/docs/Makefile.am?view=markup
<promag> you are most helpful!
<Toma-> Hey, im trying to track down a change to the Makefile in linux-ubuntu-modules. Specifically, the reason why rtl8180 is disabled
<DaveMorris> Toma-: have you looked in the changelog file?
<Toma-> yep
<Toma-> https://edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24
<Toma-> reading this
<Toma-> which is really no help at all
<DaveMorris> I'd suggest looking up the guys irc name who made the change and asking them, or firing off an email to them
<Toma-> BenC :D
<jpatrick> Toma-: best poke him in #ubuntu-devel
<Toma-> ill hassle him in -kernel
<geser> dmb: Hi, didn't you want to test pdfedit with lesstif2-dev? any results?
<dholbach> Hobbsee: which one are you talking about?
<dholbach> hey norsetto :)
<dholbach> hiya geser
<Hobbsee> dholbach: the sync request which slangasek threw down?
<dholbach> Hobbsee: which one was that?
<Hobbsee> it's listed on kmos report
<dholbach> Hobbsee: i built it myself and the build-depends doesn't seem to be necessary any more
<dholbach> Hobbsee: why were you referring to it?
<Hobbsee> was just surprised - and was looking thru the list
<dholbach> to the bug I mean?
<norsetto> hey dholbach! Still all in one piece or missed some bits after your snowboard adventures? :-)
<dholbach> norsetto: it was absolutely awesome
<dholbach> unfortunately my camera didn't work so no pictures
<norsetto> dholbach: glad to hear that, as all good things it ended though, and now you are back ;-)
 * dholbach hugs norsetto
<dholbach> yeah, it's great to be back again
<dholbach> norsetto: how were your holidays?
 * norsetto hugs dholbach too (but find him a bit cold and its surprised to find some snow flakes on him ....)
<dholbach> hehe, not from berlin
 * Hobbsee sets dholbach and norsetto on fire
<geser> Hi dholbach, Hobbsee
<norsetto> dholbach: pretty busy with a peesonal project which I had been postponing for too long
 * norsetto flame hugs Hobbsee
<dholbach> norsetto: I hope you're doing alright
<norsetto> heya geser
<geser> Hi norsetto
<BugMaN> Ave norsetto! :)
<norsetto> dholbach: as well as a I can be :-)
<norsetto> BugMaN: morituri me salutant ?
<BugMaN> norsetto: yes :)
<norsetto> BugMaN: oh, you told her the truth? Never do that!
<apachelogger__> dholbach: hooray, thanks :)
 * norsetto goes to eat something
<Chipzz> I hope this is not offtopic here, but does anyone around have experience with dotdeb?
<dholbach> Hobbsee: did you check anything regarding bug 180915?
<ubotu> Launchpad bug 180915 in big-cursor "Please sync big-cursor 3.7  (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/180915
<bobbo> I need a bit of help updating a package
<bobbo> I fixed a man page in a package a few weeks ago (showfsck-1.3ubuntu1) not knowing a new version (showfsck-1.4) had been released upstream in 2004. I want to merge with the upstream version but not sure how i should set up the changelog?
<dholbach> Hobbsee: I'll remove the "-" (regarding but 180915) in the report because I agree that Kmos should have replied to the objection, but to me it's still a valid sync request - that's why I put "please only add a review (+,0,-) for bug reports that are closed."
<dholbach> Hobbsee: if you have any objection about the bug being OK, please add your comment to the bug report
<Hobbsee> ...right
<slytherin> can anyone please tell me what is meaning of 'tentatively lool'?
<Hobbsee> lool is a person
<Hobbsee> so, presumably "possibly lool"
<Hobbsee> or "i think it's lool that you want"
<geser> slytherin: /whois lool
<slytherin> geser: I have no idea. I was just checking DesktopTeam TODO page on wiki. And it has this text against nautilus 2.21.x
<LucidFox> I've just uploaded package smplayer-themes to REVU, looking for reviews: https://bugs.launchpad.net/ubuntu/+bug/181319
<ubotu> Launchpad bug 181319 in ubuntu "[needs-packaging] smplayer-themes" [Wishlist,In progress]
<LucidFox> oops
<LucidFox> http://revu.ubuntuwire.com/details.py?package=smplayer-themes
<bobbo> Could a MOTU check out my fix for Bug #181775
<ubotu> Launchpad bug 181775 in showfsck "Showfsck package out of date" [Undecided,In progress] https://launchpad.net/bugs/181775
<somerville32> bobbo, Hi. The Debian Import Freeze is currently in-effect meaning that there needs to be a provided rational for the merge.
<somerville32> *rationale
<ScottK> bobbo: You need an interdiff, not a debdiff for a new upstream version.  See https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
<ScottK> somerville32: The bug includes a good rationale.
<somerville32> ScottK, The fact that it was released in 2006 is good rationale?
<ScottK> The fact that it's two years old, yes.
<ScottK> DIF isn't really a freeze as it is turning off the auto-sync with Debian.
<ScottK> The threshold for 'good' is very low at this point.
<ScottK> Personally, I'd settle for "I thought it was important enough to invest my time in preparing the update", but that's just me.  There is no actual process requirement for justification.
<somerville32> ScottK, okay, thanks for clearing that up.
<somerville32> bobbo, https://wiki.ubuntu.com/UbuntuDevelopment/Merging <-- for detailed merging instructions
<bobbo> somerville32: im not merging from Debian, but from upstream
<bobbo> is the diff.gz the interdiff page is talking about the same as a source .tar.gz?
<ScottK> bobbo: diff.gz is the one you get after you make the source package.
<ScottK> Source package being usually made up of orig.tar.gz, diff.gz, and .dsc.
<bobbo> running debuild -S doesnt create a diff.gz though
<norsetto> morning scottk
<ScottK> Morning norsetto.
<emgent> hello there
<ScottK> bobbo: It should.
<ScottK> hello emgent
<bobbo> ScottK: It jsut makes a showfsck_1.4.tar.gz containing the source of the package
<ScottK> bobbo: Then you're making a native package and you shouldn't be doing that.
<ScottK> bobbo: I take that back.
<ScottK> bobbo: I didn't notice that it actually is a native package.
<bobbo> ScottK: ah so how should i merge it then?
<ScottK> bobbo: Where is the source for the upstream release?
<ScottK> bobbo: Not sure.
<ScottK> bobbo: Point me at the upstream site and let me see what they have there.
<bobbo> http://www-id.imag.fr/Laboratoire/Membres/Danjean_Vincent/deb.html#showfsck but i included the 1.3ubuntu1 changes in my debdiff in the bug
<bobbo> ScottK: http://www-id.imag.fr/Laboratoire/Membres/Danjean_Vincent/debian/pool/main/s/showfsck/showfsck_1.4.tar.gz <-- Direct link to the tar.gz i used to merge
<ScottK> bobbo: For a native package, interdiff makes no sense.  What I'd suggest you do is take his 1.4 package, add your changes and call it 1.4~ubuntu1, and then make a debdiff between the two.
<bobbo> ok i'll do that and upload it
<ScottK> bobbo: Think about it based on the idea that whoever sponsors it will retrieve the upstream source themselves.
<tjaalton> Mez: are you still working on the iFolder ITP's you've filed?
<Mez> tjaalton, no. Not after novell messed me about - I thought they'd been automatically closed thoug
<tjaalton> Mez: ok.. I've been planning to do that for quite some time now, but so far haven't had the time
<mattva01> I'm pretty new to packaging so I'm wondering if someone could help me out
<ScottK> mattva01: Probably.  Asking specific questions will get you more help.
<mattva01> I have a package that does not create any binaries , it just configures eclipse in a certain way
<mattva01> but I get errors similar to this :dh_builddeb: I have no package to build
<mattva01> dh_testdir
<mattva01> and dpkg-genchanges: failure: cannot read files list file: No such file or directory
<mattva01> is there something obvious i'm missing?
<man-di> mattva01: you always need to build on binary deb
<man-di> mattva01: you do this by adding an entry to debian/control
<mattva01> the entry is correct I believe
<man-di> mattva01: then you would not get the above error message
<mattva01> well let me check then :)
<siretart> mattva01: not every binary package needs to actually contain binaries. if the package is architecture neutral, make it 'arch: all'
<man-di> mattva01: paste your debian/control to some paste.bin like http://rafb.net/paste
<man-di> mattva01: binary package just means, its some deb you can install
<mattva01> ah
<man-di> it can contain everything or nothing
<man-di> or something in between
<mattva01> http://rafb.net/p/lHaGwj36.html
<bobbo> ScottK: My new debdiff is up at Bug #181775 if you want it
<ubotu> Launchpad bug 181775 in showfsck "Showfsck package out of date" [Wishlist,In progress] https://launchpad.net/bugs/181775
<mattva01> so is there anything wrong with it?
<man-di> mattva01: Version: 1.0 should not be in there
<man-di> but thats most probably not your error
<mattva01> hmm
<man-di> version number comes always from debian/changelog
<mattva01> oh yeah
<Chipzz> I think a space is required after :
<Chipzz> and the cdbs build dependency is most likely bogus
<mattva01> yeah it is, sorry bout that
<Chipzz> also
<Chipzz> the dependecies on sun-java6-jre, sun-java6-jdk are most likely bogus
<mattva01> no I actually need those
<Rospo_Zoppo> Riddell: i'm working on a fix for a pk2moto ftbfs; the problem is that the debdiff is very large, can you have a look at it (bug 181581) ? thanks
<ubotu> Launchpad bug 181581 in p2kmoto "FTBFS on all architectures" [Undecided,Confirmed] https://launchpad.net/bugs/181581
<Chipzz> mattva01: is there a very good reason it won't work with for example gcj or sth?
<mattva01> the AP board seems to require sun java
<Chipzz> still
<Chipzz> you're not *packaging* the AP board
<Chipzz> you're only *configuring* it
<rexbron> Is there ap olicy of having .py files in /usr/bin/ ?
<mattva01> true
<Chipzz> if the AP board package will only work with a specific version of java, then IT should have that dependency
<mattva01> ah yeah
<Chipzz> if in the future the AP board software is changed to also work with alternative runtimes, your package will block that
<Chipzz> >> not good
<mattva01> of course
<Chipzz> hrrrm well actually it won't, it will just force unneeded packages to stay installed
<Chipzz> not good nevertheless
<mattva01> well I see I have much to learn :)
<mattva01> still don't understand these errors I'm getting though
<\sh> moins
<geser> Hi \sh
<Chipzz> mattva01: btw, I don't know ap board nor do I particulary care; but, is it a seperate ubuntu package or just some tarball?
<Riddell> Rospo_Zoppo: hmm, you're modifying autofoo generated files, isn't there a way to fix it without doing that?
<Chipzz> since you have Source: apjava; assuming apjava is the AP board source package, that would also be incorrect ;)
<Riddell> Rospo_Zoppo: or how did you create that patch?
<mattva01> its a tarball
<\sh> hmm...is it my ISP or is archive.ubuntu.com slow today?
<mattva01> AP board=  Advanced Placement (for high school) , the case study for AP Computer Science is something called gridworld
<Chipzz> mattva01: then another question is, why are you just packaging some postinstall scripts instead of that tarball? ;)
<Rospo_Zoppo> Riddell: I deleted the old one, then I created a new one with the same name and I did aclocal, autoconf, automake
<Rospo_Zoppo> Riddell: this makes the package build but the debdiff is very large
<mattva01> well I am packaging the tarball  for gridworld but it never actually gets untarred
<Riddell> Rospo_Zoppo: right, fair enough, if that's what it needs than that's what needs to be done
<Riddell> Rospo_Zoppo: has there been any upstream activity on this do you know?
<Rospo_Zoppo> Riddell: I don't know this honestly
<Riddell> Rospo_Zoppo: no, doesn't look like there has been
<Rospo_Zoppo> ok
<Riddell> Rospo_Zoppo: well fine with me, I'll upload
<Rospo_Zoppo> Riddell: thanks :)
<Riddell> Rospo_Zoppo: builds for me, uploaded, thanks for the fix
<Rospo_Zoppo> good
<\sh> wow...guys...thx for all the cheering :)
<mattva01> :( failed again
<bddebian> Heya gang
<ScottK> Heya bddebian
<bddebian> Hi ScottK
<\sh> damn..my body is hurting now...why do I have to go into a gym and do some training...:(
<LaserJock> \sh: hi
<LaserJock> nice to see your MOTU app ;-)
<\sh> LaserJock: thx :)
<Nightrose> \sh: wohooo you applied again? /me checks
 * ScottK kicks dholbach to approve \sh today ....
<Nightrose> hehe
 * Nightrose hugs dholbach instead
<Nightrose> might work better :P
<dholbach> Nightrose: thanks, exactly :)
<Nightrose> ;-)
 * dholbach looks at it after the CC meeting
<\sh> thx a lot to all of you...but let dholbach do his paid work first :)
<\sh> it's nothing to hurry about :)
 * ScottK has been trained by hobbsee
<leonel> ScottK: hello :     For  cve-2007-6337   I've made a diff  in  clamav 0.92 and  0.91.2   for   bzlib_private.h  and it's  a little change   should  I do the  debdiff  ??
<ubotu> Unspecified vulnerability in the bzip2 decompression algorithm in nsis/bzlib_private.h in ClamAV before 0.92 has unknown impact and remote attack vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6337)
<\sh> ScottK: lol :)
<leonel> even is an  unknown issue
<ScottK> leonel: CVE says ClamAV before 0.92.  What change do we need in 0.92?
<leonel> in 92  none  for  91.2
<ScottK> Ah.
<ScottK> Yes, please
<ScottK> (debdiffs)
<leonel> ScottK: http://paste.ubuntu-nl.org/51455/
 * ScottK looks
<leonel> searching for more info
<leonel> I've found the same partch for gentoo : http://bugs.gentoo.org/attachment.cgi?id=138930
<ScottK> leonel: Where did you find the patch originally?
<\sh> leonel: is it on the CVE mitre page linked?
<leonel> as the   cve says  the bug was   in the  bzlib_private.h   made the diff     then   looking more
<\sh> ScottK: I think it comes from here http://security.gentoo.org/glsa/glsa-200712-20.xml
<leonel> found the  gentoo one
<ScottK> OK.  I'd say go for it then.
<\sh> http://bugs.gentoo.org/show_bug.cgi?id=202762
<leonel> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2007-6337
<ubotu> bugs.gentoo.org bug 202762 in Vulnerabilities "app-antivirus/clamav < 0.91.2-r1 Multiple vulnerabilities (CVE-2007-{6335,6336,6337})" [Major,Resolved: fixed]
<leonel> and there links to gentoo
<\sh> it's always good to have a patch from a different distro ready...I trust redhat very much but sometimes as well gentoo ,-)
<ScottK> It looks like gentoo is the only one with a patch for this yet.
<\sh> ScottK: fedora is pushing new upstream versions for bug fixes
<\sh> ScottK: RHEL doesn't have clamav afaik
<ScottK> OTOH, they released it two weeks ago and haven't had to fess up to any changes.
<ScottK> Ah.
<leonel> \sh: same here about redhat security
<leonel> so .. go for the  debdiff  for  gutsy  and   feisty   ?
<\sh> ScottK: afaik we and debian are the only two distros with really stable releases and bugfixes for even non enterprise distros ready...
<ScottK> Well Fedora is going to have fun with 0.92 then as we had to patch at least two packages in addition to rebuilding for the soname change
<\sh> ScottK: they will push 0.93 to their archives
<\sh> ScottK: and deal with the rest
<ScottK> leonel: Yes.  And then once the Gutsy one is out, we'll backport that to feisty-backports.
<leonel> ScottK: Ok..  going to the kitchen to   cook the debdiff  ...
<ScottK> Great.
<\sh> ScottK: btw...are we still nailed for -backports with the packages from the latest developement version or can we also upload to it like to -motu?
<ScottK> We can do source backports, but it takes a core-dev to upload.
<ScottK> We can backport from any release though, so a backport from gutsy-security to feisty-backports is no problem (clamav does require a source backport though)
<\sh> ScottK: so actually we could do a backport of wine to all other releases with a source change...
<\sh> well, this will be fun...correct time to celebrate: 11th january, 2008: Release Of KDE4.0.0, birthday of kris koehntopp (aka isotopp) and Stephan Hermann (aka \sh) ... if this isn't perfect I don't what is
<bluefoxicy> why can I perpetually not record in ubuntu
<bobbo> Does anyone have a tutorial on packaging a Python script with a Distutils setup.py?
<geser> ScottK: while speaking of clamav: what do we do with the clamav-data package in hardy? should we try to keep it as up-to-date as possible? i.e. sync it from debian regularly?
<bluefoxicy> https://bugs.launchpad.net/ubuntu/+source/gnome-media/+bug/174550
<nxvl_work> does anyone knows where norsetto is? i haven't see him in a long time
<ubotu> Launchpad bug 174550 in gnome-media "can't record sound with microphone. listening works. tested several applications among them the simple sound recorder!!" [Undecided,New]
<mok0> <a href="https://wiki.ubuntu.com/PackagingGuide/Howtos/CDBS?highlight=%28CDBS%29">bobbo: PackagingGuide/Howtos/CDBS - Ubuntu Wiki</a>
<norsetto> nxvl_work: hmmm, here?
<bobbo> nxvl_work: He was on about 3pm GMT
<nxvl_work> norsetto: hi!
<mok0> bobbo: <a href="https://wiki.ubuntu.com/PackagingGuide/Howtos/CDBS?highlight=%28CDBS%29">PackagingGuide/Howtos/CDBS - Ubuntu Wiki</a>
<nxvl_work> norsetto: it's long time i don't see you
<norsetto> nxvl_work: Hola!
<bobbo> thanks mok0
<norsetto> nxvl_work: yes, was pretty busy, how is it?
<nxvl_work> norsetto: little boring, really light days on work
<mok0> bobbo: it has the rules file for you right there
<bobbo> mok0: "Packaging Python modules with CDBS"?
<mok0> bobbo: yep
<ScottK> geser: Yes.  Please keep it up to date.
<ScottK> bobbo: It's easy enough to do.  The pypolicyd-spf source package is a decent example.
<jdong> LucidFox: just a status update, mpeg4ip was rejected by archive admins due to debian/copyright issues. I'm going to work on fixing that up but it's a lot of work and will probably take me the rest of today and tomorrow.
<jdong> LucidFox: it bundles all kinds of works from 10+ sources and some of them don't have live website links anymore so I'm gonna have to do some detective work
<\sh> dholbach: thx :)
<dholbach> \sh: :-)
<\sh> dholbach: what to do now?
<dholbach> \sh: wait for the other MC members to send in their vote
<imbrandon> moins all
<dholbach> if everybody's happy you will get re-added to the team
<\sh> dholbach: cool...so no work from my side anymore...
<dholbach> no :-)
<\sh> would be a cool birthday present...;)
<nxvl_work> imbrandon: i have just write you and e-mail some minutes ago
<nxvl_work> :D
<imbrandon> nxvl_work: i just replyed
<imbrandon> nxvl_work: you can count on me
<nxvl_work> imbrandon: thnx
<nxvl_work> :D
<nxvl_work> received
 * nxvl_work *HUGS* imbrandon
<imbrandon> :)
 * ScottK reads dholbach's mail and looks over at geser and soren.
<soren> ScottK: Exactly which e-mail are you talking about?
<ScottK> soren: The one where dholbach +1'ed \sh's MOTU application.  Maybe I lost track, but I didn't see a reply from you yet.
 * ScottK is hoping we can give \sh a good MOTU birthday present
<soren> ScottK: I haven't replied yet.
<soren> On purpose.
<soren> His birthday is coming up?
<\sh> soren: http://www.sourcecode.de/content/day-celebrate
<soren> Ah, I see.
 * \sh needs a coffee and tries to fix simage...
<leonel> ScottK: should I do a new bug report for this cve ??   I have the gutsy debdiff   all builded  installed and  checked  bzip2   fine
<ScottK> leonel: Yes.
<ScottK> leonel: Let me know when you have it filed and I'll approve the tasks for gutsy/feisty
<leonel> ScottK:  ok
<leonel> ScottK:  done  bug  181830
<ubotu> Launchpad bug 181830 in clamav "CVE-2007-6337 Unknown impact remote attack" [Undecided,New] https://launchpad.net/bugs/181830
<leonel> baking feisty's debdiff
 * ScottK looks
<ScottK> leonel: Done.
<ScottK> keescook: Would you please have a look at bug 181830 for Gutsy?
<ubotu> Launchpad bug 181830 in clamav "CVE-2007-6337 Unknown impact remote attack" [Undecided,In progress] https://launchpad.net/bugs/181830
<dholbach> see you guys tomorrow! have a nice rest of your day! :-)
<keescook> ScottK: sure thing
<ScottK> keescook: Thanks.  Patch is from Gentoo.
<\sh> grmpf...where is the cdbs documentation...the link from DeveloperResources is not working anymore
<ScottK> \sh: You'll just end up reading the source anyway.  May as well start there.
<\sh> thx soren
<\sh> ScottK: well I just need the correct line for regenerating autofoo crap
<\sh> ah it's in the doc dir
<\sh> ScottK: to fix simage I needed to add a new macro to the source package
 * ScottK nods
<ScottK> geser: Ping
<\sh> I'll do it differently .. I#ll recreate the autofoo stuff manually (and put it into a patch file)
<leonel> ScottK:  feisty's clamav does not have  libclamav/nsis/bzlib_private.h    ...
<leonel> searching where is the bzip things
<ScottK> leonel: OK.  I think the nsis library may have been new in 0.91.
<leonel> ScottK: yes
<leonel> ScottK:  there's no  #define   BZ_GET_FAST
<ScottK> leonel: Sounds like non-applicable to Feisty then.  Thanks for checking.  I'll update the bug.
<ScottK> keescook: Could you point me at (or provide) the final version of your Gutsy package for clamav so I can prepare a source backport for feisty-backports?
<bobbo> I just uploaded a package to REVU without the source tar.gz, how should i fix this?
<ScottK> bobbo: Upload again with the tar.gz
<bobbo> ScottK: It says there is nothing to upload whe i try to re-up it
<ScottK> bobbo: dput -f
<bobbo> ScottK: brilliant thanks
<ScottK> bobbo: man dput, not brilliance
<bobbo> ScottK: ive spent so long at the command line today, trying to figure something out for myself would be just too hard
<ScottK> Understand.  No problem.
<sladen> bobbo: dput revu foo.changes
<bobbo> ScottK: Thats it uploaded and registered thanks
<ScottK> bobbo: You're welcome
 * man-di is too dumb to use launchpad. how can I found the build logs for lucene2 again?
<DktrKranz> man-di, https://edge.launchpad.net/ubuntu/+source/lucene2/2.2.0-2
<man-di> DktrKranz: thanks
<DktrKranz> :)
<\sh> ScottK: do you have some time to check on something?  I need some advice here
<ScottK> Sure
<\sh> ScottK: please dget http://ftp.de.debian.org/debian/pool/main/s/simage/simage_1.6.1-3.dsc (new release from debian) and check out aclocal.m4
<\sh> ScottK: you will find a libungif rule inside, but when you do a aclocal you won't see it again in the newly generated..even when you add the cfg/ dir (where some simage macros are)...I wonder if they patched it in manually ...or if it's automatically generated..I don't find anything in the cfg/ dir
<ScottK> You may be assuming I know more about auto**** stuff than I do, but I'll have a look
<\sh> ScottK: well, I only want another opinion...:)
<ScottK> OK.  Looking
<\sh> ScottK: what I did was patching aclocal.m4 manually and recreate configure with a patched configure.ac to recognize the new macro...but this is not the normal way of doing things
<amarillion> Hey there, if anyone has some spare time please review my package speed-game http://revu.tauware.de/details.py?package=speed-game
<ScottK> \sh: The aclocal.m4 from the Debian package and the upstream tarball identical with the same time stamp.
<ScottK> It hasn't changed since 2004, so if it's automatically generated, it's not very often.
<\sh> ScottK: well, yeah...but it looks like that it was generated manually and not via aclocal
<ScottK> \sh: I'm of the view that if your approach worked, then that's a good sign you're doing the right thing.
<C10uD> hai all
<\sh> ScottK: ok...will provide something and test
<bobbo> Hey, if any MOTU's have some spare time could they check out http://revu.tauware.de/details.py?package=ckkern for me?
<C10uD> sorry if i start with a question but i have some problems signing a debian package, this is the script i'm actually using http://pastebin.ca/848388 and seems like is building a package but are signed only the dsc and the changes files, any idea in where the problem is?
<jdong> oh for crying out loud! every file has a different author/contributor and licensing terms!!
<jdong> can debian/copyright just say see the headers of the source files or do I have to re-list the first 100 lines from each source file?
<amarillion> head -N 100 * >> debian/copyright
<amarillion> :)
<jdong> haha
<jdong> echo "Go figure it out yourself" >> debian/copyright? :D
<Burgundavia> jdong: what package is that?
<ScottK> jdong: debian/copyright MUST list all licenses.   It's OK not to list all contributors if there are a lot of minor ones.
<amarillion> C10uD, I think only those files need to be changed, right?
<amarillion> s/changed/signed/
<C10uD> i don't really know ? :P
<jdong> Burgundavia: mpeg4ip contains the ISO MPEG-4 reference software
<C10uD> if i upload all the files to a ftp server
<jdong> Burgundavia: each file in the reference software has a different set of contributors
<C10uD> then the people get it's an unsecure package
<amarillion> C10uD, the changes file contains md5sums of the rest
<ScottK> jdong: Have fun.
<amarillion> at least that is how I understand it
<mok0> I challenge any MOTU to find errors in http://revu.tauware.de/details.py?package=gpp4
<keescook> ScottK: You bet; it'll be in the archives in the next few hours.
<ScottK> keescook: THanks.
<keescook> np, thanks for the ping on it.
<jdong> ScottK: thanks, will do :D
<\sh> ScottK: looks like that I'm correct...actually it finds libgif :)
<C10uD> :s i don't really know.. people add the the repository then they download the package but they get the "unsecure" message.. i'm likely a noob in debian packaging i tried to follow some guides but i really can't find the problem :s
<amarillion> Well, somebody other than me should be better to answer this
 * \sh would like to see upstream developers to use the documented, correct way of using autofoo crap
<amarillion> but I think your problem lies elsewhere. The fact that only the dsc files and changes files are signed is normal
<C10uD> ok thanks anyway for your interest
<C10uD> :)
<\sh> strike..worked
<amarillion> mok0, you're MOTU hopeful too right?
<mok0> amarillion: yup :)
<amarillion> mok0, are you doing only new packages or updating existing packages as well?
<mok0> amarillion: I have mostly been doing new packages
<amarillion> I'm wondering which of the two is better
<amarillion> and easier
<amarillion> Until now I've only tried new packages
<C10uD> mok0: could you please take a look at my problem lines above? :P
<mok0> amarillion: you are more free to do your own stuff with new packages
 * mok0 looks 
<LaserJock> anybody know how to do spell checking in irssi/gnome-terminal/konsole-kde4 ?
<C10uD> thanks :P
<amarillion> so it's more fun... yeah, I can see that
<\sh> ScottK: are fake syncs still acceptable? (new debian revision, not new upstream?)
<mok0> C10uD: What's the problem?
<C10uD> the problem is that if i upload all the files (deb, targz, dsc, changes) to the ftp server then people get the "unsecure" message
<LaserJock> amarillion: I find updating existing packages to be better for people just learning, but new packages tend to be a bit more rewarding
<C10uD> even if seems like i've signed the dsc and changes files
<mok0> Isn't that because you have not signed the "Release" file?
<broonie> C10uD: It's the Release file needs to be signed for apt
<LaserJock> C10uD: the archive needs to be signed, Release file
<LaserJock> darn, little late to the party ;-)
<mok0> :)
<C10uD> well maybe :D i'm a noob packager
<C10uD> :P
<C10uD> how can i do that? :D
 * C10uD points at the script
<LaserJock> C10uD: what are you using to make the archive?
<C10uD> :P
<mok0> LaserJock: http://pastebin.ca/848388
<C10uD> >> http://pastebin.ca/848388
<C10uD> whoops
<mok0> Fastest again
<mok0> hehe
<C10uD> :)
<LaserJock> oh heavens
<broonie> Use something like
<minghua> LaserJock: What does irssi/gnome-terminal/konsole-kde4 mean?  It's impossible to spellcheck in gnome-terminal without help from other programs, AFAIK.
<mok0> C10uD: I found the reprepro utility really nice to build a repo, it signs & everything
<vud1> hi! i need add a bash variable to the system (MOZILLA_FIVE_HOME=/usr/lib/firefox). in what file must my postinst file insert it?
<LaserJock> minghua: I just need *something* that I can easily check spelling when I'm using irssi
<LaserJock> mok0: falcon might be better for a new person
<LaserJock> C10uD: I think you can do all that much easier and in fewer steps
<C10uD> i think so, but as i said i'm a newb :P
<mok0> LaserJock: never heard of falcon, will check it out!
<amarillion> vud1: what kind of package do you need it for? Can't you set it in a wrapper shell script for the app that needs it?
<LaserJock> mok0: written by Seveas
<amarillion> I think that i show the firefox run script itself does it
<LaserJock> C10uD: for instance, to get rid of all the .svn use svn export
<ScottK> \sh: They should be avoided.
<ScottK> \sh: Is there a reason a regular sync can't be done?
<LaserJock> C10uD: you really don't need to use dh_make either. Just copy the old debian/ files
 * minghua knows a way to spellcheck in irssi/gnome-terminal, though it likely won't help LaserJock. :-P
 * C10uD writes the tips :P
<Seveas> dh_make sucks anyway :)
<mok0> Seveas: +1 from me
<vud1> amarillion: is a desktop package writed in python+gtk. i am not sure if i can use a shell script
<LaserJock> C10uD: then instead of dpkg-buildpackage try using debuild (install fakefoot as well) then you don't have to sudo
<LaserJock> Seveas: does falcon do archive signing?
<Seveas> LaserJock, of course
<C10uD> mm
<vud1> amarillion: my debian/rules uses my setup.py file to write the package.. so.. i dont know how to insert a shell script there (sorry for my english)
<Seveas> LaserJock, building, archiving, signing, mirroring
<LaserJock> C10uD: then use falcon to manage the repo
<Seveas> LaserJock, apt-get data, maintainer mailing, linda/lintian
<Seveas> it does it all :)
<Seveas> I meant app-install data btw
<LaserJock> that's what I thought
<LaserJock> I just wanted to make sure
<C10uD> ok i'll try these, thanks :P
<mok0> Seveas: sponsor, upload, fix bugs...
<LaserJock> I need to install it and try it out
 * mok0 too
<LaserJock> Seveas: I'll probably be writing about falcon in an upcoming book. I might be picking your brain here soonish
<Seveas> LaserJock, I released 2.0.0 recently
<mok0> LaserJock: What book is that? Sounds interesting
<Seveas> at 2.0.3 now, quite a few bugs are being found
<LaserJock> Seveas: and that'll be in Hardy I presume?
<Seveas> imbrandon is working on that
<LaserJock> mok0: called Ubuntu Server in Action
<Seveas> LaserJock, the 3rd reincarnation of it?
<LaserJock> I'm writing chapters on packaging and repo management
<LaserJock> Seveas: heh, something like that
<Seveas> LaserJock, I've been reviewing parts of it since over 2 years :)
<LaserJock> Hardy man, we've got to wait for an LTS ;-)
 * mok0 has used Seveas' debomatic with pleasure
<Seveas> debomatic?!
<amarillion> vud1, well you could put a shell script e.g. yourprogram.sh in your debian directory and add "install -m 755 yourprogram.sh /usr/bin/yourprogram" or something like that
<Seveas> that's not mine for sure :)
<mok0> Ah, its not yours ;-/
<amarillion> vud1, and then the shell script should set the environment variable and then run the python script
<vud1> amarillion: mmm aha i understand
<mok0> Its DktrKranz's
<LaserJock> minghua: would that involve learning an asian language?
<LaserJock> :-)
<DktrKranz> mok0, ah. Nice to know :P
<vud1> amarillion: so.. my package should insert 2 files in /bin but.. i think it is problematic.
<amarillion> yeah maybe. It's just one solution
<vud1> amarillion: for example the *.desktop file is in the source and is common for all distributions,  (not in the package)
<amarillion> but the alternative of setting MOZILLA_FIVE_HOME globally is not great either
<vud1> amarillion: so the desktop file will launch the "program bin"
<vud1> amarillion: i see
<amarillion> yeah, but you can patch the .desktop file to use the new script as well
<amarillion> that is just one line change
<mok0> DktrKranz: it's great, I'd like it to be able to build both amd64 and i386 in one go
<vud1> could i do that?
<vud1> how can i pathc the desktop file?
<mok0> DktrKranz: but I haven't had time to play with it
<DktrKranz> mok0, me too, but I need to understand cross-compilers or qemubuilder first
<mok0> DktrKranz: I think you can do it in a pbuilder on an amd64 machine
<amarillion> vud1, yeah, but you need to read up a bit I guess
<mok0> DktrKranz: you can build i386 there
<amarillion> better get a second opinion from someone more knowledgeable than me before you commit a lot of time to this
<mok0> DktrKranz: but you need to be able to fork the build
<vud1> thanks
<DktrKranz> mok0, on amd64 I can build i386 as well, but my server is i386 only :(
<amarillion> vud1, here is the documentation on patch system though: https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/ps-chap.html
<DktrKranz> (and it's down since days now...)
<mok0> DktrKranz: out of luck, huh?
<vud1> amarillion: i will read it now. thanks a lot
<DktrKranz> yeah
<DktrKranz> mok0, but yes, I wrote it just because I started to hate wanna-build
<mok0> DktrKranz: I think you can give up on running qemu if you don't have a cpu that does virtualization
<amarillion> gotta go now. Good night
<DktrKranz> mok0, I don't think an old celeron can :)
<mok0> DktrKranz: me neither :-)
<mok0> I'm getting a dual quadcore shortly :-P
<DktrKranz> so, let's keep it warm until dancer releases something really cool
<mok0> DktrKranz: is he still developing pbuilder?
<DktrKranz> I guess so
<mok0> DktrKranz: you can do it in debomatic
<mok0> DktrKranz: Allow the user to start 2 (or more) pbuilders
<DktrKranz> mok0, it does actually
<DktrKranz> it can run as many parallel builds as you wish
<mok0> DktrKranz: Aha? I have to play with it soon again, I guess
<mok0> DktrKranz: With different parameters for the pbuilder?
<DktrKranz> mok0, yes. even two distributions (e.g. ubuntu and debian)
<DktrKranz> as far as debootstrap is instructed :)
<mok0> DktrKranz: cool
<DktrKranz> mok0, I'd like to show you it in action, but my server is down...
<mok0> DktrKranz: bah
<mok0> DktrKranz: my mobo is also dead on my own box
<DktrKranz> my friend's mother destroyed his router during some housekeeping tasks, and now he's out of the net
<mok0> DktrKranz: That should teach him to do his own cleaning :-)
<DktrKranz> Trust me, it's not advisable, last time I lost my mobile!
<mok0> DktrKranz: Can't you just call it?
<DktrKranz> so I did :)
<mok0> DktrKranz: ... but it was out of power...
<DktrKranz> no, it was out of reach... :P
<geser> ScottK: pong
<ScottK> geser: I was hoping you'd +1 \sh's MOTU application so dholbach can give it to him on his birthday tomorrow (later today for you).
<geser> ScottK: will do
<ScottK> geser: Thanks.
<mok0> No takers for my challenge? ;-)
<jdong> ok, whew, that was a long copyright file
<C10uD> ok thanks to your tips i'm improving dramatically the script :P now i have a question: is there a way i can tell debuild to build the package and sign the files without inserting my passphrase twice? e.g. a conf file or whatever
<jdong> C10uD: use a gpg agent :)
<C10uD> im messing with /etc/devscripts.conf  and i've found an interesting  # Do we cache the gpg passphrase by default?  This can be dangerous! # DPKGSIG_CACHE_PASS=no
<C10uD> :P
<jdong> the warning might be iimportant :)
<jdong> I'd rather have my passphrase cached by something designed to do so securely :)
<C10uD> anyway that seems not working for me (fast test.. :P)
<C10uD> so what was your advice? :P
<jdong> hahaha
<jdong> to have users configure a GPG agent
<jdong> such as gpg-agent at the command line or the Seahorse GPG agent shipped by default with Ubuntu GNOME
<C10uD> erm isn't that a waste of resources? :P
<jdong> howtos on both readily available
<jdong> well it's better than insecurely transporting a GPG passphrase
<C10uD> well i don't need that security...yet :P
<jdong> err... suit yourself?
<slangasek> C10uD: so you'll be discarding your current gpg key and creating a new one when you decide you do need that security, right?
<jdong> why even GPG sign something with an insecure key like that?
<jdong> I wouldn't care if your packages are signed if that's how they're signed.
<C10uD> mmm well maybe you are right lul
<jdong> at this rate you might as well hard code it into your script and echo it into debuild!
<C10uD> ok ok gotcha
<jdong> :)
<C10uD> i'll follow the REAL MEN's way!
<C10uD> :D
<C10uD> do i have to learn how to make up a gpg agent? :P
<slangasek> C10uD: ... why are you claiming in your IRC client to be "mark shuttleworth"?
<C10uD> i like trolling
<jdong> slangasek: everyone likes to be mark :)
<slangasek> what an odd thing
<C10uD> do you really think i'm mr.ubuntu asking for packaging? :S
<jdong> C10uD: I'd like to talk about my raise....
<Fujitsu> slangasek: We get them a bit.
<C10uD> lul
 * jdong grins at Christian Marillat's reply to his mail
<jdong> slangasek: everyone likes to be mark :)Thanks you very much, I hate to write debian/copyright file.
<jdong> oops
<jdong> GRR
<jdong> Dear Synaptic touchpad gods:
<jdong> Two-finger scroll and two-finger middle click do not mix well.
<jdong> CC: Santa, Easter Bunny.
<C10uD> lol
<nxvl_work> how often are the CC meetings taking place?
<ScottK> nxvl_work: Nominally every 2 weeks, but it varies.
<persia> nxvl_work: Generally about once a month, but sometimes they are missed due to various conflicts.  Longest span I've seen was about 6 weeks.
<nxvl_work> thnx
<nxvl_work> persia: i emailed you, did you received it?
<persia> nxvl_work: Likely, but I haven't read it yet.  Looking now...
<civija> guys, how can I found out does slrnface package has ubuntu maintainer or is it synced from debian?
<geser> !info slrnface
<ubotu> slrnface: shows X-Faces from a newsposting on an X11 terminal emulator. In component universe, is optional. Version 2.1.1-6 (gutsy), package size 25 kB, installed size 104 kB
<jpatrick> civija: look at it's version if it has -*ubuntu* it has ubuntu changes
<geser> civija: looks like it was taken directly from Debian
<jdong> am I correct in thinking that for a SRU debdiff, one should NOT adjust the Maintainer field for the maintainer spec?
<jdong> or is that trivial enough that it's acceptable to put it in too?
<civija> geser: aha, tnx
<civija> so i could take slrnface and package it for universe?
<ScottK> jdong: For Dapper/Edgy no, for Feisty + yes.
<geser> jdong: for >= feisty (?) it's ok to change the maintainer and also done
<jdong> ScottK: geser thanks :)
<geser> civija: what do you mean? it's already in universe
<civija> geser: i'm thinking of becoming motu and i would like to maintain slrnface
<slangasek> ScottK: so following the maintainer spec for dapper in an SRU would be cause for rejection?
<ScottK> slangasek: Yes because the tool chain for Dapper has never been tested with modified maintainers and the new fields
<geser> slangasek: the tools are not tested if they work with the maintainer change
<slangasek> ScottK: ah, I see
<ScottK> Dapper and Edgy
<geser> civija: have you tried to work with the Debian maintainer on this package as we try to use the Debian packages where possible?
<mok0> Isn't the whole point of using rfc822 files that unknown tags are ignored by the tools? I thought there was a forward compatibility in that
<emgent> hello people ;)
<civija> geser: yes but didn't get any response
<civija> btw slrnface doesn't work in ubuntu without litle patch
<ScottK> mok0: Thats the theory, but for an SRU we don't want any risks that are avoidable.
<civija> i can try to contact him again ...
<mok0> ScottK: I understand
<geser> civija: prepare a debdiff then and let is sponsor into Ubuntu
<civija> geser: ok, tnx
<sommer> /wc/
<sommer> woops
<emgent> DktrKranz, in hardy there is phpbb2 or phpbb3 ?
<DktrKranz> emgent, IIRC phpbb2
<emgent> uhm ok cool. vulnerable too
<emgent> i go to write diff
<slangasek> civija: generally you're more likely to get a response from Debian maintainers if you're sending them concrete patches than if you just say you want to help, particularly on smaller packages; I guess you did the latter, since I don't yet see any bug reports or patches from you in the Debian BTS?
<civija> slangasek: yes you are right
<civija> i'll make a debdiff
<ScottK> geser: Thanks.
<ScottK> \sh_away: You got +1 from all the MC, so now we just wait for dholbach to make it official on your birthday.
<StevenK> \sh is coming back?
<ScottK> Yes.  He applied for MOTU again.
<geser> StevenK: if \sh doesn't pull back his application he'll be a MOTU in a few hours again
<StevenK> Heh
<mok0> Good then he can review my perfect package
<TheMuso> mok0: What is this package that you so boldly claim is "perfect"?
<mok0> gpp4 on revu
<TheMuso> Ok, I'll take a look.
<mok0> (he took the bait ;-)
<persia> mok0: Are you sure I can't find anything if I looked?
<mok0> persia:  you'd have to be good
<ScottK> persia is good, so watch out.
<mok0> ScottK: yes, but I am upstream :-)
<ScottK> That helps, but is no guarantee.
<mok0> ScottK: heh
<TheMuso> mok0: For a start, thers the out of date standards version.
<persia> mok0: Your debian/copyright doesn't match http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html :P  Specifically doesn't mention the debianisation, fails to have licensing for the packaging, and uses globs.
<persia> Anyway, I don't have time for a full review now.
<mok0> http://wiki.debian.org/Proposals/CopyrightFormat
<mok0> persia: that's what DD's want now
<TheMuso> mok0: There are 2 * in your changelog.
<TheMuso>   *   * Initial release (LP: #176211)
 * persia notes that monsterz was a poor choice as an example
<mok0> TheMuso: arrrgh
<TheMuso> mok0: Since your address is not @ubuntu.com, you need an XSBC-Original-Maintainer field.
<mok0> TheMuso: I am upstream
<TheMuso> No, you still need it, for packaging reasons.
<persia> mok0: the ftp masters reject FAQ still lists the other.  Can you pass a pointer showing me that this proposal was accepted by a significant number of DDs?
<TheMuso> The package won't build oterhwise.
<TheMuso> otherwise
<mok0> persia: no, I don't have such documentation
<mok0> persia: only from 1
<persia> Further, the w.d.o page says "This is not a proposal to change the policy in the short term.", so I don't think it's started yet.
<mok0> persia: "to prepare for future changes, you might as well.."
 * persia still wants to know who did the initial packaging for a given package.
<mok0> persia: that's in changelog
<persia> mok0: Not reliably, as long as it remains best practice to have a truncated changelog for first introduction.  Take a look at some of the packages first in Ubuntu and later brought into Debian.
<mok0> persia: ..and in copyright: Files: configure,ac .. debian/*
<mok0> persia: I don't like the idea of truncating the changelog for those packages that were first in ubuntu
<mok0> persia: like rewriting history...
<TheMuso> mok0: In libgpp4-0.install, you know you can use wildcards? SO something like
<TheMuso> usr/lib/libgpp4.so.*
<persia> mok0: True, but I don't like preserving 37 upstream changelog revisions and small bumps before the package attracted the attention of a distro.  There's surely a happy balance somewhere, but I'd prefer the debian/copyright header until one is found.
 * nxvl *HUGS* persia 
<mok0> TheMuso: yeah, ok
<mok0> persia: granted, I don't know why they didn't keep that.
<mok0> persia: I'll put it back
<persia> mok0: If you want to put it in a format that is easily machine-readable, I've no objections :)
<mok0> persia: Of course, I can make my own tags legally in rfc822 :-)
<TheMuso> mok0: You don't need dh_link in debian/rules, as you don't need to create any symbolic links other than the library ones do you? Those are automatically created.
<mok0> X-First-Packager: blah blah
<mok0> TheMuso: that's right
<mok0> TheMuso: 1-0 to you
<TheMuso> mok0: Do you want me to document my comments on the revu page?
<mok0> I think I have them in the scrollback
<TheMuso> Ok.
<mok0> TheMuso: I'll fix them right away, and persia's comments on debian/copyright, too
<TheMuso> ok
 * mok0 hugs TheMuso and persia 
<TheMuso> mok0: Oh yeah, you also might consider making sure your library has a soname, and you ahve a libgpp4-0.shlibs file to specify the minimum library version for more tight linking for other programs
<TheMuso> s/ahve/have/
<mok0> TheMuso: the major and minor version are both 0
<TheMuso> mok0: I know, but when symbols change, new versions of the library need to indicate to other packages somehow that they ned to depend on a newer version when being linked against.
<mok0> TheMuso: Isn't .shlibs created by dh_makeshlibs?
<TheMuso> mok0: I suggest you check out the school session next thursday that slangasek and another MOTU are doing about library packaging.
<mok0> TheMuso: Yeah, I have it on my calendar already!
<TheMuso> mok0: Yeah it does, but I've seen instances where packages have had them in the debian dir.
<mok0> TheMuso: isn't that a problem only if I bump the soversion?
<TheMuso> mok0: I think so. I'll be attending that session as I need a few things cleared up myself. At this point, I'm going only on experience.
<mok0> TheMuso: I won't do that unless the API changes
<slangasek> if your symbols have changed, *not* bumping the soversion is a problem...
<mok0> slangasek: that would be an ABI change, right?
<slangasek> yes
<mok0> But this is the first public version of the library, so I can't see how problems could arise until I release another version
<mok0> Say I change the API/ABI, I would bump the major sonumber and also change the name of the package to libgpp4-1
<C10uD> is there a way i can hardcode the dput ftp password somewhere? :P (now, i can do this uh!)
<slangasek> mok0: right
<mok0> That means applications using version 0 and version 1 could live side-by-side
<mok0> So I really don't understand what TheMuso talked about before, with the .shlibs file being necessary to write
<mok0> C10uD: ~/.dput.cf ?
<C10uD> i can't find the appropriate option in the manpage
<mok0> C10uD: Is it a local ftp site?
<slangasek> mok0: something has to generate the .shlibs; in some cases it's appropriate to let dh_makeshlibs do this on its own
<C10uD> nope
<mok0> slangasek: yeah that's what I thought
<slangasek> mok0: in other cases, you need to provide more information; such as when a new .0 version of the lib has added new symbols
<mok0> slangasek: I need to think about that
<nxvl> persia: i have edited mi wiki page, can you take a look and tell if if thats was you where talking about?
<mok0> slangasek: my understanding is that any change in API/ABI requires you to bump the major sonumber
<mok0> slangasek: but if you release a new version, for example with a bugfix, you bump the minor sonumber
<slangasek> mok0: any ABI change that breaks compatibility with existing apps built against a previous version of the lib requires you to bump the major sonumber
<mok0> slangasek: I think we're on the same page...
<slangasek> mok0: well, but you said "any change in API/ABI" - adding a new function is a change to the ABI, but it's a backwards-compatible one
<slangasek> so the soname doesn't change, but you need to make sure any apps built against that new function have a versioned dependency on the library
<slangasek> which is where you need to give that version information to dh_makeshlibs
<mok0> slangasek: got it
<mok0> slangasek: so creating a .shlibs file sort of helps you keep track
<mok0> slangasek: ... but then I have to get rid of dh_makeshlibs, yes?
<slangasek> mok0: in the normal case, you can still use dh_makeshlibs and just pass a -V option to it
<mok0> slangasek: ok, I will look at the man page.
<mok0> slangasek: thanks for a useful discussion. I will try to attend the motu school session next Thursday
<slangasek> mok0: ok, cheers
<TheMuso> I must admit, I think all prospective MOTUs should know this stuff. I'm not affraid to admit I don't entirely, and think this needs addressing, as MOTUs are expected to touch many packages, libraries included.
<slangasek> I think this definitely falls in the realm of "nice if everyone knew, not practical for that to happen any time soon"
<TheMuso> True, but I think something could be done for future MOTUs.
<slangasek> well, I think that would mean setting a much higher bar for MOTU admission
<bobbo> On the REVU wiki page it says i need an elgamal secondary key to recover my password, how do i go about creating one?
<TheMuso> slangasek: Well, IMO so be it.
<slangasek> hmm, you want the technical bar for MOTU to be higher than the technical bar for DDs?
 * TheMuso wasn't aware that this wasn't covered as something that dds should know.
<Fujitsu> slangasek: In some ways I think it should be, but perhaps not.
<slangasek> TheMuso: most DDs are pretty clueless when it comes to packaging libraries, both long-time DDs and NMs.  When I went through the NM queue, I remember there being a warning about not picking a library for my first package because libraries are Advanced. :)
<TheMuso> slangasek: Thats something that the library packaging guide mentions.
<TheMuso> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
 * slangasek makes warding signs
<TheMuso> huh?
<slangasek> TheMuso: I'm not happy with the library packaging guide; as you can see it's an independent work by one particular DD, and a few of the recommendations are insane
<TheMuso> Warding signs against the guide?
<TheMuso> slangasek: Ah. I must say the guide does ramble a bit as well, which makes it hard to read./
<TheMuso> SO fair enough, I won't be so quick to recommend it then.
<slangasek> yes, warding signs against the guide
<Kmos> http://ftp-master.debian.org/~joerg/removals/removals.rss
<Kmos> if someone interested
<slangasek> because I usually hear it mentioned in the context of "of course we changed the -dev package name, the library packaging guide said to"
<StevenK> Ugh.
<StevenK> BAD.
<TheMuso> slangasek: Has th ere been any thought o making an official packaging guide, if there isn't one already?
<slangasek> TheMuso: sure, I've thought about it a lot ;)
<slangasek> doing anything about it is another question entirely
<TheMuso> for libraries
<TheMuso> yep of course
<slangasek> unfortunately, I myself am behind the times; buxy has done a great job of implementing dpkg-gensymbols, but while I understand all the concepts I haven't had a chance to use it yet in any of my own libs
<TheMuso> Nice.
<minghua> Yeah.  I think I just saw a Debian package having a non-back-compatible ABI change without SONAME bump yesterday.
<minghua> The problem is that most upstream is clueless about SONAMEs too.
<rexbron> Question: CDBS does not seem to handle .desktop files, does someone know a way to do this?
<slangasek> yes, that is a problem; distros bear the burden of ensuring ABI consistency as part of their integration work, because many lib upstreams are ignorant or don't care
<slangasek> but that's exactly why -gensymbols is so valuable once we've grown a community of experts around its use, because it makes checking for ABI breakage an automatic thing
 * minghua nods
<minghua> I need to learn symbol versioning and the dpkg-gensymbols tool and apply them to my package.
<mok0> What is the correct Standards-version for hardy?
<minghua> Although I'm still not sure how good they will work for C++ libraries.
<Fujitsu> mok0: 3.7.3 at the moment.
<mok0> Fujitsu: thx
<minghua> Right, so this SONAME breakage is real, I can crash my application with it.
 * minghua goes to report a bug.
#ubuntu-motu 2008-01-11
 * minghua wonder if he should make it RC or not.
<Fujitsu> That sounds RC.
<minghua> The thing is, all packages that use this library is from the same source package.
<slangasek> minghua: if they're in separate binary packages, that's no excuse :)
<mok0> minghua: RC?
<TheMuso> release critical
<TheMuso> afaik
<minghua> slangasek: Right.  But only a small group of people use this package.  I doubt if I don't report, anyone else will.  And stopping the new version from migrating into testing is really worse than having this hypothetical "old version of executable segfaults with new library" issue...
<minghua> mok0: TheMuso is correct.
<mok0> thx
<minghua> Anyway, enought (sort of) off-topic ranting.
<mok0> minghua: we love rants
<mok0> Google said: "Did you mean: dpkg-gang symbols " :-)
<TheMuso> lol
<Fujitsu> Haha.
<minghua> Hmm, which policy section I should cite to justify my bug's RC status...
<minghua> Let's just use 8.6 and a blanket.
<mok0> minghua: have you had a chance to try out torque?
<minghua> mok0: No.  I don't really have an cluster system to try it on, actually.
<mok0> minghua: ah, you need at least two machines :-)
<mok0> minghua: but the more you have, the more fun
<mok0> minghua: anyway, I will fix the issues on REVU (all minor) and upload it again
<mok0> minghua: It would be good to get it into hardy
<minghua> mok0: That would be very nice.
<minghua> mok0: You still need to persuade people about the license issue, though.
<mok0> minghua: you think so? The most strange parts of the license have expired
<emgent> keescook, ping
<keescook> emgent: pong
<emgent> keescook, weel patch is done but i have some problem with phpbb package.
<mok0> minghua: "After December 31, 2001, only conditions 3-6 must be met"
<minghua> mok0: Yes, I feel it's good for universe, but I'm no license expert.
<emgent> keescook, http://rafb.net/p/5MIUqV62.html
<mok0> minghua: neither am I
<minghua> mok0: And my opinion hardly matters.
<keescook> emgent: I'd communicate with upstream first, and once there is an approved upstream patch, then worry about package builds.
<mok0> minghua: but there must be somebody who can make a qualified decision?
<emgent> ok cool.
<mok0> minghua: perhaps an Ubuntu member?
<emgent> i go to mail phpbb's people
<minghua> mok0: An archive admin, usually.
<mok0> minghua: perhaps I can ping one and discuss it
 * minghua doesn't think it's a good idea.
<mok0> why?
<minghua> They are busy, and they may not be acting archive admin duty today.
<minghua> Just IMHO anyway, feel free to ping one if you want.
<mok0> minghua: It's probably better to get the package in good shape, and get it processed the normal way.
<minghua> mok0: Yes, that's my preference.  You can always ask an archive admin to review the license before uploading (or once it's in NEW queue).
<mok0> minghua: great.
<minghua> mok0: By the way, "Ubuntu member" is a group with very low threshold: https://launchpad.net/~ubuntumembers
<minghua> mok0: You can become one if you want.
<mok0> minghua: Ah, i thought that was the exclusive group of canonical employees
 * minghua thinks that group is simply called "Canonical employees". :-P
<mok0> mok0: minghua; heh, I will try to join the ubuntu-member team, then
<mok0> 352 active members, 852 proposed members :-)
<emgent> lol
<emgent> mok0, good luke :P
<mok0> emgent: thanks I need it :-/
<emgent> i will try to motu
<mok0> me too
<emgent> motu include ubuntumembers
<emgent> mok0, I think that is good Continue on this road
<mok0> emgent: by the time the team adminstrators get through the list of 852 applicants, I will be a developer, lol
<emgent> ahahahaha
 * emgent nod
<pochu> mok0: that's handled differently. You need to present your application to the Community Council, and they will either approve you or not.
<mok0> pochu: yes I know, just kidding
<emgent> but in this council meeting there are news about approvation
<pochu> mok0: heh, ok :)
<mok0> pochu: I plan to submit my motu-application later this spring
<pochu> Good luck! :)
<mok0> pochu: heh, thanks
<mok0> pochu: it takes more hard work than luck I'm afraid
<emgent> mok0, https://wiki.ubuntu.com/CommunityCouncil/Delegation
<pochu> mok0: You're afraid? That's a good thing!
<emgent> fast procedure
<mok0> pochu: nothing to motivate like fear
<emgent> dholbach++
 * pochu goes to study
<emgent> bye pochu
<mok0> bye
<owh> Hiya, I'm trying to make a .deb with checkinstall for vmware-tools so I don't have to install the build-deps on a JEOS. I don't suppose anyone has already succeeded in doing that?
<Hobbsee> checkinstall is not supported in here.
<StevenK> Hopefully, it isn't supported anywhere, but that isn't likely.
<owh> StevenK: Is there a better way?
<Hobbsee> StevenK: well, you were the one who stopped it segfaulting.
<StevenK> owh: There is, but I've not managed to get vmware-tools packaged sanely.
<StevenK> It makes lovely assumptions, and fails if builder != host
<StevenK> If I recall correctly, it's been a while since I looked.
<owh> Ah, niiice :|
<owh> So, I get to install the build-deps, mount the .iso, extract the .gz, build it, delete the extracted dir, unmount the .iso and purge the build-deps?
<jdong> owh: the tools do a bit of host-specific kernel module compilation too so checkinstall will also NOT be able to deal with it
<jdong> owh: it's going to be complex to repackage and it might not even be legal for us to mangle their sources in this fashion
<owh> All I really care about is that I can sanely shutdown a vm-guest, don't care about anything else.
<Hobbsee> jdong: who said anything about us building it?
<StevenK> What Hobbsee said.
<owh> As opposed to powering it down :)
 * Hobbsee notes one can do that with virtualbox with no problem
<jdong> Hobbsee: checkinstall implies it. I'm just giving another reason why checkinstall will fail miserably in this application
<owh> jdong: We're talking about the guest tools here, not the server tools right?
<owh> Hobbsee: Yes, but then I'd have to deploy a whole new range of tools and given where I am right now, that's not an option :_(
<jdong> owh: right, the guest tools
<owh> jdong: I didn't see any kernel module stuff going on.
<Hobbsee> owh: ah right
<jdong> owh: I could've sworn there's kernel modules involved...
<jdong> owh: maybe I'm wrong and it's just binary Xorg drivers
<Hobbsee> jdong: sure you're not confused with virtualbox?  that has kernel modules
<jdong> owh: do the terms of licensing permit repackaging?
<owh> jdong: AFAIK that's the vmmon/vmnet stuff for the server. Could be the X stuff.
<jdong> Hobbsee: no, I was thinking of some redhat clients I deployed last summer
<owh> jdong: Dunno, this is in-house between guests on one server.
<Hobbsee> jdong: ahhh
<jdong> owh: why can't you just install linux-headers-generic build-essential and proceed from there?
<jdong> I don't see why it has to be rolled into an awful deb package
<owh> jdong: I can, but I'm trying to keep my jeos deployment simple. If I need to build a vm, then install depends, extract stuff, compile and remove things, my 4 minute automatic new machine deployment becomes a manual nightmare.
<jdong> owh: why not deploy the systems as tarballs of preconfigured systems?
<jdong> owh: or other forms of image cloning.... I don't see how deb packages would even simplify your life :)
<jdong> owh: or modify the install script (perl) to automatically apt-get the dependencies and remove them afterwards
<owh> jdong: Because deploying tarballs makes maintaining the tarball a manual mess.
<jdong> I think you'll waste more time trying to package the tools sanely compared to just rolling it out
<owh> jdong: Modifying the perl script is an idea.
<owh> Sigh, so much to do and so much time being wasted in mundania :(
<jdong> you will need a custom package of some sort. A custom deb package you have to craft vs modifing a perl script and re-rolling the tools tarball?
<jdong> I think the latter is much much easier
<owh> jdong: Thanks for your thoughts, I'll take a break and have another look at it.
<jdong> owh: sure thing, good luck :)
<owh> :)
<bddebian> Heya gang
<RAOF> Aloha bddebian.
<bddebian> Hi RAOF
<TheMuso> Ok it built.
<TheMuso> Now to disect the debs.
<TheMuso> woops wrong channel
<jdong> TheMuso: I think you mean dissect. I'm pretty sure disecting involves cutting in half....
<jdong> TheMuso: though if they were automatix debs...
<TheMuso> jdong: Whatver. :p Basically pulling them appart.
<StevenK> dict doesn't know about disect
<TheMuso> Well my typing hasn't been the best on this keyboard lately. I think it needs replacing.
<RAOF_> Yay, cool.  Looks like monodevelop can be sync'd soon.
<jdong> RAOF_: yay!
<jdong> is there a LP dgettable URL that's aliased to the latest version of source package foo for distro bar?
<jdong> or am I still gonna have to regex-scrape for that? *grumble*
<Fujitsu> jdong: There isn't one for the latest, but one can add /+files on the end of any SourcePackageRelease URL to get dgettable .dsc.
<jdong> Fujitsu: mmmkay I'll just navigate to $release/+source/pkgname and scrape for a dsc to dget :)
<bddebian> Can I regexp the search expression in grep?  I want to find every instance of SDL_*.h  ?
<StevenK> That's a glob, not a regex
<lifeless> its a regex
<bddebian> OK, can I use globs then? :)
<lifeless> but the regex won't do what you want :)
<StevenK> Oh right.
<ion_> Unless you want to find e.g. SDL.h and SDL____________________________________.h :-)
<lifeless> and SDLKh
<ion_> Oh, and SDL__Xh
<StevenK> bddebian: grep -E 'SDL_[A-Za-z]*.h
<StevenK> '
<bddebian> OK, OK, I get it, how can I do it.. Sheesh :)
<bddebian> Ah, thx StevenK
<lifeless> egrep 'SDL_[\w]+\.h'
 * StevenK recommends bddebian actually read grep(1)
<lifeless> perhaps
<ion_> No need to put [] around \w
<lifeless> bleh true
<bddebian> StevenK: Well I knew I could, I just completely suck at regexp :-(
<lifeless> actrually, 'SDL_.+\.h' is really what is wanted
<ion_> Also, to avoid matching fooSDL_bar.hz, add \< \> around the expression.
<StevenK>  399 files changed, 26415 insertions(+), 107889 deletions(-)
 * StevenK sobs
<ion_> Hehe. What is that?
<StevenK> A diff between two Pidgin trees
<Fujitsu> StevenK: Is that a micro-release?
<StevenK> Nope.
<Fujitsu> Ah. Boring then.
<emgent> morning *
<bddebian> Goddamnit, why does adonthell have it's own SDL headers.. Grrr
<ScottK> StevenK: Still around?
<StevenK> ScottK: I might be.
<ScottK> StevenK: I need a core-dev to do a source backport for clamav to close a remote execution vulnterability.  It's a small change.  Would you be up for an upload in ~20/30 minutes after I'm done testing?
<StevenK> ScottK: I could be convinced.
<ScottK> OK.
 * ScottK will finish testing and then work on convincing.
<bddebian> heh
<StevenK> You have: 900000000000000 seconds
<StevenK> You want: millennia
<StevenK>         * 28519.888
<StevenK> I don't think so, dmb
<dmb> lol
<emgent> hahaha
<ScottK> StevenK: The debdiff (from the current version in gutsy-security) for feisty-backports is in Bug #181830.
<ubotu> Launchpad bug 181830 in feisty-backports "CVE-2007-6337 Unknown impact remote attack" [Undecided,Confirmed] https://launchpad.net/bugs/181830
<ScottK> StevenK: Would you please be so kind as to upload that?
<dholbach> good morning
<TheMuso> Hey dholbach.
<ScottK> Good mornging dholbach.
<ScottK> morning even
<dholbach> hey TheMuso, hey ScottK!
<dholbach> how are you doing?
<ScottK> dholbach: The other MC members +1'ed \sh while you were out, so you can give him a nice birthday present today.
<emgent> morning dholbach :)
<dholbach> ScottK: working on it
<dholbach> hey emgent
<ScottK> Cool
<emgent> Rock and Roll! (an beer)
<emgent> heheh
<ScottK> Good night all.  I'm off to bed.
<dholbach> sleep tight!
<emgent> ScottK, see you later
<ScottK> \sh_away: Congratulations and Happy Birthday.
<ScottK> Good night again.  This time really.
<dholbach> \sh_away: and the same from me - and welcome back to the team :)
<TheMuso> dholbach: I'm great thanks.
<TheMuso> p/c
<TheMuso> ugh
<AnAnt> hello, how do I make a patch for a diff.gz ?
<AnAnt> I mean a diff between 2 diff.gz files
<Chipzz> apologies if this is off-topic, but can anyone check if sourceforge cvs is broken? I'm getting "cvs [checkout aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: No route to host" on 2 different hosts...
<StevenK> AnAnt: gunzip them and then interdiff them
<josesanch> Hello. I have uploaded a package to revu and I'm wondering if i made any mistake beause the package is not comment by anyone
<AnAnt> ok
<josesanch> The name of package is gnomecatalog
<StevenK> Chipzz: telnet: Unable to connect to remote host: No route to host
<AnAnt> Chipzz: aren't they phasing out CVS in favor of SVN ?
<Chipzz> AnAnt: no idea really...
<Chipzz> the weird thing is
<Chipzz> tcptraceroute 66.35.250.207 2401 actually *does* work
<AnAnt> wierd
<Chipzz> StevenK: thx, same as I was getting apparently
<AnAnt> svn isn't working even
<Chipzz> what I was actually trying to do is checkout the cvs version of gitk
<Chipzz> because I was wondering if there was a reason we ship the tcl/tk version when gitk cvs has a gtk+ front-end
<Chipzz> (was going to look into what version gitk cvs was etc...)
<Chipzz> hrrrrm
 * Chipzz slaps self
<Chipzz> ignore what I just said
<lucas> Fujitsu: could you please enable a "Ruby-related packages" list on http://qa.ubuntuwire.com/~fujitsu/mdt/?
<man-di> Fujitsu: and a "Java-related packages" list...
<lucas> Fujitsu: listing all packages that have binary packages that (indirectly) depends on libruby1.8 or libruby1.9 would be enough
<Fujitsu> man-di: How would I determine that?
<Fujitsu> lucas: Doing so.
<josesanch> Hello. I have uploaded a package /to revu and I'm wondering if i made any mistake beacuse the package is not comment by anyone. The package is http://revu.tauware.de/details.py?package=gnomecatalog
<amarillion> josesanch, no mistake... I'm too waiting for someone to review my package
<amarillion> this one btw: http://revu.tauware.de/details.py?package=speed-game
<josesanch> amarillion Thanks. I'm a newbie in this
<amarillion> me too :)
<amarillion> But it seems that it takes a while to get your package reviewed
<Fujitsu> lucas: That's a lot of packages.
<lucas> Fujitsu: a few hundreds, no?
<amarillion> josesanch, I'm looking at your package right now
<Fujitsu> lucas: The recursive rdepends of libruby1.8 are enormous.
<amarillion> is it in Debian already?
<josesanch> No, is not in debian.
<amarillion> ok, then you need to use 0ubuntu1 as package version number
<josesanch> ahh.
<amarillion> Also, is this a native package? I don't see an orig.tar.gz
<amarillion> You can ignore the linda error: gnomecatalog; 3.7.3 is a newer Standards-Version.
<amarillion> everyone is getting that
<amarillion> But you definitely need to fix this one: E: gnomecatalog_0.3.1-1.2_source.changes: bad-distribution-in-changes-file hardy
<josesanch> amarillion gnomecatalog-0.3.1-0ubuntu1 ?
<amarillion> I suspect that it goes away once you use "ubuntu" in the version number
<josesanch> Ahhh..
<amarillion> josesanch, exactly. Whenever gnomecatelog is added to debian, it will get gnomecatalog-0.3.1-1 which is higher than 0.3.1-0
<amarillion> so it will be automatically overriden when added to debian
<josesanch> I don't know why then orig.tar.gz is not there
<josesanch> It must be there
<josesanch> :)
<josesanch> Well, it looks like i have work todo with the package
<amarillion> Did you package with debuild -S -sa
<amarillion> ?
<josesanch> Yes, i think so
<huats> morning dears motus
<amarillion> oh then I don't know why that is happening
<amarillion> hi huats
<josesanch> I'll make the chages you comment me and will submit again
<amarillion> josesanch, ok, good luck
<josesanch> amarillion Thanks a lot
<josesanch> I will be back :)
<huats> nxvl: ping
<man-di> Fujitsu: a good start would be to look in Maintainer and XSBC-Original-Maintainer for "Debian Java"
<man-di> Fujitsu: that doesnt find all of them as some are not maintained by debian java team
<man-di> Fujitsu: in debian you can search the tags for "lang:java" but I dont know if Ubuntu has that tagging yet too
<Fujitsu> GOod point. Anybody know why we don't have such tags?
<\sh> moins
<\sh> and THANKS A LOT good to be back :)
<\sh> was someone working on the final debdiffs from che regarding the libgif transitions?
<TheMuso> \sh: Congratulations! Great to have ou back!
<\sh> TheMuso: thx :)
<\sh> cool....all my libgif stuff uploaded...
<\sh> thx dholbach
<persia> StevenK: AnAnt: interdiff has a -z option to save on the unpack.
<StevenK> Aww
 * StevenK will have to remember that
<persia> Fujitsu: If you're updating mdt feeds, could you also look at the links on the main mdt page?  Some of them seem odd.
<josesanch> amarillion. I have uploaded a new version, now with orig.tar.gz
 * rzr fixed http://revu.tauware.de/details.py?package=jaaa
<amarillion> josesanch, yeah. looks better
<persia> rzr: Could you do a quick bounce of -0ubuntu1 in preference to -1ubuntu1?  I'd be happy to take a look, but know that needs to be fixed before even digging in.
<amarillion> btw, my package speed-game (http://revu.tauware.de/details.py?package=speed-game) has been fixed too
 * josesanch fixed http://revu.tauware.de/details.py?package=gnomecatalog
<rzr> persia: sure
 * persia recommends that josesanch review speed-game whilst amarillion reviews gnomecatalog.  persia will review whichever one of the packages that escapes unscathed
<amarillion> hehe, so I have to find a fault in gnomecatalog otherwise you won't review my package?
<amarillion> dirty tricks...
<amarillion> well, let me take a look then
<persia> amarillion: Something like that.  I like to think of it as an incentive for collaboration :)
<josesanch> persia: Ok.. i am going to review it right now
<persia> Excellent!  The game is on...
<amarillion> btw I already did one quick review of gnome-catalog earlier. Just so you know that I really am willing to help out.
<persia> amarillion: I don't doubt it.  Few without that attitude come here :)  I just only feel like a couple reviews this evening, and so proposed this to pick the second of them.
<amarillion> It's actually not a bad way to go about this. A little machiavellian... but with good results.
<persia> superm1: I don't suppose I could convince you to move more of the mythbuntu packages to multiverse to make debcheck happy, could I?
<Ng> if some kind soul would care to look over http://revu.tauware.de/details.py?upid=1212 I believe I have addressed all of the comments now :)
 * persia wonders if anyone would like to pair with Ng
<StevenK> Ah. A clue to find more.
<josesanch> amarillion: the game is very cool
<rzr> persia: well I have this warning "Description: The menu file has section Applications, which is unknown."
<josesanch> it has two warning that have mine package too  Maintainer: does not have Ubuntu address and there is no XSBC-Original-Maintainer field
<persia> rzr: That's because revu isn't using the newest lintian (I suspect).  Check again against lintian 1.23.41
<rzr> /exec -o lintian --version
<rzr> Lintian v1.23.41
<rzr> on my system ..
<rzr> debian tough
<persia> Uploads unique to Ubuntu should have an @ubuntu.com maintainer.  You can assign maintenance to the MOTU team with Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com> (but we like XSBC-Original-Maintainer when assigned maintenance, and appreciate help)
<persia> josesanch: Maybe it needs to be Applications/Something?
<DaveMorris> I don't suppose there is a google calender version of the gutsy release schedule, I see there is a iCal version
<DaveMorris> s/gutsy/hardy
<rzr> grep section  debian/jaaa.menu
<rzr>  section="Applications/Sound"\
<josesanch> persia: application/accesories
<persia> josesanch: s/Application/Applications/, I suspect.
<amarillion> josesanch, thanks, I didn't write it myself
<josesanch> thanks persia i'm going to do that changes
<promag> persia: do you know how can I make a custom automake rule available system wide?
<persia> promag: No.  Also, why me?  Also, why #ubuntu-motu?  Also, why would that even be interesting?
<persia> rzr: Umm.  I asked for "0.4.2-1ubuntu1" -> "0.4.2-0ubuntu1".  The new candidate is "0.4.2-1ubuntu2".
<promag> why you? because you're a nice person :P why #ubuntu-motu? becase #devtools is like a dead channel and because here are intelligent ppl... and it would be interesting to me :)
<rzr> it's because of the distortion in the channel :)
<rzr> sorry
<persia> Aha.  Always be sure the communication channels are at right angles to the power channels, and you'll be safe.
<rzr> now I open my eyes :)
<rzr> let me fix this
<persia> rzr: Oh, goot catch on the security issue.  -13 looks much nicer :)
<rzr> yea
<rzr> I waited it to enter testing to comment the bug
<rzr> i wanted to wait ..
<josesanch> persia: in what file have to change application by applications/ ?
<persia> josesanch: menu
<rzr> josesanch: w/ a "A"
<rzr> persia: should I also upload whitedune to revu ?
<josesanch> section is now Apps/Tools i have to change by Applications/Tools?
<persia> rzr: Isn't that in Debian?
<rzr> it is
<rzr> I did the job
<persia> josesanch: Right.  There was a policy change between gutsy and hardy for menu structure.
<persia> rzr: I thought I remembered a sync request.  No need to send to REVU.
<rzr> ok
<rzr> anyway my priority is on jaaa, and will be unicorn before whitedune
<persia> rzr: Just watch the sync request, and make sure it gets synced in the next couple weeks, or it likely won't make hardy.
<amarillion> Hey josesanch, I get a few lintian errors when I try to build your package
<amarillion> e.g E: gnomecatalog: extended-description-is-empty
<amarillion> and E: gnomecatalog: copyright-should-refer-to-common-license-file-for-gpl
<amarillion> for the last one you can simply refer to /usr/share/common-licenses/GPL3
<josesanch> amarillion: Thanks, i'll to review that
<persia> jdong: s/disect/bisect/
<rulus> how long does it take for an uploaded package to appear on the REVU website?
<amarillion> rulus, a few minutes usually
<rulus> ah, thanks :)
<persia> rulus: between 2 and 12 minutes.
<amarillion> provided that your GPG key is added to the revu list
<amarillion> I had that problem a few days ago
<rulus> I think it is, dput said that the upload was succesfull
<amarillion> it depends on when you subscribed to the Universe contributors team
<rulus> I am
<rulus> :)
<rulus> already a few weeks, so that should be not problem
<persia> rzr: jaaa commented.
<persia> amarillion: josesanch: did either of your packages survive?
<amarillion> I'm making a new one with the Maintainer set to the motu list
<rzr> persia: > I like ALL_CAPS for make variables.
<amarillion> then I can set XBC-Original-Maintainer set to me right?
<LucidFox> inkblot, which passed REVU, was rejected on the grounds that it lacked the text of the LGPL for eggtrayicon.{c,h}. I was asked to repackage the orig.tar.gz and add it. Now here's the question:
<rzr> persia: UPCASE_VAR are for conventional vars ... locase_one are for private usage
<LucidFox> If it's "LGPL 2 or later", which version should I add - 2, 2.1 or 3?
<amarillion> s/XBC/XSBC/
<rzr> FYI, I've read that somewhere on the wide internet :)
<persia> rzr: Depends on how one defines "private" :)
<persia> LucidFox: Depends on how you want to license it to others (based on the license you received).  -2 grants your endusers (the distribution, and it's users) the most flexibility.
<rzr> for me private refer to something isnt wrote on some public paper ..
<amarillion> persia, can I ignore this: warning, `debian/speed-game/DEBIAN/control' contains user-defined field `Original-Maintainer'?
<persia> amarillion: Yes.  I thiought that was taken away for -XubuntuY.  Hrm.
<LucidFox> The license headers mention "Lesser GPL 2 or later", but version 2 is called "Library GPL" - it was renamed to Lesser in version 2.1. Does this affect anything?
<amarillion> josesanch, did you find more problems with my package?
<persia> LucidFox: That might deserve clarification with upstream.  If there is no "Lesser GPL 2", then you may not have a good guide as to what license you received, which may impact your ability to extend a license to Ubuntu.
<josesanch> No..
<josesanch> But i'am not an expert :)
 * persia notes that this technicality of the packager providing the license to the distribution, which the distribution then uses to provide licenses to end-users is why having the name of the original packager in debian/copyright is useful.  This doesn't apply in all jurisdictions of course...
<LucidFox> But the author of inkblot is not the author of eggtrayicon. It's found in many sources.
<persia> josesanch: Don't worry that you're not an expert.  I learned half of what I know about reviewing from lintian and linda.
<josesanch> jejeje
<amarillion> this reminds me: persia, why did you suggest the ISC license earlier?
<persia> LucidFox: In that case, it may be that the author of inkblot needs clarification regarding the license extended to you.  Such recursion may be even more levels, depending.  This is why precision in licensing is important.
<rulus> amarillion, persia: it has appeared :)
<amarillion> When I needed to add the text, I couldn't find a good source for it
<amarillion> ISC doesn't seem to be very well documented
<persia> amarillion: For people without an existing relationship with the Regents of the University of California, it's easier to use than BSD.
<persia> amarillion: The full license is three paragraphs, quoted entire in the wikipedia entry.
<amarillion> Well... I couldn't find exactly how to do it so I just copied the text from the dhcp package
<LucidFox> Now looking at the rhythmbox source, and it only includes the text of the GPL, even though it also includes eggtrayicon.{c,h}
<persia> amarillion: Also, I don't recommend ISC as a blanket license.  It's not right for everyone.  I just think it's a better choice when people are considering a BSD license.
<amarillion> It's just that after googling I found this: http://ictlab.tyict.vtc.edu.hk/pub/tarball/dhcp-3.0b2pl3/ISC-LICENSE which confuses me. It's a lot more text
<persia> LucidFox: Write up your research, and forward it with your rejection note to cjwatson.  A test case was sought earlier on this.
<josesanch> persia: from lintian i don't have warnings but for linda i have a 3.7.3 is a newer standards-version
<amarillion> There doesn't seem to be documentation from the ISC itself
<persia> amarillion: When I say "ISC license", I mean that listed at http://en.wikipedia.org/wiki/ISC_licence
<amarillion> ok
<amarillion> but I don't think you should recommend that one over BSD
<amarillion> not anymore
<amarillion> it's too unclear
<persia> josesanch: linda is currently experiencing the bends (issues with decompression), and has not yet become aware of the new standards version.
<persia> amarillion: The "BSD" license requires copyright assignment to the Regents of the University of California, which is not even possible in many jurisdictions.  I think using ISC is preferable to drafting a new license based on the BSD license.
<persia> Also, I don't see what is unclear.  It states who holds copyright, what the licensee is entitled to do with the work, and provides a disclaimer of liability.
<amarillion> The text on wikipedia is very clear. To me, what is unclear is: who is the ISC? Why is it a good idea to use their text when almost nobody else uses it? Which text do I use exactly (you didn't refer to the wikipedia entry explicitly before, and just googling for ISC license comes up with contradictory results)
<LucidFox> mpeg4ip rejected again? Nnnnnoooooo
<persia> amarillion: Internet Systems Consortium.  (#2 in Google for "ISC"), and the wikipedia entry is #1 in Google for "ISC license".  It's used by heaps of stuff, but it is fairly new, so there's not so much talk about it, and a lot of people consider it a "modified BSD", so it falls into the "BSD-style" licenses in many discussions.
 * persia grumbles at ISC for being "Internet Systems Consortium" and "Internet Software Consortium" both housed at isc.org :(
<verb3k> guys what's the easiest ubuntu packaging guide? (not MOTU  guide)
<emgent> sure
<emgent> wait
<persia> !packaging | verb3k
<ubotu> verb3k: 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
<emgent> http://doc.ubuntu.com/ubuntu/packagingguide/C/
<emgent> persia++
<verb3k> emgent, thank you :)
<persia> emgent: That's a little outdated (although the one ubotu provided is WIP).
<emgent> persia, ok cool.
<verb3k> persia, so I should use the one supplied by ubotu ?
<persia> verb3k: Both work to get started.  One is in-process, so may have gaps or unclear portions.  The other is old, and so may have inaccuracies or recommend deprecated processes.  Either can be a useful introduction.
<verb3k> persia, I see, thanks for your help and time
<ChrisGibbs> !info initramfs
<ubotu> Package initramfs does not exist in gutsy
<persia> Note also that we're about 4 weeks from feature freeze, so the chances of a brand new candidate getting into the hardy archives are fast narrowing (especially for those just learning packaging).  Don't get discouraged if we hit the freeze, and the package is delayed until hardy+1.
<persia> ChrisGibbs: -tools
<ChrisGibbs> persia, ?
<persia> ChrisGibbs: the missing part of the package name for the package you seek.
<ChrisGibbs> persia, soz ty
<ChrisGibbs> !info initramfs-tools
<ubotu> initramfs-tools: tools for generating an initramfs. In component main, is important. Version 0.85eubuntu20 (gutsy), package size 62 kB, installed size 372 kB
 * persia advocates the use of rmadison
<ion_> Eubuntu â Ubuntu for amphetamine users.
<ChrisGibbs> think im about to break my Ubuntu 7.10 desktop for the 50th time this wk trying to get RAID toplay nicely :)
 * persia likes amphetamine, but can't get past the house
<persia> (http://n.ethz.ch/student/loehrerl/amph/amph.html for those without context)
<ion_> persia: 404
 * persia grumbles about upstreams who lose their homepages, and hopes someone will submit a debdiff against amphetamine fixing that little issue.
 * DaveMorris pimps his package again - http://revu.tauware.de/details.py?package=libserial - please review it, all previous comments addressed
<persia> Ng: More points added, but I shan't review again until someone else has a look, as more viewpoints make a better package
 * persia stops REVUing until REVU day (only 46.5 hours away)
<Ng> persia: ok thanks :)
<persia> Ng: Please get the viewpoints quick though.  I want to use it :)
<Ng> persia: hehe, will do. I just upgraded to hardy, so I want to be able to install it with apt-get soon, and I only have a month to make that happen ;)
<\sh> moins jono
<jono> hey \sh
<\sh> jono: as promised last year ;)
<persia> Ng: Really only a couple weeks, as you need to allow time for the archive admins to process the NEW queue.
<jono> \sh: eh?
<Ng> persia: erk
<\sh> jono: see p.u.c.
<jono> \sh: you are a hero! :)
<\sh> jono: na..I just want to have the opportunity to listen to your music some time :) and to have a good place in front of the speakers, I have to stay to my promises...
<jono> \sh: you are a good man :)
<\sh> .oO(that reminds me, I need to make a phone call to get my birth certificate...one of my important promises is to marry my GF)
<\sh> ok..birth certificate is on its way
<amarillion> How do I write a watch file if upstream doesn't include a version no in the filename / path?
<amarillion> or do I then not write a watch file at all?
<persia> amarillion: You can't write a watch file if upstream doesn't have a version in their filename or path :(  Use a get-orig-source rule in debian/rules.
<amarillion> okidoki
<amarillion> b
<josesanch> persia: what else can to try to review the package?
<persia> josesanch: I'm afraid I don't quite understand.  Are you asking how else you can review a package, or how else you can get your package reviewed?
<josesanch> persia: Sorry. I mean. how else i can do to verify that the package is correct. I have use lintian and linda and compiles ok..
<persia> josesanch: My review process (which may not be best) consists of lintian and linda run against the source package, a test build, linda and lintian against the binary, manual inspection of all files modified in diff.gz, a licensing header check, comparison of everything output by `less $(suspicious-source)` against debian/copyright, and tests with uscan --report-status, uscan --force-download, and debian/rules get-orig-source.
<persia> On the other hand, few packages I advocate get into the archive without someone else finding something, so that's by no means comprehensive.
<emgent> uhm people
<emgent> i have debchange problem
<emgent> see: http://rafb.net/p/JlaIiU54.html
<emgent> some idea?
<Fujitsu> emgent: You forgot the leading space on your signature line. Don't edit that manually in future.
<emgent> uhm ok thanks
<josesanch> persian: seens prety complex. Thanks for the advice. i'll try to do that
<persia> emgent: Not related to your problem, but you probably want 5.2-2ubuntu2.2 for your new candidate version.
<emgent> ok cool thanks
<persia> Amaranth: Lots of candidates on REVU for your attention.  Even a few with an advocate.
<Amaranth> d'oh
 * Amaranth needs to learn to stop talking
<Amaranth> I don't even know where revu is hosted these days
<Amaranth> and i don't think i've ever had upload access to any version of it :P
<Amaranth> !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
<persia> Amaranth: revu.ubuntuwire.com works
<persia> Amaranth: You've had upload access since 26th April :)
<Amaranth> interesting
<persia> (or thereabouts: I may be off by a couple days)
<Amaranth> lintian and linda are outdated on revu?
<DaveMorris> yeah
<persia> Amaranth: Can you comment when you log in?
<Amaranth> i dunno my login info
<persia> Amaranth: Try to "recover" it.  If that doesn't work, I'll play with a couple things.
<Amaranth> No REVU account for amaranth@ubuntu.com exists yet.
<persia> Right.  OK.  Trying to fix...
<persia> Amaranth: Try the email address listed on your key.
<Amaranth> i have two listed on my key
<persia> (Assuming E7B7AC6B is yours)
<Amaranth> but neither one works
<Amaranth> alleykat@gmail.com and amaranth@ubuntu.com
<persia> Amaranth: keyserver.u.c only knows about the former.  I can set that up now, or wait for you to refresh your key on LP.
<Amaranth> oops
<Amaranth> persia: hrm, i forgot how to do all of this :P
<persia> Amaranth: First, make sure your local key is correct.  Then either use the GPG command line to update the keyservers, or use "Update OpenPGP keys" from https://launchpad.net/~amaranth
<Amaranth> there we go
<Amaranth> stupid seahorse is setup by default to not actually sync anything when you tell it to sync
<Amaranth> updated
<persia> Amaranth: OK.  Adding your Ubuntu address as a reviewer, and resyncing.  I'll let you know when I think you can recover your password.
<Amaranth> alright
<verb3k> guys in the packaging guides of ubuntu and debian, they assume you want to package binaries you build from source code at packaging time, is there a quick guide for making packages of binary files only without dealing with source code compilation?
 * Hobbsee blinks
<Hobbsee> uh...
<Pici> uh?
<verb3k> ???
<Pici> Magic?
<verb3k> Did I make a mistake :(
<amarillion> Why is REVU suddenly rejecting my uploads?
<persia> verb3k: It's generally not permitted.
<persia> amarillion: Might be my fault.  I'm in the middle of a keyring sync.  Sorry.
<amarillion> "Signer has no upload rights at all to this distribution."
<amarillion> ok, I'll wait
<verb3k> persia, I know, they are for my personal use only
<amarillion> verb3k, i've done it once, it's not hard
<amarillion> Let me find some notes on how I did it
<persia> verb3k: If you really, really, really, really, really want to, you can just install the stuff in the right places.  Look at one of the -looks or -theme or -artwork packages as an example.  Note that this is not considered a good idea, for several reasons.
<amarillion> verb3k, you have to start writing a DEBIAN/control file
<verb3k> amarillion, I am following
<verb3k> I've read about that file
<amarillion> I've got an example, just a sec
<amarillion> Note that the control file for binary packages is different from the control file from source packages. It's derived from it, but it's not exactly the same. Just know that when you're reading docs on control files, because usually they apply to control files for source packages
<amarillion> Ok, here is one I used in the past: http://paste.ubuntu-nl.org/51546/
<ion_> Priority probably should be optional, Standards-Version is missing and what is Version doing there?
<amarillion> You also need to create a complete hierarchy of the files you want installed
<ion_> Oh, also Source: is missing from the beginning.
<amarillion> ion_, this is just an example
<amarillion> ion_, this is a control file for a binary package
<verb3k> amarillion, nice, execuse me ....5 mins and I will come back
<RainCT> @now europe/berlin
<ubotu> Current time in Europe/Berlin: January 11 2008, 13:31:59 - Next meeting: Kubuntu Developers in 22 hours 28 minutes
<ion_> amarillion: Uh. You still should make a source package, even if it doesnât compile anything.
<amarillion> ion_, yes, if you're an ubuntu MOTU
<amarillion> but for ordinary users it may be handy sometimes to make a binary package directly
<persia> amarillion: I agree with ion_, it's better to create a "source" package, even if you're just manually pushing binary files around.
<amarillion> creating a binary package directly is easier. You don't need to understand makefiles
<ion_> You donât really need to understand makefiles to put stuff in debian/foo.install.
<amarillion> You only need to create the file hierarchy you want, c/p a control file and run dpkg-deb -b
<amarillion> ion_, I don't know about foo.install ?
<persia> amarillion: Yes, but it's hard to recreate if you want to fix it later.  A debhelper-only CDBS debian/rules, debian/package.install, and debian/control will get you an easy to edit "source" package.
<persia> amarillion: Comes from dh_install.
<ChrisGibbs> gday all
<\sh> grmpf...I set /etc/alternatives/x-window-decorator back to gtk-window-decorator...but emerald is always starting...what's wrong..I don't see the bug
<ion_> sh: /desktop/gnome/applications/window_manager iâd guess.
<\sh> ion_: compiz is in there
<ion_> Ah, sorry, i misread your question.
<\sh> ah
<\sh> now I know where it is
<ion_> I somehow managed to interpret it as you want to switch to metacity.
<ion_> The compiz wrapper always uses emerald if itâs installed.
<verb3k> sorry amarillion, I had something urgent, back now :)
<\sh> ion_: yeah...I think it's abug ;)
<Amaranth> \sh: the problem is the compiz start script starting the wrong one and overriding the alternatives (which i didn't even know existed)
<ion_> sh: Correction: you can add USE_EMERALD=no to /etc/xdg/compiz/compiz-manager
<amarillion> verb3k, there is only one more step
<verb3k> yes
<amarillion> you have to run dpkg-deb -b your-work-directory
<amarillion> this will produce a .deb file
<dholbach> MOTU Q&A Session in 14 minutes in #ubuntu-classroom!
<verb3k> amarillion, this means that I only need three things: 1-dpkg-deb 2- the control file 3-my actual binaries .....is that true?
<amarillion> verb3k, right
<amarillion> read back the discussion that went on while you were away
<verb3k> amarillion, ok
<amarillion> with debian/package.install you can create a source package to do the same thing, it's a better way to do things
<amarillion> the way I explained is the most direct though
<minghua> Hmm, why are we talking about directly modifying binary packages here?
<minghua> IMHO it's a very hackish and wrong approach.
<verb3k> amarillion, how do I create the file hierarchy? what's the syntax and should they be in the control file itself?
<amarillion> not in the control file no
<amarillion> it depends. What kind of files do you want to install?
<josesanch> amarillion: it seens that there is an error in your manpage
<amarillion> josesanch, aaahhh, thanks for checking
<amarillion> how did you find out?
<Hattory> \sh, ping
<josesanch> I run lintian on the binary package
<josesanch> lintian -i binarypackage.deb
<\sh> Hattory: pong
<verb3k> hmm....basically I want to install executables, scripts and other binaries(data and so)
<amarillion> josesanch, weird? I don't get any errors when I do that on my own package
<josesanch> in your binary package?
<Hattory> \sh, Yesterday, I sent you an email about a merge of alogg package
<Hattory> You have received it?
<amarillion> verb3k, so for example, executables usually go in /usr/bin
<amarillion> data that is cross-platform can go in /usr/share/
<Hattory> Have you* :D
<amarillion> Hey Hattory, are you into allegro?
<verb3k> amarillion, I see, but what's the file and its syntax?
<amarillion> verb3k, well simply create a hierarchy like this
<amarillion> ~/workdir/usr/bin/your_binary
<persia> Amaranth: Please test REVU password recovery (sorry for the delay)
<amarillion> ~/workdir/etc/your_config_file
<Amaranth> persia: err, but i already have my password :P
<amarillion> ~/workdir/usr/share/dir/your_data_files
<Amaranth> but alright
<amarillion> ~/workdir/DEBIAN/control
<ScottK> Good morning all.
<persia> Amaranth: Yes, but I want to make sure you can recover it.
<amarillion> and then run dpkg-deb -b on workdir
<\sh> Hattory: not that I know..I check my trash could be that it landed there
<verb3k> amarillion, can I name it anything or something specific?
<amarillion> anything, as long as it doesn't clash with existing stuff
<\sh> Hattory: got it :)
<Hattory> sorry.... -.-'
<verb3k> amarillion, and that's all? I mean just these two files only?
<Hattory> \sh, good.... can I do it?
<Amaranth> persia: works fine
<josesanch> amarillion: lexgrog -m speed-game.1
<amarillion> verb3k, yes, try it
<persia> Amaranth: Excellent.  Cleaning my history and wiping my brain :)
<josesanch> checks the manpages
<verb3k> amarillion,   :)    thanks I'll try and let you know
<\sh> Hattory: please do :) just check if debian upstream added our changes..if not merge it :)
<amarillion> josesanch, I don't really get an error
<amarillion> it just echo's the title of the man page
<ScottK> StevenK: I gather you weren't able to find the time to do the clamav upload for feisty-backports?
<Hattory> \sh, ok thanks ;)
<StevenK> ScottK: That and forgot. I can do it now if you wish.
<verb3k> if I have to make the package depend on some other packages in the repositories, where do I specify that?
<josesanch> amarillion: Oh.. sorry then..
<DktrKranz> hey \sh, happy birthday and congrats!
<ScottK> StevenK: Yes, please.
<\sh> DktrKranz: thx :)
<StevenK> ScottK: debdiff / interdiff / source link?
<josesanch> i got the parse.error i don't know why
<amarillion> josesanch, it's allright. I'm really not 100% sure the man file is correct
<verb3k> amarillion, if I have to make the package depend on some other packages in the repositories, where do I specify that?
<amarillion> I haven't found good docs on writing simple man pages yet
<ScottK> StevenK: Debdiff is in this bug: Bug #181830 - Debdiff is relative to the version in gutsy-security.
<ubotu> Launchpad bug 181830 in feisty-backports "CVE-2007-6337 Unknown impact remote attack" [Undecided,Confirmed] https://launchpad.net/bugs/181830
<amarillion> verb3k, That should go in the Depends line of the control file
<Hattory> \sh, is your birthday? :D
<verb3k> amarillion, I see
<\sh> Hattory: yepp :)
<persia> verb3k: If you compile it, debhelper can help automatically set the dependencies, based on the files you build-depend upon.
<Hattory> \sh, cooool.... happy birthday and congrats for the membership!!!
<Amaranth> \sh: happy birthday
<verb3k> persia, right, but I am dealing with binaries so can't compile anything
<Amaranth> knew i forgot something
<persia> verb3k: Frustrating that, but understood.
<\sh> thx a lot guys...good to be back :)
 * persia notes that people who file patches to fix http://qa.ubuntuwire.com/lintian/reports/Tbuild-depends-on-obsolete-package.html get extra points
<ScottK> persia: For debmake, do removal bugs count as fixing?
<persia> ScottK: Yes, but not all of those are actually candidates for removal.
 * ScottK will take your word on that, but finds it hard to believe something not yet updated to debhelper is worth keeping.
<persia> ScottK: lamont just migrated a couple packages of his to work with current tools (still not debhelper) in the last couple weeks, as they were still building and working previously.  I suspect some others might have the same situation.
<persia> On the other hand, that lintian error is definitely RC, so removal without blacklisting after FF seems ideal to me.
<ScottK> Fair enough.
 * Hobbsee ponders an entire shift of MC people, as all but one of the original people have gone
<emgent> keescook, when you have time see #181416 and #181984 Thanks :P
<emgent> 181416
<emgent> uhm..
<persia> Hobbsee: That's the nature of governance.  We grant leaders, and they serve, and when they are done, we get new ones.  As long as we only add one or two at a time, we should be able to preserve continuity.
<persia> bug #7
<ubotu> Launchpad bug 7 in rosetta "Need help for novice translators" [Medium,Confirmed] https://launchpad.net/bugs/7
<Hobbsee> dholbach: what was the rationale behind private nominations, out of curiousity?
<ScottK> persia: I would disagree that we've actually granted leaders so far.  One person elections aren't elections.
<StevenK> ScottK: So why can't you upload it?
<persia> ScottK: I agree with that, but believe it is a separate issue.  We have gotten council members, although some there may be issues with previous elections.
<ScottK> StevenK: Source backports take a core-dev regardless of the component.
<StevenK> Neat.
<dholbach> Hobbsee: I'm in a session right now, but in a nut shell it's about avoiding public discussions of the merits of nominees
<ScottK> dholbach: I would say that's exactly what we ought to have.
<Hobbsee> dholbach: i don't really see the problem with that - especially when everyone needs to vote on it anyway.
<dholbach> ScottK: I personally disagree - I feel that it turns people off and that it's too easy to get into flamewars because of that
<Hobbsee> dholbach: to an extent, it's like campaigning - so those who arent' on irc a lot know who the various candidates are, and what they want to do if they get it
<ScottK> dholbach: Even if we had a "only be positive in your comments rule" I think it would be useful.
<ScottK> Plus CoC should keep flaming to a managable level.
 * StevenK idly wonders if he trusts ScottK enough to not test build it.
<Hobbsee> dholbach: otherwise it becomes a bit of a popularity vote, with the people who speak the most, and send mails the most, get higher status, principly due to being more active.
<Hobbsee> dholbach: which is bad news, for those with a low S/N ratio, and a lot of output.
<dholbach> I feel that almost all people in ubuntu-dev (the people that vote) know each other or a group of developers quite well and well enough to decide on somebody who is up for election
 * persia notes that we haven't seen the means by which the final nominees will be selected.  It may be that some subset will be presented for a period of comment
<dholbach> I wonder why nobody objected to it in the CC meeting yesterday
 * ScottK wasn't there when it was discussed.
 * persia was asleep
 * ScottK only even knew it was going to be discussed because of dholbach's mention of it as a pre-requisite for filling out the MC.
 * ScottK would have thought such a fundamental governance issue would have been announced more broadly.
<Hobbsee> dholbach: based on how i don't know a great group of the new MOTU's, i can't see why they'd know about me, beyond that i talk a lot on irc.
 * Hobbsee was also asleep.
<StevenK> Hobbsee: And you randomly attack people ...
<Hobbsee> StevenK: well, yeah.
<Hobbsee> dholbach: the likely way it works is that the new MOTU's feel excited about voting, and so vote for their sponsors, as they're recognised names, the old MOTU's vote sensibly, and various people don't vote at all.
<Hobbsee> the first group isn't actually terribly helpful, when you're looking to select good leaders
<dholbach> I think that will happen whatever campaigning will happen before: the people that vote, vote people they trust and who they have witnessed doing good work
<ScottK> Which is a recipe for that status quo.
<ScottK> Since, of course, people who've stepped back due to being dis-satisfied have a limited ability to make a case for change.
<dholbach> ScottK: what do you mean?
<persia> Even without "campaigning", a comment period is good.  Let's people raise issues.  Alternately, just posting platforms.
<ScottK> Yes, but making nominations a secret really isn't helpful.
<persia> ScottK: It's more helpful than not accepting community nominations, no?
<Hobbsee> persia: it appears that dholbach doesn't want issues to be raised, though, as that leads to flamewars.
<ScottK> persia: Agreed.
<ScottK> It's progress.
<Hobbsee> persia: thus, a gag, by making it private is quite effective - and opens up the possibility of corruption
<dholbach> Hobbsee: calm down
<persia> Hobbsee: Depends on the issue, really.
<dholbach> of course I want issues to be raised
<Hobbsee> persia: oh, of course, but we're assuming these are going to be fairly big, important issues, no?
<ScottK> dholbach: I'd suggest listening rather than trying to stifle dissent.
<Hobbsee> dholbach: i'm perfectly calm.
<Hobbsee> dholbach: but, i think you've chosen the wrong option here, for some bad reasons.
<dholbach> I'm just wary of the fact that discussing the merits of applicants will turn people down
<ScottK> So you want elections without discussions?
<persia> Hobbsee: I don't think so.  For instance if someone who had been MOTU for one day was nominated, I'd complain about it being only one day (although the current person in that situation might get special treatment)
<Hobbsee> dholbach: the type of people who would be turned down by that would presumably also be turned down by the thought that people are going to think about their merrits, and probably discuss them in private.
<dholbach> If you feel very strongly about this process, best to raise it with the CC. Why should I want issues not to be raised?
<ScottK> dholbach: Since you've said you don't want discussion.
<Hobbsee> dholbach: so you don't have to deal with them, if anything too hard comes up.
<Hobbsee> i'm sorry to be harsh, but...
<Hobbsee> persia: what did your comment relate to, sorry?
<dholbach> sorry... I just got a huge delivery and in a session at the same time, so a bit ... torn
<persia> Hobbsee: "oh, of course, but we're assuming these are going to be fairly big, important issues, no?"
<dholbach> Hobbsee: what is too hard and what don't I want to deal with?
<Hobbsee> persia: ah right.
<Hobbsee> dholbach: i don't know, exactly.  of course, the fact that these issues can't be raised, are they're forbidden, are why i can't answer the question of what examples those issues would be.
<emgent> dholbach, what do you think about bug #181853 ?
<ubotu> Bug 181853 on http://launchpad.net/bugs/181853 is private
<dholbach> I'm afraid I don't understand
<Hobbsee> dholbach: so, here's a hard question for you in the meantime?
<Hobbsee> dholbach: what happens with MC quorum, as the MC said it would make a decision in a few days about kmos.
<StevenK> ScottK: clamav_0.91.2-3ubuntu2.2~feisty1 uploading.
<Hobbsee> as you now only have 3 members
<persia> quorum is 3 and there are 3 active members.  No issue (as I read things).
 * dholbach nods towards persia
<dholbach> soren, geser: can you jump in on the discussion - I'm a bit torn between activities right now
<Hobbsee> persia: right, so all it takes is one to decline now, and it gets floored.
<ScottK> StevenK: Thanks.
<StevenK> ScottK: s/ing/ed/
<Hobbsee> persia: the advantage, of course, to quorum of more people is that one (or two) people can disagree, and be overruled
<soren> I'm completely starved, so I'm on my way to lunch. :/
<Hobbsee> unanimous decisions on complex issues are quite rare, it appears.
<persia> Hobbsee: In that case
<persia> In that case, it gets revisited when the council is back to nominal size.
<achadwick> Do new multiverse packages go through the normal MOTU process as described at https://wiki.ubuntu.com/MOTU/Contributing#head-f4c6048b1531f4e4fe48f096350ea435d40ed9f5 , but with s/universe/multiverse/ throughout?
<Hobbsee> (having seen the kubuntu council make decisions, or attempt to make them, with everyone in full agreement before, i know that sometimes doesn't happen)
<dholbach> emgent: I'm not quite sure: why am I on the bug?
<emgent> yes
<emgent> i attached you now.
<emgent> s/attached/subscribed/
<persia> achadwick: Yes, although some reviewers refuse to review multiverse, so it can take longer.
<emgent> dholbach, it's cool debian road?
<achadwick> persio: Fair enough. In this case it's a GPL program made to install some non-free software, which is contrib in Debian.
 * achadwick assumes that that translates to multiverse in ubuntu.
<dholbach> emgent: best to discuss with keescook or jdstrand - I'm a bit occupied right now
<Hobbsee> persia: a nice delaying tactic, especially for those who have left, so don'[t have to make a decision on kmos :)
<emgent> ok dholbach thanks
<persia> Hobbsee: I actually don't believe it will be delayed, but I don't have a voice on that.
<dholbach> Hobbsee: I don't think that's fair to say: crimsun and ajmitch both were very busy when they left the MC
<Hobbsee> dholbach: oh, i can undersatnd that.  which means that they wouldn't have wanted to have to deal with kmos, due to said busyness.
<Hobbsee> which is why leaving a few days prior to the report ot the MC is *very* smart from their end
<ChrisGibbs> Hobbsee, how'd your key signing end up??
<Hobbsee> ChrisGibbs: was good :)
<txwikinger2> ping persia
<\sh> sounds like fun today :)
<rulus> can someone look into bug #180383?
<ubotu> Launchpad bug 180383 in gnuvd "Van Dale website code changed" [Undecided,Confirmed] https://launchpad.net/bugs/180383
<persia> imbrandon: LaserJock: DktrKranz: jdong: TheMuso: is there a mailing list for ~motu-sru?
<persia> rulus: Needs a candidate submission for the new upstream.  Submit an interdiff.
<rulus> persia: hmm, that's like Chinese to me
<persia> rulus: Looking in a little more depth, it appears that gnuvd is currently at version 1.0.3-4 in the archive.  If this was fixed upstream (as the bug report seems to indicate), then the new upstream should be submitted to Ubuntu.
<persia> rulus: The current way to do this is by adapting the current package to match the new upstream, submitting an interdiff to the bug report, and subscribing the sponsors to request upload.
<persia> Some useful URLS are https://wiki.ubuntu.com/MOTU/Contributing, https://wiki.ubuntu.com/PackagingGuide/Howtos/PackageUpdate, and https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
<rulus> there is no new upstream release. gnuvd is a parser for the Van Dale website written in C, and I used it in my GtkVD application which was basically a Gtk GUI around gnuvd. Recently the Van Dale website was renewed, so gnuvd doesn't work anymore. Therefore I wrote my own html parser to get the data, which is included in GtkVD - but this doens't affect gnuvd.
<persia> rulus: Can you use your experience with GtkVD to create a patch for gnuvd that would work?
<DarkSun88> Hi all
<rulus> I doubt it, I know Python, but not C
<DarkSun88> \sh: Congratulations. Welcome back. :)
<rulus> I don't know if it's actually usefull to patch gnuvd..
<ScottK> rulus: Can you file a bug with Debian with enough detail that maybe the Debian Maintainer can fix it?
<\sh> DarkSun88: thx :)
<persia> rulus: Others know C.  If you could draft up a spec and help test, and note this in the bug, it might be good.  I don't like removals for fails-to-work-out-of-the-box unless it's also dead-upstream-and-unmaintained
<rulus> Actually it is quite dead I think, the last update on the website of the author dates from 2005
<rulus> ScottK: that should be no problem
<ScottK> I think your odds of having someone care enough to write C code are better in Debian where there's a dedicated Maintainer who's taken an interest in the package.
<ScottK> If Debian fixes it, then we can sync the fix from them.
<persia> (depending on the fix, we can also cherrypick)
<ScottK> Be sure the link the Debian bug to the LP bug in LP after you file it.
<ScottK> Yeah.
<rulus> Yeah I understand, but I don't know if it's usefull to rewrite gnuvd if my VanDale.py module does exactly the same thing
<persia> rulus: Users may already have gnuvd installed.  It's a support issue.
<rulus> ah, right
<Hobbsee> ScottK: actually, the private discussion would probably be waranted, so that certain people don't get on the MC
<ScottK> Except those kinds of people are probably the same ones the would complain about it later publically and so we'd get to have a public discussion anyway.
<Hobbsee> or before it.
<ScottK> So secrecy really solves nothing IMO.
<Hobbsee> sure, but most people don't watch irc on a friday night
<ScottK> Transparency is virtually always the right answer.
<\sh> lol...you guys are really crazy :)
<Hobbsee> \sh: we work on ubuntu.  duh.
 * txwikinger2 agrees with ScottK
 * persia notes that this is not always equivalency, and sane people are also welcome to join
<ScottK> Not that it's actually happened yet.
<Hobbsee> ScottK: yes, and that's why a lot of open source actually works, which is why i'm surprised that this is decided to be private.
<Hobbsee> i might have been listening to pia too much, but i thought one of the defining factors of open source was open management
<ScottK> It doesn't have to be, but if it's not, it generally doesn't have a happy ending.
<persia> Not necessarily.  I've seen closed source with open management and open source with closed management, and both work OK.  On the other hand, community efforts with closed management don't tend to do as well.
<dholbach> ScottK: do you think it would help if people who nominate themselves put up a wiki page with their ideas about MOTU, the MC and their contributions?
<ScottK> dholbach: Yes.  Definitely.
<Hobbsee> persia: sure, but as in, if it's open, it needs to follow and do this bunch of stuff.
<persia> dholbach: Maybe just edit their standard wiki page to demonstrate activities, involvement, and share a platform, rather than have them separate.  Also, perhaps have a central page listing all the nominees pages for easy reference.
<dholbach> What I *personally* really want to avoid is mud-slinging sessions (be it on mailing lists or on IRC) about how some people like nominee A to do XYZ half a year ago
<persia> Hobbsee: I'm not disagreeing with your point, only that it is related to community projects, rather than open source.
<dholbach> things like that aren't helpful even if they are "transparent"
<Hobbsee> persia: true, true.  was clarifying.
<dholbach> sharing information and making goals obvious is a good thing, I agree with that
<Hobbsee> dholbach: the ones who get blamed for not doing stuff tend to be in power at the time of the complaint.
<persia> dholbach: Surely that's governed in part by MC calming role and CoC, no?
<Hobbsee> dholbach: else you're blaming people for stuff that they actually can't fix, which is futile, and doesn't tend to happen around here
<dholbach> persia: I just thought about how we could adress the need for clarification of goals and giving out more information to the people who vote in a good way
<txwikinger2> virtual caucus? :D
<Hobbsee> dholbach: i guess i'm unconvinced that there would be mudslinging at innocent parties - only those who had the power to fix things, but didn't.
<Hobbsee> which aren't those who would be being nominated.
<persia> dholbach: Right.  Sorry.  Insufficient context.  I think your wiki pages idea is good.  I am less worried about mailing lists, IRC, etc. due to CoC and MC calming activities.
<persia> Hobbsee: People who are not MC (and maybe even not nominees) might also have made egregious mistakes for which they would be slapped.  Don't discriminate :)
<dholbach> there's nothing wrong about telling people about their mistakes - I just think that it should happen in the context where it happens and not as a long mailing list thread during an team council election
<ScottK> dholbach: I think the only reason that happened last time was because of poor timing and the fact that nominees had not come from the community.
 * persia agrees with the word "long" in that context
<Hobbsee> persia: well, i guess this is a point.  i was thinking of motu leadership.
<dholbach> ScottK: I'm happy to make the "wiki page" admendment to it... I'll drop a mail to the CC, TB and MC - and we can formalise it for the next round
<ScottK> dholbach: OK.  I do like what was said about it being their regular wiki page, not a special one.
<dholbach> ScottK: fine with me
<emgent> bye people!
<dholbach> bye emgent
 * soren is reading scrollback
<soren> Hobbsee: Re: "it becomes a bit of a popularity vote, with the people who speak the most, and send mails the most, get higher status, principly due to being more active"> I can think of a few who send *plenty* of e-mail but I wouldn't vote for..
<Hobbsee> soren: yes, but you're clueful, and watch motu reasonably closely.
<Hobbsee> soren: your category of people aren't the worry
<persia> Err.  Let's avoid categorisation, and look at systemic solutions.
<soren> Hobbsee: I guess I just tend to give the average MOTU more credit than expect them to vote based on the count rather than contents of people's postings.
<persia> Essentially, the community is large enough that we can't all know each other anymore, therefore "I know them, they are good" becomes a weak validation.  What would be a better validation?
<Hobbsee> soren: i wish i could do the same.  for hte msot part, that certainly holds.
<ScottK> persia: Which is why campaiging is good.  That also brings in "I know X and they speak in favor of Y that I don't know."
<persia> ScottK: To some degree, yes.  On the other hand, it unfairly balances in favour of politicians over technical types.  The balance is tricky.
<ScottK> Yes, but we're hiring management, so that's not necessarily bad.
<persia> ScottK: Maybe.  Depends on "hiring management" vs. "appointing administrators".  "suits" aren't always best in community or volunteer projects.
<ScottK> Sure, but we need community skills in MC more than we need the best packager.
<persia> On the other hand, having the administrators be those who are active in the community and look at community rather than just pushing 1000 uploads is also good.
<ScottK> persia: Speaking of which, would have have a little time to look into a problem for me?
<mok0> I've been following this discussion for a while, and the topic seems to be "How do we limit the influence of people that we don't trust to make the decisions we want them to."
<persia> (that could have been written more concisely as "Yes")
<persia> ScottK: What sort of problem?
<persia> mok0: Maybe :)
<Hobbsee> mok0: depending on "the decisions we want them to", and how that expands, yes.
<Hobbsee> mok0: we want people to make good decisions, based on credible reasons, to apoint the best people for hte job.
<Hobbsee> mok0: as for who that is...we're not specifyingi that.
<mok0> Hobbsee: I just don't like the outset of those premises. It's better to agree on the set of qualities you are looking for, and trust that everybody will be able to make a proper decision.
<ScottK> persia: In order to get amavisd-new into Main (a spec item for Hardy for ubutu-server), I need to break libmilter, libmilter-dev, and libmilter-dbg out of the sendmail source package and into a separate package that can be promoted to Main.  I took a look at the sendmail package and just about fainted.  I'd appreciate advice on a packaging strategy for my new package (ripping the milter stuff out of sendmail doesn't look particularly hard).
 * persia grabs sendmail
<ScottK> persia: Thanks.
<Hobbsee> mok0: which assuems that all people are sane - which is also a bad premise.
<mok0> Hobbsee: absolutely not
<ScottK> persia: And if you get motivated and actually want to DO the new package, I'd be totally cool with that.
<Hobbsee> then again, the few that aren't will probably be minor enough not to matter
<mok0> Hobbsee: You are focusing on an irrelevant concern, IMHO
<persia> ScottK: That's fairly unlikely.  I've a heap of stuff I should hit this weekend, and after (mostly) skipping last REVU day, need to push if we're to get many of the current packages into hardy (some are good)
<mok0> Hobbsee: ... and you'll never gain influence by attempting to limit that of others
<ScottK> persia: OK.  Just saying ...
<persia> mok0: That's not quite true.  Big fish/small pond
<Hobbsee> mok0: it's not really that - it's more the compromised nature of the vote, if apathy is used as a method of voting
 * persia declares that tarball-in-tarball doesn't only make the md5sums guarantee to fail to match, make patching difficult, and make inspection difficult, but is also infuriating when cdbs-edit-patch doesn't work
<ScottK> persia: Do you feel my pain?
<Hobbsee> persia: ...ouch?
<mok0> Hobbsee: any organization goes through cycles... It's best to focus at the goal - and get to agree on that - than to descend into politics
<persia> ScottK: Not yet.  So far, it's just normal pain.  I'm still digging around in the upstream build system: it looks maybe not so bad.
<soren> persia: Which md5sum will fail to match?
<persia> soren: orig.tar.gz to upstream tar.gz
<mok0> Hobbsee: the latter tends to be more destructive that productive
<soren> persia: Oh, right.
<Hobbsee> mok0: true, there's the question about a) do the politics ever get solved, and b) should they?
<mok0> Hobbsee: ... and you'll end up with N one-person organizations, which all are in perfect agreement with themselves :-)
<persia> soren: Which means, in the absence of get-orig-source, we have to either trust the packager implicitly (and given what I see from Debian and here, I don't really) or manually dig around trying to verify things (although it is nice when the packager puts an .md5 file in the package to help)
<mok0> Hobbsee: I
<mok0> I'd say b). If you move ahead, focused on the goal, it doesn't matter if things are not always perfect
<Hobbsee> this depends on what your goal is
<Hobbsee> but, yes
<soren> persia: You need to manually dig around to verify the orig's md5 anyway?
<mok0> Hobbsee: ok, if your goal is perfection :-)
 * Hobbsee heads to bed, and figures that someone else will solve the problem.
<Hobbsee> mok0: MOTU perfection?
<mok0> Hobbsee: ... well, it's always going to be a normal distribution
<Hobbsee> mok0: why, though?  you've got to make a standard to get there in the first place
<Hobbsee> i don't see why hte bottom of the distributoin should be there at all
<mok0> Hobbsee: well, like you said, some are more active than others etc
<Hobbsee> wasn't thinking in terms of activity
<ScottK> It's not a question of activity level, but activity quality.
<mok0> There's quality control built into the system afaics
<persia> ScottK: It's a trivial pull.  Disable libmilter* from debian/control.  Since libmilter is already commented out in the upstream Makefile, just rip out all the special handlers in debian/rules.  This should give you a libmilter-free package.
<persia> ScottK: Next comes the hard part: building libmilter.  Looking in more depth...
<mok0> ... again, this is a discussion of the cathedral vs. the bazaar
<ScottK> Yeah.
<ScottK> mok0: I don't think so.
<ScottK> mok0: I think it's more do you let absolutely everyone into the bazaar or does the bazaar get more done with some people left out.
<persia> ../devtools/bin/Build is just ugly, but then again, I remember thinking it was neat the first time I compiled it
<mok0> 'nuff said, I gotta get back to work :)
<persia> ScottK: You're mixing things.  Having a large gated city with an internal bazaar is different from having some police in the bazaar to ensure the thieves restrain themselves to acceptable levels.
<ScottK> persia: Fair enough.  And making sure the police aren't in league with the theives.
<markvandenborre> this is not strictly a moty thing, but it's such a critical bug that I need all help I can get in reporting it as well as possible
<markvandenborre> https://bugs.launchpad.net/ubuntu/+bug/182028
<ubotu> Launchpad bug 182028 in ubuntu "evince and eog freeze on all printing related actions" [Undecided,New]
<markvandenborre> is there anything I can do to improve this bug report?
<persia> ScottK: That's just basic anticorruption.  Who watches the Watch?  Governance is tricky, but it is one of the few places where circular dependencies are a good thing.
<rexbron> Hey, I have an interesting problem. When I compile a library (OpenLibs in this case) on a 64bit arch, all of the lib directories are changed to lib64. Looking at the fs, lib64 is just a symlink to lib. Does anyone know of a configure option (because I found the line in the configure script that does this) or another work arround that might be able to solve this?
<persia> markvandenborre: Likely, but #ubuntu-bugs was the right place to ask (although most triagers don't seem active just now :( )
<ScottK> markvandenborre: And you already got told that in #ubuntu-devel.  The advice is still good.
<markvandenborre> ScottK, yeah, sorry, should have been a bit slower about coming here
<persia> ScottK: To be fair, he did ask in #ubuntu-bugs, and nobody responded (although that doesn't make this the right place)
<markvandenborre> please ascribe this to the fact that I stuck my neck out quite far by having
<ScottK> persia: Not getting a question answered where it's on topic, doesn't make the question on topic here.
<Hobbsee> markvandenborre: you don't happen to wokr for canonical, do you?
<persia> ScottK: Right, which is the reason for the parenthetical comment
<persia> ScottK: How well do you know m4?
<ScottK> persia: Right.
<ScottK> persia: Not very well at all.
<markvandenborre> Hobbsee, no, and that wouldn't make my question here appropriate here either
<persia> Ah.  Yet another reason you likely ran screaming when looking at sendmail :)
<ScottK> persia: I've hacked on m4 files until stuff built, but that's about it.
<ScottK> Yeah.
<Hobbsee> markvandenborre: was just curious, seeing as you'd been at UDS
<markvandenborre> Hobbsee, I have been an extremely active non-code community, that's right
<ScottK> persia: If I wanted to know m4, I'd use Sendmail as my MTA and not Postfix ;-)
<markvandenborre> Hobbsee, extremely active non-code community member
<Hobbsee> markvandenborre: fair enough
<Hobbsee> markvandenborre: does that happen with any other printers?
<markvandenborre> we have only this kind around here
<persia> ScottK: I don't see any real internal dependencies in libmilter that require it to be built with the rest of sendmail.  I'd suggest you create a completely new build system from scratch, rather than trying to rescue upstream, and just pull ./libmilter/.
<markvandenborre> but at another place with a very similar setup (other type of hp laserjet)
<ScottK> persia: Thanks.
 * persia encourages Hobbsee and markvandenborre to move to #ubuntu-bugs
<markvandenborre> persia, will do, sorry
<persia> ScottK: Feel free to ping me if Makefile.m4 causes you too much pain.  I have a list to do this weekend, but should have at least some time.
<ScottK> persia: Thanks.
<persia> Oh, and regarding sendmail vs. postfix, there are other reasons beyond m4.  While I'm a sendmail fan, and ran it on all my mailservers for as long as I was a mail admin, it doesn't always integrate most cleanly with other tools, and has some quirks about queue management that can be very frustrating.
<ScottK> Yes.
<gnd> How long does it usually take for a package to appear in PPA from running the dput command?
<rulus> gnd: a few minutes
<gnd> Allright, i'll wait :D
<rulus> but it takes a little longer to get built
<jdong> LucidFox: another status update, more things have to be fixed/investigated in the orig.tar.gz.... Messy upstream syndrome. They look simple to resolve so I'd say by the end of today I should have another upload prepared
<LucidFox> Good.
<db-keen> If I am the original developer of a program called jump, and the official Debian repo has an older version of jump, am I supposed to have the version be 1.0.0 or 1.0.0-0jump1?
<LucidFox> db-keen> if you're upstream, the versioning is up to you
<LucidFox> if you build your own Debian packages upstream, you... shouldn't do that :)
<persia> db-keen: Depends on whether you are releasing a new upstream, or just making a debian source package also available to your users.
<db-keen> just a package available to users
<mok0> db-keen: I'd choose a version scheme based on the nature and importance of updates to the software
<persia> If the former, I'd recommend 1.0.1 or something similar (up to you).  If the latter, using -XjumpY would be one way to release a .dsc without blocking a later debian override.
<mok0> db-keen: if the new version is 1.0.0.0.0.0.1 it is less likely to be picked up ;-)
<LucidFox> I think it should be 1.0.0-0[something]X
<LucidFox> the version for the package, that is
<LucidFox> 0 indicates that this upstream version is not in Debian yet
<mok0> LucidFox: You're talking about the release tag
<persia> db-keen: If you do decide to use 1.0.0-XjumpY, please don't include debian/ in orig.tar.gz, and try to keep your version lower than an official Debian version would be (or Ubuntu version, if you think it might get pulled by Ubuntu).
<db-keen> LucidFox: but as the original developer, I'm never sure what that [something] should be
<mok0> db-keen: as persia said, go for 1.0.1, the release tag has to do with the packaging
<persia> db-keen: Any value for something works.  Avoid '~' and strings sorting higher than 'ubuntu' and you should be safe.
<mok0> foo-1.0.1-0ubuntu1
<persia> Errr..  jump-1.0.1-0jump1
<mok0> sorry foo_1.0.1-0ubuntu1
<LucidFox> mok0> not ubuntu, because he's not packaging it for the official Ubuntu repository
<db-keen> so I can't use a string sorted higher than ubuntu?
<db-keen> that really limits the alphabet
<db-keen> vwxyz
<LucidFox> db-keen> persia's suggestion works
<persia> db-keen: You can use those, but ubuntu won't pull from you if you do.
<db-keen> ubuntu probably _should_ pull from me once they get an 'official' version in the repo
<LucidFox> db-keen> vwxyz are those that you _shouldn't_ use, you can use everything else
<minghua> If you want name flexibility, -0~xxx is almost always safe, altough a bit ugly.
<LucidFox> if Debian or Ubuntu package 1.0.1, your package 1.0.1-0jump1 will be overridden by 1.0.1-1 or 1.0.1-0ubuntu1, respectively
<db-keen> Okay, thank you
<nxvl_work> ScottK: ping
<ScottK> Pong
<ScottK> nxvl_work: ^^
<nxvl_work> ScottK: can you help us with q revu? on #terminator
<ScottK> Not currently, no.   I'm tied up with some other things.
<nxvl_work> ok
<nxvl_work> it will be on other time
<nxvl_work> thanks anyway
<nxvl_work> :D
 * nxvl_work HUGS ScottK
<rexbron> Does Vcs-Bzr still need the XS- prefix?
<pochu> rexbron: nope
<rexbron> cool
<pochu> neither does Vcs-Browser
<pochu> (or Vcs-*)
 * persia notes that it in fact oughtn't have it, but that it's not worth a variance from Debian, as in most cases we should be stripping vcs-* when modifying a package anyway
<soren> persia: Or prepending X-Original- (as some of us have done during merging).
<soren> Er... make that "XS-Original-".
<persia> soren: That's even better.  Maybe we should come up with a common standard for the next merge cycle?
<soren> persia: I belive that *is* the standard? I think it was briefly discussed on one of the mailing lists (shortly before DIF).
 * ScottK hopes soren will write a wiki page on the matter then (if not already done).
<persia> soren: I can't find it in my mailspool (but I may not be using the right search terms).  I wouldn't consider it accepted and official unless it was documented as best practice on the merging page (not that I currently agree with everything there, but a ML is a poor way to track policy)
<soren> persia: I can't find it either, which puzzles me.
<soren> persia: I distinctly remember discussing it somewhere.
<persia> soren: I also remember discussion, but I thought it was a couple different IRC sessions, rather than the ML or in the context of a meeting.
<soren> persia: I may be confusing things. I *know* I discussed it with cjwatson in e-mail, but I'm only 87% sure it got wider discussion on e-mail, but surely IRC.
<soren> Well, it's not really a merging thing. It's something you should do whenever you change a package.
<persia> soren: Surely IRC, but in a meeting?  Lots of things happen on IRC, but I don't think that makes them policy: more guidelines, or good practices, etc.  Moving from there to best practice to policy seems like it should be deliberate and documented.
<soren> persia: I agree.
 * soren ponders where to add it.
<persia> True.  I'm not sure if we have a proper package adjustment page (and we ought).  There are several things to do: discussion XbuildY vs. XubuntuY, what control fields should change, etc.
<soren> It's only something to remember during merging for the the hardy+1 cycle.
<persia> I'd think under UbuntuDevelopment/ would be the right place, but I'm not sure what to call it.
<soren> Same logic as the Original-Maintainer field.
<persia> soren: One hopes.  We've still > 200 packages that don't comply with DebianMaintainerField :(
<ScottK> soren: But the maintainer field thing was a spec
<soren> ScottK: Yes.
<persia> (and lots more binary packages that don't comply, but that's just a rebuild fix, which is easy)
<Beber80> I've got a question about PPA. Am I in the right chat room ?
<persia> Beber80: Depends on the question, but likely not.
<persia> On the other hand, I don't think there is an active non-support PPA channel, so this might be your best bet.
<Beber80> ok, so I'll try;)
<ScottK> There's #launchpad
<persia> Yes.  #launchpad is the place to ask for ppa support.
<Beber80> I successfuly uploaded the files with dput but I can't see the package from the web interface
<Beber80> ok, I'll have a look at #launchpad
<persia> Yep.  That would be a support question.
<mok0> A quick pointer to installing *.pc files using CDBS?
<gnd_> Is something wrong with PPA? I have waited an hour now for the first package to appear.
<mruiz> hi all
<gnd_> dput says that it is already uploaded, but launchpad says it isn't.
<Beber80> gnd_: I'm maybe experiencing the same pb...
<Beber80> gnd_: same for me
<ion_> mok0: debian/foo.install, see dh_install(1)
<gnd_> Great i'm not the only one :D
<persia> gnd_: You likely want #launchpad.  The both of you might consider starting a ppa channel to discuss ppa issues as well :)
<persia> (let us know what it is called, if you do :) )
<soren> mok0: You can add it from a post-build hook, perhaps?
<Beber80> dput also tells me "Not running dinstall"
<soren> Beber80: Don't worry about that.
<soren> Beber80: It's just noise.
<soren> mok0: Like: "install/packagename::\n\tcp $(CURDIR)/something.pc debian/tmp/usr/lib/pkg-config/"
<soren> or something.
<DktrKranz> persia: thanks for your mail.
<mok0> soren: thx
<soren> mok0: np :)
<mok0> ls
<persia> DktrKranz: Thanks for the response.  Great strides have been made, and I suspect we're almost there :)
<mok0> oops wrong focus
<DktrKranz> persia: my pleasure. Probably we still need to discuss on some points and to coordinate with other interested parties (and to fill our lack of public announcments). After that, we can have a rocking policy.
<imbrandon> persia: re:sru mailing list, not that i'm aware, we agreed to just use the -motu ML when needed
<imbrandon> unless it becomes an issue
<persia> imbrandon: Makes sense.  It was just to save me collecting all your names & emails from LP.  Doesn't matter now :)
<imbrandon> kk :)
<pochu> Hmm, would you recommend me to use schroot with sbuild to build packages? As the buildds use sbuild, right?
<pochu> I'm building anjuta with pbuilder and it's installing libneon27-dev although Build-Depends have libneon26-dev o.O
<pochu> So I'm wondering whether that would happen with sbuild or not.
<geser> pochu: pbuilder should also pick the right depends
<pochu> Well it won't be the first time I successfully build something in my pbuilder but fails in the buildds
<geser> pochu: right now I get unsatisfiable build-depends for anjuta (amd64)
<pochu> libneon26-dev?
<geser> pochu: the sbuild on the buildds may behave differently than the sbuild from the package
<pochu> Oh, ok
<geser> probably, I didn't check
<pochu> It Build-Depends on libneon26-dev, but installed libneon26 libneon27 libneon27-dev
<geser> hmm
<pochu> Hmm, maybe because libneon26-dev Provies libneon-dev and libneon27-dev Provides and Replaces it too?
<geser> libneon26-dev and libneon27-dev can't be installed at the same time
<pochu> Provides*
<geser> yes
<pochu> But I'm B-D on libneon26-dev (!)
<pochu> And libneon26-dev Provides and Replaces libneon-dev too
<geser> and apt-get -s build-dep anjuta still works for you?
<pochu> Maybe I should just B-D on libneon-dev and let it choose what install ;)
<pochu> let me see
<pochu> E: Build-dependencies for anjuta could not be satisfied.
<pochu> So no pbuilder bug...
<geser> pochu: libneon-dev seems to be a virtual package and one shouldn't build-depend only on a virtual-package
<pochu> Ok, so maybe building with libneon27-dev directly?
<minghua> pochu: Find why it's trying to install libneon26-dev and libneon27-dev at the same time and solve it. :-)
<geser> yes
<pochu> Dunno if that would be ok...
<Kmos> pochu: the sbuild package is version 0.57.0, and ubuntu sbuild is 1.175.X :) is a fork
<Kmos> debian sbuild is also different from the package they provide
 * Kmos upgraging to hardy
 * Kmos upgrading to hardy
<Kmos> :)
<pochu> Kmos: lol, that's a big fork :)
<Kmos> pochu: hehe
<pochu> minghua: do you mean some of the other build-depends is now depending on libneon27-dev?
<geser> pochu: some of the Debian buildds report 99.99 as sbuild version and the Debian maintainer is searching for the source code
<minghua> pochu: Most likely so.
<pochu> minghua: hah! libsvn-dev
<pochu> geser: heh, I guess upstream will be interested too ;)
<pochu> Ok, let's try with libneon27-dev then. Thanks for the help :)
<tuxmaniac> if there is a package available in debian but not in Ubuntu also I rasie a bug for sync request right?
<pochu> geser, minghua: it worked. Thanks again.
<minghua> tuxmaniac: Correct.  But be sure to specify reasons in the sync request for breaking DIF.
<minghua> pochu: No problem.
<tuxmaniac> DIF?
<nxvl_work> how do i package a file for ppa? i cant upload it
<minghua> tuxmaniac: Debian Import Freeze.
<tuxmaniac> minghua, oops. Its over. I forgot :-(
<pochu> tuxmaniac: if it's a new package it will likely be accepted if you say why it's useful
<tuxmaniac> ok
<minghua> tuxmaniac: It's okay.  You don't need a very strong reason, just make sure not just to say "Debian has it, so we should sync".
<tuxmaniac> minghua, ofcourse. I have a reason. Its there on the MOTU Science team wiki for wishlist packages from Edgy
<minghua> tuxmaniac: Go ahead, that's a good reason.
<ScottK> We aren't to feature freeze yet, so there isn't a LOT of reason needed.
<nxvl_work> how do i build a package on my PPA
<nxvl_work> i have already upload the source
<ScottK> nxvl_work: Ask in #launchpad
<nxvl_work> oh right
<nxvl_work> sorry
<ScottK> No problem
<tuxmaniac> do I have to subscribe any particular team like "Sponsors Universe" for the bug report to be acked?
<pochu> Yes.
<nxvl_work> tuxmaniac: ubuntu-universe-sponsors
<tuxmaniac> nxvl_work, yeah thanks. got that one already
<nxvl_work> i'm building a package, and i don't know why i'm getting /usr/lib when i "dpkg -L $package" does anyone knows how can i check it?
<pochu> nxvl_work: python package?
<nxvl_work> pochu: yep
<nxvl_work> pochu: build using cdbs
<pochu> nxvl_work: that's a bug in python-central or python-support
<nxvl_work> so i don't need to worry about it?
<bddebian> Heya gang
<pochu> nxvl_work: Debian bug #452227
<ubotu> Debian bug 452227 in python-central "Leaves empty /usr/lib in package" [Normal,Open] http://bugs.debian.org/452227
<pochu> nxvl_work: nope, just ignore it.
<nxvl_work> ok, thnx
<LucidFox> https://launchpad.net/ubuntu/+source/inkblot/0.99.9-0ubuntu1 <-- What does "Failed to upload" mean?
<geser> Hi bddebian
<geser> LucidFox: this usually happens when the package is promoted/demoted while still in the build queue
<LucidFox> What can be done about it?
<geser> LucidFox: ask a build admin, I don't know (yet)
<bddebian> Heya geser
<bluefoxicy> this is awesome, firefox has more memory resident than all of windows XP
<ion_> FF 3?
<bluefoxicy> no, FF2
<bluefoxicy> it had 810M Resident, while Vmware has 632
<ion_> FF 2 + a bunch of extensions leaking memory + crap like Flash and Java are a sure way to eat all the RAM and a bit more. :-)
<bluefoxicy> thunderbird has 641 resident.
<imbrandon> Seveas: fyi, 2.0.4-0ubuntu1 uploaded , will make another sunday ( or close if its not ready for some reason ) for .5
<Seveas> imbrandon, thanks! Do you have plans for debian as well?
<imbrandon> Seveas: yea, i am working on plans for debian now too ( probably by the end of the weekend )
<geser> RainCT: any progress on bug #164854?
<ubotu> Launchpad bug 164854 in classpath "Please merge classpath 2:0.95-3 from Debian unstable" [Wishlist,Triaged] https://launchpad.net/bugs/164854
<RainCT> geser: you can take it if you want
<geser> RainCT: what questions did you have that stayed unanswered?
<RainCT> geser: something about that Xb-Npp Firefox tags
<RainCT> ah no
<RainCT> 'bout the MOZILLA_CFLAGS I think.. I'm not sure thought.. I had forgotten about that merge :P
<asac> RainCT: please keep the Xb-Npp tags
<asac> if you are a hero, check in about:plugins if the set of supported mime-types has changed and add/update the mimetype npp line accordingly :)
<RainCT> :P
<ScottK> leonel: Clamav update is published in feisty-backports now too.  Thanks again.
<leonel> ScottK:  Great    and  thank  YOU  really for your support
<minghua> ScottK: Is that the last piece of clamav security updates?
<ScottK> minghua: For feisty/gutsy, yes.
<ScottK> dapper/edgy are horribly ancient.
<ScottK> I think I've about got my nerve up to try a mass backport of clamav and it's rdepends to dapper.
<ScottK> I know sgran is holding back a clamav update in Debian until 0.92 makes it into Lenny.  I'll probably do it after he uploads one more and we sync it in.
<minghua> Oh, I forgot dapper.  But is edgy still supported?  When is its end of life?
<ScottK> Edgy dies about the time Hardy is released.
<minghua> Hmm, still a few months.
<ScottK> I'm considering trying the backport there first because if I break it, it'll go away shortly.
 * minghua praises ScottK for the great effort.
<ScottK> Thanks.
<ScottK> From a distribution perspective I think it's one of the more important packages in Universe.
<minghua> You mean the packages in -backports can be just pulled without affecting other parts?
<ScottK> No, I mean if I break edgy-backports and clamav or it's rdepends are messed up it goes out of support in ~ 3months.
<ScottK> Dapper has another 3 years to go.
<minghua> I see.
<ScottK> Actually, the clamav in both those releases is old enough to be completely useless.  The downside risk is close to zero.
<minghua> The packages in feisty-backports are the newest upstream version, aren't they?
<minghua> You still risk breaking dpkg database and hose the whole package system, so trying edgy first sounds a good idea.
<ScottK> minghua: feisty backports is 0.91.2 with all the security fixes from 0.92 patched in.  0.92 introduced a soname change in libclamav, so I'd have to backport rebuilds for about a dozen packages with it.
<ScottK> So feisty-backports should be as secure as the current upstream, but freshclam will still complain.
<minghua> So for feisty the rdepends don't need to be rebuilt?
<minghua> feisty-bakcports, of course.
<ScottK> Correct
<ScottK> Managing the library transition in Hardy was relatively painless, so if edgy/dapper go well, I'll do feisty/gutsy eventually too.
<minghua> And for dapper/edgy you plan a similar fix as in feisty?
<minghua> Ah, so dapper/edgy is going to be 0.92, with rdepends rebuilds as well.
<ScottK> Yes.  I'll backport 0.92, get that built and then backport the rdepends too.
<ScottK> Yes.
<ScottK> That's my plan.  Now all I need is a spare day of the week to sit down and test it all.
<Fujitsu> ScottK: Have people tried to knock some sense into upstream?
<ScottK> Fujitsu: They haven't succeeded.
<leonel> ScottK: let me know that day  to help with that
<ScottK> At least this time they appear to have packaged it sanely.
 * Fujitsu strangles them.
<ScottK> leonel: Sure.
<ScottK> Fujitsu: Maybe you can convince LP to at least close the bugs against the right pocket when I fix stuff in backports...
<geser> oh, cdrtools got removed from the archive again?
<Fujitsu> ScottK: Oh, it didn't? Nice of it.
<Fujitsu> Wait, Malone doesn't know about pockets.
<ScottK> Fujitsu: See bug #182137
<ubotu> Launchpad bug 182137 in launchpad "LP marks bug 'fix released' against wrong pocket" [Undecided,New] https://launchpad.net/bugs/182137
<Fujitsu> (though it would be nice if we could track backport tasks sanely)
<ScottK> Well it's an entirely separate project in LP.  You'd think that would be enough of a distinction.
<Fujitsu> Urgh, that one wouldn't be easy to fix sanely.
<ScottK> I've filed a bug, that's really all I can do ...
<Fujitsu> Ideally, each targetted task could have a pocket selector, so one could mark each fix as being for -updates, -security, or -backports. That would also mean the appropriate teams could be notified, and there wouldn't be the gross *-backports project hack.
 * ScottK is just a poor little user who just wants it to work sanely.
<Fujitsu> That would be nice, yes.
<ScottK> Conveniently enough, it's proprietary nature frees me of the obligation to do anything other than file the bug and expect instant results.
<RainCT> is anyone from the release team (or whoever approves freeze exceptions) around?
<geser> RainCT: which freeze exceptions? /me isn't aware of any freezes.
<RainCT> feature freeze, once it's there
<ScottK> RainCT: DIF just means autosync is turned off.  There is no freeze
<ScottK> Ah.  We don't have a motu-uvf selected for Hardy yet AFAIK
<geser> RainCT: I don't think we have a new motu-uvf team already
<RainCT> oh. and when will there be one?
<geser> hopefully before FF :)
<RainCT> lol
<blueyed> http://daniel.holba.ch/blog/?p=66
<blueyed> Cheers! This is an awesome set!
 * blueyed is in the middle of creating his MOTU application, but sooooo drunk already (KDE4, you know?) ;)
<Hattory> Hi all.... I'm working to a merge for alogg package. In the last version of Ubuntu there is a file called postinst that is dropped from debian.... Should I keep it?
<Hattory> the changelog says:  Drop useless debian/libalogg.postinst.
<apachelogger> Riddell, stdin: is one of you around?
<stdin> just about
<apachelogger> Hattory: please paste the content
<Hattory> apachelogger, a moment
<apachelogger> stdin: I think teh best solution for the current icon problem (i.e. icons not available in hicolor but oxygen, hence not showing up for the desktop files) is to evaluate which apps actually ship their icons to hicolor and which don't so
<Hattory> apachelogger, http://paste.ubuntu-nl.org/51594/
<apachelogger> Hattory: drop it, it doesn't do anything
<Hattory> apachelogger, ok thnks
<stdin> apachelogger: seems most do, from what "dpkg -S usr/lib/kde4/share/icons/hicolor/" says
<apachelogger> stdin: yeah, most important ones don't though ;-)
<apachelogger> dolphin
<apachelogger> systemsettings
<apachelogger> konqueror
<apachelogger> konsole
<apachelogger> kwrite
<apachelogger> kate
<apachelogger> well, I think everything from base probably
<stdin> apachelogger: konqueror does
<apachelogger> stdin: yes, the old version
<apachelogger> which makes oxygen rather pointless ;-)
<stdin> no 4.0.0
<stdin> konsole-kde4: kdelibs5-data: konqueror-kde4: kfind-kde4: all do for a start
<apachelogger> stdin: have a look at the icons
<apachelogger> they are not the oxygen versions
<stdin> yeah, but konqueror-kde4 and the like don't install any oxygen icons
<apachelogger> stdin: yeah, because the icons are in oxygen itself
<stdin> then the answer is kdebase-data-kde4 kdebase-workspace-data, kdebase-workspace-data and kde-icons-oxygen from what I can tell so far are the only things to touch /oxygen/, but I haven't installed the whole of kde4 yet
<apachelogger> stdin: yeah, I'm currently checking everything
<apachelogger> also I think for some apps there are no oxygen icons yet
<apachelogger> like for kappfinder
<stdin> when you install everything, "dpkg -S usr/lib/kde4/share/icons/oxygen/|awk '{print $1}'|sort|uniq" is easy :)
<apachelogger> aye :)
 * Fujitsu wonders why the KDE4 fonts are so... unhinted.
<rexbron> this is not fun, openlibs configure script installs to lib64 on 64bit arches. The problem is it breaks all of my .install files. Any thoughts?
 * joejaxx wonders with Fujitsu on KDE4 and why he cannot change the position of the Panel
<imbrandon> wow, /me walked into a kubuntu room
<imbrandon> :)
<somerville32> :)
 * RainCT wonders to try out KDE4 :P
<RainCT> eh.. s/wonders/goes lol
<Fujitsu> Errrrm.
<Fujitsu> Should I be able to drag the Plasma desktop around?
<Fujitsu> Because in some situations I can.
<dennda> So this is the place for packaging-wishes? :p
 * dennda would love to see (at least) icewm 1.3.34 in hardy instead of 1.3.33... Any chance?
 * Fujitsu can't seem to attach things to the kicker replacement, and can drag Plasmoids behind it, so they can't be retrieved. Nice one.
<Fujitsu> It is shiny, but not finished.
 * Fujitsu also wonders about the purpose of the selection box one can drag on the desktop, which seems to select a grand total of nothing.
 * Fujitsu is unconvinced, and returns to GNOME.
<joejaxx> Fujitsu: i cannot drag plasma aroudn
<joejaxx> around*
<joejaxx> it also does not extend to my other monitor
<Fujitsu> joejaxx: Only in some circumstances can the Plasma background be dragged around. I somehow managed to click through one of the Plasmoids, I think.
<joejaxx> anyway to extend it?
<joejaxx> to the other screen
<joejaxx> lol
<joejaxx> because i have not found a way
<ScottK> KDE 4.0 is release ready only in the sense that the APIs are stable.  Right now it's for enthusiasts and developers only.  Wait until 4.1 if you actually want it to be useful.
<joejaxx> ScottK: just trying it out :)
<bigon> talking about kde, could someone have a look at decibel, it currently FTBFS because of the kde4 path
<ScottK> Sure, just don't expect to much.
<Kano> hi, why is openscenegraph not installable with hardy?
<Fujitsu> Kano: Because one of its libraries has not yet been migrated from libungif to libgif.
<Kano> then migrate it
<ion_> kano: Where did you post the debdiff?
<Fujitsu> Why don't you?
<Kano> why should i?
<Fujitsu> Why should I?
<ion_> Why should i?
<Kano> well it is stupid to have no openscenegraph
<Kano> then gl2benchmark does not work
<Fujitsu> Many would say it's stupid to expect Hardy to work.
<ion_> Feel free to migrate it. Thatâs a simple way to get rid of said stupidness.
 * ScottK gets popcorn
<ion_> scottk: ;-)
 * Fujitsu delegates the fixing to ScottK.
 * ion_ delegates the fixing to popcorn.
 * ScottK puts in on the list.
 * ScottK has a very long list.
<ajmitch> ScottK: be sure to put it right at the bottom, please
<TheMuso> Heya ajmitch!
<ajmitch> I'm not here
<TheMuso> Oh no, of course not.
 * ajmitch has no internet connection at home
<ion_> Thereâs a Finnish job ad in the tubes with a programming puzzle you need to solve to get the recruitment e-mail address. The puzzle contains a grammar error. So, i emailed the resulting address with a polite message saying iâm not interested of a job at the moment and pointing out the error. I also attached my solution just for fun. ;-)
<ion_> Whoops, wrong channel.
<ion_> Heh, someone suggested the error was there intentionally so that they can filter out nitpicks. ;-)
<Kano> why is it impossible to search for content on hardy?
<Kano> looks like incomplete web update
<Fujitsu> ... what?
<Fujitsu> Hardy doesn't have the web on it, so I doubt it would have a web update at all, let alone an incomplete one.
<Kano> well you can not select it on packages.ubuntu.com
<Kano> but you can edit the line from gutsy to hardy
<Fujitsu> That's normal.
<Kano> so webfrontend needs an update
<Fujitsu> Or perhaps people who expect everything to work flawlessly shouldn't be using the development version.
<Kano> btw. if you recompile osg
<Kano> it would be better to add one build-dep
<Fujitsu> File a bug, then. It will be lost here.
<Kano> http://kanotix.com/files/fix/openscenegraph/openscenegraph/openscenegraph_2.2.0-2+c0.kanotix.1.dsc
<Kano> check this
#ubuntu-motu 2008-01-12
<Kano> libxine-dev
<Kano> is missing
<Kano> which is needed for one plugin
<Fujitsu> Telling me isn't going to do any good.
 * ajmitch notes that \sh uploaded a new revision just recently
<vemon> ion_, which ad is that?
<TheMuso> c
<TheMuso> wrog tab
<Fujitsu> TheMuso: I think you need an irssi script to automatically say `ugh', `wrong tab', `orca let go of my keys' when it sees ^c$.
<TheMuso> Fujitsu: har har
<TheMuso> Its this keyboard as well I think
<minghua> TheMuso: Or maybe just a script that filters "^c$" from input? :-)
<TheMuso> possibly
 * imbrandon yawns
<imbrandon> evening all
<persia> Hey imbrandon.
<imbrandon> man been a long 3 days at work, $world broke, but i got to be the saviour with a ubuntu live cd :)
<imbrandon> hehe
<persia> imbrandon: Doesn't most of your equipment support EFI in one way or another?  I don't suppose you could trick it to boot Ubuntu off the network on-demand so that you don't even need to open the cabinet when something can't boot.
<imbrandon> yea mostly , but in this case someone already tryed to "fix" the issue
<imbrandon> and i was left with scraps to fit back togather
<imbrandon> generaly though we have port 46 on all the switches in the cabnets set to a DHCP + PXE + multi distro live + bart pe , etc etc etc
<imbrandon> so when something breaks or we are swapping hardware we just unplug it from the network its plugged into and put it on 46 and reboot
<imbrandon> choose from a ncurses menu the pxe env we want, dell diag, ubuntu/centos live , etc
 * persia advocates switchport vlan reassignment over physically moving cables
<imbrandon> :)
<madrazr> Hii all
<madrazr> we want to build a tool apt- package
<madrazr> its a tool which is used to create a mirror of the packages that a user wants
<madrazr> **I mean it is a tool which can be used
<Kano> why not use apt-proxy
<madrazr> are there any alternatives already available for this??
<madrazr> Kano: what is apt-proxy??
<madrazr> is it somewhere close to what we have thought??
<Kano> well use it as proxy server for apt
<Kano> it will cache the files
<madrazr> Kano: I did not get you
<Kano> install it and read manpage
<blueyed> persia: you've fixed bug 74097, but bug 154180 requests that it should not run without confirmation.. what do you think? add a confirmation or remove the postinst-update again?
<ubotu> Launchpad bug 74097 in apt-file "apt-file update needs to be run" [Wishlist,Fix released] https://launchpad.net/bugs/74097
<ubotu> Launchpad bug 154180 in apt-file "apt-file update should *not* be run in postinst without any feedback (was:  [Feisty->Gutsy] apt-file causing upgrade to fail)" [High,In progress] https://launchpad.net/bugs/154180
<madrazr> I have read the mapage but did not understand it
<imbrandon> madrazr: apt-mirror
<madrazr> imbrandon: apt-mirror wont work for single packages I think right??
<madrazr> say suppose I want only amarok to be mirrored
<persia> blueyed: Hrm.  The issue is that apt-file won't work when installed (waits for the next cron run) if we don't run it, but I agree that I didn't consider the needs of those with bandwidth constraints when doing 74097.
<madrazr> so that I can install it on another machine not connected to internet
<persia> Maybe we could do something with debconf to allow the user to choose whether to run it automatically or manually later?
<imbrandon> madrazr: aptoncd in that case
<Burgundavia> persia: why not just have apt-file run it automatically the first time it is run?
<madrazr> aptoncd is not working in the manner we want, and it works for only the packages that I have already installed on my system
<madrazr> imbrandon: actually I thought this as an extension for aptoncd
<persia> Burgundavia: That could work too, but means patching the script, rather than just maintainer scripts.
<Burgundavia> it is a cleaner solution
<blueyed> persia: yes, I've thought so.. but it should not be a "high-level" question and default to "no", so it won't make sense - except from providing this reconfiguration, which may be useful to some and later.
<joejaxx> hey its Burgundavia :P
<joejaxx> lol
<madrazr> imbrandon: what do you say for that?? can we take this up as an extension to aptoncd??
<Burgundavia> hey joejaxx
<joejaxx> Burgundavia: :)
<madrazr> so that it can handle the files that aren't cached also
<persia> Burgundavia: Thnking about it, I'm less sure.  I can well imagine that users might try to find a high-bandwidth environment for upgrade, but be in a lower-bandwidth environment when trying out new packages.
<persia> blueyed: One possible workaround to improve user experience, without changing much of current behaviour would be to run the update in the background so that the package manager didn't appear to hang.  This raises other issues, and doesn't solve the 14MB download without warning issue.
<bddebian> Heya gang
<persia> Hey bddebian
<bddebian> Hi persia
<joejaxx> hello bddebian :)
<bddebian> Hi joejaxx
<joejaxx> anyone here touch Xorg other than b r y c e ?
<joejaxx> :)
 * joejaxx checks the changelogs :)
<persia> joejaxx: There are other people who work on X, but they tend to follow weekdays, and tend to discuss things in #ubuntu-devel
<joejaxx> oh bah
<joejaxx> i just forgot xorg is in main
 * persia is impressed
<joejaxx> so i would have to get someone from core to sponsor a patch
<joejaxx> persia: lol why :P
<persia> joejaxx: The process is about the same.  Just subscribe ubuntu-main-sponsors.  Sometimes it takes longer, as there are fewer active main sponsors
<persia> Why?  Because forgetting X is part of main seems to be to take effort :)
<joejaxx> lol :)
<joejaxx> i keep forgetting there are two parts to the archive
<persia> Ah.  That makes more sense.
<joejaxx> yeah
<blueyed> persia: well, maybe it should just auto-detect the download capacity and fallback with a warning/info that download has been skipped..
<joejaxx> persia: i was reminded of that when i accidentally created patces for bugs that were in main
<joejaxx> patches8
<joejaxx> dfdfgdfg
<blueyed> ..but that appears overly complex
<joejaxx> patches*
<persia> blueyed: I'm not sure that is ideal either, but I think we need a complex solution.  Both "do it" and "don't do it" received bug reports.
<blueyed> any ideas?
<persia> blueyed: We can't always download at install time, as the user may not have the bandwidth.  We can't always download at runtime, for the same reason.  It's not an important enough question to get -phigh, so we can't leave it up to the user.  Maybe we could use the notification system, like alsa does to remind you to update your default card definition?
<blueyed> persia: I don't know the notification system, but why not add the notification to apt-file itself: notify the user if there's no index and point him at "apt-file update"? After all it's a cli tool.
<blueyed> I've fixed the download expressions already to output errors, I could add a hint there, too.
<blueyed> (through the exit code and in apt-file itself probably)
<persia> blueyed: I'd like to give the user some information that we don't expect it in advance, just so they can update the cache before getting on the plane, etc.
<persia> I do agree having a runtime check for the cache would be a nice improvement.
<persia> Regarding the notification system, this postinst seems to work: http://revu.ubuntuwire.com/revu1-incoming/mscore-0801022000/mscore-0.8.0+dfsg/debian/mscore.postinst, with a notifier file like http://revu.ubuntuwire.com/revu1-incoming/mscore-0801022000/mscore-0.8.0+dfsg/debian/soundfont-required.update-notifier
 * persia doesn't understand the notifier system well enough to know if that is the preferred method of using it.
 * blueyed doesn't know it at all.. but it looks self-explaining.
<blueyed> But I still think that we should disturb the user during installation..
<crimsun> it's really straightforward to use, yes.
<blueyed> even when the download only takes 5 seconds.. the user would use the tool on the commandline anyway: why not just ask him to download the files, if there's no index yet (or it's outdated)?
<crimsun> arguably, the scripts should not assume you have an active Internet connection at the moment postinst is executed.
<persia> blueyed: Because the user in bug #154180 took a long time to download, which may not be ideal.
<ubotu> Launchpad bug 154180 in apt-file "apt-file update should *not* be run in postinst without any feedback (was:  [Feisty->Gutsy] apt-file causing upgrade to fail)" [High,In progress] https://launchpad.net/bugs/154180
<persia> crimsun: Good point, although we've quite a few packages that fail that test.
<crimsun> yes, flashplugin-nonfree being an infamous one
<blueyed> it asks, doesn't it? but it's not a cli tool.
<persia> I don't see how CLI vs. non-CLI is related to asking or not asking.
<crimsun> (I don't think *cli is revelant here.)
<superm1_> persia: the license on all of them does not fit in multiverse though
<superm1_> persia, many of them *should* stay in universe as they are
<persia> superm1: Packages in universe shouldn't Depend on packages in multiverse, which hits mythbuntu-control-centre, mythbuntu-meta, mythstream, mythtv-theme-mythbuntu, and ubiquity source packages.
<blueyed> I mean, you're supposed to call "apt-file search" anyway: then you could get asked..
<persia> blueyed: Sure, but what if I run my install, and then get on a plane.  If I'm not notified until runtime, I'm stuck without a cache for the next 17 hours :(
<blueyed> persia: good point. So just adding a notification instead of the automatic update?
<persia> blueyed: I think it requires a few things.  1) Dropping the automatic update, 2) Adding a notification, 3) checking at runtime, and suggesting an update if the cache is missing.
<blueyed> agreed. I think I could do that.
<persia> blueyed: Thanks.
<superm1_> persia, yick i see what you would mean there.
<bddebian> Oh, persia, got a minute?
<persia> bddebian: About 13 of them :)
<bddebian> Bah, probably not enough :)
<persia> bddebian: What's the issue?
<ScottK> Any motu hopefuls out there right now?
<crimsun> (me!)
 * bddebian 2
<hophet> i did a pack for a tool, how can i concact a sponsor to upload this to multiverse?
<ScottK> Heh.
<crimsun> looks like Scott can!  :-)
<ScottK> hophet: Is it a new package or an update to an existing one?
<hophet> ScottK: new package
 * ScottK is busy trying to take libmilter out of sendmail and make it a separate package so I can get it promoted to Main.
<ScottK> !revu | hophet
<ubotu> hophet: 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
<hophet> i look for some request of this package, but there inst
<hophet> so i pack it.
<hophet> ScottK: thanks, let me see.
<ScottK> bddebian: Actually I feel like you seem to sometimes on this libmilter thing: WTF did I get my self into.
<ScottK> The sendmail build system is, um, interesting.
<StevenK> Much like the code?
<hophet> ScottK: cool, i will follow the steps
<hophet> good night for all
<hophet> cya
<ScottK> Dunno.  I haven't actually had to look at that, but the Debian sendmail package starts off with tarball in a tarball, CDBS with an incredible number of options set, and goes from there.
<bddebian> ScottK: :)
<macd> I have a single script that Id like to build into an existing package, what is the best way todo this?, add it in the source and build as norm?
<ScottK> macd: Is this for your own use or are you planning to try to get it into the archives?
<macd> universe
<ScottK> So there's an existing package you want to add the script to?
<macd> yes
<macd> actually I think its like 3 files, init script, and 2 in usr/bin
<ScottK> Add it to the debian dir of the package, modify debian/rules to install it, document your changes in a new revision of the package in debian/changelog and then build it as normal.
<macd> cool, thanks
<ScottK> For an init script, there's a debhelper program for that.
<ScottK> dh_installinit or some such.
<macd> alrite, I'll lookup some docs on that
<macd> thanks again
<StevenK> Hrm. Anyone else having trouble getting to LP pages?
<macd> yep
<macd> I had to turn off beta redirection
<StevenK> Ahhh, edge is busted
<macd> yeah, looks like
<a_cuozzo> Hello all :)
<a_cuozzo> I am interested in making a package of Tom Christiansen's Perl Power Tools. Would Ubuntu have any interest in it?
<ScottK> Possibly.
<ScottK> Getting packages into Ubuntu is a community process.
<ScottK> New packages are uploaded to REVU and then considered for upload.
<ScottK> !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
<a_cuozzo> I will go read the page. Thank you.
<ScottK> You're welcome
<Burgundavia> ScottK: can you confirm this not a bug but a support request (or maybe a spec)
<Burgundavia> https://bugs.launchpad.net/ubuntu/+bug/182190
<ubotu> Launchpad bug 182190 in ubuntu "How my company and MSFT are Ubuntu Linux - Please Fix!!!!" [Undecided,New]
<ScottK> Burgundavia: Looking
<Burgundavia> ugh, how do I turn off edge redirection?
<ScottK> Burgundavia: Dunno.  I don't use it.
<ScottK> Burgundavia: I'd mark it wishlist (e.g. it'd need a spec).
<Burgundavia> I don't see why we need to support WDE
<StevenK> Burgundavia: Go to the front page, and press the button
<ScottK> Right, so it's not your wish.
<Burgundavia> well, I don't see the need
<Burgundavia> if the laptop is using windows it is using wde, with ubuntu it can use dmcrypt
<Burgundavia> StevenK: I cannot get to the edge frontpage to turn it off
<Burgundavia> the only way to turn off edge redirection is to logout
<LaserJock> sorry if this a "no doh" but is LP down?
<StevenK> Burgundavia: The main front page: http://launchpad.net/
<StevenK> LaserJock: Edge looks broken
<Burgundavia> just like everything else on LP
<Burgundavia> perfectly logical, if you are an alien
<Burgundavia> and requiring about 4 clicks too manyu
<LaserJock> Burgundavia: but it's intuitively obvious to the casual observer, as we like to say in my lab ;-)
<ScottK> Burgundavia: No, you just don't understand how you're supposed to be doing development work in Ubuntu with LP.  The LP devs will be glad to explain it to you.
<LaserJock> StevenK: thanks, it was interfering with my Ponies, and we know how important that is
<StevenK> PONIES!
<Burgundavia> ScottK: I hate you :)
<somerville32> I got my key signed, woot :)
<LaserJock> hmm, weird, Fedora just doesn't like VMWare Server
<StevenK> white: I've just signed your key and pushed it to a keyserver.
<LaserJock> I need to make another UDS to get some more DD sigs
<StevenK> DD sigs are underrated
<StevenK> % gpg --list-sigs stevenk | grep -c debian.org
<StevenK> 21
<LaserJock> StevenK: well, they are underrated until you need them ...
<StevenK> I don't need them, and I have a whole bunch. :-P
<LaserJock> I've got mako's but that's it for the Debian side of things
<LaserJock> Debian Maintainer's need them, that's what I'm thinking of
<StevenK> How many do you need?
<LaserJock> only 1 I think
<LaserJock> so i think I'm good
 * StevenK updates his key
<StevenK> steven@liquified:~% for i in $(gpg --list-sigs stevenk | grep '^sig' | tr -s ' ' | sed 's/sig [23] /sig /' | cut -d\  -f2) ; do gpg --list-keys 0x$i ; done | grep -c debian.org
<StevenK> 50
<LaserJock> StevenK: ok, time for bed, http://laserjock.wordpress.com/
<gpocentek> ember_: did you work on the gnumeric merge too (to avoid re-doing it on my side)?
<LaserJock> Ponies are on Planet people!
<LaserJock> good night
<Fujitsu> PONIES!
<StevenK> And hmph.
<StevenK> I did the most uploads of any active MOTU for Gutsy, and I get no pony
<persia> StevenK: At least you got a mention :)
<StevenK> Yay woo yay
<Fujitsu> StevenK: What was the need for the `active'? Are you implying there was an inactive one that was somehow more active than the most active one?
<slangasek> there are of course the MOTU reserves, who are distinct from the MOTU on active duty
<persia> slangasek: Don't discount the MOTU Reserves.  They often step in for a day or two each cycle, and help out when we are otherwise swamped.
<RainCT> Hi
<pochu> hello RainCT
<pochu> Does anyone know what a number means next to a responsible in http://people.ubuntu.com/~dholbach/sponsoring/ ? e.g. seb128 (22)
<pochu> And how are the responsibles assigned?
<persia> pochu: The source is available by bzr pull from the same address as the web page.
<pochu> i.e. there are sometimes more than one assigne, I guess that's not from LP :)
<pochu> persia: oh, I'll have a look, thanks.
<persia> Personally, I find that to be frequently out of date.  Responsibility is assigned based on subscribers who are members of ~ubuntu-dev.
<persia> pochu: Also, for UUS stuff, don't be afraid to grab something for which someone else is "responsible", as long as they aren't "assigned".
<Kmos> persia: http://qa.ubuntuwire.com/lintian/reports/Tbuild-depends-on-obsolete-package.html -> can you update this? since november not updated..
<persia> Kmos: I can't, but thanks for pointing it out.
<persia> Fujitsu?
<pochu> persia: alright, thank you for the explanation.
<Kmos> persia: np :)
<ion_> persia: Seems like apt-mark-sync source was accepted. Should i wait for the binary to be accepted as well, or post the update already? Also, if the binary is accepted, what is the proper way to post the update â REVU, just like when posting a new package?
<pochu> persia: out of date -> tell dholbach to add it to cron.hourly ;)
<pochu> And yes, the last update has more than 24 hours...
<persia> pochu: Doesn't help.  Sometimes candidates are there for a couple weeks (when nobody wants to touch them).  Sometimes they get pulled in 20 minutes.  I once saw an upload 107 seconds after submission (although I doubt anyone but Mr. Chen can do that).
<ion_> Does anyone feel like giving a second advocation to http://revu.tauware.de/details.py?package=hardware-connected? :-) Itâs a program that checks whether given hardware exists in the system; useful for scripting.
<persia> ion_: If the source was accepted, the archive can accept updates to the source, and the buildds will just skip the superceded source.  For updates, use debdiff or interdiff patches attached to bugs against the package.
<pochu> Weeks sounds like a lot... I think bugs should ordered from older to newer, instead of the other way round.
<ion_> persia: How about when thereâs a new orig.tar.gz?
<persia> pochu: I generally sort by least-recently-changed (although I skip ones that I'm not sure I can review properly).
<persia> ion_: If there was a new upstream release, the interdiff should contain any modifications required to pull it cleanly.
<pochu> persia: hmm, I'm talking about ~dholbach/sponsoring/, what are you talking about? :)
<persia> pochu: https://bugs.launchpad.net/~ubuntu-universe-sponsors?field.searchtext=&orderby=-date_last_updated&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<persia> Or, just https://bugs.launchpad.net/~ubuntu-universe-sponsors, and adjust the sort order manually
<Fujitsu> persia: Oooops. That must have stopped running after my local mirror got eaten. liw is running a similar thing now, so I might just point to there.
<pochu> https://bugs.edge.launchpad.net/~ubuntu-universe-sponsors?orderby=-date_last_updated is the cleanest url
<persia> I think ~dholbach/sponsoring/ is more useful for main (where things can be ignored much longer) and for new packages, where it prompts people to go look or bug the person working on it for a new revision.
<persia> pochu: My browser doesn't preserve that URL.
<persia> Fujitsu: Sure.  Does liw have all your patches (or weren't there any for lintian), and does it run against universe as well?
<Fujitsu> persia: There weren't any patches other than to get it running on my local mirror, and I believe he runs it for each component.
<Fujitsu> http://people.ubuntu.com/~liw/lintian/
<persia> Fujitsu: Is that considered "production" yet?  I'm happy to change the QA page to point there (duplicated work is not ideal), but the front page makes me unsure.
<Fujitsu> persia: You should likely ask liw about that (I would, but I'm going to be largely without an Internet connection for the next two weeks).
<persia> Fujitsu: You'll be on holiday?
<Fujitsu> Unfortunately so.
<Fujitsu> Yay for family holidays to nowhere. Or not.
<persia> Heh.  Any chance you might fix the links on http://qa.ubuntuwire.com/multidistrotools/ before you go?
<Fujitsu> What's broken about them?
<Fujitsu> Hm.
<Fujitsu> That main one looks wrong, but what else?
<persia> main is universe, universe hasn't been updated since november, and I don't see all the nifty new ones I've heard about.
<Fujitsu> That sounds rather odd.
 * Fujitsu looks.
<persia> Specifically, ruby, java, ubuntustudio, etc.
<Fujitsu> Ruby and Java haven't had lists compiled yet, and I thought I'd linked ubuntustudio.
<Fujitsu> Gaaaaah I'm an idiot.
<persia> off-by-one error?
<Fujitsu> mdt removals removals.txt A < universe | mdt versions2html -t "Universe package" -d -u -a Sid -b Hardy > universe.html.new
<Fujitsu> mv universe.html.new main.html
<persia> That explains it :)
<Fujitsu> I suspect a left a g off the end of my regex months ago :(
 * persia should have been reporting bugs in LP rather than randomly reporting in IRC.  Sorry.
 * Fujitsu should have got it right in the first place.
<Fujitsu> Right, UbuntuStudio is up and looking somewhat sane, and universe is rerunning..
 * Hobbsee waves
<Hobbsee> Fujitsu: what blew up?
<Fujitsu> I'm buggy and can't write regexps properly, so my mdt output was mixed up.
<persia> Fujitsu: Thanks.
<Fujitsu> persia: Sorry about that.
<persia> Fujitsu: No worries.  I've been working around it, and didn't really care about main :p  Only a few missed, but still a month to catch up.
<Hobbsee> PONIES!!!
<StevenK> And guess who didn't get one.
<Hobbsee> awww
<Hobbsee> you just need to yell more
<Hobbsee> awww, no pony for you.  not yours
<persia> pochu: Why doesn't liferea use ~/.liferea?  It's cluttering my home directory, but I don't know if it's a bug.
<Fujitsu> persia: It uses ~/.liferea_1.4 here... is that a problem?
<persia> Fujitsu: I have ~/.liferea_1.2/, ~/.liferea_1.3/, and ~/liferea_1.4/, which I imagine will eventually exhaust my inodes
<Fujitsu> Ah.
<persia> On the other hand, if upstream changes the preferences format at each significant release, the migration scripts are working perfectly, and I should have deleted them.
<RainCT> what was the command to check which package version is higher?
<man-di> RainCT: dpkg --compare-versions ...
<RainCT> thanks
<persia> RainCT: There's no output, so add && echo YES || echo NO at the end.
<man-di> or just do echo $? after execution ...
<pochu> persia: yes, with every major release the database/feedlist/preferences are migrated, and left there in case something goes wrong. 1.3 was the unstable series for the 1.4, btw
<persia> pochu: OK.  As long as it is intentional.  I don't suppose 1.5 could contain a NEWS.Debian entry reminding people to delete the old directory if the migration worked?
<persia> Oh, and thanks for the confirmation.  I like not filing non-bugs :)
<pochu> That sounds like a good idea. I'll try to remember it when the time comes (hardy+1 I suppose).
<persia> pochu: Thanks.  Do you want a bug as a reminder, or do you have a separate TODO somewhere?
 * dennda would love to see (at least) icewm 1.3.34 in hardy instead of 1.3.33... Any chance?
<persia> dennda: Yes, absolutely.  Please prepare a candidate for review :)
<dennda> Uarg
<dennda> I don't know anything about packaging at all
<dennda> ;)
<persia> dennda: Several people here might be willing to help, although window managers aren't exactly an easy place to start.  Are you familiar with the icewm code?
<dennda> Not at all
<geser> dennda: then try to persuade the Debian maintainer for an updated package
<dennda> how to get hold of him?
<persia> dennda: File a bug in the BTS against icewm of Severity: wishlist asking for an upgrade (http://bugs.debian.org/)
<dennda> Ok, thanks
<persia> dennda: On the other hand, given the number of bugs open in the package, the Debian maintainer may also be busy, and may appreciate any help you can provide.
<pochu> persia: I've created a TODO for it.
<RainCT> geser, asac: What is Â«Add /usr/include/xulrunner to CLASSPATH_INCLUDES in configure. Add MOZILLA_CFLAGS to configureÂ» in classpath for? Is this still needed if it builds without adding it?
<effie_jayx> hello all
<pochu> The new agreement is to go with diff.gz instead of interdiff, am I right?
<pochu> heya effie_jayx
<pochu> (That is, for bug reports)
<persia> pochu: No.  That's currently under discussion.  If the discussion quiets, and there is no opposition, it will be proposed in a MOTU Meeting.  If it passes, it will be announced.  I think it will be about three weeks, unless someone objects.
<pochu> persia: ok, I've requested a diff.gz for the vinagre update to review it.
<persia> pochu: On the other hand, there's currently no official policy for U-M-S, so I can't advise you there.
<persia> pochu: which bug?
<slicer> Is there a good reason to manually use ucf in .postinst for something that can be handled by conffiles?
<persia> slicer: Depends on taste, I'd say.  Why do you ask?
<pochu> persia: bug 176007. I'm looking into it.
<ubotu> Launchpad bug 176007 in vinagre "Please sponsor vinagre_0.4 into Hardy" [Wishlist,New] https://launchpad.net/bugs/176007
<slicer> persia: Someone is working on a debian version of my package, and they're using ucf manually for all the files in /etc. I'm trying to figure out if it's a good idea, but it seems to add nothing and just create a harder to maintain package.
<persia> pochu: We do still want an interdiff for that, but the interdiff ember_ provided is useless, as it was built with -p1
<persia> slicer: Maybe it's easier for them to maintain.  I suggest asking them why they choose to do it that way.  One advantage of ucf is that it makes it easier to programatically modify conffiles if one wishes to later, which makes maintenance easier if there are any desired changes to the configuration files.
<asac> RainCT: well ... without looking i think those would still be needed. maybe configure just falls back to firefox-dev automatically? which value can you see for MOZILLA_CFLAGS in config.status ?
<asac> (after configure)
<slicer> persia: The reason was to "avoid automagic stuff".
<persia> slicer: Seems like it would be doing the opposite to me, but I'm not a ucf expert.
<slicer> persia: I fully agree.
<slicer> persia: There's another issue. The server package was originally named mumble-server (on my part), which I renamed to murmur as that's what the server program is actually called. However, I've been informed that there is a package in debian called 'murmur' (but it's not in ubuntu yet). I assume the correct thing is to switch back to mumble-server?
<persia> slicer: Yes.  Debian package namespace trumps Ubuntu package namespace except under special circumstances.
<slicer> persia: *Nod*. Next question then. At the moment, logfiles are in /var/log/murmur/murmur.log, database in /var/lib/murmur etc. Is it correct to rename that to /var/log/mumble/murmur.log, /var/lib/mumble/murmur.sql etc? It seems a bit counterintuitive to me, but then again, policy often is :)
<pochu> I guess it's ok to unsubscribe u-u-s if a report needs more work?
<persia> pochu: Yes.  Subscribe yourself.  Unsubscribe U-U-S.  The current process is documented at https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
 * pochu reads it
 * persia declares the use of automake to install python packages aberrant.
<StevenK> Er, yeah. Ick.
<slicer> Did anyone have any opinions on the directory naming issue?
<minghua> persia: Even for Python extension packages?
<persia> minghua: The source of the package that caused my complaint consists of some images, some XML, two python scripts, autom4te fun, and GNU templates.
<minghua> persia: Yeah, I suppose that's pretty unnecessary.
<persia> While having globals.py.in might have some benefits, I somehow think distutils would be more well suited.
 * minghua still wants to learn proper packaging of python extension that uses autotools, though.
<persia> minghua: I'll let you know if I come across such a package.  This wouldn't be a good example.
<minghua> persia: :-)  Thanks!
<minghua> persia: Although I think I'll probably have to ask on debian-python list eventually.
<zul> morning
<minghua> My package is kind of a special case.
<persia> minghua: Why not ask them now?  I've heard they are freindly and helpful people.
<minghua> persia: Have higher prority things on TODO list, mostly.
<persia> Ah.  That's certainly understandable :)
<minghua> I shouldn't be taking more packages anyway.  I can't even give enough love to the ones I currently maintain.
 * persia advocates collaborative maintenance
<persia> ember: Re: #176007: why force 3.2?  Will it FTBFS with a lower version?
<pochu> persia: maybe because of jwendell's comment, but I don't think that's reasonably.
<AndyP> hi folks
<pochu> persia: I'm going to package vinagre in Debian, although let's upload ember's work to Hardy as it will need to be NEWed in Debian.
 * jonnymind is away: Sono occupato
<ion_> Thank you for the information.
<\sh> moins
<Hobbsee> !away jonnymind
<ubotu> Sorry, I don't know anything about away jonnymind - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<Hobbsee> !away >  jonnymind
<Hattory> Hi \sh.... alogg package at the end was a sync https://bugs.edge.launchpad.net/ubuntu/+source/alogg/+bug/182146
<ubotu> Launchpad bug 182146 in alogg "Please sync alogg 1.3.7-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
<Hattory> :)
<\sh> Hattory: I thought so :)
<Hattory> :D \sh Could i make a sync for mixmaster too? you are always the last uploader :D
<\sh> Hattory: do what you want :) flatrate merging...:)
<mok0> yo, dudes
<\sh> preparing wine 0.9.53
<emgent> hello there ;)
<emgent> someone can close my bug #181416 ?
<ubotu> Launchpad bug 181416 in wordpress "SQL injection vulnerability in wp-includes/query.php in WordPress CVE-2007-6318" [Undecided,Confirmed] https://launchpad.net/bugs/181416
<\sh> emgent: is it fixed in ubuntu?
<emgent> in hardy yes.
<emgent> affected only gutsy and feisty
<\sh> emgent: so it's not fixed :)
<emgent> patch avaiable (attached on bug)
<emgent> \sh, i'm searching sponsor to commit :P
<\sh> emgent: well, this is security team work :) jdstrand or keescook are deeling with it :)
<emgent> ok thanks \sh
<\sh> emgent: I see you subscribed motu swat and ust to the bug..so everything goes the right way :)
<emgent> ;)
<AndyP> will hardy packages still get autosynced from debian at some point or is it on sync request only at the moment? (i've been out of the loop for too long, i forget how it works)
<pochu> AndyP: we are past DebianImportFreeze, so only if you request them.
<\sh> AndyP: sync requs are required
<ScottK> Yeah.  My first Pony.  Thanks Laserjock (to bad he's not actually on to get the thanks)
<pochu> \sh: I beat you ;)
<crimsun> woo, pony!
<\sh> pochu: hehe
<AndyP> pochu: \sh: thanks, i'll get them filed :)
<ScottK> minghua: Debian Python Modules Team exists precisely to help people like you who don't have time for dedicated maintenance (reading the scrollback).
<\sh> pochu: I was in the gym..and skyping on the other computer...so I'm a bit slow :)
<geser> ScottK: and a no-pony-award for StevenK :)
<ScottK> There's no such thing as bad publicity.
<\sh> hmmm?
<crimsun> unless you work for the gov't.
<crimsun> then just about all publicity is bad.
<ScottK> Well, there is that.
<\sh> crimsun: what happened...I read about your leave from the council
<crimsun> \sh: I don't have time to keep up with Ubuntu development anymore.
<\sh> crimsun: new jobs? :)
<crimsun> \sh: yeah
<\sh> crimsun: well, bad for motu and multimedia but good for you :)
<crimsun> I could say that I now work for Microsoft, but that would be wrong.
<ion_> Yes. Working for MicrosoftÂ® would be wrong. ;-)
<\sh> crimsun: lol
<\sh> crimsun: but would give a lot of money .)
<AndyP> that's one of my sync requests done... the other one would be for a package which isn't even in ubuntu yet so i'm guessing filing that sync request would be futile, right? :)
<pochu> AndyP: if it's in Debian but not in Ubuntu and you want the package in Ubuntu, then you need to request a sync.
<AndyP> pochu: oh ok, that's good, i assumed new packages wouldn't be allowed at this point
<pochu> Until FeatureFreeze they are, and later if there's a good reason and no risk of regression (e.g. new packages) maybe
<AndyP> great, thanks
<ScottK> AndyP: You're working towards becoming a MOTU, right?
<AndyP> ScottK: i was last summer, but my priorities got changed when my final year at university began (++busy) so i don't think i could put in enough time to justify it really
<ScottK> OK.
<ScottK> Any MOTU hopefuls out there needing a small learning experience?
<slytherin> ScottK: Is it short work?
<ScottK> slytherin: Should be.
<slytherin> ScottK: Tell me, if I find enough time before I feel sleep, I will do it
<ScottK> OK
<ScottK> slytherin: Yesterday I uploaded a new kdissert merge.  Ubuntu has carried a diff with Debian on the package for quite some time.
<ScottK> slytherin: Unlike before, it's no appropriate to send a bug to the Deiban BTS asking for our change to be added into the Debian package.
<ScottK> slytherin: So the task is (this is the learning part) to figure out why it should be reported now, but couldn't before and (this is the useful part) send the bug to Debian BTS.
<ion_> Not or now?
<ScottK> With Debian spelled correctly
<ScottK> now
<ScottK> ion_: Thanks
<ScottK> it's now appropriate ...
<slytherin> ScottK: Let me know the bug number
<ScottK> slytherin: There's no bug.  Grab the current kdissert package from Hardy and look at it (see debian/changelog to start).
 * ScottK goes for more clearly needed coffee
<slytherin> ok
<ScottK> \sh: Was bbkeys your first motu-reloaded upload?
<ScottK> Congratulations again in any case.  It's good to have you back.
<minghua> Hi ScottK.  Thanks for the note.  But the extension I'm interested is a python-binding of a C++ library and a dynamically-loaded plugin of an input method framework, combined in one single .so file.
<\sh> ScottK: nope...I uploaded yesterday the whole stuff of my libgif transition
<ScottK> minghua: We do have python-bindings packages in the team.
 * ScottK needs to read -chainges more closely then.
<minghua> ScottK: I doubt anyone in Debian Python Modules team would be particularly interested.  But I'll probably send a mail since many people encourage me to do so.
<\sh> guys, I think we are in the time of not asking last uploaders for doing merges right? I think we are close to freeze?
<\sh> ScottK: btw..thx for your thumbs up :)
<ScottK> minghua: or just talk to POX on IRC.  He's there now.
<ScottK> \sh: You're welcomed.  Well deserved (and not just because I can quit taking care of WINE).
<\sh> ScottK: hehe...wine 0.9.53 is on it's way to hardy btw :)
 * POX_ bbl (going out)
<ScottK> \sh: We really ought to do a WINE backport for Gutsy too.
<\sh> ScottK: hopefully we will have some more wine uploads before upstream freeze...so I want to backport the latest wine in hardy to gutsy...if this is ok
<ScottK> \sh: No reason we can't do more than one.
<\sh> ScottK: ok...let me finnish 0.9.53 and I'll do a gutsy backport testbuild
<ScottK> \sh: Great.
<minghua> ScottK: Thanks, I'm there now and asked the question.
<ScottK> Unfortunately POX was probably your best bet and he's gone out, but maybe when he get's back or someone else.
<hophet> hi all
<minghua> I can wait. :-)
<hophet> someone can re-sync the REVU uploaders keyring?
<hophet> or if it isn't possible. I wait the cron :P
<slytherin> ScottK: I am a bit confused. There is a bug open in kdissert. Were you talking about that or the dh_icons change?
<ScottK> The dh_icons change
<jonnymind> Hobbsee: what's the problem?
<ScottK> slytherin: If you've a notion how to deal with the open kdissert bug, bonus points for a patch.
<slytherin> ScottK: Nope. No idea about tex. :-)
 * ScottK neither.
<minghua> What tex-related bug are you talking about?
<ScottK> minghua: Bug #180182
<ubotu> Launchpad bug 180182 in kdissert "kdissert still using fancyheadings.sty" [Undecided,New] https://launchpad.net/bugs/180182
<minghua> Ha.
<ScottK> minghua: You know that issue?
 * minghua remembers bug 132399 well.
<ubotu> Launchpad bug 132399 in texlive-base "fancyheadings.sty disappeared" [Undecided,Confirmed] https://launchpad.net/bugs/132399
<minghua> ScottK: Yes, the TeXlive upstream seems to be in the position of "fancyheading is dead, long live fancyhdr, and fix other packages, please".
<ScottK> So the fix is to change fancyheading to fancyhdr?
<minghua> Yes, and probably check it still works.
<minghua> It's "99% compatible".
<ScottK> Well we'd need an actual kdissert user for that.
<ScottK> slytherin: You want to take a shot at fixing it or shall I?
 * minghua wonders why kdissert has "MOTU Media" as maintainer.
<ScottK> minghua: Does this change apply to Debian tex packages as well.
<ScottK> minghua: LP bug.  It's MOTU.
<ScottK> Because it has an Ubuntu change (added dh_icons)
<minghua> ScottK: I believe so.  I don't think Debian has fancyheadings.sty either.
<\sh> for syncs we have to subscribe archive-admins, right?
<ScottK> \sh: Yes.
<ScottK> ubutnu-archive
<ScottK> err
<ScottK> ubuntu-archive
<\sh> ScottK: thx :) done :)
<slytherin> ScottK: You are welcome to try. I have never used kdissert and don't know if I will be able to provbide even slightest hint.
<ScottK> OK.  I'll give it a shot since I touched it last.
<slytherin> by the way, anyone facing problem with launchpad edge version? I am getting error certificate invalid
<minghua> ScottK: Congratulations for the golden pony, BTW. :-)
<ScottK> minghua: Thanks.
<\sh> did I miss something?
<ScottK> \sh: laserjock finally published the golden pony awards for Gutsy.  See planet
<\sh> ScottK: ah this one :)
<ScottK> minghua: Yes. It applies to Debian too (the fancyheader bit).  Debian Bug #421450 is an example.
<ubotu> Debian bug 421450 in fiaif "fiaif: FTBFS: File `fancyheadings.sty' not found." [Serious,Fixed] http://bugs.debian.org/421450
<\sh> btw...what do I have to do to get my ubuntu.com address back=
<\sh> ?
<ScottK> \sh: File a LP question against launchpad, IIRC.
<minghua> \sh: How did you lose it?
<\sh> minghua: when you leave ubuntu members you lose your ubuntu.com address as well
<minghua> \sh: Oh, I didn't know you gave up membership as well.
<\sh> minghua: I left all teams these days
<minghua> But you are back now. :-)
<\sh> minghua: right :)
<slytherin> ScottK: Looks like I finally understood what you were saying. dh_icons needs debhelper >= 5.0.51 which landedn in debian in July 2007. But there has been no updates to kdissert after that. So there was no use asking them to use dh_icons, right?
<ScottK> slytherin: Right.  Before that, Ubuntu had du_iconcache for the same function, but that was never in Debian.
<ScottK> du/dh
<slytherin> ScottK: Hmm. Is it worth a bug? If you say yes I will file the bug.
<ScottK> slytherin: So you make a bug against the package with a diff that bumps the debhelper dependency (which I didn't do on my merge (bad of me)) and adds dh_icons to debian/rules.
<ScottK> slytherin: It's worth a bug, because if Debian implements it, then it's a sync with Debian and no manual merging required.
<slytherin> ScottK: oops, no debian pbuilder set. Will take few days before I do. :-(
<ScottK> slytherin: Send me your diff and I'll test it.
<ScottK> I have one
<slytherin> ScottK: Ok. I will do.
<slytherin> ScottK: Is there any way I can bypass signing. I don't have my gpg key on this machine.
<ScottK> slytherin: pass -us (I think) to dpkg-buildpackage or it will try, error out, and no harm done.
<minghua> slytherin: -us -uc option
<ScottK> slytherin: What minghua said
<ScottK> Anyone around that speaks Dutch?
<slytherin> ScottK: is it ok if I paste it in pastebin?
<ScottK> slytherin: Sure
<slytherin> ScottK: here you go, http://paste.ubuntu-nl.org/51687/
<slytherin> I will be back in 20 minutes. let me know if you need anything more.
<ScottK> slytherin: Thanks.
<albert23> ScottK: I am Dutch
<somerville32> Can someone sweep up notecase on revu?
<ScottK> albert23: I'd appreciate it if you could translate Bug 182357 for me.
<ubotu> Launchpad bug 182357 in amavisd-new "Bus error when trying to install" [Undecided,New] https://launchpad.net/bugs/182357
<ScottK> slytherin: Building it now.
<albert23> ScottK: OK, looking
<ScottK> albert23: Thanks
<slytherin> man-di: please excuse the bugging, but did you find time for looking into lucene2 package?
<man-di> slytherin: sorry I forgot to tell you, I cant reproduce that failure on debian
<ScottK> slytherin: Your kdissert patch builds just fine in my Sid pbuilder.  I'd leave the debian/changelog entry out of your patch for Debian BTS, as the maintainer will no doubt want to do his own in any case, but the rest is good.
<albert23> ScottK: done
 * ScottK looks.  Thanks again.
<\sh> hmmm..ircnick of  Adilson Oliveira anyone?
<slytherin> ScottK: I will would rather leave it in. if the maintainer wants to change that is fine by me. But I don't want to get fired because I didn't provide explaination of my changes
<ScottK> slytherin: OK.  Got for it then.  I generally explain the why in the bug report myself, be that's reasonable too.  You'd want to give it an NMU revision number then.
<slytherin> man-di: surprising. I will have to look in detail.
<pochu> \sh: agoliveira
<slytherin> ScottK: I have nod idea what is that. :-) I guess I better leave the changelog. :-P
<slytherin> i mean leave out
<ScottK> slytherin: Just give a good explanation in the bug.
<slytherin> I will
 * geser is caught again in a circular build-depends again. ARGH :(
<vemon> is there a howto on installing / packaging a different version of a library in debian?
<vemon> i need to install libmxml2.2 and the default ubuntu (hardy) version is 2.3
<geser> !library packaging guide
<ubotu> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
<vemon> i don't want to install over the default version since some other prog can depend on it
<geser> vemon: does it have a different soname?
<vemon> thanks geser
<vemon> unfortunately the default ubuntu version has no versioning in soname
<geser> that's bad
<broonie> If it has a different soname and you follow the guide geser linked you'll be fine; if it has the same soname and isn't backwards compatible upstream should be spanked.
<vemon> it's imported straight from debian and there is already a debian bug (and i created an ubuntu bug) about the new version not being fully backwards compatible
<geser> broonie: Hi, do you know where the aqsis build failure is located? it is in aqsis or scons?
<geser> slytherin: any progress to get batik build?
<vemon> does the version in soname usually result from debian/ubuntu packaging?
<azeem> vemon: no, it usually results from upstream library versioning
<ScottK> minghua: I'm unable to find where kdissert uses fancyheading.  Any clues on how to figure this?
<broonie> geser: scons, I guess. I told upstream about it but didn't hear anything back.
<vemon> azeem, thanks. that again cleared things a bit
<slytherin> geser: haven't checked recently. it is still ftbfs and 1.7 is going to be a lot of work.
<geser> broonie: ok
<azeem> vemon: if upstream library versioning is broken, debian/ubuntu packaging might have to fix it though
<geser> slytherin: do you think the new version will be ready before FF?
<slytherin> geser: new version as in new package?
<broonie> AFAICT it hasn't built in Debian for quite some time for other reasons.
<Amaranth> so, if I need to patch a package from debian that doesn't have a patch system should i add dpath or just patch the source directly? or is there any consensus at all about this?
<Amaranth> err, dpatch
<vemon> azeem, luckily the fix in this case would be to update the library to an even newer version which should be again backwards compatible :)
<azeem> Amaranth: does it patch the source directly already?
<Amaranth> no
<Amaranth> it's clean upstream
<geser> slytherin: yes, or should we upload the current package with added build-depends on sun-java (if it works)?
<slytherin> geser: I am not able to understand the reason for ftbfs from current build log. Can you take a look at it once. May be a sync to latest debian version will solve the problem.'
<geser> slytherin: the current version in hardy build depends on j2sdk1.4. This package can't get preseeded for the license question. That only works for the sun-java packages.
<slytherin> geser: ahh, then I guess adding sun-java5-jdk as build dependency is the only solution.
<vemon> i downloaded parts of a source package and it contains ".diff.gz", ".dsc" and ".orig.tar.gz" -prefixed files. how can i build this?
<vemon> or am i missing something?
<vemon> some file i mean
<slytherin> vemon: when using pbuilder do 'sudo pbuilder build *.dsc'
<vemon> and without pbuilder?
<vemon> (haven't set it up yet)
<geser> dpkg-source -x the.dsc to unpack it
<geser> the cd into the new dir and run dpkg-buildpackage -b (if you have all build-depends installed, dpkg-buildpackage will tell you)
<ScottK> Amaranth: I'd say unless the change is trivial and is known not to be needed in the future, add a patch system.
<slytherin> vemon: It is good habbit to build packages in pbuilder. :-)
<ScottK> or sbuild
<ScottK> or cowbuilder
<ScottK> vemon: Eventually you'll have a dirty source you don't know about and mess something up or miss a dependency.  slytherin is right.
<slytherin> specifically when dealing with arch all packages from debian. :-P
<Amaranth> ScottK: it's replacing mkisofs with genisoimage
<ScottK> I'd patch it because trying to maintain a change long term in the diff.gz can be error prone, but it's not strictly required.
<Amaranth> I'm guessing this is a change we'll be keeping for awhile
<slytherin> This reminds me. devede and few more have broken dependency on either mksiofs or cdrecord.
<geser> does somebody know how I can preseed a debconf question? I want to preseed the sun license question in my pbuilder.
<minghua> ScottK: No idea either (I'm a GNOME user), but I'll have a look.
<slytherin> geser: same question I had long time ago. I will provide you workaround. Login to pbuilder with --save-after-login option. Install sun jre. it should ask you to accept license. exit pbuilder and then build the package. :-)
<minghua> ScottK: In src/templates/kdisspdflatexarticle.tar.gz (main.tex after decompression).
<minghua> ScottK: And maybe others as well (still checking).
<minghua> ScottK: and src/templates/kdisspdflatexbook.tar.gz.
<minghua> ScottK: That seems to be all.
<ScottK> minghua: Thanks.
<geser> slytherin: echo "sun-java5-jdk shared/accepted-sun-dlj-v1-1 boolean true" | debconf-set-selections does it and no need it have sun-java installed in the pbuilder permanently
<jpatrick> "Newest version on remote site is 0.2.0-src, local version is 0.7" -- does someone know how I can get around this?
<minghua> ScottK: No problem.
<slytherin> geser: thanks for the tip. I better sasve it somewhere.
<ScottK> jpatrick: Add an epoch I guess 1:0.2.0-src
<ScottK> Be certain you need to thouh, there's no going back
<jpatrick> ScottK: but I want the 0.7 version...
<ScottK> Oh
<ScottK> Not sure I understand the problem then.
<ScottK> Nevermind
<jpatrick> it stops at 0.2.0 for some reson
<geser> jpatrick: which command gave you this error?
<geser> slytherin: using sun-java to build batik gives: "[javac] java.lang.OutOfMemoryError: Java heap space". Any ideas?
<jpatrick> geser: uscan --verbose
<man-di> geser: I tried that two days ago in debian and it just worked
<geser> man-di: I tried both sun-java5-jdk and sun-java6-jdk from multiverse, both with the same result.
<man-di> geser: strange
<slytherin> geser: looks like we need to change some ant options. I will investigate it on Monday. Leave it to me. :-)
<geser> slytherin: ok
<geser> slytherin: I looked today at the jbossas4 depwait: two packages jbossas4 needs for building build-depend on jbossas4 itself :(
<slytherin> LOL. I had heard of circular dependencies, but circular build dependencies is new to me. :-)
<slytherin> Looks like I need to go in hyperactive mode in cming month to squash java related bugs.
<superm1> hm what happened to libmp4v2-dev?
<superm1> slomo appears to have dropped a whole bunch of stuff from the faad2 source package
<superm1> hm which means that faac fails its builds..
<superm1> jdong, you here?
<man-di> slytherin: when you have solutions I prefer patches in Debian bts ;-)
<superm1> you pushed the last faac change, did it build locally for you?
<slytherin> man-di: sure.
<geser> slytherin: circular build-dependencies are pretty nasty as they require manual bootstrapping on the buildds by a buildd admin :(
<slytherin> geser: man-di: It is too late for me now. I will return on monday. Let's see how this goes.
<geser> slytherin: have a nice weekend
<slytherin> thanks
<pochu> superm1: https://bugs.edge.launchpad.net/ubuntu/+source/faad2/+bug/155686
<ubotu> Launchpad bug 155686 in faad2 "Please sync faad2 2.5-5  (multiverse) from Debian unstable (main)" [Wishlist,Fix released]
 * RainCT is happy as his first NMU was just sponsored :)
<superm1> pochu, yeah i saw that bug, but it doesn't explain it
<superm1> because we had several other binary packages created
<superm1> that were not created by the debian package
<pochu> Then it was probably a mistake, I guess.
<superm1> i didn't want to poke too far into it, maybe slomo knows more about it
<superm1> but i would suspect that the mp4 libraries are not there
<superm1> particularly in debian/changelog there was an entry from breezy days
<superm1>   * Added bmp plugin and libmp4v2 to tarball
<Hattory> https://bugs.edge.launchpad.net/ubuntu/+source/starplot/+bug/182380
<ubotu> Launchpad bug 182380 in starplot "Please merge starplot 0.95.4-2 (universe) from Debian unstable (main)" [Wishlist,In progress]
<Hattory> Why i see the debdiff in this way?  O.o
<Hattory> Is a simple debdiff obtained with: debdiff old.dsc new.dsc > .debdiff
<Hattory> :(
<pwnguin> hmm
<\sh> ok...regarding apt-cache rdepends libungif4-dev pgplot5 is the last package which needs to be fixed (doing so, and fixed two other packages :()...after that we can close the transition bug #174252 completly...
<ubotu> Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252
<sladen> Hattory: debdiff foo.changes bar.changes
<pwnguin> it migth be worth pushing an exception: simcity just went gpl3
<sladen> pwnguin: I'd ship with it, if we can let it in
<pwnguin> gplv3
<pwnguin> is there a reason we couldn't let it in?
<pwnguin> i guess technically, we'd be shipping "Micropolis"
<Hattory> sladen, I try.....
<minghua> Has anybody built simcity yet?
<sladen> Hattory: (make your modified source package with   debuild -S  first)
<warp10> According to https://wiki.ubuntu.com/MOTU/Merging, when a contributor work on a merge he should produce two debdiffs: between debian and ubuntu, and another one between the old ubuntu and new one
<sladen> minghua: hopefully Debian will do it for us :)
<warp10> The latter is really needed? And if so, why?
<sladen> warp10: telling whether Ubuntu-specific changes have been carried over
<minghua> sladen: Heh.  Relying on Debian when there is a release deadline ahead is usually not the best idea. :-)
<pwnguin> minghua: build? i'm still downloading the source! ;)
<sladen> warp10: the idea is to keep the diff from Debian->new-ubuntu  as small as possible, but still to include the extras added in old-ubuntu
<minghua> pwnguin: Right, which makes me think it's a bit early to talk about exception to let it in for hardy.
<pwnguin> nothing wrong with being over-excited
<warp10> sladen: ah, ok. Thank you
<sladen> bugs.debian.org doesn't have an ITP yet
<pwnguin> is there even a request?
<sladen> not from a simple greb for simcity || micropolis
<pwnguin> heh
<pwnguin> http://islandlinux.org/howto/compiling-micropolis-ubuntu-7-10
<\sh> is simcity not trademarked (the name)
<guest22> Any MOTUs here willing to review package photoml (http://revu.tauware.de/details
<guest22> .py?package=photoml)? It's already been advocated once (the previous upload, at least), so it should be very close to being acceptable.
<pwnguin> it is
<pwnguin> and ea is keeping the mark
<pwnguin> whcich is why they're calling it micropolis
<minghua> From the link pwnguin posted:
<minghua> "sudo ln -s libXext.so.6 libXext.so"
<minghua> Eww.
<minghua> There is the libxext-dev package, you know.
<pwnguin> right. im sure that there's a better way
<pwnguin> but its clearly possible ;)
<geser> Hattory: after changing the file type for your attachment from text/html to text/plain it looks now as usual
<Hattory> geser, you're right ;)
 * minghua left a comment.
<Hattory> thnks guys :D
<choudesh__> does anyone know how to add dist and pool folders to the liveCD? I can remaster a liveCD but when I add the Dist/Pool folders for apt-cdrom, squashfs fails to load
<\sh> guys, do you think bug #179864 is worth an SRU?
<ubotu> Launchpad bug 179864 in pgplot5 "shared library should link to libpng" [Undecided,New] https://launchpad.net/bugs/179864
<sladen> \sh: what uses pgplot5, that is ulimately affected?
<geser> \sh: don't forget to check also build-depends for libungif4-dev
<\sh> geser: yeah...I fixed afterstep and camlimages already
<\sh> sladen: wip and ifeffit
<sladen> hopefully it'll build with bison
<sladen> \sh: never heard of/used either of them
<sladen> choudesh__: how are you "adding the Dist/Pool" folders?
<choudesh__> sladen, dropping them into extract_cd and running mksquashfs
<geser> \sh: pgplot5 fsviewer gnome-libs gnucash kaffe libming ted wdm still build-depend on libungif4-dev
<choudesh__> sladen, how should I be doing it?
<\sh> geser: pgplot5 fixed already
<choudesh__> sladen, or should I put them in the casper directory?
<sladen> choudesh__: I'm not sure, try cjwatson
<amarillion> Hey there
<amarillion> It would be very nice if any MOTU could do a review of my package http://revu.tauware.de/details.py?package=speed-game
<amarillion> It's my first package
<amarillion> And I'm anxious to improve my packaging skills :)
<crimsun> hate when I invert the logic-test.  :/
 * ScottK2 is hating on having to figure out how to patch inside a provided tarball (inside the tarball) and the package uses CDBS.
<bddebian> Heya gang
<crimsun> 'lo
<bddebian> Heya crimsun
<bddebian> ScottK2: Good luck with that :-)
 * ScottK2 is pretty close to just reporting the bug to Debian and giving up.
<bddebian> I HATE tarball in source packages :-(
<geser> Hi bddebian
<Alexi> hi all
<Alexi> i'm looking for debhelper Gods :) could somebody help me out with some magic :P?
<geser> bddebian: I'm working on merging classpath. Do you know the reason for your change? see http://patches.ubuntu.com/c/classpath/classpath_2:0.92-4ubuntu2.patch
<geser> it builds fine without this change
<bddebian> Heya geser
<slangasek> ScottK2: what you need is yada to make it easier to work with
<bddebian> geser: Not off the top of my head.  Something to do with mozilla/firefox/xulrunner at the time
<\sh> slangasek: do you happen to know where the mobile devs of canonical are hiding their patch archive for hildonizing gnome apps? e.g. galculator? ..if I want to merge it, I need some new patches for it, or should I drop the hildon stuff for now and merge the new upstream first?
<geser> bddebian: so it's ok to drop this change?
<bddebian> geser: I would think so as long as she builds/runs/etc
<geser> bddebian: it looks like, it builds and the firefox plugin seems to work (at least it installs and firefox lists it). I didn't check the other classpath packages
 * ScottK2 cheers for lagging wifi hotspot connections.
<\sh> hmm..what replaces nowdays the package mkisofs?
<geser> \sh: currently nothing
<geser> cdrtools got removed but afaik wodim doesn't provide the old package names again yet
<TheMuso> genisoimage
<\sh> TheMuso: is it option compatible with mkisofs? I don't want to rewrite the sources of our unmet deps ;)
<geser> \sh: mkisofs was a transitional package to genisoimage in feisty
<\sh> geser: well, we have it still in fai-3.2.1 genisoimage is not symlinking to mkisofs...so looks like some functionality will break
<TheMuso> \sh: I believe so.
<\sh> I hate it...
<ScottK2> Hating all around today.
<Fujitsu> ScottK2: I hate you.
<emgent> StevenK, ping
<emgent> heya Fujitsu \sh
<Fujitsu> Hi emgent.
<ScottK2> Fujitsu: Thanks.
<\sh> that means, I have to change fai to use genisoimage and not mkisofs anymore...which makes sense....thomas will love it
<Fujitsu> ScottK2: No problem.
<superm1> for something being merged from debian multimedia, but considered NEW in ubuntu, should it still be submitted to revu you suppose?
<superm1> i think i've got a solution to the libmp4v2 issue, but it will require a few steps (one including bringing mpeg4ip in from debian-multimedia)
<ScottK2> superm1: merge or sync?
<superm1> ScottK2, it doesn't sync cleanly
<superm1> it will be a merge
<superm1> but i'm still sorting out a few of the details
<ScottK2> I think it can just be uploaded.
<ScottK2> It certainly could be sync'ed and I don't see why a few changes would make it need to go through REVU first
<ScottK2> superm1: Make sure you do a careful review of debian/copyright.
<superm1> well the thing is that Christian has cvs versions of a lot of the dependencies that we dont, so they are quick changes
 * superm1 nods
<torkel> \sh: we should update FAI to 3.2.4 too. Perhaps some of the patches could be dropped :-)
<\sh> torkel: oh..we never updated fai...fun...ok...we need to sync the source from MrFAi to our repository
<torkel> \sh: nope, we didn't
<torkel> \sh: I began to look at what patches that we could drop, but having a one year old running around, a new house and snow outside to take care I haven't got anywhere yet
<\sh> ah...
<\sh> torkel: we need to keep the changes regarding the differences s/debian/ubuntu/
<\sh> and the bugfixes we need to check if thomas had them applied to his version
<torkel> \sh: yeah, hopefully he had applied them :-)
<\sh> torkel: thomas is a nice guy :)
<\sh> torkel: if not, I'm approaching at his desk in cologne and kick his arse personally ,-)
<torkel> \sh: I know, he just needs to be pursaded sometimes to accept the patches :-)
<RainCT> wow is that KDE thing unstable :P
<RainCT> *KDE4
<\sh> torkel: well...let's check the svn commits of the last couple of weeks :)
<ScottK2> RainCT: Of course.  It's a .0 release for API stability, not for end users.
<\sh> geser: ok...all packages fixed and uploaded re: libgif
<RainCT> yes, I know :)
<\sh> let's see who will kill me because of the changes to qvamps
<torkel> \sh: I'm off to bed now and it is snowing, so I know what I will do tomorrow morning
<crimsun> argh, gvamps killed my cat!  Who's to blame?!
<torkel> \sh hopefully I will have some time tomorrow evening doing some FAI work
<crimsun> err, qvamps.
<\sh> torkel: well...:) tomorrow is family day :)
<\sh> crimsun: :)))
<\sh> ok...off to bed :)
<torkel> \sh: hopefully I will find an hour or two when they are asleep :-)
<torkel> err sleeping
<persia> somerville32: Please update bug #182226 for notecase
<ubotu> Launchpad bug 182226 in notecase "Upgrade: notecase 1.7.6" [Wishlist,In progress] https://launchpad.net/bugs/182226
<persia> hophet: syncing keyring now.  Try again in half an hour or so.
<somerville32> persia, You want me to take over from Mitsuya Shibata?
<persia> somerville32: As I read history, shibata was duplicating some of your work.  I suggest you use the bug to coordinate, rather than asking for an upload from REVU here.  If you are doing it, shibata doesn't need to, and vice versa.
<somerville32> persia, I asked for my attempt to be archived earlier today since my attempt was on an older version
<persia> somerville32: Archived?  Ah.  Sorry.  I misunderstood backscroll.  Archiving now.  Thanks for the clarification.
<somerville32> persia, no problem. thanks.
<somerville32> Speaking of packaging, I think I'll go do some QA stuff right now :)
<persia> \o/
<DaveMorris> Can anyone review my package please - http://revu.tauware.de/details.py?package=libserial
<emgent> someone can merge twiki? bug #182415 (debdiff attached)
<ubotu> Launchpad bug 182415 in twiki "Please merge twiki 4.1.2-3.1 (universe) from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/182415
<persia> emgent: You've subscribed the sponsors.  Looks like it's currently 14th in queue.  Should get processed fairly soon.
<emgent> heheh ok :)
<RainCT> good night
#ubuntu-motu 2008-01-13
<somerville32> choudesh, Are you okay?
 * persia suspects a combination of auto-join and network issues.
<Lrrr> someone's having connectivity problem
<somerville32> choudesh_, Can you please fix your connectivity issues? You're spamming the channel.
<TheMuso> He is obviously not around, or the connection is bad enough that he didn't get the message.
<minghua> I'd say just temporarily ban him.
<persia> somerville32: Thanks.
<somerville32> \o/
<persia> Don't forget to unban after a bit, when the autojoin has timed out and failed
 * somerville32 sets a timer.
<stdin> somerville32: you should probably ban-forward to ##fix_your_connection
 * somerville32 will attempt.
<stdin> perfect :)
 * somerville32 wipes brow.
 * ion_ licks brow.
<somerville32> :]
<Amaranth> whoa
<somerville32> :]
<somerville32> Ugh oh :(
<snoutmate> hello, can i ask for re-sync of the REVU uploaders keyring ?
<somerville32> snoutmate, sure. I'm sure a revu admin will get to it as soon as possible.
<cyberix> https://bugs.launchpad.net/ubuntu/+bug/182455
<ubotu> Launchpad bug 182455 in ubuntu "[needs-packaging] Micropolis" [Undecided,New]
<somerville32> lol
 * Hobbsee waves
<bddebian> Hello Hobbsee :-)
<somerville32> Hiya Hobbsee
<bddebian> Heya persia
<persia> Hi bddebian
<somerville32> Sometimes I wished we all worked in the same building or something together. I made muffins today and I have a desire to share :P
<Hobbsee> persia: what am i supposed to export to get my gpg key right?
<persia> Hobbsee: Hrm?  How do you mean?  For signing .changes?
<Hobbsee> persia: yeah
<Hobbsee> Would you like to use the current signature? [Yn]n
<Hobbsee>  signfile cli-common_0.5.6.dsc Sarah Hobbs <hobbsee@ubuntu.com>
<Hobbsee> gpg: skipped "Sarah Hobbs <hobbsee@ubuntu.com>": secret key not available
<Hobbsee> gpg: [stdin]: clearsign failed: secret key not available
<Hobbsee> debsign: gpg error occurred!  Aborting....
 * persia uses export `DEBEMAIL="Emmet Hikory <persia@ubuntu.com>"; dch -i; debuild -S`
<persia> Hobbsee: Let me take a look at your key...
<Hobbsee> oh, so export DEBEMAIL=hobbsee@ubuntu.com doesn't work?
<persia> Hobbsee: If you only do that, you also need DEBFULLNAME.  I overload DEBEMAIL to only have one command.
 * Hobbsee has overriden both usually
<persia> You need `export DEBEMAIL="Sarah Hobbs (nick: Hobbsee) <hobbsee@ubuntu.com>"`
<Hobbsee> persia: interesting, OK
<persia> (or to otherwise get "(nick: Hobbsee)" in debian/changelog)
<Hobbsee> persia: ahh, so that's the problem bit
<persia> Hobbsee: Alternately, adjust your key to not have a comment for that identity, and you don't need the comment.
<Hobbsee> yeah
<Hobbsee> persia: apparently hardcoding it in .zshrc doesn't help
 * Hobbsee hardcodes it in the script
<persia> Hobbsee: hardcoding what?
<Hobbsee> persia: the key ID
<persia> Hobbsee: No.  The keyID is fairly meaningless.  To have a package that doesn't look sponsored, the identity in the debian/changelog tagline needs to be an exact string match to one of the identities listed at http://keyserver.ubuntu.com:11371/pks/lookup?search=0x7D2BCE85&op=index
<persia> If you want to change those identities, you need to edit your local key, and resync with the keyservers.
<Hobbsee> right, yes
<persia> Many people hardcode DEBEMAIL or DEBEMAIL and DEBFULLNAME in their shell initialisation scripts, but I don't think hardcoding the keyID is supported, as it tends to lead to inaccurate changelogs.
 * Hobbsee ponders dropping the nick then
<Hobbsee> iv'e yet to see hardcoding the keyID break anything here
<Hobbsee> although apparently, for this particular script, it didn't take the alias, nor the gpgkeyid from .zshrc
<persia> It would show as a sponsored upload for tools that distinguish such things (like MoM).
<Hobbsee> well, it has to be anyway, as i can't sign it with any other key
<Hobbsee> and if i keep the debian sig, it won't get accepted into ubuntu
 * Hobbsee can't sign it with the installer key, due to ENODRESCHER.
<persia> If you're sponsoring, just use debuild -S -sa -k7d2bce85
 * Hobbsee was using thsi sync script, which effectively does that :)
 * persia suspects the sync script of checking too many things, and has always needed to further adjust with vi when using it, but has only used it when no archive admins could sync, which may not be an ideal sample set.
<Hobbsee> persia: perhaps so.  i'm not sure what it's from.  i'm not sure if they normally use it
<persia> Hobbsee: For sponsoring a sync: build the source package with -uc -us.  Add the correct Origin to source.changes.  debsign the .dsc and the .changes with your sponsoring key.  Upload.
<persia> Anyway, I thought there was supposed to be an LP interface to that by now...
<Hobbsee> persia: i ended up running the sync-script package, watching it bail out, then debsigning and uploading.
<persia> Hobbsee: Which package?
<Hobbsee> which is fine, according to the script
<Hobbsee> er, cli-common
<Hobbsee> there isnt'.  there's probably supposed to be...
<Hobbsee> persia: actually, there won't be for a while.  stuff still gets accepted into main by default from LP
<persia> Ah.  YALPB.  Right.  Why don't I see cli-common in Accepted?
<Hobbsee> it's hit hardy-changes
<Hobbsee> nothing strange should happen to it - LP will class it as a normal upload
<Hobbsee> lp might not know about it yet, if all the runes haven't been done yet
<persia> Hobbsee: Right.  I just want to look at .changes to see if I want to say anything for next time.
<Hobbsee> ahhh
<persia> Runes?  Shouldn't it hit Accepted around the same time it pushes to .changes?
<Hobbsee> i'm not sure, tbh
<Hobbsee> i know launchpad takes quite some time to do certain things
<Hobbsee> fujitsu could probably tell you, if he were here
<persia> Hobbsee: That looks like a clean sync to me.
<Hobbsee> persia: yeah, good :)
<persia> (Except that it required extra LP processing, but that's not easy to resolve in the presence of YALPB)
<Hobbsee> well, it's like a normal upload.  *shrug*
<Hobbsee> i don't see how it required more LP processing, tbh
<persia> Well, yes, but I've been told not to do uploads for syncs because it makes LP slower.
<persia> You're special, as you are in the right groups to do stuff, even though you can't due to YALPB.
<LaserJock> what's the B in YALPB?
<persia> LaserJock: Bug.
<Hobbsee> persia: oh, does it?
 * Hobbsee didn't use special groups, etc
<LaserJock> ah, right
<Hobbsee> persia: did they say why it makes LP slower?
<emgent> good night people
<persia> Hobbsee: pitti told me he'd rather I file 50 bugs and leave them open than file 50 bugs and close them.  Something about uploads being treated differently than syncs (although I don't understand the details).
<Hobbsee> persia: hm, fair enough
 * TheMuso wills the storms to arrive. Tis not often that Sydney gets them first.
<persia> Are they coming from the east?  That seems odd.
<TheMuso> No, west. However a few storms have past to the north and south of where I am.
<TheMuso> So they have hit, but in non-populated areas.
<persia> Isn't that better?  Less inconvenience, but the water table still rises?
<TheMuso> Yes, but its quite warm and humid here, and rain is needed.
<persia> In that case, I guess it makes sense.  We only get Typhoons here for rain in the summer, which is rarely a good thing (although the weather is milder thereafter).
<TheMuso> nasty
<crimsun> ok, UI discussion if anyone's around and up for some simplification.
<crimsun> take a look at the PulseAudio menu items in http://trilug.org/~crimsun/Screenshot.png
<persia> That's four.  Isn't Manager launched from the Device Chooser applet?
<crimsun> well, it's nasty for one thing
<persia> For that matter, also Volume Control, and Volume Meter?
<crimsun> yes.
<crimsun> padevchooser will grab, through Recommends, paman, pavucontrol, and pavumeter
<persia> I'm not sure that paman pavucontrol and pavumeter need to be shown in the default menu then.  As long as padevchooser is there, users should get it in the panel, and then launch the others from there.  Probably good to also include .desktop files for these though, just to make app-install-data happy.
<crimsun> I'm considering collapsing that menu akin to eog's approach
<persia> I don't even have a menu item for eog, which annoys me when I want to launch it to browse some specific directory for which nautilus navigation would take a long time.
<crimsun> OTOH, there's a use case I need to consider: user installs pavucontrol and scratches his/her forehead, "where's that darned menu entry?"
<crimsun> (and yes, there're plans to overhaul the UI for the PA tools, but that's unlikely to land in 8.04)
<crimsun> same use case applies to paman and pavumeter
<crimsun> it does not, however, apply to padevchooser, since this last package will grab the others
<persia> Wouldn't most users want padevchooser?  I don't understand the use case for one of paman, pavucontrol or pavumeter without this.
<crimsun> well, the most likely case I foresee is that _only_ pavucontrol gets promoted to main and shipped with desktop
<persia> Ah.  If that is the plan, then pavucontrol needs a .desktop entry.  Hmm.
<persia> s/.desktop/menu/
<crimsun> yeah, I'll just add "NoDisplay=true" to desktop* for now
<crimsun> presently, it's just a damned mess
<persia> I agree it's a mess.  If none of them appear in the menu, and padevchooser isn't in the session by default, how do users control their volume?
<crimsun> through mixer_applet per usual
<crimsun> they won't have stream-migrating abilities through it, though
<crimsun> (which reminds me of amitk's plans for integrating troubleshooting into gnome-media, but that's another issue altogether)
<persia> So for hardy, we'll include the new sound server (as esd is just plain cruft), but not expose the tools to manipulate it by default, preserving the current interface.  Then for hardy+1, the new upstream interface is released, and users can take advantage of the new tool by default?  That sounds sane.
<crimsun> that's the hope.
<crimsun> people are going to want padevchooser, though, I think.
<persia> I expect.  Why can't that go to main and -desktop?
<crimsun> it can, it's just a bit less likely than just pavucontrol
<crimsun> I suppose it really just requires some effort for the MIRs
<crimsun> need to run the ideas past pitti, though
<persia> If there's no blockers on the MIRs, I don't see why it shouldn't be promoted.  Whether it goes into -desktop or not is another issue.
<crimsun> or ted.  Hmm.
<RAOF> Hm.  Where should a request for a 32bit pulseaudio alsa plugin go?  ia32-libs or alsa-plugins?
<crimsun> both.
<crimsun> and - UGH.
<persia> crimsun: Didn't you have an alternative for libflashsupport in the works?
<crimsun> persia: I didn't, no.  Debian has flashplugin-nonfree-pulse (in git)
<crimsun> the version of libflashsupport currently in hardy is simply my GnuTLS hack on top of Fedora's git package by Lennart.
<crimsun> Debian's flashplugin-nonfree-pulse does not support OSS, OpenSSL, GnuTLS, or ALSA - only pulse.
<TheMuso> crimsun: Did you by chace read my core-dev app? I know you didn't respond to it, but thought you may have seen it. Since you are withdrawing from the community, one of my plans for core dev was to eventually keep the audio effort up, at least in userspace...
<TheMuso> chance
<TheMuso> ugh keyboad
<TheMuso> c
<crimsun> TheMuso: I've read the thread now (beginning with https://lists.ubuntu.com/archives/motu-council/2007-December/000659.html).  Did you have something(s) specific?
<TheMuso> crimsun: Well, alsa-utils, -lib, and pulse stuff in main. As I said in that post, I'll gradulally work my way into it, first with bugfixes, and as I get to know them better, and see what Debian is doing as well as upstream etc, I'll be will ing to take more on
<crimsun> TheMuso: ok, best of luck!
<TheMuso> crimsun: thanks
<TheMuso> crimsun: I just thought I'd tell you, as if you are ever around, I may be asking questions.
<crimsun> TheMuso: sure, anytime.
<TheMuso> ok
<TheMuso> thanks
<Hobbsee> ScottK: rofl!
<Hobbsee> ScottK: i'm liking your and Burgundavia's discussion on LP
<somerville32> link?
<Hobbsee> was a couple of days ago, in here
<persia> timestamp?
 * Hobbsee doesn't have that part of the backscroll now
<Hobbsee> persia: the one about how it's entirely obvious how to use LP, and the LP devs will be happy to show you how you're supposed to be doing ubuntu development on LP
<Hobbsee> it was just very nicely worded
<persia> Oh yes.  That was perfect phrasing :)
<\sh> moins
<desrt> somerville32; yo
<desrt> somerville32; i got your email.  i googled around and found the LP bug and left a comment there.
 * Hobbsee waves
<amarillion> Good morning
<LucidFox> https://launchpad.net/ubuntu/+source/d3lphin <-- What's the point of this?
<LucidFox> Especially since there is https://launchpad.net/ubuntu/+source/dolphin
<LucidFox> which is basically the same thing
<geser> LucidFox: looks like it was renamed: Rename package to d3lphin - New dolphin project for KDE3 (from the changelog)
<geser> LucidFox: Debian has dolphin now only in stable
<LucidFox> so, it was autosynced before DIF and nobody caught it?
<persia> One of those should likely be removed, no?
 * Hobbsee wonders what this is about
<geser> Hobbsee: about dolphin/d3lphin
<Hobbsee> one's for kde3, the other is for kde4.  what's the problem?
<LucidFox> actually, no
<LucidFox> dolphin in Ubuntu is actually d3lphin
<LucidFox> for KDE3
<Hobbsee> LucidFox: correct.  and?
<persia> Hobbsee: Are they supportable in parallel?
<LucidFox> then perhaps one of them should be removed, and the other should have a transitional package
<Hobbsee> persia: yes
<Hobbsee> LucidFox: no.  would you replace kde3 with kde4, and stick kde3 as a transitional package?
<LucidFox> erm
<Hobbsee> persia: well, as supported as d3phin ever was.
<Hobbsee> (which was only by it's authors)
<\sh> afaik, dolphin for kde3 is separated from kdebase3 and dolphin in kde4 is the default in kdebase, but I could be wrong
<LucidFox> the Ubuntu source package "dolphin" contains d3lphin
<persia> LucidFox: KDE3 + KDE4 is special for hardy.  It's a parallel support.  Usually we don't support that, but for this case we will.
<geser> Hobbsee: both dolphin and d3lphin are for kde3? or is one for kde4?
<LucidFox> and the Ubuntu source package "d3lphin" _also_ contains d3lphin
<Hobbsee> geser: d3phin is for kde3, hence the 3.  dolphin itslef is a kde4 thing
<LucidFox> dolphin-kde4 is provided by kdebase-kde4
<LucidFox> not by any of these two packages
<\sh> well
<\sh> LucidFox: is correct
<Hobbsee> oh, hang on
<Hobbsee> this is strange naming
<\sh> dolphin is ubuntu package from tonio
 * persia agrees with Lucidfox
<\sh> and d3lphin is synced from debian looks like...both are the same
<geser> Hobbsee: when I look at https://edge.launchpad.net/ubuntu/+source/dolphin the changelog mentions "Rebuild with kdesdk-script 4:3.5.8-1ubuntu6" so it looks like kde3 for me
<\sh> well ours has more b-ds ,-)
<\sh> geser: this is not important...kdelibs4-dev is important, which is kde3 , kde4 would be kdelibs5
<Hobbsee> er, actually looking at the descriptions, not the naming, d3lpin would appear to be the debian package, dolphin source would be hte kde3 package, which is in main anyway, and dolphin for kde4 seems to be in kdebase-kde4
<Hobbsee> therefore, it would make sense for the kubuntu people to merge dolphin with d3lphin as far as possible, and keep it there.
<LucidFox> And if they're merged into dolphin, blacklist d3lphin from autosync?
<\sh> this is a mess.
<\sh> the project is named d3lphin...so debian is right...
<Hobbsee> i think so.  but it may be able to get all of our patches back into debian for that, then sync it
<Hobbsee> \sh: yeah.  i've no idea why they named it otherwise...
<LucidFox> The problem seems to be that d3lphin was uploaded into Gutsy over the defunct Dolphin KDE3 branch, even though it's technically a fork
<LucidFox> and it happened after DIF
<LucidFox> (for Gutsy)
<Hobbsee> erm...
<LucidFox> in the meantime, Debian made their own package for d3lphin
<LucidFox> which got autosynced in Hardy
<\sh>   * Rename package to d3lphin - New dolphin project for KDE3. Add dolphin
<\sh>     as a dummy package to ease the transition.
<Hobbsee> i don't see the relevance of it being a fork, as such
<\sh> that was for d3lphin (0.9.1-1) unstable; urgency=low
<\sh> dolphin was the orignal name of the package until then
<LucidFox> Ah.
<Hobbsee> \sh: presumably ours never merged again, for some reason
<LucidFox> I think it makes sense to merge into d3lphin and make dolphin transitional, to reduce divergence from Debian
<\sh> Hobbsee: because we always worked with the upstream tarball (0ubuntuX versions)
<\sh> Hobbsee: we never synced from debian
<\sh> well it makes more sense to pull the changes from debian svn into kubuntu bzr and track those changes
<Hobbsee> \sh: i doubt upstream will release again
<LucidFox> Why not?
<Hobbsee> because kde4 is out?
<Hobbsee> and there are only a couple of developers on it anyway, iirc
<persia> I thought there was another couple KDE3 releases planned to support SuSE
<LucidFox> On an unrelated note, Hobbsee, could you please rerun the build process for https://launchpad.net/ubuntu/+source/inkblot/0.99.9-0ubuntu1 ?
 * \sh is also stuck and fcked with galculator...
<\sh> ubuntu mobile developers applied some hildon patches, especially for glade...and new upstream version is there...but no updated glade interfaces...
<\sh> I could break the mobile stuff and remove the patch and merge new upstream only...and never think of hildon again
 * Hobbsee wonders why that failed to upload
<\sh> if this is not going to change that we can work together in a cool way, this different ubuntu releases will be the death
 * \sh doesn't even know what a hildon device is...I though first, they were talking about a second life mobile device which is totally virtual ,-)
<Hobbsee> \sh: speak to StevenK or mithrandir or someone who's on the mobile team about htat
<Hobbsee> \sh: it may be that they've forgotten, or something
 * persia points at http://live.gnome.org/Hildon for people interested in hildon
<\sh> Hobbsee: galculator is universe...I think it#
<\sh> i
<\sh> t
<\sh>  
<\sh> j
<\sh> u
<\sh> Hobbsee:
<\sh> Hobbsee:
<\sh> f
<\sh> c
<\sh> k
<Hobbsee> ?
<persia> \sh: Are you ok, or was that a final reflex action?
* persia changed the topic of #ubuntu-motu to: Masters of the Universe: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com | It's REVU Day!  Only a couple weeks left: packagers: make sure it's perfect, reviewers: let's get them uploaded.
<emgent> hello there
<ChrisGibbs> gday all
<\sh> Hobbsee:
<\sh> Hobbsee:
<Hobbsee> \sh: hmmm?  all on one line?
<jsgotangco> hello
<persia> jsgotangco: Hi!
<emgent> hi jsgotangco
<persia> OK.  Who's up for a review?  There's three candidates already advocated that need sometime to upload.
<persia> Who has a package that needs a review?
<mok0> me
<persia> mok0: Which one?
<mok0> gpp4 and mmdb
<persia> (and where's the standard advertisement?)
<emgent> me too (merge)
 * mok0 loads revu page
<mok0> http://revu.ubuntuwire.com/details.py?package=gpp4
 * persia takes gpp4
<mok0> emgent: hehe beat you to it
<emgent> :)
<persia> mok0: Can you expand a bit on how gpp4 fixes bug #176211 ?
<ubotu> Launchpad bug 176211 in ubuntu "[needs-packaging] coot" [Wishlist,Incomplete] https://launchpad.net/bugs/176211
<mok0> persia: errr, its a dendency of coot
<persia> OK.  Is the plan to open a task against gpp4 when the bug closes, keeping it closed, and open a new empty task for coot itself?
<mok0> coot is based on several libraries that need to go in first
<mok0> persia: I don't understand what you mean
<mok0> I opened a needs-packaging bug against all of them
<persia> mok0: I'm just thinking about bug tracking.  Either gpp4 should get it's own bug, or you'll need to do task management tracking.
<mok0> gpp4 has its own bug AFAIR
<persia> In that case, the changelog is wrong :)
<mok0> could be a wrong bug number?
 * mok0 checks
<mok0> launchpad takes forever to load...
<mok0> bug #176209
<ubotu> Launchpad bug 176209 in ubuntu "[needs-packaging] gpp4" [Wishlist,Incomplete] https://launchpad.net/bugs/176209
<\sh> grmpf damn fcking kde4
<\sh> kde3 konversation is starting a kde4 konqui...and all carriage returns you ever can imagine are fcking around with the complete gnome desktop
 * persia thinks that's RC
 * persia dislikes this new proposed debian/changelog format
<\sh> persia, hmm?
<mok0> persia: yuc I put the wrong bug number in changelog
<persia> \sh: e.g. http://revu.ubuntuwire.com/revu1-incoming/gpp4-0801110100/gpp4-1.0.4/debian/copyright  The idea is to use RFC822-style to make it machine readable.  In my opinion, it makes it less pleasant for humans, and RCF822 is deprecated anyway.
<pochu> persia: you meant debian/copyright, right?
 * pochu waves, btw :)
<persia> pochu: Yes.  Thank you.
<persia> mok0: Have you already uploaded the new one, or should I comment?
<mok0> I didn't upload, might as well fix everything before upload
<persia> Why is NEWS interesting to end users?
<mok0> It's not
<persia> mok0: Then it doesn't belong in the binary package :)  Same for AUTHORS (duplicate of debian/copyright).
<mok0> persia: right
<mok0> persia: removed AUTHORS and NEWS from debian/doc
<persia> mok0: OK.  Watch file?
<mok0> made one yesterday
<mok0> will be in next upload
<persia> mok0: Huge arch:any /usr/share.  You want libgpp4-0, libgpp4-dev, and libgpp4-0-common (or similar).
<persia> Maybe common-dev?  Anyone else have a suggestion?
<mok0> persia: those are data files that are _always_ needed
<persia> mok0: Right, but do we need 10 copies in the archive?  Put them in a arch:all package, and add a Depends to make sure they get installed.
<mok0> persia: ok, I didn't think of archive space
<mok0> persia: will do
<persia> mok0: Last one is that lintian doesn't like your doc-base file.
<persia> OK.  Who's next?
<mok0> persia: I don't have a running hardy system, only a pbuilder, so I haven't seen that lintian warning
<persia> mok0: pbuilder --login?
<mok0> persia: right...
<persia> mok0: It's your lucky day.  No other advertisements.  What was your other package?
<mok0> mmdb
<mok0> bug 176218
<ubotu> Launchpad bug 176218 in ubuntu "[needs-packaging] mmdb" [Wishlist,Incomplete] https://launchpad.net/bugs/176218
<mok0> persia: should those bugs now have status "In Progress"?
<persia> mok0: Better to put the bug in the changelog than in IRC, no?  And yes, the bugs should be "In Progress" if you've a candidate on REVU.
<mok0> persia: closed bug in mmdb's changlog
<persia> mok0: Past or now?
<mok0> persia: editing files as we speak
<persia> mok0: libmmdb0 description needs some deletion: likely doesn't contain the header files.
<persia> mok0: watch file fails " In debian/watch no matching files for watch line"
<mok0> persia: hmm
<persia> mok0: There's an annoying patch to CDBS that makes me encourage the use of DEB_INSTALL_CHANGELOGS_ALL
<mok0> persia: what's annoying about it?
<persia> mok0: Upstream changelogs are silently dropped from all CDBS packages by default.
<persia> mok0: Last note: fails the long-description-contains-short-description test
<mok0> persia: huh? Weird
<mok0> persia: ok, thanks a lot
<persia> Does anyone else have a package ready for review?
<stgraber> persia: http://revu.ubuntuwire.com/details.py?package=libfprint will appear on revu at the next update (so it'll be there when I get back from lunch :))
<\sh> geser, ping resolvconf...what do you say to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431181 to get rid of the diff between ubuntu and debian?
<persia> stgraber: Poke me when you get back, and I'll take a look.
<ubotu> Debian bug 431181 in resolvconf "resolvconf: Please replace abuse of /dev/shm with /lib/init/rw and /var" [Important,Fixed]
<geser> \sh: do we have /lib/init/rw in Ubuntu? I don't have it here
<persia> geser: I don't have it either.  Have you checked Contents.gz in gutsy?
<\sh> geser, well, I wonder what magic we have in initramfs ;)
<geser> persia: packages.u.c lists no /lib/init/rw for gutsy
<persia> geser: Then I say we probably don't have it.
<\sh> geser, ok...so let's stay with our patch :)
<StevenK> \sh: Hrm, what now?
<stgraber> persia: I'm here and the package is on revu
<\sh> StevenK, well, the less diffs we have between ubuntu and debian the better for us..and this diff could have saved us work....
<persia> stgraber: URL?
<pochu> stgraber: you know there's an ITP for it in Debian? Debian bug #460493 and Debian bug #460495
<ubotu> Debian bug 460493 in wnpp "ITP: libfprint -- fingerprint library of fprint project" [Wishlist,Open] http://bugs.debian.org/460493
<ubotu> Debian bug 460495 in wnpp "ITP: pam-fprint -- PAM module allowing authentication via fprint" [Wishlist,Open] http://bugs.debian.org/460495
<stgraber> pochu: Date: Sun, 13 Jan 2008 05:27:04 UTC :)
<\sh> oh wait
<StevenK> \sh: Sorry, I've been out for a while, I'll need more information -- all I saw was Hobbsee's message in my away log.
<\sh> StevenK, ah ming was already resolved :)
<stgraber> pochu: I started packaging on the 6th, so no I didn't know :)
<\sh> geser, did you read in this resolvconf bug report about the selinux refpolicy change?
<StevenK> \sh: Fair enough.
<pochu> stgraber: I saw the two ITPs on debian-devel@ this morning :)
<pochu> stgraber: you might want to contact the owner of the ITP to share the work and collaborate, so I pointed it out to you :)
<persia> stgraber: Based on the debian reports, I see two packages.  Is there something else to go with bug #179923, or are you planning to track tasks for this bug?
<\sh> well...so stop for today...
<ubotu> Launchpad bug 179923 in ubuntu "[needs-packaging] fprint" [Wishlist,In progress] https://launchpad.net/bugs/179923
<geser> \sh: no, but I checked now the version of sysvinitrc in Ubuntu (2.86.ds1-14.1ubuntu32) and /lib/init/rw was introduced in 2.86.ds1-23, so we can't use it
<emgent> geser, cool. i have merge ready
<\sh> geser, oh fun...refpolicy needs it (which is also in ubuntu)
<persia> stgraber: bashism in libfprint0-dev.install
<persia> stgraber: You're repacking the original tarball, but don't have a get-orig-source rule.
<\sh> geser, you know, it's a mess when packages are synced or merged without understanding the impacts...when you read the refpolicy changelog, you know we need to use /lib/init/rw in some cases, because it's manufactured for debian..and ubuntu is a bit behind of the recommended way of doing things...
<persia> stgraber.  You also missed debian/changelog in the binary packages.
<persia> Next?
<\sh> anywayys.../me needs to take care of wife...
<mok0> persia, I can't reproduce the watch file error you found
<persia> mok0: Which package?
<mok0> mmdb
<mok0> persia: 33 minutes ago
<persia> mok0: http://paste.ubuntu.com/3514/
<mok0> persia: can you see the machine ftp.bioxray.au.dk?
<mok0> persia, uscan --report-status works for me
<DktrKranz> StevenK, regarding bug 182142, do you think using "[ -f /etc/dbus-1/event.d/30ppmd ] && /etc/dbus-1/event.d/30ppmd start" is enough?
<ubotu> Launchpad bug 182142 in ppm "Trying to execute /etc/dbus-1/event.d/30ppmd in preinst, but it is still not available" [Medium,Confirmed] https://launchpad.net/bugs/182142
<persia> mok0: Does the server maybe check the client?  uscan doesn't pass one.
<persia> mok0: I only have issues with uscan,  Other tools work fine.
<geser> DktrKranz: I didn't check, but why should one start a service before the files are there?
<mok0> persia: I will check the logs on the ftp server
<DktrKranz> geser, probably because we want it to be stopped during an upgrade
<persia> mok0: I'll keep the unpacked source around to scan on demand.
<geser> DktrKranz: shouldn't the service be started then in postinst? when the package is really installed?
<mok0> persia: what's your IP number?
<mok0> persia: n/m checks w. irc
<persia> heh.  Better :)
<DktrKranz> geser, sound reasonable, but I don't know the package and why it tries to start ppmd during preinst, so I'm not confident with it
<Amaranth> It should be stop on prerm and start on postint
<Amaranth> err, postinst
<juliank> (LP: #182520) industrial-icon-theme is at: http://revu.tauware.de/details.py?package=industrial-icon-theme
<broonie> geser: I have had a more detailed look at that aqsis bug - it looks to be at least partly aqsis' fault; it's replacing hte SCons-supplied Install and InstallAs methods.
<persia> juliank: If you're going to use the new copyright format, consider X-Format-Specification, and X-Debianized-By.  See http://revu.ubuntuwire.com/revu1-incoming/gpp4-0801110100/gpp4-1.0.4/debian/copyright for an example.
<persia> Also, the last paragraph doesn't match RFC822 requirements.
<geser> broonie: thanks for looking
<broonie> geser: http://scons.tigris.org/issues/show_bug.cgi?id=1884 is a (rather badly reported) upstream bug.
<broonie> See also http://bugs.debian.org/458849; as I said the other day there's also a preexisting FTBFS for aqsis in Debian which has not had any response so I'm not convinced that resolving the immediate problem will help.
<stgraber> persia: thanks for the review, about the get-orig-source, do you have a simple example of how to just bzip2 -d and gzip -9 the upstream tarball ?
<pochu> crimsun: since this morning I can't play music. Totem and Rhythmbox will crash if I try to play any file. Might this be related to the alsa updates of yesterday? See bug #182443
<persia> stgraber: https://wiki.ubuntu.com/PackagingGuide/Basic#head-4bb01b3c07548aaf98e85ac7eb7983e632f8eb38 has one
<ubotu> Launchpad bug 182443 in totem "totem-plugin-viewer crashed with SIGSEGV in strncpy()" [Medium,Incomplete] https://launchpad.net/bugs/182443
<persia> pochu: Did you run alsaconf set-default-card yet?
<pochu> Nope. Should I?
<persia> pochu: There should even be a little informative widget on your desktop with a notification telling you to do so.
<pochu> There wasn't any.
<pochu> Shouldn't that be called in postinst?
<persia> Strange.  I got one.
<pochu> Maybe I missed it :)
<persia> Do you use GNOME or KDE?
<Hobbsee> xfce!
<pochu> GNOME. Maybe it dissapeared after a panel crash due to some builds
<persia> pochu: Apply nenolod's patch :)
<pochu> I think I'll do it, since it's accepted upstream ;)
<pochu> But I'll ask seb128 first.
<pochu> Since he has do upload it :)
<pochu> s/do/to/
<pochu> And why not call that in postinst?
<persia> pochu: I meant locally.  It will get uploaded later, but why wait for the next package refresh?  Also, notification is better than postinst because it works in an all-gui environment.
<pochu> $ alsaconf set-default-card
<pochu> bash: alsaconf: command not found
<broonie> pochu: You need to be root (sudo /usr/sbin/alsaconf ...)
<pochu> persia: applying it locally will only benefit myself, while uploading to the archive will benefit all the devs ;)
<pochu> broonie: oh, ty
<pochu> Really? Not found...
<juliank> persia: mok proposed these X-* lines less than 24 hours ago. I want to do it the way Sam Hocevar does. Once mok's proposal has been discussed and accepted, this may change.    - see http://packages.debian.org/changelogs/pool/main/m/monsterz/current/copyright
<juliank> s/may/will
<pochu> dpkg -S alsaconf | grep bin gives nothing
<persia> pochu: I agree pushing to the archive is nicer, but seb127 has to upload, and already plans to.  No point having the pain locally if you can avoid it while waiting.
<pochu> asoundconf?
<persia> juliank: I really don't like anything going into the Ubuntu archives without information indicating who is licensing it to Ubuntu.  This is especially true as Ubuntu changelogs get dropped when it goes to Debian, so the original packager (and person licensing it to the distribution) is lost.  That's one of the reasons I don't like the new format.
<pochu> Yeah that's the one
<persia> pochu: Right asoundconf.  Sorry.
<mok0> juliank: ... and which is why I think the "X-" lines are pretty nifty
<pochu> I still got the crashes after running 'asoundconf set-default-card Intel' both as normal user and as root
<persia> I also had to restart alsa from the init script (but I have to do that every boot anyway, so it might just be me)
<mok0> persia, juliank: I put them in the wiki at the request of Charles Plessy; he liked to proposal
<persia> juliank: Even aside from whether it indicates who licenses the package, your debian/copyright isn't in RFC822 format
<juliank> mok0, persia: The original packager has to be kept if files are kept. When the package gets into Debian, the new maintainer has to keep the copyright part from the Ubuntu history.
<juliank> persia: It's part of the proposal "Also, it is important to allow any form of free text in the file, be it before or after the machine-interpretable part."
<persia> juliank: You're conflating copyright and licensing.  For many packages, the contents of debian/ are a shared work, based heavily on the work of previous packages, and licensed as shared.  The holder of copyright for this may not be the person providing the license to the distribution to use the files.
<juliank> persia: But we have 'Files: *' and 'Files: debian/*', one for upstream files, one for debian files. BTW, even readahead-list was accepted without any information about debian/* in its copyright file: http://changelogs.ubuntu.com/changelogs/pool/main/r/readahead-list/readahead-list_0.20050517.0220-0ubuntu11/copyright
<persia> juliank: You are again conflating the copyright holder for debian/ and the person who is extending the licensed work to the distribution.  These aren't always the same.  Anyway, I don't consider another package not matching my tests to be sufficient reason to lower them.  You may find another reviewer less strict.
<pochu> persia: I'll reboot to see if it fixes it. Restarting alsa-utils didn't help.
<persia> pochu: Rebooting shouldn't do anything restarting alsa-utils didn't do (unless you have a new kernel or libc or something).
<pochu> persia: lol, it works now. But the notification has appeared after the reboot! o.O Maybe I did upgraded it this morning too, since there were 3 uploads.
 * pochu looks at dpkg.log
<pochu> Yeah, I updated alsa-utils and libc6 a couple of hours ago :/
<pochu> Anyway it's fixed now. Sorry for the noise though.
<josesanch> persia: Hello. Today is revu day.. what means?
<Hobbsee> means that it's the day for me to avoid irc.
<josesanch> hehe.. But means that motus are reviewing packages? it isn't?
<effie_jayx> lol @ Hobbsee  dodging IRC
<Hobbsee> josesanch: yes.  which means that it's a very good time to play inactive, if you don't want to review anything :)
<zul> Hobbsee: it is the weekend afterall :)
<Nafallo> Hobbsee: you fail in that regard ;-)
<Hobbsee> zul: i'ts monday now :(
 * Hobbsee has to go to work today, too :(
<zul> Hobbsee: well sucks to be you then :)
<Hobbsee> it does.  it does
<Hobbsee> so, when's shooting people beocme legal?
<stgraber> persia: updated package on revu http://revu.ubuntuwire.com/details.py?upid=1228
 * pochu just got greasemonkey working in FF3 :)
<Hobbsee> pochu: it always worked, didn't it?
<pochu> If you change maxVersion from 2.0.0.* to something like 3.0.1.* then yes ;)
<mok0> What is the standard suffix for a documentation package? I see both *-doc and *-docs packages
<pochu> I think -doc
<StevenK> steven@liquified:~% apt-cache search doc | grep -ce '-doc '
<StevenK> 907
<StevenK> steven@liquified:~% apt-cache search doc | grep -ce '-docs '
<StevenK> 29
<mok0> StevenK: Heh, that settles it :-)
<StevenK> You'll use -docs then, since it's the underdog?
<mok0> underdoc ;-)
<StevenK> Wah!
 * StevenK pelts mok0 with rotten vegetables
 * mok0 docs
<StevenK> And it gets worse
<mok0> ... and that's a doc'ed fact
<josesanch> Anyone want to review my package? http://revu.tauware.de/details.py?package=gnomecatalog
<mok0> getting a weird error message from dpkg-gencontrol: http://paste.ubuntu.com/3524/
<DktrKranz> mok0, missing comma
<mok0> DktrKranz: I did not put libc in there.
<mok0> Depends: dpkg
<mok0> (because an empty Depends: also croaks)
<StevenK> mok0: Paste the Depends line from the source?
<DktrKranz> if Depends: is empty, you should omit it
<StevenK> Right. Depends is perfectly sensible to omit in certain circumstances
<mok0> It's a package of text files. The other has .html docs
<mok0> Arrrrrg. Forgot comma :-/
<josesanch> Can i help reviewing any package?
<the_belgain> hi there, i've created a package which i'd like to get reviewed
<the_belgain> this is my first one, should i upload it straight to REVU or get someone here to take a look over it first?
<Hobbsee> persia: clearly you need to review faster!
<Hobbsee> the_belgain: go straight to REVU, then give the link here
<the_belgain> ok, thanks - i've just added myself to the universe contributors team - do i need someone here to resync the REVU uploaders keyring?
<mok0> persia: what's this about rfc822 being deprecated?
<juliank> Bazaar, Git, Mercurial: small benchmark and branch sizes at http://jak-linux.org/tmp/vcs-performance.pdf
<LucidFox> the_belgain> I think the keyring is automatically resynced at certain times, but you can ask for it to be synced immediately
<the_belgain> i've uploaded a package and it seems to have worked fine
<the_belgain> ah, looks like i might have spoken too soon - i can't log into the REVU page with my email address
<LucidFox> the_belgain> Normally, packages appear on REVU at most within ten minutes of upload - on even minutes
<LucidFox> That is, hh:10, hh:20, etc.
<the_belgain> they should all appear on the frontpage then?
<LucidFox> If REVU accepts your key, then yes
<LucidFox> What is the package name? (Disclaimer: I'm not a MOTU.)
<the_belgain> dput reported that the upload was successful, so i assume it's gone in: http://paste.ubuntu-nl.org/51776/
<the_belgain> fuppes
<LucidFox> Wait until 15:30 UTC
<sistpoty> hi folks
<LucidFox> sistpoty> Welcome
<sistpoty> hi LucidFox
<LucidFox> the_belgain> Apparently it didn't upload
<LucidFox> Could you check your mail?
<the_belgain> yeah, it doesn't seem to be there
<the_belgain> nothing in my mail yet
<jpatrick> there are some problems with uploads disappearing
<LucidFox> jpatrick> Could it be because the keyring hasn't been resynced?
<the_belgain> shall i just give it 24 hours and reupload it tomorrow?
<sistpoty> problems uploading to revu?
<jpatrick> LucidFox: what are we talking revu or ppa?
<LucidFox> REVU
<mok0> sistpoty: seems rather slow
<josesanch> ppa is not working for me
<sistpoty> mok0: sparky is not the fastest box :/
<mok0> sistpoty: what is it?
<mok0> sparc?
<josesanch> but revu works for me
<sistpoty> mok0: cpu             : TI UltraSparc IIi (Sabre)
<guest22> Any MOTUs here willing to review package photoml (http://revu.tauware.de/details
<guest22> .py?package=photoml)? It's already been advocated once (the previous upload, at least), so it should be very close to being acceptable.
<sistpoty> LucidFox, the_belgain: what package didn't make it to revu?
<guest22> Oops, that URL should be http://revu.tauware.de/details.py?package=photoml
<LucidFox> sistpoty> fuppes
<LucidFox> the_belgain> Are you sure you uploaded the .changes file?
<sistpoty> the_belgain: it's there but got rejected... I'll import your key and give it back in a few minutes
<sistpoty> the_belgain: should appear on revu with the next cron run
<the_belgain> hi, sorry i'm back
<the_belgain> so did it get rejected because my key hadn't made it in yet? in which case should i try tomorrow?
<the_belgain> or is the package already queued until the next cron run?
<josesanch> Any MOTUs would review my package? http://revu.tauware.de/details.py?package=gnomecatalog
<pochu> We need a lintian update in REVU :)
<sistpoty> the_belgain: your key wasn't synced yet... I imported your key and put the package back in the incoming queue, so it should appear any minute now ;)
<the_belgain> great, cheers
<sistpoty> the_belgain: it's on revu now ;)
<the_belgain> excellent - this is my first package; does anyone fancy taking a look?
<mok0> When I install sbuild, it creates an entry in /etc/group, but the gid is already assigned to a user.
<mok0> the_belgain: I am not a MOTU, but I can take a quick look
<the_belgain> that would be helpful, thanks
<mok0> the_belgain: in debian/rules, get rid of the boilerplate comments at the top
<the_belgain> incidentally, one of the things i was unsure about was that some of the runtime dependencies i had to add manually myself (see the debian/control file) as they weren't picked up by dh_shibs
<mok0> the_belgain: I'll get to control in a minute
<mok0> the_belgain: in rules, in the clean rule, use the construction suggested by lintian
<josesanch> the_belgain: build-depends in libfaad2-dev witch is replaced by libfaad-dev
<mok0> the_belgain: in rules, get rid of the commented # dh_* lines
<mok0> the_belgain: in copyright, get rid of the line "<Put the license..."
<josesanch> the_belgain: distclean gives an error http://paste.ubuntu.com/3525/
<mok0> the_belgain: in control, wrap lines so they display nicely in 80 chars
<the_belgain> josesanch: is libfaad-dev introduced in hardy?  on gutsy i there doesn't seem to be a libfaad-dev in synaptic?
<josesanch> Yes.. in hardy there isn't libfaad2-dev
<mok0> the_belgain: I think section:multiverse is wrong
<the_belgain> i thought it needed to be multiverse because it pulls in lame, which is in multiverse?
<LucidFox> the_belgain> yes, libfaad-dev is introduced in hardy
<LucidFox> libfaad2-dev was removed from hardy
<the_belgain> new packages should be build against hardy right - should i dist upgrade my pbuilder environment then?
<josesanch> in changelog fuppes (0+svn578-1) should be fuppes (0+svn578-0ubuntu1)
<mok0> the_belgain: just make a hardy pbuilder. If you're smart, you can have several side-by-side
<mok0> the_belgain: you don't distupgrade a pbuilder
<mok0> the_belgain: in control, use Section: miscellaneous
<mok0> the_belgain: debian/docs: remove NEWS
<mok0> the_belgain: get rid of debian/dirs
<mok0> the_belgain: debian/changelog: go to launchpad, create a needs-packaging bug, assign it to your self. Put the bug number you recieve in changlog, like this: (LP: #nnnnnn)
<mok0> the_belgain: are you there?
<the_belgain> ok - i'd already raised a bug, i'll add it to changelog
<the_belgain> yes i am here - thanks a lot for all the feedback; i'm incorporating it at the moment
<mok0> the_belgain: cool, I cant create a comment on revu
<josesanch> create an empty dir /usr/libexec
<mok0> then you should put that in debian/dirs ^^^
<mok0> the_belgain: good work
<the_belgain> is the /usr/libexec comment aimed at me?  why is that needed?
<josesanch> the_belgain: yes
<josesanch> the_belgain: I thinks is not needed, but is created.
<josesanch> the_belgain: the dir is empty
<mok0> the_belgain: debian/dirs is for empty dirs you want created, and that are not created by the build
<mok0> the_belgain: you rarely need it
 * sistpoty is off again... cya
<the_belgain> but i should add it in here anyway?
<mok0> the_belgain: only if you need it created as an empty directory
<mok0> the_belgain: is is for plugins or so?
<the_belgain> any ideas as to why i needed to manually add Depends: for liblame, libflac, libmpcdec, libfaad?
<mok0> the_belgain: is your code linked to those libs?
<RainCT> I've just seen there's a Wordpress package in the repos... is there also Wordpress MU?
<the_belgain> mok0: it looks like not
<mok0> the_belgain: why do you need these packages then?
<bddebian> Heya gang
<the_belgain> well i'm wondering whether they should be being linked in - lame is definitely used for transcoding
<mok0> the_belgain: if fuppes spawns a process that runs lame as a encoder, you should depend on the lame binary, not the library
<mok0> the_belgain: libfaad2-dev does not exist in hardy
 * mok0 fires up his gutsy pbuilder
<the_belgain> fuppes doesn't need the lame binary installed - compiling from source with just the dependencies pulled in by liblame-dev (i.e. liblame0-dev, but not lame) works
<mok0> I see
<the_belgain> see eg. http://fuppes.ulrich-voelkel.de/wiki/index.php/Compiling_on_Linux
<the_belgain> mok0: i've now fixed up libfaad2-dev (to be libfaad-dev) - i'll set up a hardy pbuilder and check it works
<crimsun> pochu: there were no functional changes in the alsa uploads yesterday
<crimsun> pochu: they were strictly to make using PulseAudio easier
<crimsun> pochu: please attempt to reproduce the error by erasing ~/.asoundrc (and /etc/asound.conf if it, too, exists), logging out and back in, and using totem/RB
<the_belgain> mok0, josesanch: i'm uploading an updated fuppes package incorporating all the suggested changes, so that i don't get similar feedback from anyone else reviewing it
<mok0> the_belgain: the fuppes package also contains development libraries, which it shouldn't
<mok0> the_belgain: in debian/ create a file name fuppes.install, that lists all the files that should be included
<RainCT> Does anyone know if X-KDE-SubstituteUID=true (in a .desktop file) work in Ubuntu (GNOME)?
<mok0> the_belgain: you don't need libfuppes.a, libfuppes.la, libfuppes.so,
<the_belgain> so the fuppes.install file should contain the list of installed files, with those ones pruned out
<the_belgain> ?
<mok0> it should contain "usr/bin/", "usr/lib/libfuppes.so.*" and that's it
<mok0> the_belgain: and you should write manpages for fuppes and fuppesd
<josesanch> the_belgain: Ok. i'll review again.
<the_belgain> surely the fuppes.install needs fuppes and fuppesd too?
<mok0> the_belgain: it is enough to list the directory they're in
<the_belgain> ok
<mok0> without the leading slash
<mok0> the_belgain: but then you need to install into debian/tmp, so in rules, change
<mok0> DESTDIR
<the_belgain> do you mean "usr/lib/libfuppes.so*" or "usr/lib/libfuppes.so.*" above?
<mok0> the latter
<mok0> libfuppes.so is only needed for linking
<mok0> i.e. developement
<mok0> s/lope/lop/
<pochu> crimsun: can't reproduce it (there was a ~/.asoundrc.asoundconf too, but I didn't remove it).
<the_belgain> ok.  should I add an ubuntu / motu dev list to the maintainers list? dpkg-buidpackage is suggesting i do?
<pochu> crimsun: should I try removing it too?
<mok0> Yes
<crimsun> pochu: ~/.asoundrc.asoundconf is not used without ~/.asoundrc  (the latter includes the former)
<mok0> the_belgain: Put this: Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com
<pochu> crimsun: ok
<crimsun> pochu: thus, removing the former is unnecessary and demonstrates that neither alsa-lib nor alsa-utils affected the symptom
<crimsun> or effected, rather.
<mok0> the_belgain: .. and put yourself in XSBC-Original-Maintainer:
<the_belgain> done, thanks
<the_belgain> i've got to go now; thanks again for all the help and i've uploaded an updated package with all these changes
<mok0> the_belgain: https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#head-8c0f73c5468e3df4abfafb4cf121ed1d226e5a92
<the_belgain> does REVU produce binary debs of submitted packages?
<ScottK> the_belgain: No
<mok0> Yo ScottK
<ScottK> Heya
<mok0> ScottK: Did you guys decide on the new member of the Council?
<ScottK> mok0: There was mail on the nomination process to (IIRC) the MOTU ML.
 * mok0 didn't read mail today
<pochu> mok0: https://lists.ubuntu.com/archives/ubuntu-motu/2008-January/003008.html
<mok0> pochu: thx
<imbrandon> are there any nominations yet?
<imbrandon> btw moins all
<pochu> hey imbrandon, and not that I know of
<imbrandon> crimsun: quick question about sound ( sorry, dont know a better source to ask ) , if i aoss wrap a program, do i have to do anything special to other native alsa apps?
<pochu> Hmm well I'm not a member of -council so I won't know it ;)
<imbrandon> pochu: thanks
 * imbrandon wonders how long the terms are, i would consider nominating myself IF it was only a 1 year term, i dont want to make a longer term commitment atm
<pochu> imbrandon: you can step down at any moment, can't you? :)
<imbrandon> pochu: yea
 * pochu likes the new proposal better than the old one, but wonders whether nominating privately so the council and the TB evaluates the nominations is a good or a bad idea.
<pochu> Maybe those evaluations should be done by the team itself...
<LucidFox> Does pbuilder use debuild, or does it call dpkg-buildpackage directly? (Not like I care, but I'm writing a Wikipedia article on the Debian build toolchain)
<imbrandon> LucidFox: afaik it calls dpkg-buildpackage , but i would verify that in the source to make sure
<crimsun> imbrandon: aoss is solely for OSS apps.
<imbrandon> right , i'm trying to make an oss only app play nice with my system
<imbrandon> ( TeamSpeak )
<imbrandon> so i figured the easy way was to wrap it in aoss
<imbrandon> correct ?
<crimsun> yes.  However, TS is a real PTA.
<crimsun> PITA*
<imbrandon> hehe yea, i've noticed
<crimsun> you _may_ have luck with telling the oss emulation to skip using alsa-lib plugins
<imbrandon> i even thought about running it in wine, just to let wine handle the abstration
<imbrandon> abstraction*
<imbrandon> TS3 is supose to fix all this, but that could be ages away
<geser> pochu: the council will forward all nominations (with added comments) to the TB and doesn't do any selection
<crimsun> e.g., # echo "TS_executable 0 0 direct" > /proc/asound/card0/pcm0[pc]/oss
<pochu> geser: so the TB will do it, right? At least that's what I understand.
<pochu> geser: Otherwise it seems a bit stupid to me :)
<imbrandon> crimsun: should i try running it like that ?
<crimsun> imbrandon: you'd need to try that and then execute TS
<geser> pochu: yes, but I don't know how they will do it
<crimsun> imbrandon: that, however, is only for OSS and not aoss
<imbrandon> ok , and the latter wrapped in aoss correct?
<imbrandon> ohh ok
<crimsun> imbrandon: _and_ you'd likely lose software multiopen
<imbrandon> multiopen ?
<crimsun> commonly incorrectly called "hardware mixing"
<imbrandon> basicly i just want to be able to use a game and TS at the same time, the game is alsa so no issues there
<pochu> geser: I mean that it might make more sense if it was the team itself who did the selection, and not the TB, since we know ourselves better than the TB do (although I guess that's what the comments from the council are for :) )
<imbrandon> crimsun: ahh
<imbrandon> yea i doubt i have any kind of hardware mixing, i'm using whatever is built onboard my MB
<pochu> geser: but this is much better than it was before (thanks ScottK ;)
<LucidFox> imbrandon> Doesn't PulseAudio handle it?
<LucidFox> with padsp for OSS applications
<imbrandon> hehe ( not even sure what card it is tbh, it "just works" )
<imbrandon> some kinda nvidia card using ac97 drivers i'm guessing , but i dont even know how to check, sound is one of my weakest points
<imbrandon> s/one of/definately
<crimsun> LucidFox: it doesn't work any better.
<geser> pochu: if the MC does the selection then it it like before where. the new proposal tries to avoid it that the mc selects the new proposed members
<crimsun> (padsp is equivalent to aoss.)
<crimsun> imbrandon: if you want to be adventurous, probably use OSSv4
<imbrandon> crimsun: i dont mind being adventureous hehe
<imbrandon> s/e//
<pochu> geser: yeah, now it's the team members who nominate themselves, but I'm not sure I like the TB doing some filtering, and the nominations being private...
<imbrandon> really i'm looking for the easest awnser, but really i dont care, its sunday and i have not much else to do :)
<imbrandon> hrm is OSSv4 non free ( not that i'm against that, just curious from the looks of it )
<imbrandon> crimsun: ^
<imbrandon> free as in code, not beer
<geser> pochu: let's see how this ends. the process still can be improved if we see that it still has some issues, but it's an improvement
<geser> pochu: the idea behind the private nominations was to prevent a public flaming of some nominees
<crimsun> imbrandon: no, it's Free.
<pochu> geser: yeah, that's what I thought, and that's why I said 'I'm not sure' instead of 'I don't like' ;)
<jonnymind> hello all.
<pochu> geser: but I agree this looks better. Let's see how it goes as you said :)
<crimsun> imbrandon: it's dual-licensed GPLv2 and CDDL.  See http://developer.opensound.com/sources/
<crimsun> err, CDDLv1
<jonnymind> I am rewriting the debian/copyright. I would like to know; the "copyright" notice (year) refers to the package or to the upstream software?
<imbrandon> upstream
<pochu> Upstream. You can add a line regarding the packaging at the end of it. (dh_make adds it)
<imbrandon> most everything except the top and bottom lines in debian/copyright should refer to the upstream
<imbrandon> top == debinized by ..... , bottom == as pochu said
<jonnymind> And the license that must be reported in the debian/copyright file is the license of the package or the license of the upstream software?
<imbrandon> jonnymind: both asre refered to in that file, but the package lic is normaly only a one liner at the the bottom
<imbrandon> the rest is all about upstream
<jonnymind> I see.
<imbrandon> lemme see if i can find a good example, ( note that debian is looking at making a new format policy , but that should matter not atm )
<somerville32> Is anyone working on the queue today? I have four in there.
<jonnymind> imbradon: if I am not wrong, python is not released under GPL license.
<imbrandon> ... ok? how does that impact what i said ?
<somerville32> I'm pretty sure Python isn't released under the GPL
<somerville32> jonnymind, and try not to use double negation :P It can get confusing.
<jonnymind> double? where?
<somerville32> "if I am _not_ wrong, python is _not_ released under GPL license."
<jonnymind> This is not double negation. These are two sentences.
<imbrandon> a comma dosent make a new sentance :)
<imbrandon> anyhow no biggie, i got your point
<pochu> I think that's correct, isn't it?
<jonnymind> imbradon: two verbs does.
<jonnymind> imbradon: may I use python debian/copyright as a template?
<imbrandon> jonnymind: no, a sentance is based on punctuation only, even if its a run on sentance, or wrong, like this one, its still one sentance.
<somerville32> "if I am right, python is not released under GPL license"  is much clearer and removes the double negation
<imbrandon> jonnymind: lemme look
<imbrandon> one moment
<jonnymind> it seems python debian/copyright would be plainly rejected by persia.
<imbrandon> that doesnt look to be a good example, although it follow policy , its messy
<jonnymind> Great.
<imbrandon> jonnymind: basicly its like this ....
<imbrandon> the first line in debian/copyright is "this package was debinized by : blah vopyright blah" refering to the package
<imbrandon> the last line is the packaging copyright and lic again, eg if the "packaging" is gplv2 or such
<imbrandon> everything inbetween is upstream
<crimsun> any MOTU hopefuls searching for a quick source package update?
<somerville32> crimsun, oi
<crimsun> (I'll be in #ubuntu-classroom)
<imbrandon> jonnymind: clear ?
<imbrandon> jonnymind: take a look at apt-mirror if you want an example, it follows that format and i maintain it ( and am *part* of upstream ) so i'm familiar with it
<jonnymind> ok
<imbrandon> it is not in the new debian format for lenny , but its what debian and ubuntu currently follow
<josesanch> Would any MOTUs review my package? http://revu.tauware.de/details.py?package=gnomecatalog
<imbrandon> if you want to go ahead and use the new new enew format ( e.g. whats being encouraged to be used by new packages somming into debian via debian-mentors lemme get the url
<imbrandon> )
<imbrandon> http://wiki.debian.org/Proposals/CopyrightFormat
<imbrandon> jonnymind: ^^
<jonnymind> imbradon: the "was downloaded by" refers to the package or to the upstream sources?
<imbrandon> "was downlaoded from" not by
<imbrandon> if its by its a typo
<imbrandon> and yes it refers to upstream
<jonnymind> es, sorry, by
<jonnymind> ok
<imbrandon> e.g. where the source can be found outside debian/ubuntu , e.g. sourceforge etc etc etc
<imbrandon> if someone went looking
<imbrandon> It was downloaded from http://apt-mirror.sourceforge.net/
<imbrandon> Copyright 2005,2006,2007  Dmitry N. Hramstov <hdn@nsu.ru>
<imbrandon> Copyright 2007  Brandon Holtsclaw <brandon@imbrandon.com>
<imbrandon> Upstream Authors: Dmitry N. Hramtsov <hdn@nsu.ru> Brandon Holtsclaw <brandon@imbrandon.com>
<imbrandon> License:
<imbrandon> This program is free software; you can redistribute it and/or
<imbrandon> gah
<imbrandon> sorry
<imbrandon> wrong window, ment to pastebin
<imbrandon> anyhow see the "upstream" url
<pochu> persia, ember: vinagre 0.4 in Debian NEW
<imbrandon> crimsun: is that root command you pasted litteral for any card ( the proc path )
<imbrandon> or do i need to find my card
<dfiloni> pochu: congratulation, I saw now you are a motu :)
<jonnymind> persia: ping
<jonnymind> last week, persia told me I should have added a -dbg release for my software or leave debug symbols in the release.
<jonnymind> I'd prefer to give a separate -dbg package for various reason.
<jonnymind> My question is: is it ok if this package conflicts with the non -dbg package?
<jonnymind> I.e. if you can install one or the other, but not both?
<ScottK> pochu: Thanks.
 * ScottK agree the MC process is likely better, but has room for further improvement.
<somerville32> ScottK, Do you plan to run?
<ScottK> somerville32: No.
 * ScottK has been sufficiently outspoken recently that I think running now would be divisive.
<ScottK> Maybe some other time.
<jonnymind> Sorry for asking such a basic question, but what's the command to run watch again?
<jonnymind> (i suppose "watch")
<jonnymind> *something with "watch"
<jonnymind> Ok, it was uscan
<crimsun> imbrandon: it's a literal command
<LucidFox> Is there any advantage whatsoever of using simple-patchsys over cdbs+dpatch?
<ScottK> twiki could use some security love if anyone's interested...
<somerville32> ScottK, how much love?
<imbrandon> LucidFox: maintainer prefrence
<ScottK> somerville32: Look at the latest Hardy upload debian/changelog
<ScottK> LucidFox: No 00list to keep up to date.
<pochu> imbrandon: so at the end we will see who's up for election at https://wiki.ubuntu.com/MOTU/Council :)
<jonnymind> imbradon:I read your notice about "there is already a package named falcon.
<jonnymind> However, the notice is imprecise.
<jonnymind> the bug "needs packaging" for my project has been opened in 2007, while the other package with the same name was opened in 2008.
<jonnymind> Moreover, I was negotiating with those person about the package and binary names. We were talking about what to do, then the conversation stopped and the other package has been started.
<jonnymind> I think we should discuss a bit the namespace question.
<jonnymind> And also, frankly decide what to do basing on an objective criterion.
<jonnymind> imbradon:?
<crimsun> hmm, we need to do something about paman spewing menu items in Applications>  _and_  System>Preferences
<crimsun> well, I think I've addressed Applications> , at least
<jonnymind> persia: ping
<jonnymind> pochu: ping
<mok0> jonnymind: persia's east asia time, so he's probably sleeping by now
<jonnymind> Oh. So the nick persia isn't random :-)
<pochu> mok0: I thought he was in America
<pochu> jonnymind: don't send contentless pings
<mok0> he's in japan
<pochu> (pong)
<jonnymind> pochu: ok; the content is right above.
<mok0> jonnymind: why don't you just call it "falcon-repo-manager"
<jonnymind> mok0: mine is the language.
<pochu> mok0: this is a programming language ;)
<jonnymind> THAT one is the repo manager.
<mok0> jonnymind: ah :-)
<mok0> Anyway, I like descriptive package names
<jonnymind> uhm... descriptive as "python" "perl" and "ruby"?
<mok0> hehe
<jonnymind> I like them too. And I like equality and fair treatment of equivalent merits.
<mok0> programming languages are ok, so yours should be "falcon" and the other one "falcon-repo-manager"
<mok0> but it will be confusing anyway, because users will conflate the two packages
<crimsun> well, if you really want descriptiveness, you should consider "falcon-lang"
<jonnymind> I can go for falconpl; I already told it.
<jonnymind> it's also the name of the site.
<jonnymind> But changing the name of the interpreter (which is ELF c code) is a bit different.
<jonnymind> Would cause several hundrets changes needed in docs, i.e.
<mok0> jonnymind: you need a Conflicts:
<jonnymind> mok0: I don't see why if you install a language you should conflict with a package manager written in another langauge.
<jonnymind> But if no other solution is viable, I can do it.
<mok0> jonnymind: it depends what happens when you go "falcon" in the shell
<mok0> if both packages attempt to install a "falcon" binary
<jonnymind> Changing the name of the package is ok. Changing the name of the binary files would cause several days of work to be redone, and distress to the users.
<mok0> exactly
<mok0> so you need a  "Conflicts: falcon" in debian/control
<jonnymind> Fine.
<jonnymind> I will post a falconpl package with that conflict. We'll see what to do at a later stage.
<mok0> jonnymind: good idea
<mok0> jonnymind: but you may want to check out the "falcon" package, to make sure that there actually is a clash of binary names
<jonnymind> It is: we were talking with the person developing the software, that has a falcon script that lanunches python falcon.py
<jonnymind> And that bash script apparently goes in /usr/bin/falcon
<jonnymind> (yet, starting a package with the same name after that we have discussed the thing with the author, and after he said he wasn't like doing packages for ubuntu seems a bit of dirty play, and exploitation of preferential position with packagers, seen from here).
<amarillion> Hello, my package speed-game http://revu.tauware.de/details.py?package=speed-game is ready for review...
<amarillion> ...
<crimsun> amarillion: thanks for the post.  Someone may take a look when s/he has time.
<rulus> I uploaded my package gtkvd http://revu.tauware.de/details.py?package=gtkvd recently too, comments from a Master are greatly appreciated ã
<amarillion> ok, thanks crimsun
<josesanch> amarillion: Hello, do you has lucky with your package?
<somerville32> crimsun, Hi, sorry it took me so long but bug #182677 for paman
<ubotu> Launchpad bug 182677 in paman "Sponsor paman_0.9.4-1ubuntu1" [Low,Confirmed] https://launchpad.net/bugs/182677
<crimsun> somerville32: tweaked & uploaded.  Thanks!
<crimsun> somerville32: (the distribution == hardy, not gutsy)
<somerville32> crimsun, sorry, I used the dch thing and didn't double check what it put in there
<somerville32> I usually don't use dch
<rzr> lionel: hi
<lionel> hi rzr
<rzr> lionel: shouldnt we use requestsync ?
<rzr> did i miss something on https://wiki.ubuntu.com/SyncRequestProcess ?
<lionel> you can use requestsync sure
<lionel> It's about #182659
<rzr> is that html garbage normal ?
<lionel> rzr: no it was not :)
<rzr> yea unicorn
<lionel> and almost unreadable, that's why I changed in a plain text description
<rzr> I guessed that
<lionel> I don't know why you ended with a bad html description
<rzr> but I was afraid i used the tool the wrong way
 * rzr ran requestsync -s unicorn  dapper
<lionel> rzr: you want in Dapper ?
<rzr> yea because I know the driver is wroking w/ dapper kernel
<rzr> not gutsy
<lionel> it will land in hardy
<rzr> anyway it's better than the current one
<lionel> and you need then to backport in dapper (if it build/runs)
<rzr> that's what i did on my PPA
<rzr> but this is an important package for bewan modem owners
<lionel> rzr: as you are the Debian maintainer, I supposed you know the package beter than me :)
<rzr> i wish i knew it more
<rzr> this driver is really a pain in the ass ..
<rzr> lionel: so there is no hope for dapper ?
 * rzr can understand that
<lionel> rzr: once it is in hardy, you can request a backport
<ScottK> rzr: Syncs are only for the current development release (Hardy).  We can backport to Dapper after we have it in the newer release.
<rzr> ok makes sense now
<RainCT> persia: would process-interdiff still make sense in u-d-t?
<pochu> jonnymind: have you just ITP'd falcon in Debian?
<jonnymind> pochu: yes.
<pochu> jonnymind: heh, lucky you, falcon source package isn't in Debian ;)
<jonnymind> How strange.
<jonnymind> Actualluy; when I posted it to Ubuntu, it wasn't in ubuntu too.
<jonnymind> And I offered many times to change its name openly and respectfully of ubuntu philosophy
<emgent> hello there
<pochu> jonnymind: not that strange. Upstream is an ubuntu member, and the packager is an ubuntu developer.
<pochu> hi emgent
<pochu> jonnymind: the funny thing is that you can use falcon name in Debian, but then it won't be synced to Hardy until the conflict is fixed.
<jonnymind> pochu: there isn't any problem: I am already uploading falconpl in REVU. With a Conflict: field.
<pochu> * Package name    : falcon
<pochu> jonnymind: I said it because of that ^
<jonnymind> I said in ubuntu. Not in debian.
<pochu> That's Debian's ITP.
<jonnymind> Yes.
<pochu> So will you call it falcon in Debian?
<jonnymind> Maybe.
<pochu> Heh, ok.
<jonnymind> We could have openly negotitiated /usr/bin/falcon. I was willing to rename the package falconpl.
<jonnymind> The guy had my mail.
<pochu> (that's I find funny) :)
<pochu> +what
<jonnymind> Even if that would have costed me several days of works in updating documentation, scripts, build systems, etc.
<jonnymind> And would have caused problems to my users.
<pochu> That's not neccessary. You can just Conflict with the other falcon.
<jonnymind> Now I will just add Conflict; hope noone feels offended.
<pochu> Not at all. At least not me :)
<ScottK> jonnymind: Why not put your executable at /usr/bin/falconpl/falcon?
<jonnymind> :-)
<jonnymind> ScottK: it wouldn't been found as falcon in path, and it wouldn't be compatible with mac and windows
<jonnymind> And solaris.
<jonnymind> And bsd
<ScottK> But you can put it there just in the Debian package and add the dir to the path
<ScottK> Just move it there in debian/rules
<jonnymind> Should I mangle the system path dir of hudred thousand users?
 * ScottK isn't sure.  Just throwing out something else to consider
 * ScottK would need to read FHS again to be sure
<jonnymind> However, ubuntu MOTU can find any reasonable way to fix the clash.
<pochu> Or /bin/falcon
<pochu> Anyway, this is what Conflicts was created for, isn't it?
<jonnymind> I don't want to stay in charge of the packages forever: we'll find professional packagers as the project grows. Gentoo and Fedora packaging is currently being submitted too.
<jonnymind> Yes.
<pochu> I'm just thinking that it will be a pain to maintain it if it's called falcon in Debian and falconpl in Ubuntu.
<jonnymind> I cannot possibly stay in charge of all the packaging, and I don't really want to.
<jonnymind> pochu: it is not the only case.
<jonnymind> There are many packages shifting names between distros.
<pochu> jonnymind: the other cases are probably a pain to maintain
<pochu> jonnymind: but we sync packages from Debian
<jonnymind> pochu: I am sorry about that.
<jonnymind> I am sure we'll find a solution.
<jonnymind> If we talk.
<pochu> So if you package it in Debian, it can be synced to Ubuntu and you don't need to package it twice
<pochu> But if there's already a falcon source package in Ubuntu then it won't be synced to not overwrite it.
<jonnymind> pocuh: again, I am sorry about that.
<jonnymind> I am sure a frank and open talk would have solved this problem before it was born, and I have started the talk and always shown very collaborative.
<jonnymind> No, I have BEEN very collaborative.
<ScottK> jonnymind: Conflicts is more usually used for packages that provide equivalent functionality.
<jonnymind> ScottK: that is absolutely true.
<ScottK> jonnymind: Have you discussed this with imbrandon?
<pochu> jonnymind: (I'm not blaming you, just in case I'm not expressing well)
<Nafallo> Seveas and imbrandon.
<TheMuso> s/c
<TheMuso> ugh damn keyboard
<jonnymind> ScottK: No, I have discussed with the original author of the other falcon.
<pochu> That's Seveas.
<jonnymind> Well, I have started the discussion and replied to its e-mail.
<jonnymind> In which he stated he wasn't going to make a package.
<ScottK> jonnymind: Right, and he didn't
<pochu> (which is true, the package was done by imbrandon)
<pochu> ScottK: you beat me
<jonnymind> Ah.
 * pochu is eating pizza, so he's not that fast ;)
<ScottK> jonnymind: My concern right now (not having a great interest in either package) is that if you upload your package as falcon to Debian, then it's going to cause trouble between Ubuntu and Debian that it would be better to avoid.
<jonnymind> So Imbradon knew there was a falcon package made in december.
<jonnymind> so it's comment here:
 * Nafallo steals pochu's pizza so he can be fast again
<jonnymind> http://revu.tauware.de/details.py?package=falcon
<Seveas> packages for 'the other falcon' have existed since 2006
<pochu> Nafallo: that would be the last slice!
<jonnymind> seems a bit interesting...
<pochu> Seveas: not in the Ubuntu repo
<ScottK> Hi Seveas.
<jonnymind> Eh? -- where?
<Seveas> and imbrandon intended to upload them since mid 2007
<Seveas> or even earlier
<jonnymind> Ah... now I understand.
<ScottK> jonnymind: However this is going to get sorted out, please sort it out here and don't upload a package with the same name as Seveas's falcon to Debian.  It's just going to cause Debian/Ubuntu confusion.
<jonnymind> because, othwrwise ... https://launchpad.net/ubuntu/+source/falcon
<Seveas> imbrandon will upload my falcon to debian as well
<Seveas> at least he said he would :)
<jonnymind> Seveas: again; the package here is named falconpl now.
<jonnymind> That closes the question.
<Nafallo> both packages use /usb/bin/falcom? :-)
<Nafallo> s/m/n
<jonnymind> I do.
<ScottK> jonnymind: Except your Debian ITP is for a package named falcon, so it doesn't close the question at all.
<pochu> Nafallo: and falconpl conflicts with falcon
<jonnymind> ITP isn't related with a direct upload.
<jonnymind> It's on the mentor's side to decide for packages.
<Nafallo> pochu: without being the same thing? that's just ugly :-/
<jonnymind> They will decide the name of the package as well as other details.
<ScottK> jonnymind: ITP has the package name.
<jonnymind> ScottK: Mentors makes packages, so they decide.
<ScottK> Ideally a sponsor will just review the work, decide it's good, and upload.  Don't leave decisions to the sponsor.
<jonnymind> ScottK: And if they decide that it's not good, they won't.
<ScottK> jonnymind: Yes, but your ITP says you are making a package named "falcon".
<Nafallo> I would rename that ITP...
 * ScottK would hope jonnymind will.
<ScottK> Having a consistent package namespace between Debian and Ubuntu is very important.
<pochu> jonnymind: do you know the difference between ITP and RFP? Because it looks to me like if you were waiting for someone else to package falcon...
<jonnymind> ScottK: I am willing to do it. I may do it. I will do it, if everyone agrees.
<ScottK> jonnymind: What agreement is needed?  Can't you just do it?
<jonnymind> pochu: No, I have already the package sitting here. But Mentor role is a bit more extensive than MOTU roles, so it seems.
<jonnymind> I.e. I cannot upload the package. It must be taken by the mentor, possibly changed and then uploaded.
<pochu> Nafallo: at least Seveas's falcon isn't written in jonnymind's falcon ;-)
<Seveas> pochu, rofl
<Nafallo> pochu: haha
<Seveas> that would be sick :)
<Nafallo> conflictorama :-)
<ScottK> jonnymind: Depens on who's sponsoring in Debian, it's often a lot like it is here where they give you comments until they are happy.
<Seveas> couldn't have happened either, my falcon is much older
<ryanakca> hmm... what would you call the debian packaging structure if you were to put it on a resume? "Python, CSS, HTML, Debian Packaging System" ?
<ScottK> Seveas: What is your falacon written in?
<Seveas> Python
<Seveas> and Django :)
<Seveas> (which is Python)
<awalton__> Seveas, why is it called falcon?
 * awalton__ is killed by rampaging curiosity
<Seveas> awalton__, because I liked that name and it didn't conflict with anything in Debian/Ubuntu back in 2005 when I started
<awalton__> ah.
<jonnymind> Well, Seveas. Falcon p.l. was started back in 2003.
<awalton__> figured it had something to do with pythons being snakes and falcons....
<jonnymind> And there was a site.
<Seveas> jonnymind, search for falcon on google, you won't find yours or mine
<Seveas> so Debian was my guideline for conflicts
<jonnymind> falcon script
<Seveas> doesn't cound, one would need to guess it's a language
<RainCT> good night
<jonnymind> Well; up to firsts of december 2007, ubuntu and debian was mine.
<Nafallo> haha
<Seveas> lol
<jonnymind> And still, there was no conflict.
<Nafallo> can't even find it on google linux first 10 :-)
<Nafallo> oh well
<Nafallo> we already have /usr/bin/falcon, so please don't name it the same or people will need to choice which package they want :-)
<jonnymind> we who?
<Nafallo> Ubuntu
<jonnymind> I have ubuntu.
<jonnymind> and I didn't have /usr/bin/falcon. Nor I have now.
<Seveas> !info falcon hardy
<Nafallo> ehrm
<ubotu> Package falcon does not exist in hardy
<Seveas> ubotu, ?
<Nafallo> someone didn't get the point... :-)
<Seveas> heh, needs to update :)
<ion_>     falcon | 2.0.4-0ubuntu1 | http://archive.ubuntu.com hardy/universe Sources
<lionel> binary is still in new
<jonnymind> Oh
<jonnymind> As mine.
<Nafallo> jonnymind: really?
<Seveas> no
<Nafallo> is falconpl even source new anywhere?
<Seveas> no :)
<jonnymind> As someone may suspect, I must FRANKLY and OPENLY admit that didn't get very well the fact that, while I was working on the topic and finding a solution, someone (knowning the state of the things, as it/they was informed of the fact) forced this situation with an unilaterary act.
<Nafallo> that's what I thought then :-)
<jonnymind> http://revu.tauware.de/details.py?package=falcon
<jonnymind> Comments for upload of December 06 18:40   (debdiff)
<jonnymind> bug #174470
<ubotu> Launchpad bug 174470 in ubuntu "[needs-packaging] Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
<Nafallo> can't see any comments on that one.
<Nafallo> the comments where made 1st and 11th of January
<jonnymind> But the wrost thing is that I was openly available to do any change, and was here almost every day. And I offered a solution to Seveas in the first place.
<jonnymind> And?
<jonnymind> the package was uploaded in december.
<jonnymind> After days of discussions.
<jonnymind> In which I was even told "no, don't use falconpl. Falcon is OK"
<jonnymind> here by motus.
<jonnymind> It was ME that went around asking again and again how to solve it.
 * Nafallo adds comment on the bug :-)
<pochu> Nafallo: there were a lot of comments here on IRC, as I couldn't comment on REVU by then
<jonnymind> after I have been told that someone remembered about an utility with that name. So, I am sorry, I cannot be blamed as responsible for the situation.
<Nafallo> did anyone?
<jonnymind> Having that package uploaded by a person that knew both the situation and my availability to sort out problems, sorry, doesn't seem very ubuntu policy compliant.
<Nafallo> anyway. as I see it falcon is already in the repos. it would be hard to change that one now.
<jonnymind> persia and pochu reviewed the package in december.
<pochu> Nafallo: no, it isn't.
<pochu> Nafallo: you can remove it from there.
<Nafallo> pochu: source is.
<pochu> Nafallo: can't you remove source from soyuz?
<pochu> (I'm not saying it should be removed, but it's possible to change it)
<Nafallo> pochu: dunno. but it's source made it to the archive already.
<Nafallo> pochu: it's on the mirrors :-P
<pochu> Nafallo: I think that doesn't matter.
<pochu> And there aren't binaries, so even easier.
<Nafallo> https://edge.launchpad.net/ubuntu/+builds?build_text=falcon&build_state=all
<Nafallo> there is binaries :-)
<jonnymind> ppl, sorry for having stolen your time. I'd like to return to the technical aspects.
<jonnymind> Why I can't make uscan to work?
<jonnymind> I get this error:
<jonnymind> uscan warning: In debian/watch,
<jonnymind>   no matching hrefs for watch line
<jonnymind>   http://www.falconpl.org/downloads/(.*)/Falcon-(.*)\.tar\.gz
<pochu> Nafallo: not in the archive. Needs to be NEW'd
<geser> Nafallo: but only in the binary NEW queue :)
<Nafallo> yea exactly. so there is binaries :-)
<pochu> Nafallo: well there are binaries for jonnymind's falcon. They are in ~/.pbuilder/hardy/result, but there are :P
<Nafallo> pochu: they are not in any kind of queue built from anything in an archive ;-)
<jonnymind> Nafallo: I just have seen your comment.
<jonnymind> Sorry; I retire falcon from ubuntu.
<jonnymind> How can I delete the package?
<pochu> Nafallo: who cares? An archive admin can reject it with one click ;)
<Nafallo> pochu: baah. the can kill xorg as well, with lots more clicks. that's not the point :-)
<Nafallo> jonnymind: huh? it's not in yet.
<jonnymind> I mean, from revu and launchpad.
<pochu> Nafallo: But don't say things can't change just because someone uploaded a package.
<Nafallo> jonnymind: would be so much easier to do what you've already did. rename the package :-)
<pochu> And out of curiosity: a package needs two ACKs to be uploaded to Universe... who did ACK falcon other than imbrandon?
<jonnymind> Nafallo: I am not changing 6 system installation scripts and 300 doc pages for this.
<Nafallo> pochu: *sigh* you probably know exactly what I mean, so why even argue about it? :-)
<jonnymind> Someone will find a way to package falcon when it is included in the other distros.
<Seveas> pochu, could be persia, I did the final checks with them
<jonnymind> I started packaging from ubuntu because I beleived in ubuntu philosophy of respect.
<jonnymind> ...
<pochu> Seveas: I'd be surprised if it was persia since persia was reviewing jonnymind's falcon package.
<pochu> And since there's no REVU upload for it to look at, nor ACK in the needs-packaging bug...
<Nafallo> pochu: I just check my logs. persia :-)
<pochu> Crap.
 * pochu kicks persia :)
<Nafallo> pochu: he found blockers that got fixed before the upload as well
<jonnymind> I understand. If anyone wants the package it's open soruce, so they'll be able to package it.
<jonnymind> Goodbye.
 * rzr updated http://revu.tauware.de/details.py?package=jaaa
<Nafallo> oh well...
<pochu> It would really annoy me if I had a package up for review and then someone else uploaded a package with the same name, so I completely understand him.
 * pochu goes out for a godwalk
<guest22> Any MOTUs here willing to review package photoml (http://revu.tauware.de/details.py?package=photoml)? It's already been advocated once (the previous upload, at least), so it should be very close to being acceptable.
<bddebian> Heya gang
<somerville32> Heya bddebian
<cyberix> I'm looking after first advocate for my package Malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
<bddebian> Hello somerville32
#ubuntu-motu 2009-01-05
<AdamDH> is there an easy way to run a shell script from inside rules?
<coppro> it's a makefile; each line is a separate shell
<coppro> to run a script, just run it as you would from shell
<TheMuso> vorian: Please do not forget to include all changes since the last Ubuntu merge when uploading a merge.
<RAOF> crimsun: Hi!  Is nouveau-kernel-source still on your todo list, or is it time to advertise again.
<RAOF> Nice coincidence with #ubuntu+1
<crimsun> yes, on my TODO
<crimsun> overrun with alsa and pulseaudio bugs, surprise surprise
<RAOF> Shock!
<crimsun> oh, and this alsa-plugins (lib32asound2-plugins) interaction with flashplugin-nonfree on 64-bit is a bit tragic
<crimsun> now that flashplugin-nonfree uses nspluginwrapper forcibly with the 32-bit plugin regardless of installation arch, we have a bit of a mess on Ubuntu
<crimsun> i think what needs to occur is that ia32-libs needs to be fixed by removing alsa-plugins from it
<crimsun> at the same time, it should depend on lib32asound2-plugins
<lfaraone> hey crimsun
<crimsun> otherwise, we've regressed to the release of hardy, where audio is nondeterministically inaudible, and pulseaudio and all other audio apps need to be restarted
<crimsun> hi lfaraone
<RAOF> crimsun: The problem with lib32asound2-plugins is that it's built from a main source, so can't b-d on ia32-libs and so can't build the pulseaudio plugin.
<RAOF> I don't expect ia32-libs to be promoted to main anytime this geological epoch. :)
<StevenK> What does lib32asound2-plugins require from ia32-libs?
<StevenK> Perhaps that needs to be split out too?
<crimsun> apparently alsa-plugins has build-time magic to provide .so symlinks and to copy .pc for pulseaudio and dbus
<RAOF> StevenK: It requires ia32-libs in order to get 32-bit pulseaudio libs to build against.
<StevenK> RAOF: Right, so maybe we need to split out lib32pulseaudio or so ?
<RAOF> Yeah, that'd work.
 * RAOF wasn't thinking of the ogre model when he did the alsa-plugins biarch work.
<RAOF> So, who wants to take the review of nouveau-kernel-source off crimsun's overstreached TODO list?
 * TheMuso will look into bi-arch pulse libs.
<TheMuso> Although I don't look forward to implementing it. :p
<milos_> good morning!
<milos_> how much it usually takes for one package to get sponsored?
<dholbach> good morning and happy new year!
<Hobbsee> hey there dholbach!
<dholbach> hi Hobbsee
<iulian> Hiya dholbach!
<dholbach> hiya iulian
<fabrice_sp> Hi dholbach1 and happy new year also!
<fabrice_sp> oops: dholbach, no dholbach1
<dholbach> hiya fabrice_sp
<fabrice_sp> Now that I'm back from holidays, I will start again to request review for dvsdstyler package at http://revu.ubuntuwire.com/details.py?package=dvdstyler? Is there someone willing to have a look at it? It has already been reviewed by mok0 and siretart
<wikz> I have uploaded a new package for spicebird, would someone like to revu it? spicebird is a collaboration client and it's based on TB3a2. http://revu.ubuntuwire.com/details.py?package=spicebird
<fabrice_sp> wikz, will have a look (even if I'm not a MOTU, I saw some errors in your packaging)
<wikz> fabrice_sp: thank you so much :)
 * Hobbsee does the 'upgrade to jaunty' dance
 * TheMuso corsses his fingers for Hobbsee.
<pwnguin> ive got a question about patches
<pwnguin> i recall seeing that you can put comments in quilt system packages' patches
<pwnguin> is that unique to quilt, or does the standard unified diff format allow comments?
<didrocks> Hi everybody and happy new year \o/
<NCommander> pwnguin, the patch utility ignores anything that isn't proper diffs, so its not quilt specific
<pwnguin> "proper diffs"
<pwnguin> meaning, anything that isn't the header or a chunk?
<pwnguin> ah. the manpage say patch skips leading and trailing garbage, so you can save a message and give it to patch without processing
<huats> morning all
<Hobbsee> morning
 * Hobbsee wonders why a jaunty dist-upgrade installs lilo by default.
<Hobbsee> oh.   recommended by the kernel images. yay.
<orly_owl> the kernel recommends lilo? why?
<Hobbsee> orly_owl: i've no real idea, although i remember hearing something about it being needed for some configurations?
<orly_owl> sounds odd
<Hobbsee> i've asked in -kernel, but might be too early in the day?
<dholbach> Is there anybody who would like to give a session about merging at the Ubuntu Developer Week? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
<dholbach> Is there anybody who would like to give a hands-on session about python packaging at the Ubuntu Developer Week? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
 * directhex hands Hobbsee a fresh copy of elilo
<jpds> thekorn: re: lplib for requestsync: that's great work :)
<thekorn> jpds, thanks, hugdaylist and grab-attachments also done but not pushed yet
<thekorn> jpds, I think massfile is the only one which still depends on launchpadbugs
<jpds> thekorn: It's okay, mark the branch for merging when you think they're ready and I'll copy it across.
<thekorn> jpds, before merging this branch we should think about adding a tool for managing access tokens,
<jpds> thekorn: You write far better python than me :)
<jpds> thekorn: Good point.
<thekorn> managing right now would mean "creating access tokens" right now, but in the future it can also show you all your tokens etc
<dholbach> thekorn: that'd be awesome! :)
<dholbach> thekorn: that should probably be in a separate package - what do you think?
<dholbach> I could imagine that a bunch of packages (not just development tools) would make use of it
<thekorn> dholbach, yes, maybe launchpadlib itself would be the best place for it
<dholbach> james_w: ^ what do you think?
<james_w> I think you are probably right
<thekorn> ok, I will think about such an token management tool later today and write a patch
 * dholbach hugs thekorn
<Hobbsee> directhex: elilo?  haven't heard of that
<directhex> Hobbsee, it's what us cool doodz with itanium use
<directhex> Hobbsee, i.e. for EFI-based bootings
<Hobbsee> ahhh
<Hobbsee> hrm, another open week
<Hobbsee> some of those sessions look interesting
 * Hobbsee hopes logs appear in findable places.
<directhex> doko__, do you have plans to package the new ironpython 2.0?
<doko__> directhex: yes, but python2.6 comes first. go ahead if you want to do the update
<directhex> jms@osc-franzibald:/tmp/IronPython-2.0$ mono ipy.exe
<directhex> IronPython requires .NET 2.0 SP1 or later to run.
<directhex> this is gonna be fun
<doko__> directhex: it's available in jaunty
<directhex> doko__, 2.0?
<directhex> hm, doesn't seem to run
<milos_> would somebody be kind and review my debdiff?
<nhandler> milos_: What is it for? And is it a simple one? (I only have a few minutes)
<milos_> I am not in a hurry so, you can look at it when you have more time
<milos_> nhandler, http://launchpadlibrarian.net/20901340/yagiuda_1.19.5%7Eppa1.debdiff
<milos_> nhandler, it's about 3 lines of code
<nhandler> Is there a bug report?
<milos_> yup nhandler https://bugs.launchpad.net/bugs/312842
<ubottu> Launchpad bug 312842 in yagiuda "yagiuda crashes in Ubuntu Intrepid" [Undecided,Confirmed]
<khashayar> Hi folks. I've been backporting ardour 2.7.1 for hardy and intrepid. It's the first time I attempt to do official backporting. Is there a backporter who could tell me what the next step is?
<nhandler> milos_: Well, looking at the patch, it is not perfect. For one thing, the syntax for closing a launchpad bug is (LP: #312842). Closes is for Debian bugs. Second, you need to get the the patch applied in jaunty before it can get into Intrepid. Third, your version is not correct. You want to look at the version currently in jaunty and just bump the ubuntu revision. You also should filter out the changes to config.sub and config.guess from you
<Laney> you got cut: "from you..."
 * nhandler is starting to hate irssi
<stefanlsd> milos_: to add to nhandler - you have lines showing change where you've changed white space... (dont do that)
<stefanlsd> milos_: we want to make the diff as minimal as possible
<nhandler> http://paste.ubuntu.com/100286/
<nhandler> milos_: Actually, it looks like the package is auto synced from Debian. Is the patch relevant to debian? If so, send the patch upstream
<nhandler> milos_: If not, you can subscribe ubuntu-universe-sponsors to the bug report after making the changes. That will ensure it gets looked at
 * nhandler has to run now
<Hobbsee> nhandler: you want http://scripts.irssi.org/html/splitlong.pl
<maxb> khashayar: https://help.ubuntu.com/community/UbuntuBackports
<milos_> nhandler, I don't know bout Debian. I would search it.
<stefanlsd> nhandler: or, not talk so much :P
<milos_> nhandler, ok I will try to fix this and will send again to ubuntu-universe-sponsors mailing list
<milos_> stefanlsd, about lines with white space, I should just delete those lines from patch?
<khashayar> maxb: Thanks. I've built packages using prevu, and they're currently being built in ppa. Where do I find someone to take a look at them?
<Laney> nhandler: I have a script which automatically splits lines taht get too long if you're interested
<stefanlsd> milos_: yeah, you can do that (or fix your source and redo the debdiff). either way
<Laney> nhandler: Oh, you already got linked, nm
<vorian> khashayar: are they new packages?
<vorian> if so you can upload them to revu http://revu.ubuntuwire.com/
<hyperair> nhandler: i've made the changes you've requested in codelite
<khashayar> vorian: thanks, I'll check that out.
<khashayar> vorian: sorry, they're backports, not new packages.
<Laney> khashayar: The backports wiki you got linked to explains it
<khashayar> Laney: I've read that page, but there are some things I don't understand. Will investigate some more and get back here later, possibly with questions. Thanks again.
<vorian> hi rrittenhouse
<rrittenhouse> hi vorian
<rrittenhouse> vorian, how are you?
<vorian> good good
<jpds> thekorn: Do you know what could be wrong here: http://pastebin.ubuntu.com/100312/ - it's not working for me against staging either and I've redone the cookie file, everything..
<thekorn> jpds, I will have a look at it in about 10 minutes
<jpds> thekorn: I'm not in a hurry.
 * hanska waves
 * ScottK waves back.
<directhex> hanska visiting ubuntuland again?
<directhex> come to steal our bugs? :o
<hanska> directhex: nah :)
<hanska> directhex: have some plans about becoming a MOTU too, some day
<soc> hi
<soc> i could need some packing help ...
<soc> i would like to package the droid font for ubuntu/debian
<soc> can someone help me?
<soc> i plan to start working on it in 50 minutes ...
<thekorn> jpds, which version of py-lp-bugs are you using? is it jaunty, intrepid or earlier?
<hanska> soc: what's your problem?
<soc> hanska: i never really did it before
<soc> so i decided to start with a typeface, because i don't have to compile anything and the dependencies are easier ...
<thekorn> jpds, what's the result of
<thekorn> python -c 'from launchpadbugs.http_connection import HTTPConnection; h = HTTPConnection("path/to/cookie"); print h.needs_login()'
<soc> ok, i'll be back in 45 minutes ...
<stefanlsd> anyone have a pointer to why my watch file isnt working... looking for this  ftp://ftp.uk.linux.org/pub/linux/Networking/netkit/netkit-tftp-(.*)\.tar\.gz    and debug returns nothing - uscan debug: requesting URL ftp://ftp.uk.linux.org/pub/linux/Networking/netkit/  -  uscan debug: received content: [End of received content]
<bddebian> Heya gang
<ScottK-desktop> Heya bddebian.
<bddebian> Heya ScottK-desktop
<stefanlsd> for info - it needs   opts=passive   before the ftp:// to do pasv ftp
<stefanlsd> could just be where i'm sitting
<RainCT_> dholbach: hey
<dholbach> RainCT_: hiya :)
<RainCT_> dholbach: I don't arrive home until around 17:15 UTC on mondays :(
<dholbach> RainCT_: ah ok - I guess I'll just pester the others then :)
<dholbach> RainCT_: would you like to give another session during the rest of the week? :)
<RainCT_> dholbach: I guess the Getting Started is supposed to be an intro for your session?
<dholbach> RainCT_: a very general introduction with room for lots of questions about ubuntu development in general
<ScottK> dholbach: Where do HoF bugs get put? Do I just tell you?
<stefanlsd> can i just start grabbing merges from mom?  i see we're past 25th dec. and still 106 merges left... and alpha 3 coming up
<dholbach> ScottK: yeah :)
<ScottK> dholbach: Currently it looks like all my non-sponsor uploads are changed-by scott@kitterman.com and signed-by ubuntu@kitterman.com (even though both email addresses are on the key) so ALL my uploads get counted towards sponsored uplods.
<ScottK> uplods/uploads.
<dholbach> ScottK: I'll check that - are both mail addresses in LP?
<ScottK> Dunno if you care about special casing that, but it doesn't seem fair.
<RainCT_> dholbach: I was thinking about doing it the week before, but I think I'll be busy finishing my research project that week, so dunno..
<ScottK> dholbach: yes.
<dholbach> ScottK: alright, I'll let you know
<dholbach> RainCT_: oh... I was thinking about some session about a different topic
<AdamDH> hey all trying to run a shell script from my make file with  $(shell scripts/patch) but I get scripts/patch: 23: /tmp/buildd/msp430-binutils-msp430-binutils-2.18-msp430/patches/msp430-binutils-2.18-msp430-cvs.0.0.20090105.patch: Permission denied line 23 is when it runs my function, I am running pbuilder build ../*.dsc as root
<AdamDH> its chmodded +x as well
<maxb> AdamDH: If it's within the diff.gz part of the source package, then you need to remember that diffs don't preserve modes. So, it won't be +x by the time the build actually runs
<AdamDH> so I need to somewhere in my rules chmod it +x so it executes
<maxb> That, or run $(shell /bin/sh the_script) instead
<AdamDH> the script works perfectly when not been called by make! I will give that a go, thanks
<AdamDH> still get permission denied, now I get it when it reads in the /tmp/buildd/msp430-binutils-msp430-binutils-2.18-msp430/patches/msp430-binutils-2.18-msp430-cvs.0.0.20090105.patch: Permission denied patch
<soc> mhhh, sorry took longer to get rid of that snow :-/
<soc> i want to package the droid fontface, can someone guide me?
<vorian> soc: have you read any kind of documentation yet?
 * vorian will show a couple of links if not
<soc> yes
<pmjdebruijn> soc: how are they licenseD?
<soc> apache
<soc> in https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging%20From%20Scratch : The underscore, "_", between the package name (hello) and the version (2.1.1), as opposed to a hyphen, "-", is very important. The packaging tools will look for a file with that exact name. If you get it wrong, the result is that the tools will incorrectly assume that there is no original source at all and the package will be built as a Debian native package.
<dholbach> directhex: do you think we could have a session at Ubuntu Developer Week about Mono Packaging? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
<vorian> how far have you gotten soc?
<soc> so my first question:
<vorian> ah :)
<soc> i have the font files, should i put them in an archive?
<soc> i'm just starting
<directhex> hanska, what do you think?
<directhex> or sebner or Laney
<pmjdebruijn> soc: are the android fonts Apache licensed? seriously?
<soc> yes
<soc> i opened them with fontforge
<hanska> directhex: pong
<pmjdebruijn> cool :)
 * hanska was going to bed
<hanska> :)
<soc> license states:
<directhex> dholbach, possibly, just gotta bounce ideas off clever people like hanska first
<directhex> hanska, bed? it's 4pm!
<hanska> directhex: didn't sleep tonight :/
<hanska> (5pm here though)
<pmjdebruijn> soc: use a current font package, like liberation as an example
<pmjdebruijn> soc: ttf-libration (for example)
<hanska> dholbach: tell me :)
<soc> Licensed under the Apache License, Version 2.0
<soc> pmjdebruijn: i alredy did that ...
<pmjdebruijn> soc: huh? well it should be simple enough then
<soc> but i'm not really sure, what things i can reuse
 * hanska just saw the link, second, let me look at it
<sebner> directhex for mono packaging \o/
<Laney> directhex: recruits to transition the libraries? ;)
<hanska> Laney: ahah right :)
<directhex> hanska, you'll muck up your circadian rhythms if you go to bed early. anyway... ubuntu developer week is a week of exciting lessons for new devs (and new skills for old devs) on given topics
<directhex> Laney, could be, could be :p
<dholbach> hanska, directhex: we're going to have Ubuntu Developer Week again with a weel full of one-hour-long tutorial sessions
<sebner> directhex for mono packaing \o/
<sebner> *packaging
<sebner> ^^
<soc> so basically i have to write a .dsc file and that diff file, am i right?
<dholbach> I just thought it'd be great to demonstrate to people what's special about mono packaging and answer a bunch of questions
<hanska> dholbach: on IRC? :)
<sebner> hanska: sure
<dholbach> hanska: yep
<directhex> dholbach, i agree
<hanska> uhm
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
<hanska> directhex: you know I don't have connection where I study :/
<hanska> directhex: and I'll leave again on 12 :/
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek the schedule (and logs) of last time
<hanska> :(
<Laney> leave?!?!?!
<directhex> hanska, crap, i forgot about that
<hanska> directhex: I would've really joined you guys :/
<Laney> it's ok
<Laney> you can record a video
<Laney> we'll play it at the start
<sebner> lol
<hanska> Laney: lol
<hanska> Laney: I can also call by phone, heh :P
<Laney> dholbach has done MOTU videos in the past!
<hanska> Laney: well.. if I were to talk about mono packaging with some sort of screencast
<directhex> the ideal would be to get meebey involved, but he's been AWOL for a few days
<soc> mhh
<hanska> Laney: I believe that an open terminal and me typing commands (even if I could also record voice), that wouldn't be too exciting!
<Laney> haha
<hanska> :)
<Laney> It'd excite me
 * hanska excites Laney 
<hanska> oO
<dholbach> hanska, directhex: I think it'd be enough to have a small example or two, talk through it and answer heaps of questions
<Laney> for sure
<Laney> helloworld-sharp
<hanska> dholbach: I would've done that, sure, but I have internet connection only on weekends
<sebner> more like debian/control and rules magic
<dholbach> hanska, directhex: and explain how to help out on the Mono Packaqing goodness
<dholbach> hanska: right :/
<soc> so now i'm going to put the font files in an archive and call it ttf-droid_1.00b112.orig.tar.gz?
<sebner> hanska: remembers me on me ^^
<sebner> *myself
<dholbach> anybody else up for giving a hands-on session at UDW?
<hanska> sebner: just because I'm at university :/
<sebner> hanska: university without internet. wired
<Laney> weird*
<sebner> Laney: +1
<hanska> sebner: Uni has, my home there hasn't
<hanska> (it's ~140km from here)
 * sebner wouldn't stay in a home without internet :\
<directhex> slomo can help too. right slomo?
<Laney> directhex: "How to package ikvm", right?
<hanska> Laney: \o/
<dholbach> hanska: where do you live?
<soc> mhh the version is "Version 1.00 build 112"
<soc> how should i translate that?
<directhex> Laney, i need to perfect face-stabbing-over-IP i think
<soc> 1:112?
<hanska> dholbach: Palermo (university), Mazara del Vallo (home city, where I am now) --> Italy
<soc> or 1.00b112?
<dholbach> hanska: ah ok
<directhex> soc, 1.00b112 works for me
<soc> ah ok
<slomo> directhex: ikvm? no, packaging that needs more time than i currently have ;)
<hanska> soc: also something like 1.00~b112 wouldn't be too bad
<soc> so now i have the fonts in that archive
<soc> ah ok
<directhex> slomo, nah, ikvm is almost in reasonable shape now (!)
<sebner> directhex: anyways, you just need a simple example and show howto deal with the control and rules file (also howto patching the makefiles) and answering questions, that's all
<soc> ttf-droid_1.00~b112.orig.tar.gz is the filename now ...
<hanska> directhex: openpgp-sharp, it's a project of mine :)
<directhex> slomo, an ubuntu developer week session on mono packaging. you've experience with one of the bigger examples
<sebner> hanska: with *good* makefiles? ^^
<hanska> sebner: I wrote that by hand, so... but it needs monodevelop installed :P
<hanska> sebner: however, I could make a preview-release-tarball
<sebner> hanska: heh
<slomo> directhex: ... like mono itself? or which one do you mean?
<hanska> (with a sane Makefile)
<soc> directhex, hanska: or shouldn't i create my own archive? should i better download that "snapshot" file from git???
<soc> problem is, that there are more things in that archive that i don't need ...
<directhex> slomo, no, CLI packaging in general. just education for people, so they can package mono apps/libs more effectively. same as other dev week tutorials, really
<directhex> slomo, i'd like to agree to dholbach's request, but i want to have people on-hand who are super smart & can answer real-world questions
<soc> directhex, hanska: should i use the generated archive from the git ( http://android.git.kernel.org/?p=platform/frameworks/base.git;a=snapshot;h=6b8721393400f8e98bb6c29d47b38c79be7ade32;sf=tgz ) which has many files i don't need or should i extract the fonts out of that archive, and place them in a new archive?
<dholbach> directhex: I'm sure that having a few examples at hand you can talk about, knowledge about general packaging techniques and a few people you can ask on IRC if you don't know the answer yourself off-hand, that's fine :)
<hanska> soc: do you intend to package the whole platform as well?
<hanska> directhex: I can give you my phone number *hrhr*
<soc> no, i just want to have a package for the font
<soc> hanska: just a ttf-droid with the fonts
<hanska> soc: then yes, make a separate source package, and state what you did in a debian/README.source file
<soc> ah ok
<directhex> hanska, i should make a README.source for ikvm!
<soc> ok, then now i extract the files from my orig.tar.gz again
<hanska> soc: also, implement a get-orig-source target in debian/rules, which should grab the snapshot (the same exact revision you got), and mangle it appropriately to have the final tarball
<soc> cd into it and do dh_make?
<hanska> soc: sure.
<hanska> soc: remember, debian/README.source and get-orig-source in debian/rules.
<soc> hanska: that's the thing i don't know how to do
<hanska> get-orig-source should automatize all the steps you did to get the original tarball
<soc> because of that i asked, if i can just create my own source archive instead of cleaning up the original ...
<hanska> soc: sure you can, but you should give other users/developers the chance to get the same exact tarball you created
<hanska> s/should/must/
<hanska> (as far as I'm concerned)
<directhex> dholbach, let me try and get ahold of meebey, since he's been doing this stuff a few years longer than me
<dholbach> directhex: if meebey can just hang out there or be around to answer the questions that you really can't answer, that's fine
<dholbach> directhex: we'll have a bunch of really really new people there
 * hanska to bed, later guys!
<soc> mhh, i can't see how ttf-liberation did that ...
<dholbach> and we're going to get them excited
<dholbach> and it's going to be great
<soc> hanska: is the debian/rules a bash file?
<directhex> soc, it's a Makefile
<soc> what should get-orig-source do? just get the archive?
<soc> or overwrite the files locally?
<directhex> soc, download (or generate) an orig.tar.gz
<soc> ah k
<soc> where should that orig.tar.gz be placed?
<directhex> dholbach, if i can pin down meebey, i can check over things like suggested example packages, or times/days he'll be about, or things like that
<soc> in the source folder?
<directhex> soc, policy says in ../ i think
<soc> ah ok
<soc> btw. should i put the font files in my archive in a folder?
<dholbach> directhex: awesome - the earlier we fix up the schedule the better :)
<soc> and do the font files need some special permissions?
<soc> or will fix the installer that for me
<soc> because atm the files belong to me, not to root
<directhex> dholbach, hence [16:12] /me jumps up & down on meebey
<dholbach> hehe
<directhex> soc, your rules file should do any general cleaning up of things
<dholbach> somebody asked for a session about merging? anybody up for talking about merging?
<soc> ah k
<soc> i'll guess i try it and then rinse and repeat :-/
<directhex> i wonder how long to assign to heckling in a mono session...
<soc> ttf-droid_1.00~b112$ dh_make -e soc@krg-nw.deThe directory name must be <package>-<version> for dh_make to work!
<soc> I cannot understand the directory name or you have an invalid directory name!
<hanska> soc: just what it says
<hanska> ttf-droid-1.00~b112
<directhex> soc, when you extract foo 1.0's orig, it should go into a folder called foo-1.0
<soc> so i have to call the archive ttf-droid_1.00~b112.orig.tar.gz, but the folder inside it ttf-droid-1.00~b112?
<soc> type of package?
<soc> single binary, multiple binary, library, kernel module or cdbs?
<hanska> soc: single binary
<soc> even if there are multiple *.ttfs?
<hanska> yes.
<directhex> it means "single binary package"
 * hanska really goes now
<soc> ah ok
<soc> thanks!
<directhex> as opposed to lots of binary packages from one source
<soc> atm Licence states: blank
<soc> ah ok, i understand
<soc> how can i tell dh_make the licence?
<directhex> generally your upstream should come with a COPYING or LICENSE file in the tarball
<soc> Skipping creating ../ttf-droid_1.00~b112.orig.tar.gz because it already exists
<soc> Currently there is no top level Makefile. This may require additional tuning.
<soc> Done. Please edit the files in the debian/ subdirectory now. You should also
<soc> check that the ttf-droid Makefiles install into $DESTDIR and not in / .
<mok0> soc: man dh_make
<soc> yes
<soc> where do i have to place that file?
<soc> mhh, i have both a NOTICE file with Copyright, License, the "No warranties" paragraph and the full apache license text
<soc> and i have a README.txt with Copyright, License, the "No warranties" paragraph and a comment "This directory contains the fonts for the platform. They are licensed under the Apache 2 license."
<soc> which one is the right ne?
<savvas> I think you have to add them all if you include all of those files
<soc> savvas: afaik the debian distribution has some shared directory with all common licenses ... does that matter
<directhex> soc, common-licenses? are your files under Apache 2.0?
<soc> yes?
<savvas> Well um.. you can add a note in debian/copyright:
<savvas> On Debian systems, the complete text of the GNU General
<savvas> Public License can be found in `/usr/share/common-licenses/GPL'.
<savvas> at least this is what dh_make command creates :)
<directhex> s/GPL/Apache-2.0/
<savvas> correct directhex!
<savvas> soc: I would just mention one by one which licenses are used for which files - just make sure you are allowed to package/distribute them using those licenses :)
<soc> ok
<soc> only apache2.0 is used
<savvas> ah cool then
<soc> what is the debian/watch file?
<directhex> it's used by "uscan" to let the archive inform you of new upstream releases
<savvas> https://wiki.ubuntu.com/PackagingGuide/Complete#Creating%20And%20Using%20A%20debian/watch%20File
<directhex> i.e. DEHS (and whatever ubuntu equivalent exists) periodically uses the watch file to detect a source tarball newer than your packaged version
<Laney> UEHS!
<soc> mhhh
<soc> the font was build by Steve Matteson
<soc> but Google has the copyright and the trademark
<soc> so who should be "upstream autjor"?
<savvas> the best way to clear out copyrights and licenses is to contact the authors directly :)
<soc> mhh
<savvas> the project is on google code?
<soc> on kernel.org
<savvas> ah ok
<savvas> I thought my watch file could help you :)
<savvas> I'm playing around with fspy currently :P
<savvas> http://mytty.org/fspy/
<soc> do i have to put the whole Apache license text in that file?
<soc> or is this enough?
<soc> License:
<soc>     Apache 2.0 License
<soc> The Debian packaging is (C) 2009, Simon Ochsenreither <soc@krg-nw.de> and is licensed under the Apache 2.0 License, see `/usr/share/common-licenses/Apache-2.0'.
<superm1> crimsun, what would you think about adding something to set the default Digital Input Source to be a digital device in the init script for alsa?  If it's available, it should work, otherwise it should fall back nicely i'd think..
<savvas> soc: looks good to me. Here's an alternative: http://paste.ubuntu.com/100426/plain/
<soc> do you think i can cite parts of the press release from ascender for the description?
<hanska> soc: "17:49 <soc> The Debian packaging is (C) 2009, Simon Ochsenreither [..]"
<hanska> the (C) has non legal value
<hanska> soc: the only recognized terms are "copyright", "copr." and "Â©"
<hanska> soc: so fix that to be "Copyright (C)"
<soc> hanska: i just took what dh_make generated :-P
<soc> that wasn't my idea
<savvas> that's true
<hanska> soc: or, it would be better if you use "Copyright Â©" (that's an utf-8 character, if you can't see it, it's the C in a circle)
<savvas> So, the debian version of dh_make uses "The Debian packaging is copyright (C)" ?
<soc> i can see it :-)
<soc> no problem ...
<soc> "The Debian packaging is (C)"
<soc> not even copyright :-P
<hanska> soc: add Copyright there!
<savvas> hanska: did you mention this to the maintainers of the dh-make package?
<soc> no
<soc> ok, i did
<hanska> savvas: not yet, but it's a well-known issue among us Debianists :)
<hanska> savvas: there also was some thread on debian-legal
<savvas> darn
<soc> ok, i have copyright and control
<savvas> 2 down, 98 to go
<savvas> just kidding :p
<soc> :-P
<soc> next thing is the defoma file
<soc> ttf-droid.defoma-hints i guess ...
<soc> wth???
<soc> ubuntu doesn't have the package i need ... *argh*
 * soc fetches libft-perl from debian ..
<soc> no installable --- *grrrrrr*
<ScottK> soc: If there's a package in Debian that's not in Ubuntu there's generally a good reason why not.
<soc> ah k
<soc> i need the file FreeType.pm for defoma-hints
<ScottK> So the first step would be to find out why we don't have it.
<soc> defoma-hints truetype DroidSans.ttf
<soc> Wait for second...
<soc> defoma-hints Can't locate FreeType.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at (eval 4) line 2.
<soc> yes ...
<soc> that would be good
<soc> it depends on perlapi-5.8.8 ... weird...
<soren> soc: Deleted in intrepid-release on 2008-09-05  (Reason: (From Debian) RoQA; buggy, orphaned )
<soren> soc: perlftlib, that is.
<soren> soc: ...which is the source package for libft-perl
<soc> so i can't use defoma-hints naymore?
<soren> I have no idea. I'm just telling you why libft-perl isn't there anymore.
<soc> yes, i see
<soc> but that doesn't really help me :-/
<soren> Well, it tells you that Debian also doesn't have the package anymore, so you're hardly alone with your problems.
<jcfp> hi all. For sabnzbdplus I'd like to get ubuntu's libjs-mochikit updated. The current mochikit package (1.3.1) appears to be copied straight from debian. What's the best approach here? Ask the debian javascript maintainers?
<hanska> jcfp: yes, please. As a Debian maintainer I'd like to keep the delta between the two distros as narrow as possible
<hanska> jcfp: reportbug -B debian libjs-mochikit
<hanska> jcfp: file a wishlist bug, asking for the version you need to be pushed in
<hanska> (however, other guys' mileage may vary here, that's just my humble opinion.)
<Laney> jcfp: You might ask if they have an update in the works, or are planning one soon and offer to help them with it to speed it along
<jcfp> hanska: thanks, sounds good
<jcfp> Laney: I'll try to ask nicely. The update itself appears simple though I know nothing about that git stuff etc.
<jcfp> After that, will it automatically appear in ubuntu or should i ask/file a bug somewhere?
<soc> mhhh "Width = Variable" is certainly wrong for a monospaced font, isn't it?
<james_w> jcfp: you will need to file a "sync request"
<ScottK> jcfp: After it's in Debian you'll need to ask to have it sync'ed into Ubuntu as we are past the point in this release cycle where it's done automatically.
<jcfp> thanks
<Laney> jcfp: looks like a pretty easy update. As it's team maintained, you could visit their IRC channel and ask if they mind you doing the update
<Laney> jcfp: Actually, it's already in their git!
<jcfp> Laney: serious? I only checked at packages.debian.org
<Laney> http://git.debian.org/?p=pkg-javascript/mochikit.git
<jcfp> So all there's to do is file the sync request in launchpad
<Laney> jcfp: No, they need to upload it
<Laney> (to debian)
<Laney> maybe they haven't finished doing it yet, you should pop over and ask how you can help
<jcfp> ah. last stupid question: which is their irc channel?
<jcfp> Laney: I tried the update locally, just for testing with sabnzbdplus, and it appeared (to me that is ;) no further changes would be needed... but we'll see.
<pochu> there's #debian-java on OFTC, not sure if that's the one you're looking for
<Laney> javascript
<jcfp> ok thanks all
<Laney> TheMuso, crimsun: I'm seeing symptoms of that pulse race bug again. Have you heard/experienced similar elsewhere?
<Laney> (Intrepid)
<soc> can i delete every file in the /debian folder that i don't use?
<coolbhavi> hi james_w
<directhex> doko__, FYI, ironpython depends: mono >= 2.2
<james_w> hello coolbhavi
<soc> ok, i have built the package
<soc> i got one error
<soc> make[1]: *** Keine Regel, um Â»cleanÂ« zu erstellen.
<soc> "No rule to create clean" or something like that ...
<soc> is that bad?
<maxb> A clean target is mandatory: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
<maxb> dh_make should have supplied you with an example one
<soc> i deleted that ...
<soc> #!/usr/bin/make -f
<soc> include /usr/share/cdbs/1/rules/debhelper.mk
<soc> include /usr/share/cdbs/1/class/makefile.mk
<soc> this is my rules file ...
<soc> ithought this was enough
<maxb> Hm. It is supposed to be enough.
<maxb> Perhaps your problem is more complex than a single line of error can explain
<jpds> thekorn: I'm using intrepid, but tjaalton tried both.
<thekorn> jpds, the output of the command I gave you would be intresting,
<soc> mhh
<thekorn> jpds, I'm about to leave, can you please file a bugreport against py-lp-bugs with the result
<soc> i want to upload my source package to my ppa, to try it, how can i do that?
<jpds> thekorn: I get False.
<thekorn> jpds, then you should not get this error :)
<thekorn> I'll check the logic behind it again tomorrow
<khashayar1> Hi, I've been talking to the ubuntustudio guys about becoming their backporter. There's a bugreport on launchpad requesting a backport of ardour. I've successfully built backports of 2.7.1 for hardy & intrepid in my ppa (and locally with prevu), and I've read the wiki page about backporting. Still, I'm a bit confused what the next step should be. There's the bugreport, there's the package, but what's the next n
<AdamDH> can any one tell me why http://www.pastebin.ca/1300274 this is running configure make and make install but nothing is there in the package after the .deb has been created
<jmarsden|work> soc: Once it builds cleanly on your own machine and in a pbuilder, you can use dput to upload it to your PPA... https://help.launchpad.net/Packaging/PPA
<soc> just read it, thanks, yes
<_MMA_> ScottK: If ya can help out khashayar here that would rock.
<soc> although i don't understand why it doesn't build cleanly
<soc> i let cdbs handle that ...
<ScottK> _MMA_: Sure thing.
<maxb> khashayar1: You need a better/fixed IRC client, or you need to manually avoid saying things longer than ~400 characters
<ScottK> khashayar1: What bug do you have?
<ScottK> That too.
<soc> btw, do i need to set some permissions on files in the debian folder?
<soc> or is this done automatically?
<khashayar1> Oh, sorry maxb, I'll try to think of that. New to irc.
<_MMA_> bug 299287
<ubottu> Launchpad bug 299287 in hardy-backports "Please backport Ardour 2.5" [Undecided,Confirmed] https://launchpad.net/bugs/299287
<maxb> khashayar1: You got truncated at "....but what's the next n" - better IRC clients will autosplit long lines into multiple messages
<khashayar1> maxb: Thanks, I'll try to find something better (using pidgin now).
<khashayar1> _MMA_: thanks
<khashayar1> ScottK: I've built packages for hardy and intrepid.
<ScottK> khashayar1: OK.  Did you test that the work?
<khashayar1> That is, I've backported ardour 2.7.1 successfully. The packages are in my ppa.
<khashayar1> Yes, they work well for me.
<ScottK> khashayar1: You said you'd filed a bug?  What bug?
<khashayar1> (Quick tests though)
<_MMA_> ScottK: Above.
<ScottK> For backports that's considered sufficient except in special cases.
<ScottK> OK.
<khashayar1> ScottK: I'm hoping to be able to backport ubuntustudio related packages on a regular basis.
<ScottK> khashayar1: Please put the exact version/revision you tested in the bug.
<ScottK> khashayar1: Did you have to make any changes to the package?
<_MMA_> It's for 2.5 but 2.7.1 is latest and in Jaunty. But scons in Hardy/Intrepid is a pain. So hopefully this can work.
<khashayar1> For intrepid, no changes at all.
<khashayar1> For hardy, I had to make two small changes.
<ScottK> Intrepid already has 2.5.  Did you do 2.7?
<ScottK> if the package needs changes then you need to provide a debdiff for that too.
<khashayar1> ScottK: Yes, 2.7
<ScottK> OK.  Are you trying to get 2.7 in both or 2.7 in Intrepid and 2.5 in Hardy?
<khashayar1> Alright, I'll read up on debdiff. Should that debdiff be attached to the bug report?
<ScottK> Yes
<khashayar1> 2.7 in both
<khashayar1> Well, hardy's my priority.
<ScottK> OK.  Bug  says 2.5.
<ScottK> We need to have both because we don't want Hardy to have a higher version than Intrepid.
<khashayar1> Yes, I thought so, that's why made both.
<khashayar1> Should I file a new bug concerning 2.7?
<ScottK> khashayar1: Just edit the existing one.
<khashayar1> Alright, let's see what I can do.
<ScottK> You can actually do both Hardy and Intrepid backports in one bug in the future using also affects.
<khashayar1> Good to know.
<_MMA_> ScottK: Thanx for the help.
<ScottK> No problem.
<ScottK> _MMA_: NCommander can also help on backports stuff too.
<khashayar1> By the way, I didn't file that bug (_MMA_ did). I assume that means I can't edit it?
<_MMA_> Ahh... That's right.
<_MMA_> khashayar1: Done. (refresh page)
<khashayar1> Thanks :-)
<khashayar1> I found a debdiff howto. I'll read that first, and then I'll post on the bug report. Thanks a lot for your help, ScottK.
<ScottK> khashayar1: No change.
<ScottK> change/problem.
<ScottK> Sorry.  Doing too many things at once.
<khashayar1> Haha, I see that :-)
<soc> hmmm, i have uploaded a source package to launchpad, how long will it take until it shows up in the webfrontend?
<cody-somerville> soc, did you get an accept e-mail?
<soc> mom
<soc> no
<AdamDH> any one mind taking a look at this and telling me why its not installing anything into the completed deb? I have used the same install line from a previous package I did and cannot see why it will not work in this case, http://www.pastebin.ca/1300274, bugging me as I cannot see anything wrong
<AdamDH> everything completes with out an error
<khashayar1> ScottK: I've updated commented on the bug report with a debdiff, a link to my ppa, and some other info.
<AdamDH> *compiles
<ScottK> khashayar1: What's the bug for Intrepid?
<_MMA_> ScottK: I though tit could be done for multiple releases? Though my bug was only for Hardy.
<ScottK> _MMA_: It can, but I thought he said he'd done a separate bug already.  Just use also affects to add intrepid-backports
<_MMA_> I don't think he filed another. I'll let him chime in.
<lfaraone> Do sync requests tke a while to process once ack'd by motu?
<jpds> lfaraone: archive admins are bake from holiday.
<jpds> So it shouldn't take too long now.
<lfaraone> jpds: kk, thanks.
<jpds> back*
 * lfaraone has a tendency to pester, and is trying to ensure I don't.
<gerlumpi_> hallo
<khashayar> ScottK: Sorry, I was gone for a while there. No, there's no report about intrepid. Just the one mentioned here.
<ScottK> khashayar: Then add intrepid-backports using also-affects.
<ScottK> khashayar: Does Intrepid need the changes too?  If so, another debdiff.
<khashayar> No changes for intrepid, I only changed the changelog for that.
<cody-somerville> who maintains mdt?
<Adri2000> is it maintained?
 * cody-somerville croaks.
<Adri2000> cody-somerville: launchpad says wgrant and I'd say maybe lucas as well
<cody-somerville> wgrant, lucas: ping
<cody-somerville> wgrant, lucas: compare-versions seems to get tricked if there is multiple versions of a package in an archive
<oliver_g_> hello
<oliver_g_> I'm quite new to Ubuntu packaging and would like to package a Gedit plugin I've made
<oliver_g_> and there are some questions about this...
<oliver_g_> maybe someone can help me with this?
<jpds> oliver_g_: It's best to just ask away, and those who can help will help :)
<oliver_g_> for start, there is no version number, so is it ok to just create a version number like "git20080105-1" ?
<jpds> oliver_g_: I would go for: 0.0~gitYYYYMMDD-1 .
<directhex> and use the date, not a git hash (i've seen that before o_o)
<jpds> This way you wouldn't need an epoch for the first release (ie. 1.0).
<oliver_g_> doesn't the ~ sign give problems later when extending the version to 0.0~gitYYYYMMDD-1~ppa1 ?
<directhex> oliver_g_, no.
<jpds> Not at all.
<oliver_g_> or is it ok to have as many tildes in the version as needed?
<oliver_g_> ah ok
<jpds> oliver_g_: And if it is an Ubuntu package not in Debian, it should end in -0ubuntu1.
<oliver_g_> right... that's another question: how do I decide for which system the package is?
<oliver_g_> should I create different control files for Debian Lenny, Ubuntu Hardy, Intrepid...
<oliver_g_> (that was probably a somewhat dumb question because it shows how I didn't grasp the very basics, but anyway :-)
<oliver_g_> in essence, after going through the examples in PackagingGuide, there's a source package as result... Is that package Intrepid-specific, or Ubuntu-specific, or would it basically work with every .deb system?
<jpds> oliver_g_: Sometimes it can be exactly the same, depends on the package.
<jpds> oliver_g_: There are no dumb questions, everyone had to start off at one point.
<oliver_g_> So if I create a package from scratch and want to get it into Ubuntu repos, I add -0ubuntu1 (for bookkeeping), and if it later goes into Debian, the -0ubuntu1 part is removed but the package can otherwise remain the same?
<jpds> The package would need a -1 entry in the changelog after the -0ubuntu1 one.
<AdamDH> hi, been on this allmost 5 hours now, any ideas why this http://www.pastebin.ca/1300420 rules is not installing anything into the completed deb? I get no errors etc
<AdamDH> i get a few dh_install: Compatibility levels before 4 are deprecated.
<jpds> AdamDH: echo 5 > debian/compat .
<AdamDH> but it still goes onto dpkg-deb: building package `msp430-binutils' in `../msp430-binutils_msp430-binutils-2.18-msp430-cvs.0.0.20090105_amd64.deb'.
<jpds> AdamDH: And make sure you Build-Dep: debhelper (>= 5).
<AdamDH> jpds where do I run that? in the TLD of my package folder?
<AdamDH> i am using allot of dh commands in my rule but there is nothing including anything or setting anything is this right?
<jpds> AdamDH: You just need a debian/compat file with a number between 5 and 7.
<maxb> AdamDH: Is your "cd src && $(MAKE) install prefix=$(CURDIR)/debian/msp430-binutils/usr" line being executed and if not why not?
<AdamDH> yes its been ran
<AdamDH> I can see the output from it
<maxb> Then, why isn't it doing anything?
<AdamDH> the deb is just empty
<AdamDH> it all runs with no errors apart from the ones about compatability levels
<maxb> You are running dh_install twice, that doesn't sound right (though would not cause this problem)
<serialorder> I want to replace pt.po in the source tree with a better transation and call it pt_PT.po. The package uses quilt for its patch system. There is also a pt.gmo file do I also need to remove that as well? If so should I removed pt.{po,gmo} using the patchsystem or just delete them from the source tree?
<AdamDH> maxb there are no errors as usally it would stop if there was a make error
<AdamDH> it just runs and gives me an empty deb
<AdamDH> at a quick glance installing fr.gmo as /tmp/buildd/msp430-binutils-msp430-binutils-2.18-msp430/debian/msp430-binutils/usr/share/locale/fr/LC_MESSAGES/bfd.mo
<AdamDH> so install is running
<maxb> AdamDH: Your problem is that you have not set the debhelper compatibility leve.
<AdamDH> just set that and re ran it and it built the package, never spotted that
<maxb> In the ancient fallback compatibility level that you are currently using, debhelper expects the package files to be installed somewhere else
<AdamDH> do i have to have a compat file or can I set it in the rules file?
<maxb> You should have a compat file
<maxb> There is a way to set it in the rules file but it is deprecated, so don't do that
<AdamDH> thanks maxb and jpds I have a working package now
<jpds> AdamDH: Brilliant. :)
<AdamDH> i will create a compat file with 5 in it
<AdamDH> i can use the same rules to build the others with some slight mods
<oliver_g_> I've got another question... When developing some app, the code goes into a version control system, so there's a definite location for original code... But for the debian/ directory files, there is no such location, right?
 * serialorder is sad wants to answer my question ;(
<oliver_g_> I mean the files in debian/ are hard to make (same as for the app code) but there is no central repository for those files?
<maxb> AdamDH: You might consider renaming all those -time-stamp suffixes to just -stamp. That would more match the general convention I've seen in other packages, and also reflect the fact that they are more stamps of a certain step being complete, than anything to do with time, particularly
<maxb> serialorder: Do you know what a .gmo file is? I don't off-hand
<AdamDH> maxb:I will do that, any other tips for the rules file? I have to remove some files that are made because they are part of the normal binutils package
<serialorder> maxb, they are the compiled translations generated from a po file
<maxb> AdamDH: You are hardcoding the --build and --host architectures, that's definitely a bad thing
<agent47a> can someone name a source package off the top of their head that uses a docbook file to generate a man page with docbook-to-man?
<maxb> serialorder: eww. Nasty that the source ships compiled files
<maxb> oliver_g_: Most packagers will keep the debian/ directory in a version control system too
<maxb> serialorder: I suppose then you'll need to add the pt_PT.po in a quilt-patch, and maybe just patch the build system to ignore the pt.po? Or let it be installed as well, but then delete it from the installation shortly after the "make install"
<AdamDH> maxb yes just noticed that will change it
<maxb> You don't seem to be using PACKAGE_TARGET for anything
<maxb> --prefix=/usr is the default for almost all packages, consider omitting it
<maxb> Are the CC and CFLAGS definitions actually doing anything? I doubt it.
<maxb> What is the remove-patch target for and does it really want a stamp file?
<maxb> oh, sorry, I have just seen the use of CC and CFLAGS
<AdamDH> CC and CFLAGS are been used
<AdamDH> CFLAGS are needed for gcc4
<maxb> My personal opinion is that it would be clearer not to use variables for CONFIGURE_ARGS, CC, and CFLAGS, since they are expanded only once, in fairly simple circumstances
<maxb> Overriding prefix= in "make install" is not the recommended way to do it. DESTDIR is the standard make variable for this purpose. I would hope binutils would support it?
<AdamDH> yes I dont think the prefix=is required
<AdamDH> I can do it with the configure flags
<maxb> No!
<maxb> That's an even worse way to do it.
<maxb> Some packages will hardcode their configured paths into scripts and or binaries.
<maxb> The correct way to do it is to configure for the *installed* location, and use the DESTDIR make variable to install into an alternative directory
<maxb> The clean target currently does not actually clean up
<maxb> The binary-indep target builds no packages, so there is no reason for it to depend on build and install
<maxb> "confiure" (sic) is misspelt in .PHONY
<maxb> Right, I'm done :-)
<AdamDH> thanks maxb I will inplement all of that and see where I go from there
<AdamDH> is usr the correct path to install it to?
<AdamDH> can I use say /opt/msp430 and ensure its exported correctley
<maxb> An official distro package should definitely fit under the /usr hierarchy and stay away from /opt.
<serialorder> agent47a,  btpd does I also found a bunch of other packages that do in google with the search string 'build-depends: docbook-to-man'
<AdamDH> maxb even a cross compiler?
<maxb> Yes. Here is an example for a different architecture: http://packages.ubuntu.com/jaunty/binutils-avr
<hanska> night!
<crimsun> superm1: RE: 'Digital Input Source' -> can we assume, though, that people will want that instead of 'Mic' or 'Front Mic'?
<superm1> it's got nothing to do with that
<superm1> separate mixer items
<superm1> it's a matter of analog vs digital, not "which analog"
<superm1> crimsun, ^
<crimsun> except for on the codecs where options for 'Digital Input Source' _offers_ 'Mic' or 'Front Mic'!
<superm1> then presetting "Digital Mic 1" wouldn't harm them as the command to set the default would fail
<khashayar> I've been trying to learn some packaging recently, so I've been having a few rounds with lintian.
<khashayar> What's one supposed to do with with "binary-without-manpage", if there's no manpage provided?
<crimsun> not necessarily, because 'Digital Mic' and 'Digital Mic 1' have both been seen as input choices
<crimsun> yes, obviously if the latter isn't an option, it will fail nicely
<superm1> so perhaps then setting "Digital Mic 1" followed by "Digital Mic"
<superm1> so that if it uses the former it works, and then falls back to the latter if that's what's used
<AdamDH> maxb so how do i rewrite this so I dont have prefix as that example uses it as well cd src && $(MAKE) install prefix=$(CURDIR)/debian/msp430-binutils/usr
<crimsun> superm1: i say go ahead and make the change; we can sort out any mess before 15 jan
<superm1> crimsun, okay will do, thanks
<maxb> AdamDH: $(MAKE) install DESTDIR=$(CURDIR)/debian/msp430-binutils
<superm1> crimsun, something else i've wondered, is there any sane way for filtering extraneous mixers from even being offered at all?  Things like analog loopback mixer?
<crimsun> superm1: oh man, that's crazy talk
<superm1> crimsun, haha
<crimsun> superm1: yes, one could selectively blacklist certain mixer elements in the driver, but deciding which are extraneous would be contentious
<crimsun> superm1: which really implies, "why expose those controls at all"? and that's a slippery slope
<superm1> crimsun, ah i can see what you'd mean there.
<superm1> crimsun, well i suppose as the "defaults" get set better, the need for users to go and check tons of mixers in the gnome tool will decrease, so those will at least be hidden more and more so
<AdamDH> thanks for all the help maxb
<AdamDH> once I have done this gcc should be half the work
<AdamDH> there are no man pages for this apart from the offical binutils ones will that be fine to try and get it submitted?
<Laney> you should write ones for any new binaries
<AdamDH> I will add that to my todo list but testing can still happen even if there are no man pages
<Laney> right
<AdamDH> any one spot anything I have missed http://www.pastebin.ca/1300531 the package build and tests out ok
<AdamDH> *builds
#ubuntu-motu 2009-01-06
 * maxb re-raises the question about remove-patch, and questions the clean target's completeness
<AdamDH> remove-patch was going to be used in clean target
<maxb> well: (1) it isn't, and (2) it doesn't need a stamp file
<AdamDH> whats wrong with the clean section?
<maxb> Well, it doesn't remove src/, for a start
 * coppro bugs MOTUs to REVU
<AdamDH> so I need a rm -rf src anything else?
<maxb> You should make a copy of your source package, do a build, and a clean, and then see if there are any differences (stuff left over). If there are, your clean isn't complete
<directhex> so who wants to write a clean rule for my ikvm package/ think of it as, uh, a technical challenge!
<dholbach> good morning
<iulian> Morning dholbach.
<dholbach> hiya iulian
<iulian> How is it going?
<dholbach> good good, just triaging the sponsoring queue :)
<dholbach> how are you?
<tmurder> is there some automagic way to check compliance with a Debian Policy Standards-Version (3.8.0) ?
<fabrice_sp> Morning dholbach
<dholbach> hiya fabrice_sp
<iulian> dholbach: I have just woken up. I'm going my homework now.
<iulian> s/going/doing
<dholbach> iulian: hehe :))
<tmurder> lintian.
<iulian> Well, I must print something for school and my bloody ink is low.
<fabrice_sp> sound familiar to me this kind of situation :-)
<iulian> Heh
<slytherin> persia: ping
<slytherin> tmurder: lintian
<dholbach> I don't think that running lintian on your package will give you 100% policy compliance safety
<dholbach> but it's a very good indicator for things that are wrong in your package
 * persia studiously ignores contentless pings
<slytherin> persia: ok, here is the one with content. Most of the packages needed for maven 2 support seem to be uploaded in Debian. But since we are post DIF I have to file sync bugs after verifying that Debian sources built in jaunty pbuilder. I was wondering if I should bug one particular archive admin for all the syncs.
<persia> I generally don't bug the archive-admins about syncs, except where there is some priority that something needs to be done soonest.
<persia> If there's a specific order in which they should be synced to build cleanly, then it's worth putting that on the wiki, and adding a note to each of the sync bugs pointing to that doc, so that they don't get pulled out-of-order, although Soyuz *should* autodetect this, and build them in the right order.
<persia> If there is a priority, bug the archive-admin of the day (days posted in the archive administration section of the wiki)
<slytherin> persia: I usually don't file sync bugs without verifying that it builds. As of now I am waiting for sync on one package after which I can evaluate it's reverse-build-depends.
<persia> Then that package counts as priority, as your work is blocked.  Try something like "could an archive admin please prioritise the sync of foo (bug #nnnnnn) from {unstable, experimental}: it's blocking processing of a host of other syncs for maven support" in #ubuntu-devel.  I'd recommend asking either early in your morning, or in your evening, as that's when you'd most likely find an archive admin (I don't think there are any between UTC+1 and U
<persia> TC+11)
<slytherin> persia: I will ask in evening then.
<tmurder> should i be building static libraries too, if i have the option? default is no.
<didrocks> morning everyone o/
<persia> tmurder, I'd recommend not doing it unless there is an overwhelming reason to do so: static libraries don't tend to automatically get security updates, which can mean a *lot* of recompiling, depending on the library.
<tmurder> ok, thanks
<stefanlsd> why doesnt mom or dad let u know when u have merges...  do you think some people don't even know they have merges to do?
<stefanlsd> james_w: can i grab some of your merges?
<persia> stefanlsd, Because merges weren't owned when MoM was invented, and DaD mirrored MoM's behaviour.  There's still a school of thought that says merges shouldn't be owned, but there's another school of thought that those who work on a package know it best.  I think we're still reaching for the right balance.
<stefanlsd> persia: yeah. im never sure if someone minds if you just take their merge and do it, or if they know something that would save a ton a trouble and its best for them to do it.  from the schedule tho, merges should of been completed 25th dec. (and debian in import freeze, so not too much will change) and there's still about 100 outstanding...
<persia> stefanlsd, I'd personally recommend evaluating the Debian changes, and the history.
<stefanlsd> would be nice if someone could just indicate, as a preference, like... feel free to grab, or i would prefer to do it myself kinda thing
<persia> If the package is primarily uploaded by a single person, and the changes are complex or interesting, then it makes much more sense to ask them.
<persia> If the package has small or standard changes, and a variety of uploaders, then it's probably safe to do.
<persia> In either case, the specific changes in Debian should be the overriding concern when deciding which is correct: it's not worth doing a merge unless there's some specific benefit to Ubuntu from the merge, at this point.
<pwnguin> yay, new desmume!
<persia> So, if the maintainer changed, or there was a minor update, don't bother.  If it's a critical bugfix, it's worth merging, if we don't already have the fix in Ubuntu.
<stefanlsd> persia: ok. new version we always want to merge thou.. i agree, small changes with a debian revision that dont fix anything, are prob not required.
<pwnguin> anyone remember what the name of that ubuntu game oriented project was?
<pwnguin> xeiso
<persia> stefanlsd, Actually, no.  We specifically *don't* always want to merge a new version after DIF.
<persia> We want to review the impact of the new version on the release we are building, and merge it iff it will improve the coming release.
<persia> Often when there is just a Debian revision bump, it's far more important to do the merge, as these are frequently bugfixes.
<stefanlsd> persia: mmm. ok.  makes sense also.  i guess also app minor revisions.  yeah, we dont want major revisions and api/abi changes to break stuff
<persia> Except when we do :)
<persia> For instance, if a new version of a library comes out, with an ABI change, and some API additions (but no removals or context changes), and upstream declared this was the version to support, and that they planned to offer several years of bugfix support, we'd want that over whatever we had.
<persia> (Assuming we trust upstream, which we usually do)
<persia> Or something where there's a central set of servers (e.g. network games), where we want to support the current server version protocol, we'd upgrade to the newer version.
<stefanlsd> persia: kk. thanks. makes total sense.   so actually saying 100 merges remaining doesnt really matter.  dad is nice when u can make a comment. like some say, not neccessary.
<persia> Well, are the "outstanding" merges or "new" merges?
<persia> If we've never merged yet in the jaunty cycle, they deserve a good hard look.  If we've merged before, it's just a quicker look to try to determine the state.
<persia> Sometimes I would like comments, just so someone could say "I reviewed 1.2.3-4: no benefit" or "I'll do this on the weekend: I'm in touch with upstream on a couple outstanding issues".
<stefanlsd> yeah. i've looked at a couple of them to find existing merge or sync bugs (although its my fault by not checking, would still be nice if we had one place with the info...)
<persia> The launchpad crew is looking at having syncs from registered sync sources be fully supported, which persumably would be expressed in a way that MoM could then parse at some point in the future.
<persia> There was also some talk at UDS about attempting to parse patches submitted to launchpad for application against bzr trees for packages, and present that in a UI somehow, which might catch the merge bugs.
<persia> Given that, it's probably not worth trying to create a system now, when there's the possibility of doing it in an integrated fashion later.  MInd you, "later" is poorly defined.
<stefanlsd> yeah. its pretty good, but i guess it takes time to improve process and systems
<persia> RIght.  Until then, we relay on clear thought and a common goal, which mostly works :)
<stefanlsd> with communication. which helps :)
<stefanlsd> where can i see history of a package and why its not in jaunty.  looking for libmagick9-dev  which is in intrepid and in sid... i see what its been replaced by in debian experimental, just wanted to know who makes the call in jaunty and where i would see it?
<persia> stefanlsd, You'd need to translate the binary package name into a source package name (in this case imagemagick).  Then look at the binary packages produced by the current imagemagick.
<persia> The set of included binary package names is determined by those who adjust each source package (developers generally, but typically the relevant Debian maintainer)
<persia> The set of included source packages is determined by the archive-admins, based on input (as bugs) by developers.
<pmjdebruijn> .win 13
<pmjdebruijn> sorry
<slytherin> dholbach: my bad that I didn't get time to reply to your mails earlier. :-( I will reply to both mails tonight.
<dholbach> slytherin: take your time :)
<stefanlsd> NCommander: you around?
<james_w> stefanlsd: you are welcome to them
<james_w> stefanlsd: feel free to subscribe me directly for sponsorship
<stefanlsd> james_w: kk. thanks :)
<stefanlsd> james_w: trying to look at the FTBS for imview...
<james_w> take a look at the bugs on the imagemagick package, and follow the link on the top one to Debian
<Laney> morning folks
<stefanlsd> does anyone know if i can put something running into a screen session?
<jpds> morning Laney.
<stefanlsd> james_w: do u have a link to what you are referring to - i only got http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470777
<ubottu> Debian bug 470777 in imagemagick "imagemagick: package msising files (threshold.xml, magic.xml etc.)" [Normal,Closed]
<james_w> bug 301618
<ubottu> Launchpad bug 301618 in imagemagick "imagemagick merged from Debian experimental has broken packaging" [High,Triaged] https://launchpad.net/bugs/301618
<james_w> the Debian counterpart to that
<AdamDH> hi, I have built a couple of packages that require one common package, if I try and build the package that is dependant on the common package I get  pbuilder-satisfydepends-dummy depends on msp430-binutils; however:
<AdamDH>   Package msp430-binutils is not installed.
<AdamDH>  even tho its installed
<AdamDH> any ideas?
<directhex> it's available inside the pbuilder?
<persia> AdamDH, Can your pbuilder see a repo that provides msp430-binutils?
<DktrKranz> is anybody able to display https://roundup.mplayerhq.hu/roundup/ffmpeg/issue711 ?
<slytherin> just out of curiosity ... has anyone successfully played a blue ray drive in Ubuntu?
<StevenK> % telnet roundup.mplayerhq.hu 80
<StevenK> Trying 130.192.86.145...
<StevenK> DktrKranz: ^
<StevenK> (It doesn't answer)
<DktrKranz> so, it's not just me
<StevenK> Nope
<StevenK> Wait, just noticed the https, but it doesn't answer on 443 either
<DktrKranz> I'll try later, thanks ;)
<AdamDH> no non of my packages are in a repo
<persia> AdamDH, You could force-install it into the pbuilder with --save-after-login, but you might do better to use a PPA for that one package, or apt-ftparchive for a local package directory.
<maxb> I like to turn /var/cache/pbuilder/result into a repository, such that pbuilder can see packages that it build in previous runs
<DktrKranz> http://hattory.no-ip.info/jaunty/result/mlt_0.3.4-0ubuntu2/mlt_0.3.4-0ubuntu2.buildlog       is pbuilder going crazy?
<persia> DktrKranz, Do you get debian/control from dpkg-source -x ?
<DktrKranz> yes, the interesting part is everything goes fine on i386
<DktrKranz> this happens on my amd64 buildserver
<AdamDH> i am on an amd64 system any way I can force it to make an x86 binary?
<directhex> use an i386 pbuilder
<persia> DktrKranz, Very odd.  Especially odd that it appears to build a dependencies line, and then claim it can't find debian/control.
<persia> This can be repeated?  Are you low on temporary space for the pbuilder run?
<DktrKranz> Filesystem            Size  Used Avail Use% Mounted on
<DktrKranz> /dev/sda5              44G  2,7G   39G   7% /
<DktrKranz> it's an intrepid box
<stefanlsd> what are the consequences of having a build-dep which isnt really required?
<persia> Curiouser and Curiouser.  Does sbuild also break there?
<DktrKranz> no sbuild installed
<persia> (and no, sbuild/schroot *doesn't* need LVM, it's just better that way)
<persia> Is the source package somewhere easy to grab?
<persia> (unsigned, please)
<persia> Or rather, I like the source signed, but not .changes :)
<hyperair> persia: why not
<DktrKranz> persia, https://launchpad.net/ubuntu/+source/mlt/0.3.4-0ubuntu2 :)
<persia> hyperair, Because a signed .changes file for something that shouldn't be uploaded is a dangerous thing to exist.
<persia> DktrKranz, Ah, repo.  Grabbing.
<DktrKranz> just uploaded, so you need pull-lp-source
<persia> Not published yet?  I thought it didn't work.
<hyperair> persia: what dyou mean something that shouldn't be uploaded?
<maxb> Gah. I wrote my own script not realizing pull-lp-source existed :-/
<DktrKranz> maxb, heh :)
<persia> hyperair, Say I'm working on a package, and there's a bug, and I haven't fixed it yet.  I don7t want that uploaded until it's fixed, but I might want to share it with others so they can help debug.
<maxb> though mine pulls from debian too
<persia> DktrKranz, The amd64 buildd is already building under sbuild: no point me restarting.
<hyperair> aah i see
<hyperair> i'd just share the diff.gz file
<nhandler> maxb: There is a pull-debian-source script too ;)
<persia> hyperair, Well, I like signed .dsc just because I'm lazy and like dget :)
<hyperair> heh
<hyperair> i se
<persia> But yes, the diff.gz is the only useful part.  One of these days, someone ought write the script that converts from diff.gz to full package.
 * DktrKranz tries to launch pdebuild to see if things change
<persia> Grumble.  crested log shows it purging everything, but build record says the log isn't available yet.
<hyperair> nhandler: http://revu.ubuntuwire.com/details.py?package=codelite
<hyperair> persia: you can't generate a full package without the orig.tar.gz
<hyperair> and it's not scriptable either
<persia> hyperair, Actually, you often can.  The diff.gz just either needs an accurate watch file, or a working get-orig-source rule.
<nhandler> hyperair: I know, I'll get to codelite soon. I've just been busy
<hyperair> nhandler: okay then.
<persia> and, yes, it is scriptable.  I've a (mostly broken) script that does it, that needs some work, and productionising.
<hyperair> hmm
<hyperair> i see
<hyperair> with the debian/watch file eh
<persia> Or debian/rules get-orig-source
<hyperair> i see
<persia> My script tried get-orig-source first, and uscan if that failed.
<hyperair> but it won't get the exact version
<hyperair> and for repackaged sources, it won't work
<persia> It will for a correctly written get-orig-source that does reproducible repackaging checksums.
<hyperair> eh?
<persia> And yes, it won't get the original source, it gets the current best source.  Personally, I wanted get-orig-source to get the correct source for the package, rather than the latest upstream, but policy optimised for developers rather than users (as only makes sense).
<hyperair> i can't remember what get-orig-source does again
<persia> It gets the latest upstream source, repackages as necessary, and provides orig.tar.gz.
<hyperair> i see
<persia> So, theoretically, if one added X-orig-md5sum: to the Source stanza in debian/control, one ought to be able to fully trustfully automate collection of original sources, which ought reduce all this fuss about mismatched origs, but that's a ways off, at least.
<persia> DktrKranz, It's your pbuilder.  Works fine on the buildds.
<DktrKranz> I see
<persia> https://launchpad.net/ubuntu/+source/mlt/0.3.4-0ubuntu2/+build/828141
<didrocks> is it possible to run some daily cron job by a non root user like www-data (appart from writing this in the script)? run-parts runs as root from /etc/crontab and run every scripts in /etc/cron.daily/. I want to make that in a package, so not edit one user's crontab
<persia> didrocks, Why not create a system users (like www-data), and then install it in that user's crontab?
<didrocks> persia: system user has to be declared with fixed uid from debian policy, right? (I thought I read something on that...)
<persia> Well, there's a couple classes of system user.
<didrocks> do you have a link on that? But I think you go the point :)
<maxb> didrocks: What you want is to put a file into /etc/cron.d/
<persia> didrocks, Policy 9.2.2: UID 0-99 is statically assigned, 100-999 is dynamically allocated at package installation time (adduser --system)
<didrocks> maxb: and that file executed by another user than root
<didrocks> persia: thanks a lot :)
<DktrKranz> persia, interestingly, it seems only jaunty pbuilder is affected, intrepid builds are fine...
<didrocks> persia: so, I think, I will go in this way. Thanks :)
<persia> DktrKranz, methinks you've found a bug :)
<DktrKranz> really
<maxb> didrocks: If you look at one of the existing files in /etc/cron.d/, you will see that you specify a username in it
<didrocks> maxb: I use the default run-parts and drop files in */cron.{daily,weekly...}
<didrocks> maxb: that was part of my issue but I will use a system user for that
<maxb> Are you sure you need a user?
<maxb> Even if you do create a special user, I think it is wrong to install crontabs for non-human users
<maxb> that's what /etc/ is for
<didrocks> maxb: I try to catch up some additional services for transmission-daemon and want to run it as a transmission user
<maxb> Then you do want to create a user, but any cron stuff should go in /etc/, not a crontab(1)-installed one
<persia> maxb, so `su ${transmission-user} -c ${command}` would be your advice ?
<maxb> No
<didrocks> persia: it was my first idea
<maxb> Go look in /etc/cron.d/ on your system
<persia> Oh, those file names are usernames?  Nifty.
<maxb> No, the file names are not usernames
<persia> No, package names. but one can still fix them.
<persia> Yeah, that's lots better.
<maxb> the username goes in the cron-line - the files are fragments that get processed like /etc/crontab does
<didrocks> ok, I thought they were no username in thoses files, like the one in cron.{daily...}, but there are :)
<didrocks> yes I see, there are regular crontab files :)
<didrocks> thanks both of you!
<persia> maxb deserves all the thanks: I just recommended the wrong solution :)
<didrocks> persia: yes but you give so many good advice that I can't blame you :)
<didrocks> maxb: next time, I will read more carefully man cron :)
<mok0> pwd
<mok0> oops
<pochu> /home/morten/.irclogs/Freenode/
<mok0> pochu: cute :-)
<soc> hi
<soc> can somone help me?
<soc> i built a source package, but i get the error make[1]: *** No rule to make target `clean'.
<soc> i use cdbs and thought the standard tartgets would be handled ...
<mok0> soc: cdbs assumes there's a top level Makefile that implements the target "clean"
<mok0> soc: That target should return the directory to the same state as it is when the tar file is unpacked
<mok0> soc: i.e. remove all *.o files etc
<soc> there are no .o files
<soc> there are just some fonts!
<soc> nothing to compile, nothing to configure, nothing to clean up
<mok0> soc: then make an empty clean target
<soc> where?
<mok0> soc: in Makefile
<soc> just "clean"?
<soc> or "clean/<packagename>"
<mok0> soc: don't you know about make?
<soc> no
<mok0> soc: ah
<mok0> just try putting "clean:" on a line by itself in debian/rules
<mok0> soc: an empty line after that
<soc> ok thanks
<soc> debian/rules:9: *** target file `clean' has both : and :: entries.  Stop.
<soc> dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2
<mok0> soc:  change it to clean:: then
<soc> already tried
<mok0> soc: meh
<soc> make[1]: *** No rule to make target `clean'.
<soc> http://pastebin.com/m1374e29e
<soc> thios is my rules file currently
<soc> btw, i want to do a native package, i heard that i have to look at the file name of my src archive, is that true?
<mok0> soc: you shouldn't make a native package
<soc> mok0: i can't figure out how to do a non-native one ...
<mok0> soc: you have to
<soc> the watch file doesn't really work with that http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=data/fonts
<mok0> soc: it will be made automatically if you have the orig.tar.gz file
<soc> even if i had figured out that, i'm still missing the right version
<soc> i just made an archive myself with that .orig.tar.gz
<soc> because the version of the fonts is only in the fonts intself
<mok0> soc: it needs to have the form xxxxx_1.0.orig.tar.gz
<mok0> using 1.0 as version
<mok0> change that to whatever
<soc> i made one following that scheme
<soc> but my "original" tarball isn't really original, because i made it myself
<mok0> soc: you need to specify version-release in debian/changlog
<soc> it isn't available for download somewhere
<soc> how can i do that?
<mok0> soc: you are packaging your own stuff?
<soc> i'm trying to learn it
<soc> i'm uploading it first to my ppa, but would be happy if i cloud get it into ubuntu
<mok0> soc: you mean how to make a tarball?
<soc> mok0: no, i just wonder what "original" tarball means
<soc> because there is no usable file i can download from upstream
<mok0> soc: it's usually a copy of the upstream tarball
<mok0> soc: renamed according to the scheme above
<soc> that won't work
<soc> the version info is only inside the fonts itself
<mok0> soc: then something else is wrong
<mok0> soc: please explain
<soc> the fonts are version 1.00 build  112
<soc> and that's only written inside the font file
<mok0> soc: can you make a tarball of that directory (without the debian/ one)?
<soc> which directory?
<mok0> soc: where you have the font files
<soc> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=data/fonts ==> Click on "snapshot"
<soc> that gets me a archive with some random git revision at the end
<soc> even if i could figure it out how to clean up that archive, i still can't get the version of the fonts ...
<mok0> soc: (my system disk is about to die, so I can't really do much right now)
<mok0> soc: so rename the tarball you get from that android.git. place
<mok0> for example android-fonts_1.0build112.orig.tar.gz
<soc> i can't do that!
<soc> i don't know the version
<mok0> soc: you just said it was 1.0 build 112
<soc> that is the one currently, but i thought the watch file should help people to update an existing package
<mok0> soc: it should, but never mind the watch file right now
<soc> of course i could hardcode 1.0 build 112, but that wouldn't make sense, would it?
<soc> ok, so no wtach file
<directhex> GAH
<directhex> quilt hates my guts
<mok0> soc: yes it would because thats the version inside it
<soc> just that get-orig-source atm?
<mok0> soc: you can add that later
<soc> mok0: but the version can change very day
<mok0> soc: are you going to update the package every day?
<soc> no
<mok0> soc: First, you have to learn how to build a package
<soc> but i can't promise that people will get the same file i used for the package and i can't even read out the version
<soc> mok0: i'm just fixing the last things ...
<mok0> soc: right. But as I said, the watch file is not important right now
<soc> all the other files are ok
<mok0> soc: huh? You can't build the source package
<soc> changelog, control, copyright, install, rules
<mok0> soc: remove the clean:: target from rules, and also remove the include .... makefile.mk line
<soc> ok
<mok0> that's line 3
<soc> mhh cool
<soc> now it works
<soc> i guess i'll upload it  now ...
<mok0> soc: does the .deb files contain what you expect?
<soc> i didn't build an deb file yet
<soc> just did  debuild -S -sa
<mok0> soc: do you have a pbuilder environment?
<soc> i tried not to compile anything on my machine, because most of the time these tools won't work cleanly and i don't have the time to clean up the whole mess
<mok0> soc: that's why we all use pbuilder
<soc> and my internet connection is slow
<mok0> soc: pbuilder stashes the deb files it downloads away, so you only need to download once
<soc> and afaiu pbuilder builds a new chroot and therefore downloads all the packages again with things i already have installed ...
<soc> does it use the files from /var/cache/apt?
<mok0> soc: a minimum set
<mok0> soc: yes
<soc> ok, then let's try
<mok0> soc: if you have the CD you could copy all the deb files there
<mok0> soc: but the compiler etc is not on the CD though
<persia> Does it do that by default now?  One used to have to specifically bind that directory manually.
<persia> Also, compiler is on the CD, in the pool directory.
<mok0> persia: Hmm, not sure
<mok0> persia: ah I stand corrected
<soc> "Default mirror site:"??
<soc> this is a question i get when installing pbuilder
<soc> http://archive.ubuntu.com/ubuntu?
<mok0> soc: you could use ubuntu.com but it's slow
<soc> ah k
<mok0> soc: preferrably a mirror near you
<soc> http://de.archive.ubuntu.com/ubuntu/
<soc> then?
<soc> (germany)
<mok0> ! mirror
<ubottu> Ubuntu installation CDs can be downloaded from http://releases.ubuntu.com - Mirrors can be found at http://wiki.ubuntu.com/Mirrors - PLEASE use the !torrents to download Intrepid, and help keeping the servers' load low!
<soc> ok, pbuildinstalled now
<mok0>   pbuilder --build [options] .dsc-file
<persia> I'd recommend using two mirrors in your sources.list: the local mirror first, and archive second.  apt will pull from the local mirror if it's there, and from archive if it's been updated, but not mirrored yet.
<persia> Given the mirror refresh cycles, this may get you newly uploaded stuff as much as an hour earlier.
<soc> mok0: i ran  "sudo pbuilder create --debootstrapopts --variant=buildd" before that
<mok0> soc: good
<soc> but somewhere it said "Distribution is jaunty."
<maxb> debootstrap unfortunately doesn't use /var/cache/apt, it just redownloads. I wrote myself a wrapper which bindmounts /var/cache/apt/archives into the chroot being built to save myself download time.
<soc> and i don't want this
<mok0> soc: I assume you are reading the wiki
<soc> i don't want to download all the packages again
<soc> yes
<bddebian> Heya gang
<mok0> bddebian: yo, Dude!
<bddebian> Hi mok0
<mok0> maxb: huh? I though pbuilder did that by default
<soc> mok0: mhhh in /usr/share/pbuilder/pbuilderrc:
<maxb> Apparently not, for me.
<soc> APTCACHE="/var/cache/pbuilder/aptcache/"
<soc> could i just point to my normal cache directory?
<soc> /var/cache/apt?
<mok0> soc: sure
<soc> ah ok
<maxb> I don't think that's enough to make debootstrap use it too, though
<persia> If you run one release (e.g. hardy) and develop another (e.g. jaunty), keeping them separate can be useful.
<mok0> maxb: oh that's probably true
<mok0> persia: ... but does it matter? I don't think it does
<mok0> persia: (I agree it's messy)
 * mok0 uses sbuild on an lvm snapshot
<persia> mok0, Well, depends.  I'd probably want autoclean run regularly on the pbuilder apt-cache, but not on my normal system (as there are times one wants to downgrade, despite the pain)
 * persia uses sbuild, and has ethernet to a mirror, so this is all theoretical
<mok0> persia: right, of course
<soc> mhhh ok, no it says validating or retrieving
<soc> but it's quite fast
<mok0> soc: good
<soc> but my /var/cache/apt directory doesn't change
<soc> even if the package isn't available there ...
<soc> i thought it would download the required packages ..
<mok0> soc: Like maxb said, it's only pbuilder using the cache, not debootstrap
<soc> ah k
<mok0> soc: when you use pbuilder, it figures out what extra packages it needs and installs them
<mok0> soc: downloading if it hast o
<soc> but pbuilder and apt-get have compatible directory structures?
<soc> or will it mess up things if i use the same dir for both?
<mok0> soc: not if you build for the same distro that's on your rig
<soc> ah k
<mok0> soc: usually people have different dirs for different distros
<mok0> soc: if you install ubuntu-dev-tools, theres a wrapper called pbuilder-dist that takes care of a lot of the nitty-gritty
<mok0> of working with different distros
<soc> mok0: do i need a debian/install file?
<mok0> soc: most likely
<soc> what has to be in there?
<mok0> soc: file names that you want to include in the package relative to topdir
<soc> addtional files?
<mok0> soc: and in column 2 the directory you want them to go into
<mok0> soc: eg. "font /usr/lib/fonts"
<soc> *.ttf		/usr/share/fonts/truetype/ttf-droid/
<mok0> soc: right
<persia> Well, except that one omits the initial '/' from the list.
<mok0> soc: I recommend you call the install file <packagename>.install
<directhex> how would i perform an action in a debian/rules on the basis of whether a file exists or not?
<soc> persia: which initial "/"?
<mok0> directhex: there's probably some gnu make macro that can test for the existance of a file
<persia> soc: you want a line like "`.ttf    usr/share/fonts/truetype/ttf-droid"
<soc> ah ok
<soc> ok, it worked ...
<soc> but where is my *.deb now?
 * directhex abuses 'rename' instead
<mok0> soc, in ..
<soc> where?
<persia> Isn't it something like /var/cache/pbuilder/result/ _
<soc> ahh thx!
<soc> cooÃ¶l
<soc> package looks good
<soc> could someone review that package?
<mok0> !REVU |soc
<ubottu> soc: 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
<hanska> \o
<jpds> soc: Only source packages are REVUed, but have a sucessfully built binary package is a great start to knowing that it works.
<jpds> hanska: hello.
<soc> mok0, jpds: do i have to upload that thing again to revu, or can i move it from my ppa to revu?
<hanska> hello jpds
<hanska> soc: still working on ttf-droid? ;)
<jpds> soc: Upload it to REVU.
<soc> hanska: i'm finished now
<soc> except for the small things ...
<soc> https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/311415
<ubottu> Launchpad bug 311415 in kubuntu-meta "Add the droid fonts and make it the default for Kubuntu" [Wishlist,Won't fix]
<RainCT> soc: you can copy it
<soc> should i use that bug, or should i create another one?
<Riddell> DktrKranz: bug 303245 is probably a legit target for poking archive admins on irc, most of the admins forget about processing backports New queues
<ubottu> Launchpad bug 303245 in intrepid-backports "Please backport amule-adunanza" [Wishlist,Fix released] https://launchpad.net/bugs/303245
<RainCT> soc: http://revu.ubuntuwire.com/import.py
<Riddell> DktrKranz: (I'm processing them now)
<jpds> RainCT: Hmm, didn't know that.
<RainCT> jpds: yeh, that's new (well, actually it's old, but it hasn't been publicized yet :P)
<soc> RainCT: thanks
<soc> mhh
<soc> RainCT: the package doesn't appear on that import.py ...
<soc> mhh now it appeared on launchpad, but not in revu
<Riddell> soc: did you upload to ubuntu instead of revu?
<RainCT> soc: is it already built on the PPA?
<DktrKranz> Riddell, thanks ;)
<RainCT> soc: and did you upload for jaunty?
<soc> Riddell: i uploaded it to my ppa
<soc> RainCT: it is built for intrepid on my ppa
<soc> can i just use the interface to build it for jaunty?
<soc> or do i have to reupload the modified changelog?
<RainCT> I'm not sure, never tried that. If you do, please tell me if it works
<maxb> reupload the modified changelog
<soc> The following source cannot be copied: ttf-droid 1.00~b112-2 in intrepid (same version already has published binaries in the destination archive)
<soc> no it doesn't work ...
<soc> it's probabyl a bug
<RainCT> soc: ok, then change to jaunty and upload to REVU
<soc> mhh ok, i copied that thing
<soc> should probably work
<soc> status pending ...
<khashayar> If there's a new upstream release of an application, but the package is neither in debian nor in ubuntu, what's the next step? If I build a package, should it go to revu?
<persia> No.
<jpds> khashayar: New upstream release for a package not in Debian/Ubuntu?
<khashayar> persia: Somehow, I suspected that :-)
<persia> First, file a "Please upgrade" bug in the BTS.  See if there's any response.  Next update the package, and attach a diff.gz to the bug, and subscribe the sponsors.
<khashayar> Yes,
<khashayar> Thanks. I'll go about that.
<directhex> i'm confused how "New upstream release for a package not in Debian/Ubuntu?" is possible
<persia> Oh, sorry.  Package *not* in Debian or Ubutu does go to REVU.
 * persia missed the "not"
<hanska> persia: or, filing a RFP in DBTS :)
<DktrKranz> directhex, there are several packages to be transitioned against new gnome-sharp2, is a rebuild sufficient or are there adjustments to make?
<directhex> if it's not in any dist, then it's irrelevant if there's a new upstream - it's a new package, full stop
<khashayar> The package I'm thinking of is audacity 1.3.6. 1.3.5 is in debian + ubuntu.
<persia> hanska, For people just starting in Ubuntu, I generally recommend REVU pre-ITP.  Many RFPs just sit there for a while.
<directhex> khashayar, then that's not "not in Debian/Ubuntu"
<hanska> persia: ACK :)
<khashayar> directhex: yeah, sorry, I'm confusing the terms here.
<directhex> DktrKranz, erm, oh god..... wasn't this some bodged ABI bump or something? slomo knows more about it than me
<persia> khashayar, In that case, ask in #debian-multimedia on OFTC about the upgrade plans.  If they don't mind, just do the upgrade.
<persia> Publish your packaging so they can put it into VCS, and push the diff.gz to a bug report.
<DktrKranz> directhex, yes. There has been a SONAME bump.
<hanska> DktrKranz: to', un altro italiano :)
<directhex> DktrKranz, i don't imagine anything other than a rebuild is needed, unless there's a serious problem with the gnome# package. give it a punt in a pbuilder
<DktrKranz> hanska, indeed! ;)
<khashayar> persia: thanks for the info. I'm a bit confused about all the shorts (VCS, ITP, OFTC). I'll get back here with questions if I get stuck.
<directhex> hanska, you remember anything about gnome#? i think slomo had something to do with updating it, but there was some kinda issue
 * khashayar is off to google
<persia> khashayar, OFTC is an IRC network.  VCS is a version control system.  ITP is a special class of bug in Debian.
<soc> mhhh
<soc> something is not working in my ppa i believe
<hanska> directhex: yes, I had nothing to do with that beast either :/
<DktrKranz> directhex, I'll have a look with sebner, he likes this kind of stuff ;)
<khashayar> persia: thanks :-)
<hanska> DktrKranz: lol :)
<directhex> hanska, you remember the specifics? my memory is terrible
<soc> the status of my ttf-droid package is still pending, although it was only copied, not built ...
<jpds> khashayar: OFTC is the IRC network where the debian people hang out: http://www.oftc.net/
<hanska> directhex: we're two, then.
<directhex> DktrKranz, yeah, sebner's a clever chap. poke him
<directhex> DktrKranz, my main issue is the oracle of debian mononess is MIA
<hanska> yeah, anyone seen meebey? :P
<hanska> directhex: taken by aliens, I told you.
<DktrKranz> he uploaded a NEW package for sebner some days ago
<DktrKranz> he's not totally MIA ;)
<directhex> DktrKranz, how many days, though? :o
<soc> RainCT: is it normal, that it takes more time to cpoy a apckage from intrepid to jaunty in the same ppa, then to build it on the server?
<DktrKranz> directhex, less than one week ago
<RainCT> soc: I don't know, sorry
<DktrKranz> directhex, http://ftp-master.debian.org/new/themonospot_0.7.1.1-1.html    <- 4 days ago
<directhex> haven't seen him since then!
<directhex> need to pin him down for about 10 things
<directhex> meybe he's hiding frmo me Â¬_Â¬
<hanska> directhex: nah, hiding from me too
<hanska> directhex: probably he got 5mins and did the upload
<directhex> hanska, but not moon! :O
<hanska> directhex: probably he wants to beat you on something :/
<directhex> MOON!
<soc> https://help.launchpad.net/Packaging/PPA "If you only copy the source, the corresponding build records are created in the destination PPA immediately. "
<soc> i don't understand it ..
 * rexbron is still lacking the revu luv: http://revu.ubuntuwire.com/details.py?package=libffado
<soc> lol ...
<soc> i don't get it: the package for jaunty in my ppa doesn't get finished but hangs with "pending" and the ppa of the fonts team, where i rebuild my packages for jaunty doesn't even exist in revu
<oojah> soc: From the PPA page: "However, it can take up to twenty minutes for the files to actually appear in your archive."
<soc> does status "pending" mean that?
<ScottK> Pending means not published yet.
<soc> oojah: "If you only copy the source, the corresponding build records are created in the destination PPA immediately." this is the next sentence
<oojah> soc: My experience is that it can take a while to go from pending->published, even when just copying binaries.
<soc> if i upload the source, it gets build and published within minutes, but if i just want to copy one thing from intrepid to jaunty, it takes ages ... wrong world :-/
<soc> should i mabe just do a new revsion with jaunty in the chnagelog and upload it?
<persia> Better to ask in #launchpad to see if someone can track it down first.
<oojah> soc: You can do that but you'll need to change the version number as well.
<soc> can i do something like 1.00~b112-2~jaunty and 1.00~b112-2~intrepid?
<oojah> Yes
<soc> "Connection failed, aborting. Check your network (111, 'Connection refused')"
<soc> lol ... somehow everything is failing now
<soc> i give up
<oojah> soc: ftp is down - the guys in #launchpad know about it.
<soc> so what should i do now?
<oojah> Just chill out a bit :)
<soc> *sigh*
<soc> i spent days on that package and now when i'm finished, everything i depend on fails ... *sigh*
<soc> File ttf-droid_1.00~b112.orig.tar.gz already exists in PPA for soc, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
<soc> Files specified in DSC are broken or missing, skipping package unpack verification.
<soc> is there a way to remove _all_ packages from my ppa including the source packages and starting again?
<DktrKranz> soc, packages are not removed immediately, you should wait a bit or use a higher version numver
<soc> but incrementing the number of the .orig.tar.gz??
<soc> that doesn't make sense really ...
<DktrKranz> soc, I misread sorry. .orig.tar.gz differ in md5sum, so you should use the one provided by Ubuntu or by your PPA itself for future revisions
<maxb> soc: Once uploaded, it is never permitted to change the contents of a file. You MUST use a new version number.
<maxb> For example: 1.00~b112+repack1
<fabrice_sp_> Hi. I'm doing an upgrade of a package and a previous patch is not accurate anymore (one line has been move). Do I update the previous patch or do I create a new patch?
<Laney> fabrice_sp_: update it, no point keeping an old patch around
<LaserJock> is anybody maintaining kompozer?
<soc> mhh, how long will it tkae until my package actually appears in revu, after i imported it?
<vorian> LaserJock: i've touched it recently
<LaserJock> vorian: do you know if there is a usual maintainer?
<LaserJock> I'm considering putting it in Main
<LaserJock> but I'd hate to rip it out of a MOTU's hands
<vorian> hmm
<sebner> LaserJock: I thought upstream is dead since years?
<LaserJock> sebner: on kompozer?
<vorian> LaserJock: yeah, that's tonyyarusso's package
<LaserJock> we found some signs of life
<vorian> it hasn't been changed since hardy :o
<sebner> LaserJock: ah, well lastest release is 5. sep 2007. Besides, the mozilla team told me that it's dead (but another replacement already in work)
<LaserJock> that's not all that long ago
<LaserJock> sebner: you happen to remember what it was called?
<sebner> LaserJock: unfortunately not but it wasn't stable yet anyways. I'll ask the mozilla guys :D
<LaserJock> it seems like most software is either dead/dying or new/unstable
 * sebner likes new stuff :P
<LaserJock> I don't
<LaserJock> because it teases you with possibility ;-)
<sebner> heh
<sebner> LaserJock: btw, I think it's http://www.bluegriffon.org/
<CarlFK> I need rules/quilt help:  rules/results: http://dpaste.com/106056/
<LaserJock> CarlFK: I think that's supposed to be patched-stamp not stamp-patched
<hanska> CarlFK: line 35
<hanska> $(QUILT_STAMPFN) is a dependency of configure-stamp, not a command
<hanska> thus, that should be
<hanska> configure-stamp: $(QUILT_STAMPFN)
<hanska> (i.e. it's a target, not a command inside the configure-stamp target)
<hanska> CarlFK: also, you forgot the unpatch target as dependency of the clean one
<CarlFK> right.  been years since I did make.  thanks
<hanska> (be careful if you use patched makefiles for the clean -- and, however, I suppose something like "$(MAKE) clean" should go there)
<soc> how long will it take until my package actually appears in revu after i imported it?
<pmjdebruijn> I can take a few minutes
<pmjdebruijn> max 20 if I'm not mistaken
<james_w> would "ppamadison" have a place in ubuntu-dev-tools?
<james_w> "ppamadison james-w bzr-builddeb"
<james_w> it was bigon's idea
<fabrice_sp_> I'm working on bug 313995. What do I attach to the bug? a debdiff between the 2 debian directories? Or the dsc, orig tarball and diff file?
<ubottu> Launchpad bug 313995 in mountmanager "MountManager should be upgraded" [Undecided,In progress] https://launchpad.net/bugs/313995
<Laney> fabrice_sp_: just the diff
<Laney> if it's an ubuntu upgrade and not a merge
<Laney> diff.gz that is
<fabrice_sp_> this package is only in ubuntu
<fabrice_sp_> ok
<james_w> the url of the upstream tarball is also useful to have
<Laney> damn you sponsors
<james_w> :-)
<fabrice_sp_> just building in a sbuild. If it works, I will upload the diff file and put the url. :-)
<slytherin> calc: there? need to discuss something about OOo dependencies that needs to be moved to main.
<huats> persia: are you around ?
<tonyyarusso> For when LaserJock returns, there is a new version of KompoZer in the works currently, with an alpha that seems to run pretty well for most people (and better than the current version in Intrepid does).  Hopefully that will be finalized in time for 9.04, and either backported or PPAd for 8.10.  The long-term replacement, BlueGriffon, is likely to be ready in time for 9.10 (hopefully).
<tonyyarusso> I'm tracking various developments and do plan to package whatever I can get my hands on.
<calc> slytherin: ok
<calc> slytherin: whats up?
<slytherin> calc: with all the java libraries that are build dependencies of OOo 3, are we expecting them to be included on CD? Also does that mean a JRE will be included?
<calc> slytherin: not included on the cd, no
<calc> slytherin: they are needed for build-depends and will be in main so if you install 'openoffice.org' they will be pulled in
<calc> there isn't nearly enough space on the cd to actually include all of openoffice.org much less all of its dependencies
<slytherin> calc: Ok.
<huats> nxvl: ping
<huats> are you around ?
<jpds> huats: is idle : 1 days 4 hours.
<huats> jpds: I have realized right after :)Ã 
<huats> thanks jpds
<huats> :)
<jpds> huats: bonsoir anyhow. :)
<huats> :)
<Chris`> huats: Have you finally managed to get around to the mentoring list with my email? :)
<huats> Chris`: I am doing that right now :)
<Chris`> Wow really? :)
<huats> I will contact you by the end of the week
<huats> Chris`: really !
<Chris`> Great, ok thanks :D
<Chris`> A bit of a time lag but who cares?
<huats> Chris`: thanks...
<huats> I am clearing the mentoring request queue
<huats> but before I have to check the status of the current mentee
<huats> that is what I am doing right no
<huats> w
<nxvl> huats: pong
<huats> so you can expect a mentor by the end of the week (or early next one)
<Chris`> huats: That sounds fantastic
<jpds> Anyone remember where harvest is?
<Laney> http://daniel.holba.ch/harvest (iirc)
<jcastro> ^^
<Laney> i do rc!
<jpds> Ah, I was looking under his people.ubuntu.com place. Thanks.
<kees> siretart: do you want to do the cryptsetup merge?  I don't have the bzr trees set up at the moment :)
<directhex> who's good with man pages?
<directhex> i have one last lintian error in the most tricksy of evil packages, and it's from man
<Laney> pastebin it?
<directhex> Laney, i cracked it
<Laney> mad skillz
<directhex> Laney, i MIGHT just have a lintian-clean IKVM package here
<Laney> sanity-clean?
<Laney> working?!
<broonie> How big's the ignore file? :P
<directhex> Laney, other than the john goerzen problem
<directhex> broonie, non-existeny
<slytherin> calc: One more question. Is it ok to disable the unit test that causes the build failure for lucene2?
<siretart> kees: I'm sorry but I've  been so incredibly busy since weeks that I didn't get to do any merge so far :-(
<kees> siretart: okay, no problem, I'll take a stab at it.
<siretart> kees: AFAIR I've pushed all branches to launchpad
<siretart> kees: thanks!
<siretart> kees: cryptsetup needs some love anyway. there are some bugs that need to be looked at.
<siretart> one of them looked rather important, the UUID= not supported one...
<kees> siretart: yeah, I can't commit to that bit of work, but I can at least get us merged with Debian, which added a ton of fixes.
<Laney> directhex: he is on oftc
<Laney> you could harass in PM
<directhex> Laney, what's his /nick ?
<Laney> directhex: cosmicray
<directhex> * cosmicray :No such nick/channel
<directhex> i'd guessed it was that, but it's never been there for my whoising
<siretart> kees: yes. it was a real please being able to compare to the debian branch and revert and validate diffs on a per file basis (instead of a per tree basis) with the bzr branch
<broonie> CosmicRay normally
<broonie> but he's not online ATM AFACIT
<siretart> kees: I hope that we get the debian bzr imports soon.
<Laney> oh, irssi automatically does a whowas too
<Laney> mea culpa
<directhex> i hope meebey reappears & starts on the sponsoring backlog soon!
<directhex> and i hope ikvm stops needing 1.5 gig of ram to compile
<directhex> and for pigs to fly
<calc> oops i missed him
<fabrice_sp> by the way, someone interested in reviewing dvdstyler (http://revu.ubuntuwire.com/details.py?package=dvdstyler)?
<soc> mhhh weird ....
<soc> i imported an package into revu approx. 3.5 hours ago, but it didn't appear on my profile
<soc> can maybe someone check if that package hangs somewhere?
<jpds> soc: Which package?
<soc> ttf-droid
<jpds> soc: Afraid I can't find that in the queue or the archive.
<jpds> Then again I'm not sure how the importer works..
<jpds> NCommander: Can you please look into soc's problem?
<NCommander> The PPA importer?
<jpds> Yep.
<NCommander> To my knowledge its non-functional
<NCommander> The crontab is disabled
<NCommander> RainCT was working on it, he's your main
<jpds> soc: OK, in that case, sorry to keep you waiting, you're better off dput'ing the source package to revu.
 * RainCT runs the importerÃ§
<RainCT> soc: there you have it
<soc> thanks!
<jpds> RainCT: Where is the importer script?
<RainCT> jpds: /srv/revu-production/scripts/ppa-import.py
<RainCT> jpds, NCommander: I'll add a cronjob for it
<soc> jpds, RainCT: could you review that package?
<jpds> soc: About to go to bed here, I'll look at it in the morning tomorrow.
<NCommander> RainCT, the crontab is something else, thats just the frontend one.
<RainCT> NCommander: no, the frontend is /srv/revu-production/import.py
<NCommander> oh
<soc> jpds: ah ok, np thanks
<soc> "The Maintainer     field is invalid. It has to contain an @ubuntu.com address (usually the     Ubuntu MOTU Team's)."
<soc> so what _is_ the mail address then? :-)
<jpds> soc: make sure you have the ubuntu-dev-tools package installed and run: update-maintainer in the source root.
<soc> motu@ubuntu.com?
<Adri2000> Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
<Adri2000> but better use update-maintainer indeed
<jpds> the script will do it for you, but that's the address^
<RainCT> jpds: Cron job added. If you ever want to run the importer manually, do "sudo /srv/ppa_import.sh" (this new file implements a lock)
<jpds> RainCT: OK. Thanks.
<soc> jpds: which section do i need?
<soc> universe?
<Adri2000> soc: for update-manager?
<Adri2000> euh
<Adri2000> update-maitainer*
<Adri2000> +n
<soc> yes
<soc> ok, chose universe
<soc> seems to be right
<jpds> Yeah, it's in universe.
<soc> Note: This package has no debian/watch file or get-orig-source rule.
<soc> is that too bad?
<soc> because i'm sure that i can't fullfill that wish
<soc> or maybe just get-orig-source
<soc> but that won't help people to update the package
<soc> basically you have to mess with fontforge to get the version info of the fonts
<soc> i don't believe this can be done by some script ...
<blizzkid> lo all. is Dustin here by any chance?
<Laney> blizzkid: #ubuntu-devel
<blizzkid> ty Laney
<soc> hi
<soc> can someone review http://revu.ubuntuwire.com/details.py?package=ttf-droid
<soc> this is a package with some fonts, so it isn't much work, i guess
<jpds> james_w: You have my + for ppamadison in u-d-t.
<james_w> cool, thanks jpds
<james_w> though that means I'll have to make it work more than just writing some output on my blog :-)
<soc> is it a good idea to downgrade the Build-Depends from debhelper (>= 7) to debhelper (>= 6) so it builds on hardy correctly?
<soc> or should i leave it alone?
<jpds> soc: If you want to backport it later on, yees.
<soc> down-grade?
<soc> do  have to change the debian/compat file too?
<jpds> Yep. But you only would need to do it if you want to backport it to hardy.
<Adri2000> james_w: is ppamadison useful for ubuntu development? if it's only related to ppa I'm not sure everyone will agree
<soc> or can i request behavior version 7 and if the versio of debhelper is too old it will fail gracefully?
<soc> jpds: i'm thinking of debian at the moment
<james_w> Adri2000: some people use PPAs for development, so it might be useful to them
<soc> they have all the outdated things there ...
<james_w> I don't really want to start a new project
<jpds> soc: Then check which version if debhelper is in stable (I think it's 5).
<soc> jpds: yes, just checked it
<soc> it's 5.0.42
<soc> so it won't make a difference
<soc> then i guess i'll leave it
<Adri2000> james_w: I'm saying that because of what happened with ppaput
<soc> jpds: could you look on my package for a few seconds?
<jpds> soc: what's debian/bug/script for?
<soc> jpds: i took that from the ttf-liberation package
<jpds> soc: Package not in Ubuntu/Debian. changelog should only have one entry with "Initial release." and version ending in -0ubuntu1.
<soc> i guess it has something to do with debian/bug/presubj
<jpds> soc: is there actually a release of the font on the web somewhere?
<james_w> debian/bug/script is a reportbug script isn't it?
<jpds> soc: if not: I think the version ought to be: 0.0~gitYYYYMMDD-0ubuntu1.
<jpds> james_w: It has a dpkg command in it, no idea what it does.
<soc> jpds: version from what?
<jpds> soc: debian/changelog.
<jpds> james_w: Actually looks like it grabs from some packages.
<soc> i took the version from the fonts
<jpds> OK. Didn't see that anywhere.
<soc> james_w: that could be, i don't understand what that at the end should be, i get /home/soc/Entwicklung/Pakete/ttf-droid-1.00~b112/debian/bug/script: 3: 3: Bad file descriptor
<jpds> soc: Might be a good idea to put the copyright text in README.txt in debian/copyright.
<soc> jpds: that's my problem with debian/watch ... to see the version of the font, i have to open fontforge .. i gues that can't be automated
<soc> i don't have a README.txt ....
<jpds> soc: it's in the git repo linked from the package.
<jpds> soc: It is possible to parse web pages for tarballs for watch files, take a look at http://dehs.alioth.debian.org/wwiz_detail.php?id=15766059&type=watch - for example.
<soc> yes, i already tried that
<soc> but the tarballs always have some git revision at the end
<soc> and i can't get the version of the fonts
<soc> to get the version i have to open them with fontforge
<soc> regarding the README.txt: i didn't take that one, because the font files stated something different
<jpds> Hmm, well, I'm going to bed for real time this time.
<jpds> soc: OK; I'll take another look when I'm more awake in the morning.
<soc> and because i'm not distributing the whole tarball with lots of android opensource project files, but just the google files, i wrote google in the copyright
<soc> because in the font files, google is stated as the copyright holder
<soc> ok, new version for revu and ppa
<soc> is someone willing to look at the package?
<soc> i'm just uploading a new one, after reading https://wiki.ubuntu.com/MOTU/Packages/REVU/CheckList and setting the version back to 0ubuntu1
#ubuntu-motu 2009-01-07
<soc> hi, i packaged the fonts of the android mobile platform, could someone review them? http://revu.ubuntuwire.com/details.py?package=ttf-droid
<vorian> Laney: are you about?
<savvas> darn, aptitude 0.5.0 didn't make it with its fancy aptitude-gtk gui in ubuntu :\
<persia> savvas, Should it have?
<savvas> persia: I don't have anything to back it up except for the wish to try it out - so probably no :)
<persia> savvas, Try it out in a PPA.  If you come up with a convincing reason, it could be a candidate.
<persia> That said, it's fairly core, so time is of the essence.
<savvas> you're right, I'll do that!
<savvas> persia: come to think of it, it should wait for another release and a proper review - there's a dependency on apt-xapian-index package that looks quite interesting
<savvas> I'll give it a go in my ppa though, maybe I'll find something radical :)
<persia> savvas, Good catch.  We'll certainly catch it for autosync for jaunty+1.
<serialorder> microsoft sure is creative... oh wait I have seen this model before: http://news.zdnet.com/2424-9595_22-256995.html
 * ScottK runs python3.0 for the first time.
<fabrice_sp> Hi, I've used requestsync to request a sync for icu4j package (bug #314615), and Package Archive admin has been directly subscribed, without the sponsorship step.
<ubottu> Launchpad bug 314615 in icu4j "Please sync icu4j 3.8.1-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/314615
<fabrice_sp> Is there a problem? (the -s flag doesn't work in requestsync)
<persia> fabrice_sp, There've been a few bugs reported against requestsync.  You might try tweaking the code to point at staging.launchpad.net, and fiddle a bit to determine if you've found one.
<fabrice_sp> ok persia. And about the bug? Will P-A-a reject the request as no sponsorship has been done?
<persia> Or ignore it.  I'd recommend subscribing the sponsors now.
<fabrice_sp> ok
<fabrice_sp> thanks
<fabrice_sp> thanks for the ack, persia ;-)
<iulian> G'morning.
<fabrice_sp> (and there is a bug in the launchpad interface, as according to syncrequest, I am a member of ubuntu-dev) :-S
<fabrice_sp> Morning iulian
<iulian> Hiya fabrice_sp.
<binarymutant> hi all, just wondering if someone could point me to some Ubuntu ruby policy, I've read Debian's policy and can't seem to find Ubuntu's
<dholbach> good morning
<persia> binarymutant, In practice, they are identical.
<binarymutant> thanks persia :)
<liw> binarymutant, I don't know much about Ruby, but generally, unless Ubuntu has documented doing something differently, you can assume that Debian's stuff applies to Ubuntu as well
<binarymutant> okay thats what I thought, just making sure thanks :)
<fabrice_sp> good morning dholbach
<dholbach> hiya fabrice_sp
<didrocks> good morning o/
<dholbach> hi didrocks
<didrocks> hi dholbach :)
<_ruben> this probably not the best place to ask but dont know any better place .. when i use debmirror to create a local mirror, why do some packages get deleted when there's a new version available, and others do not (keeping old versions around which could come in handy)
<liw> _ruben, do you have more than one release ("distro") in the mirror? if so, the old versions might be in those
<_ruben> liw: true, but the downloaded list output by debmirror tends to be a fair bit larger than the deleted list
<\sh> moins and happy new year :)
<thekorn> hi \sh! happy new year to you too
<soc> good morning, i packaged the fonts of the android mobile platform, could someone review them? http://revu.ubuntuwire.com/details.py?package=ttf-droid
<Laney> vorian: hi
<slytherin> calc: I was trying to analyze the build failure for jaxme. What I am not able to understand is that the function names mentioned in the error don't even exist anywhere.
<vorian> Laney: I was just trying to catch you on irc before i responed to your reportbug bug
<Laney> vorian: Oh ok, I'll post a thread
<Laney> we should still update to the new version whatever happens, as the default (bugs.debian.org) SMTP server is broken apparently
<ScottK> Laney: There isn't a good default we can put there.
<Laney> Why can't we use Debian's default?
<Laney> reportbug.debian.org
<ScottK> Oh.  Actually that might work.
<ScottK> Historically the problem has been that any generic mail server you put in there would need to be an open relay.
<Laney> the point is that Debian recently changed their default and we still have the old one
<ScottK> OK.
<Laney> but I accidently started a discussion which now blocks my upload :(
<ScottK> What bug are we discussing?
<Laney> bug 314556
<ubottu> Launchpad bug 314556 in reportbug "Please merge reportbug 3.48 from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/314556
<Laney> see Don Armstrong's change
<vorian> I feel some would have strong feelings both ways
<vorian> (that's too much use of feel)
<slytherin> is the server used by requestsync an open relay?
<mgdm> I would hope not...
<Kalidarn> does anyone know how the RELEASE.gpg file is made
<Kalidarn> it looks like a detached clearsigned signature
<Kalidarn> ive tried making my own for sha1s but... i havn't been able to
<Laney> 288 		    # get server address
<Laney> 289 		    mailserver = os.getenv('DEBSMTP')
<Laney> 290 		    if mailserver:
<Laney> 291 		        print 'Using custom SMTP server:', mailserver
<Laney> 292 		    else:
<Laney> 293 		        mailserver = 'fiordland.ubuntu.com'
<mgdm> Oh, I was taking open relay to mean you could relay to anywhere from anywhere
<Kalidarn> http://mirror.internode.on.net/pub/ubuntu/releases-DVD/8.10/release/MD5SUMS.gpg
<slytherin> mgdm: I meant without auth, from a ubuntu.com address, to any address.
<Kalidarn> im wondering how that was created
<Kalidarn> it's obviously a clearsigned detached signature of http://mirror.internode.on.net/pub/ubuntu/releases-DVD/8.10/release/MD5SUMS
<slytherin> calc: found the reason for jaxme FTBFS.
<mgdm> slytherin: eeek!
<mgdm> slytherin: that's basically the same thing
<Laney> I don't think it works like that
<Laney> it probably relays from anywhere to LP/ubuntu/canonical
<ScottK> So we changed it to default to report to Debian?
<ScottK> This is a very bad idea.
<StevenK> Kalidarn: Look at the --detach-sign to gpg
<Kalidarn> yeah i tried that
<Kalidarn> it didnt clearsign though
<StevenK> Kalidarn: Then you want -a, too
<Laney> ScottK: No, the default is to die unless you configure bts=debian
<Laney> die with a message pointing to ubuntu-bug
<Kalidarn> thanks StevenK
<Kalidarn> that did work :)
<Kalidarn> sign i am  newb ;)
<ScottK> Laney: isn't bts=debian the default?
<Laney> ScottK: The configuration process will set you up to bts=debian, sure, but the patch we've applied kills it before you even get that far
<ScottK> Laney: I don't see that in your debdiff.
<Laney> if not self.options.bts or self.options.bts == "ubuntu":
<Laney> bts isn't configured by default, so it bombs out there
<Laney> or if the user previously had it set to "ubuntu"
<ScottK> I see.
<ScottK> OK.
<Laney> I just wonder if it should allow you to carry on instead of sys.exit(1) in the unconfigured case (for bts=ubuntu I agree that this is probably correct)
<ScottK> Laney: Since you have the package that it's wanted to file the bug against and ubuntu-bug is installed by default (I'm pretty sure) why not just fire it off in this case?
<ScottK> Or try anyway.
<Laney> I don't know. I'll fire off a mail with options later. I guess some people might think that discouraging end-users from using reportbug at all is a good aim
<ScottK> Laney: Having it end up someplace useful is even better.
 * Laney agrees
<dholbach> would somebody to give a session at Ubuntu Developer Week about "how to collaborate best with Debian"?
<Laney> ScottK: Do you think it's a good idea to update reportbug anyway? There's no regression from what's in Jaunty now, and 3.47 could break at any time for people who haven't set up an alternative SMTP host to use
<dholbach> we still have some open slots
<Laney> dholbach: Someone from Debian might be best to do that?
<dholbach> Laney: best somebody from Ubuntu and somebody from Debian?  :)
<Laney> well, yes
<Laney> Debian: Here's what we want you to do
<Laney> Ubuntu: Here's how to do it?
<dholbach> it'd be great to talk about how to forward patches, which patches, how to use the bts, etc
<dholbach> how to link bugs in LP
<dholbach> who to talk to
<dholbach> etc
<hanska> ScottK: ping
<ScottK> hanska: Pong.
<hanska> ScottK: are you one of the bash-completion maintainers?
<ScottK> hanska: No.
<hanska> ScottK: sorry then, I was looking for the maintainers, and I saw your name on LP
<ScottK> Virtually everything in Ubuntu is at least formally team maintained.  I'd suggest looking at debian/changelog to see who's been active on the package.
<ScottK> Weird.
<hanska> ScottK: the fact is that Ubuntu guys keep forking an old version of bash-completion
<hanska> while me and other guys have already released newer versions
<hanska> (the Debian team became upstream a while ago, and now we also have Fedora and Gentoo guys with us)
<hanska> so.. I was sending a mail, I'd like to know whom to send it to :)
<ScottK> Right.
<slytherin> hanska: send it to ubuntu-motu@lists.ubuntu.com
<ScottK> Even better subscribe first so it doesn't get moderated.
<slytherin> hanska: oh wait, the package is in main, so send to ubuntu-devel-discuss@l.u.c
<hanska> slytherin: I was sending it to the guy who provided the debdiff, the MOTU who did the actual upload
<hanska> s/MOTU/I_don't_know_how_people_uploading_in_main_are_called/
<hanska> :)
<slytherin> they are called core-dev.
<slytherin> :-)
<hanska> ah, great :)
<hanska> slytherin: ubuntu-devel-discuss or just ubuntu-devel?
<hanska> (I saw also the latter @ l.u.c)
<ScottK> hanska: devel-discuss and subscribe first so it doesn't get moderated.
<slytherin> hanska: ubuntu-devel-discuss.
<hanska> ScottK: I believe that posting through gmane doesn't get moderated either
<ScottK> OK.  I'd find that suprising.
<hanska> Sent. Let's see if it arrives.
<hanska> (otherwise I'll just cancel the post, subscribe and re-send)
<ScottK> hanska: lists.ubuntu.com does helpfully send backscatter to tell you you're moderated.
<hanska> ScottK: seems like it arrived, instead. Please check :)
<hanska> (I believe gmane.org is automagically accepted, since it requests a confirmation mail before sending the *first* mail)
 * ScottK hasn't got it yet.
<hanska> ScottK: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-January/006617.html
<hanska> ;)
<ScottK> Got it now.
<ScottK> hanska: If you can verify that all the Ubuntu changes are in the current Debian package, you can file a sync request.
<hanska> ScottK: it's not just a sync request
<hanska> ScottK: it's about joining forces.
<ScottK> hanska: I agree that you have a broader agenda, but the narrower purpose is useful too.
<hanska> in what ways?
<ScottK> I don't know how much reply you're going to get since no one person is minding the package.
<ScottK> Getting Ubuntu to use the same as Debian instead of the old one.
<hanska> ScottK: It's not about *Debian*, did you see who's in the team?
<ScottK> Once it's updated, then it's easier to see the use in working with Debian.
<hanska> we're Debian, Fedora/RH, Gentoo
<ScottK> hanska: Yes, but from my perspective as an Ubuntu developer, Debian is upstream.
<hanska> ScottK: better!. Let me explain
<hanska> You ("generic" you) receive a bug about bashcomp in LP. What are you going to do?
<hanska> if the package has been synced from Debian, "fork" an *-ubuntu? version from it, and do the changes there
<ScottK> Look at it, if I can fix it, upload the fix to Ubuntu and send a patch to Debian in the BTS.
<hanska> ScottK: no one has ever done that.
<ScottK> That's because it's so forked at the moment.
<hanska> ScottK: I keep receiving Ubuntu Merge-o-matic mails about new uploads, and just keep merging changes from you
<hanska> it's *annoying*.
<ScottK> Understand.
<hanska> best would be if an Ubuntu core-dev/MOTU/$with_uploads_power was part of upstream
<ScottK> What I'm describing is the 'normal' maintenance approach for packages we get from Debian.
<ScottK> hanska: Except that that would be everyone.  That's a bit much.
<hanska> ScottK: we need just *one*!
<hanska> btw, that was just a suggestion
<ScottK> Right, and looking at the history in debian/changelog, except for maybe bryce, I don't know who that would be.
<hanska> we're being a cross-distribution group now, and having someone from you guys would be great.
<ScottK> The question is who.  In the meantime if it were sync'ed then the odds of people working at least with Debian would go way up.
 * DktrKranz could have a look at our bash-completion package to see if it can be synced
<hanska> DktrKranz: thank you.
<DktrKranz> and eventually follow its maintenance
<ScottK> Excellent.
<hanska> ScottK: I understand Ubuntu's dev model is kinda different from ours
<DktrKranz> it's in main, so it's quite important because almost everyone uses it
<hanska> after all, we needed just one volunteer (which seems to have shown up :))
<ScottK> DktrKranz: Agreed.
<hanska> DktrKranz: if you see Debian's changelog, you can see we did quite a lot of improvements.
<DktrKranz> hanska: I see :) I use it every day, so I can beta-test it before Feature Freeze
<hanska> DktrKranz: http://bash-completion.alioth.debian.org/
<hanska> instructions for bzr ;)
<hanska> and -- really -- we would have chosen git, but chose bzr for you *lol*
<DktrKranz> :)
 * DktrKranz likes git...
<hanska> DktrKranz: sure, but I didn't know "the Ubuntu guy" would have been some git-fanboy :P
<mok0> Anyone has time to help me debug an FTBFS? Here: https://edge.launchpad.net/ubuntu/+source/illuminator/0.11.0-1/+build/752609
 * ScottK looks over at NCommander.
<hanska> mok0: petsc-dev: Depends: libpetsc2.3.3-dev but it is not installable
<mok0> hanska: right
<mok0> uh, wait, I goofed
<NCommander> ScottK, its just a misidentified depwait
<ScottK> Oh.
 * ScottK should have looked before calling in the expert.
<NCommander> find what package libpetsc belongs do, and fix it :-)
<ubottu> package is not a valid distribution ['dapper', 'gutsy', 'gutsy-backports', 'hardy', 'hardy-backports', 'intrepid', 'intrepid-backports', 'jaunty', 'jaunty-backports', 'kde4-ppa', 'kubuntu-members-kde4', 'medibuntu', 'partner']
<soc> hi, i packaged the fonts of the android mobile platform, could someone review them? http://revu.ubuntuwire.com/details.py?package=ttf-droid
<soc> it's a small, uncomplicated package, nothing big
<hanska> MOTU-related question: is it possible to review packages not being a MOTU?
<mok0> hanska, yes
<ScottK> hanska: What you can't do is advocate them as ready for upload.  People who know about packaging, but aren't MOTU are encouraged to help out with reviews.
<hanska> soc: since you repackaged the tarball, in these days I suggested you to provide a get-orig-source target
<hanska> but, well... "This package has no debian/watch file or get-orig-source rule.".
<ScottK> hanska: "Oh, this should really go into Debian and I can help you get it sponsored there" is a really good comment we like to see.
<ScottK> hanska: That's a good comment as most MOTU would reject a package that didn't have one or the other.
<hanska> ScottK: IANADD, still in NM, so I can't really sponsor anything ;)
<soc> hanska: imo it is not possible to get an original tarball by an automated script
<hanska> soc: why not?
<ScottK> Right, but if you're on a team in Debian that has willing DD's ...
<soc> i wrote the url to download the latest version into the control file
<soc> hanska: i can't download it via wget
<soc> uscan doesn't work
<soc> no possibility to get the right version
<soc> etc.
<hanska> soc: there are other ways too. Let me give a look at the package
<soc> ok, one problem after another:
<soc> a) android uses some weird webgit system, you can download the files, but only via a real browser ... some wierd redirect i guess
<hanska> uh?
<hanska> is ./debian/bug/ an Ubuntu-specific layout?
<ScottK> soc: Can you check it out using git?
<soc> it is made for reportbug
<hanska> soc: ACK. That could be useful for us too, I believe.
<soc> b) to get the version of the fonts, you have to open them in fontforge and read the version, no way to handle this automatically
<hanska> us == Debian
<ScottK> hanska: No.  I've seen that in other font packages.
<soc> ScottK: that might be possible, but doesn't solve the whole problem
<hanska> ScottK: never saw that in any Debian package
<ScottK> soc: Sure it does.  You can use git in your get-orig-source rule.
<hanska> Debian-proper
<soc> the biggest problem is the version info, which is only inside the font file itself
<ScottK> hanska: I think I have, but I wouldn't swear to it.
<hanska> k
<hanska> however soc, reviewing your package ;)
<soc> ScottK: how can i download single files via git?
<ScottK> soc: Right, then you toss in some awk and sed magic, stir, and presto, new package.
<soc> or do i have to clone the whole repo for it?
 * ScottK is almost completely git ignorant.
<soc> ScottK: so should i just hardcode the version myself?
<broonie> You have to clone the whole repository.
<soc> ouch ... ok
<soc> and after that i have to clean up the whole mess again?
<ScottK> soc: Hard coding is almost always the wrong answer.
<soc> ScottK: so how should i get the version number?
<soc> really, the version is only available inside the font file ...
 * ScottK would have to look at the file and is actually trying to do $WORK currently.
<broonie> strings or some font-specific utility that can parse the metadata both spring to mind.
<soc> get-orig-source is a normal bash-file?
<soc> broonie: do you know a utility that can do that?
<ScottK> soc: See plasmoid-kbstate for a package with an svn oriented get-orig-source that works.
<ScottK> That'll at least point you in the right direction.
<ScottK> You might even be able to convince JontheEchidna to help you.
<ScottK> Since he's like trying to get approved to be a MOTU and all right now.
<ScottK> hanska: Look at ttf-sil-scheherazade for a package in Debian that has the bug dir.
<soc> btw, what's the idea of that get-orig-source?
<hanska> ScottK: I'll do, thank you
<hanska> soc: almost completed the review :)
<ScottK> soc: It exports the head of the svn trunk and makes a tarball out of it.
<soc> in general i mean
<soc> afaik, even if the developer uses that script to get exactly the same files again, his tarball won't have the original hash, because of the gzip timestamps
<ScottK> In general it's to automate fetching a new upstream when you can't just download the tarball.
<ScottK> Right, you don't do it every time.  Just for new upstream version/snapshot/etc.
<soc> mhh, but it won't fetch a new upstream version, i thought it should get the original source used to package these files?
<ScottK> Now get the upstream source for the next version.  The idea is to make package updates easier.
<ScottK> It's just make -f path/to/debian/rules get-orig-source.
<mok0> soc: reviewed!
<broonie> ./debian/rules get-orig-source even
<hanska> mok0: argh :P
<hanska> beaten on time
<soc> ok, i guess i just write a script which fetches the latest version of the files and name the package ttf-droid_LOOK-IN-THE-FONTS-METADATA-FOR-VERSION-NUMBER.orig.tar.gz
<mok0> hanska: you probably have some stuff I missed :-)
<pmjdebruijn> soc: I don't think that the plan
<pmjdebruijn> soc: there's a watch file for that
<pmjdebruijn> soc: packages are not ment to be built dynamically
<soc> can i use git in that watchfile?
<pmjdebruijn> not sure
<mok0> soc: don't they distribute a tarball?
<pmjdebruijn> soc: packages are always built on a concrete upstream release
<soc> no
<mok0> soc: at some point in the future, packages will be created directly using the git repo
<pmjdebruijn> soc: ttf-droid_1.2+git20090107.orig.tar.gz ?
<soc> these are the fonts used in the android phone, i guess they will never do a font-release
<soc> pmjdebruijn: the "1.2" part is the problem..
<pmjdebruijn> soc: isn't there a version number in the metadata
<soc> pmjdebruijn: yes, that's the version from the font's metadata
<pmjdebruijn> good
<pmjdebruijn> use that
<soc> i don't know if there is a command line application to extract that metadata
<pmjdebruijn> that should correspond to a release number if any...
<pmjdebruijn> soc: why would you need a command line application for that?
<mok0> soc: see my comments @ REVU
<soc> pmjdebruijn: how should i get the version then?
<mok0> soc: I think that makes up for the watch file
<pmjdebruijn> soc: use fontforge?
<pmjdebruijn> soc: you only need to look it up onc
<pmjdebruijn> once*
<pmjdebruijn> soc: check git, lookup the version, tarball it, call it ttf-droid_FONTVER+gitREVISION.orig.tar.gz
<pmjdebruijn> does git have revisions? or just dates?
<maxb> it has revisions, but they have no ordering, so are not suitable for version numbers
<pmjdebruijn> then i'd stick with checkout date I guess
<mok0> soc: also please note that defoma is going away soon
<hanska> mok0: eh ehm.
<hanska> mok0: "- Homepage: field should be changed to Vcs-Git: (because it is actually a VCS browser page) " -- this is WRONG
<mok0> hanska: I know, see next comment :-)
<hanska> mok0: Vcs-* fields are meant for *packaging* VCS's, not upstream code's! ;)
<mok0> hanska: uhh
<hanska> mok0: no, lol :D
<hanska> also Vcs-Browser is for packaging repo
<ScottK> mok0: He's right.
<mok0> Ydrrk
<hanska> mok0: :)
<mok0> I need to read up on policy
<hanska> soc: I reviewed your package too.
<soc> pmjdebruijn: afaiu, everytime i download the fonts, i have to look up the version in fontforge, not only once
<soc> hanska, mok0, pmjdebruijn: thanks!
<hanska> soc: I'm trying to write a get-orig-source for you, if you don't mind.
<soc> sure, i would be absolutely happy about that
<soc> the git line is most probably git clone git://android.git.kernel.org/platform/frameworks/base.git
<soc> who is dpaleino? is that you, hanska?
<ScottK> soc: It is.
<hanska> soc: yes
<mok0> hanska: just to add to the existing confusion... :-)
<soc> :-)
<hanska> mok0: I'm a picky Debian guy, lol :P
<soc> ah ok, regarding: "- the long description seems taken from some kind of online journal -- are you allowed to do it? If no, please rephrase it properly, or do it yourself; "
 * liw wonders about the choice of "hanska" as a nick
<soc> it's from the press release, i assumed that would be the right way
<hanska> liw: just "invented" it somehow (who remembers!) about 15 years ago, or so
<soc> at least that text has printed "PRESS RELEASE" on the top...
<liw> hanska, are you aware that it's a word in Finnish, meaning glove?
<hanska> liw: no, really :)
<mok0> I think you are allowed to use press releases freely
<soc> mok0: you said that defoma is going away, what will happen to that?
<soc> a, good
<hanska> mok0: I suppose that too -- but you might never know.
<ScottK> mok0: Depends on what the license of the press release is.
<hanska> exactly.
<mok0> soc: I don't know, but it seems that way from d-d
<soc> d-d?
<mok0> soc: debian-devel mailing list
<hanska> mok0: I can confirm that. defoma is outdated, undermaintained, $bad_adjective_here
<soc> but how will font configuration work then?
<mok0> may no fonts in lenny+1? :-P
<hanska> mok0, soc: there was some ongoing project on replacing it (I admit I hacked it a bit too), but nothing concrete yet
<hanska> mok0: that's called squeeze! :P
<mok0> hanska: oh yes.
<soc> i don't understand "- the long description seems taken from some kind of online journal -- are you allowed to do it? If no, please rephrase it properly, or do it yourself; "
<mok0> hanska: what Toy Story animal is that?
<soc> oopps, wrong line sorry
<hanska> mok0: wikipedia -->
<hanska> ;)
<soc>  i don't understand " - you forgot the boilerplate (s) -- itâs just ONE upstream author! ;) "
<hanska> soc: minor issue ;)
<hanska> soc: "Upstream Author:" instead of "Upstream Author(s):" :)
<soc> ah ok
<soc> " - you state that Droid is a trademark of Google Corp. Are you allowed to use it in the package name, the descriptions and so on? "
<soc> that's a very good question ...
<mok0> hanska: a 1970's English New Wave band??
<hanska> soc: we in Debian had many problems with trademarks *cough* firefox *cough*
<ScottK> hanska: That's because of restrictions in mozilla's code license.
<mok0> hanska: ah, those little cute aliens
<hanska> mok0: yep
<hanska> ScottK: the MPL doesn't talk about "Firefox" or "Thunderbird" or "The world with the fox around it"... that's a general-purpose license
<hanska> ScottK: the fact is, Mozilla Corp. has trademark over those things -- thus can enforce it / prohibit anyone at will to use those.
<hanska> -- and same could do Google.
<soc> hanska: mhh, so should i rename the package to something stupid?
<hanska> soc: no, just ensure you can
<hanska> soc: example, mail the author and ask him :)
<soc> which author?
<hanska> upstream.
<soc> google bought the whole copyright from Steve Matteson ...
<hanska> soc: then contact Google! :)
<soc> mhh, is there a email address where i get an answer in the next few years?
<hanska> soc: eheh, good question.
<soc> i always thought, that a trademark is no problem as long as it doesn't restrict your rights?
<soc> because then debian couldn't use Linux for instance
<hanska> soc: yes, as long as the holder does not enforce you not to use it
<hanska> soc: but then neither Ubuntu, Slackware, Gentoo, ...
<hanska> ;)
<soc> but that debian problem was that to use the trademark, mozilla wanted specific conditions to be met
<soc> this isn't the case here, afaiu
<hanska> soc: however, I'm probably being too picky. Ask an ubuntu dev, maybe in Ubuntu this are different
<hanska> soc: did you read any condition anywhere?
<soc> hanska: no, no conditions
<hanska> soc: wait, I'll try to look in upstream's homepage
<soc> and normally, poeple are allowed to use trademarks, as long as they don't dilute that brand's image
<hanska> soc: you can't suppose things.
<soc> but i want to make sure, that the package can be used in ubuntu _and_ debian
<hanska> soc: that's great :)
<ScottK> AFAIK, trademark isn't a problem unless it's known to actually be a problem.
<soc> so solving that problem is necessary
<mok0> soc, btw, you should include the files NOTICE, MODULE_LICENSE_APACHE2 and README.txt
<soc> ScottK: ah ok, thanks
<soc> only in the source build?
<hanska> soc: http://www.android.com/branding.html
<hanska> 03/ Android Custom Typeface
<hanska> The custom typeface may not be used.
<hanska> I suppose that's a problem.
<hanska> but then again:
<hanska> For applications, you can use 'Droid' as part of the name if the application adheres to the Developer Content Policy.
<hanska> Policy being http://www.android.com/market/terms/developer-content-policy.html
<mok0> hanska, it says nothing about "droid"
<hanska> mok0: right, sorry, the fonts are under APL-2 nevertheless
<hanska> however, that's the link we looked for
<ScottK> There is also http://www.google.com/permissions/index.html
<ScottK> Which says to me that you may need a new name.
<mok0> "Android" can be used as a descriptor
<hanska> ScottK: the link I gave before says the contrary
<hanska> The word 'Android' may be used only as a descriptor, 'for Android'. If used with your logo, 'for Android' needs to be smaller in size than your logo. First instance of this use should be followed by a TM symbol, 'for Androidâ¢'.
<hanska> For applications, you can use 'Droid' as part of the name if the application adheres to the Developer Content Policy.
<ScottK> OK.
<ScottK> Dunno.
 * ScottK goes back to $WORK.
<soc> so is it now ok to use "droid" or not?
<mok0> apt-cache search google|grep google
<mok0> A whole bunch of packages have the word "google" in them
<hanska> soc: who knows :/
<soc> so should we invent some stupid packagename now?
<hanska> mok0: http://www.google.com/permissions/guidelines.html
<soc> fedora is packaging it as droid
<hanska> that says you must fill in a form for permission, blablabla... not suitable for Debian :/
<hanska> soc: I suggest you to go with ttf-droid
<soc> is that ok for debian?
<hanska> uhm..
 * hanska dubious
<hanska> the fact is, there are two links/documents saying opposite things
<hanska> and both are kinda "official"
<soc> imo opinion the more specific one counts
<mok0> hanska: for example, libgoogle-perftools-dev  comes from Debian
<soc> and that is the one in the font directory ...
<hanska> mok0: I did your same apt-cache line, and there are packages with "google" inside
<mok0> hanska: /me thinks you're being paranoid here
<soc> ok, then i'll package it as ttf-droid
<hanska> mok0: probably, but you don't know debian-legal guys :D
<hanska> soc: go :)
<soc> and if someone complains, we need a stupid name
<soc> or should i choose ttf-android-fonts?
<hanska> mok0: I could ask debian-legal, or search there
<mok0> hanska: I'm sure they could have a 100-thread flamewar about it :-P
<hanska> ;)
<soc> would that be safer?
<hanska> soc: neither
<hanska> soc: ttf-android-fonts would have the same problems ttf-droid has.
<hanska> so, just go ttf-droid :)
<mok0> soc: go for ttf-droid
<mok0> :-)
<soc> ok
<soc> thanks for the advice
<soc> i'll upload a new package in a few minutes
<mok0> In any case, droid is not a trademark they own
<mok0> soc, but be sure to include _all_ files from the git repo in your tarball
<hyperair> mok0: got time for a review? http://revu.ubuntuwire.com/details.py?package=codelite <-- you've reviewed it before, and i've fixed a lot of stuff since then
<mok0> hyperair: ok
<hyperair> mok0: thanks
<soc> mok0: i thought it was ok to copy them into the right files in debian ...
<mok0> soc: no, they have to remain in the tarball as well, because that is distributed as part of the source package
<soc> ah ok
<mok0> soc: people could go to packages.ubuntu.com and download only the tarball
<soc> ah ok
<soc> is it allowed at least to clean up these files a bit?
<soc> do i have to put the ahem.ttf, android.mk, fonts.xml in there too?
<mok0> soc: yes, just do that to make things transparent
<mok0> soc: then the tarball is an exact copy of the git repo
<soc> but the ahem.ttf is missing an license
<soc> that is just some file to test the platform's hinting
<mok0> soc: hmm
<hanska> soc: do a repackaged tarball
<soc> mhhh, i guess i just take README, NOTICE and MODULE_LICENSE_APACHE2 to be safe
<hanska> soc: yes, but you have to specify what you removed
<soc> hanska: what is a repackaged tarball?
<soc> or what do i have to do for it
<hanska> what's the version number now?
<soc> Version 1.00 build 112
<hanska> 1.00~b112, right?
<soc> yes
<hanska> then, make it 1.00~b112+dfsg-1
<soc> what's dfsg?
<hanska> "dfsg" meaning Debian Free Software Guidelines
<mok0> hanska: that's a tilde right?
<soc> debian free software guidelines?
<hanska> mok0: yes
<soc> what does that mean?
<soc> that it has been verified to confirm?
<hanska> soc: yes. It's a common practice in Debian to mean that the package had something non-free, which has been removed
<soc> ah ok
<hanska> soc: so, you're removing ahem.ttf -- say that in debian/README.source
<mok0> hanska, soc, except the version should be -0ubuntu1 and not -1
<hanska> (or README.Debian, or whatever)
<hanska> mok0: right, I'm a Debian guy, remember :)
<mok0> s/version/release
<hanska> soc: you'll end up with 1.00~b112+dfsg-0ubuntu1
<hanska> how ugly :)
<soc> lol :-)
<mok0> hanska: it's so it will be superceeded when the package comes to Debian
<mok0> hanska: the ubuntu* part means there are ubuntu changes
<hanska> mok0: yep
<hanska> I know how dpkg --compare-versions works ;)
<hanska> (or was it just --compare? Bah!)
<mok0> hanska: sorry
<hanska> mok0: for what?
<mok0> hanska: didn't mean to lecture you
<hanska> mok0: are you kidding?!
<hanska> mok0: I'm fine! :)
<mok0> hanska: ok cool
<mok0> hyperair: I have to go -> dinner, not finished reviewing, but I will just submit the 1 comment I have so far
<hyperair> mok0: okay thanks
<LucidFox> Wow. Looks like I have been using Intrepid with the Hardy kernel all along, and only realized it today when an update introduced version mismatch to the NVIDIA drivers
<mok0> hyperair: looks almost ready though
<mok0> hyperair: I see nhandler is ready to advocate too
<soc> ok, new try
<hyperair> mok0: yeah.
<mok0> later, guys!
<soc> ok, that will take some hours i guess ... 11k/2091k ...
<ScottK> hanska: In Intrepid and Jaunty we have a apparmor profile for clamav that prevented (until today) signature updates in user directories.
<ScottK> hanska: So with your clamtk maintainer hat on I wanted to let you know it's fixed in Jaunty so it should work now.
<hanska> ScottK: I was just upgrading clamtk to 4.08! :)
<hanska> ScottK: thank you, though.
<ScottK> hanska: The clamtk upstream contacted me and wanted to know why it worked everywhere except on Ubuntu.
<hanska> Ah. Yeah, we had some issues too on Debian, and hopefully we fixed those
<hanska> (wrong perms on signatures database)
<ScottK> I tested with your 4.07-1 package and it seemed fine.
<hanska> ScottK: I'm preparing 4.08-1 now, I'll ping you when it's ready
<ScottK> OK.
<ScottK> I've put in to get 4.07-1 backported to Intrepid, so that should get some more real world use.
<hanska> Thank you Scott.
<hanska> ScottK: is it ok to you if I switch to dh7-debian/rules ?
<soc> ScottK, hanska: i uploaded a new one
<soc> should appear soon
<hanska> soc: busy right now, will have a look later :)
<ScottK> hanska: That would cause me some complications for backports, but I'll manage.
<hanska> ScottK: I can just stay with dh6, it's not a problem.
<ScottK> hanska: Actually 6/7 are equally problematic for me.
<hanska> 5? :)
<ScottK> I want to, eventually, get all the way back to Dapper.
<ScottK> Yes.
<ScottK> Don't worry about it though.
<hanska> uhm, ok... also because in Debian I have dh6 since 3.03
<hanska> s/3.03/4.04/
<hanska> :)
<hanska> ok, going dh7 then, sorry.
<ScottK> Yes and you've got dh7 in b.p.o too.
<maxb> but:  debhelper | 7.0.13ubuntu1~hardy1 | hardy-backports | source, all  <--- doesn't that make it ok?
<maxb> oops
 * ScottK looks at jdong to go ahead and backport dh7 to Gutsy and Dapper.
<maxb> evidently I can't tell the difference between hardy and dapper
<ScottK> ;-)
<soc> http://revu.ubuntuwire.com/revu1-incoming/ttf-droid-0901071830/lintian
<soc> should i name my original package ttf-droid_1.00~b112+dfsg.orig.tar.gz now?
<pmjdebruijn> lo
<pmjdebruijn> in the past I requested a sync request for ufraw for jaunty, which was passed...
<pmjdebruijn> however there a new version again, which I'd like to have synced again... should I file a new bug report? or just comment on the old one?
<Laney> make a new one please
<ScottK> pmjdebruijn: If the sync for the existing bug has already been done, you have to make a new one.  If it were still pending, you could edit the existing bug.
<pmjdebruijn> ok
<soc> ok, new upload: http://revu.ubuntuwire.com/details.py?package=ttf-droid
<pmjdebruijn> ScottK: are Please sync ... request periodically checked?
<ScottK> pmjdebruijn: You need to subscribe ubuntu-universe-sponsors to get a MOTU to review.
<ScottK> Yes.
<pmjdebruijn> ScottK: I didn't previously do that?
<sebner> !sponsorship | pmjdebruijn
<ubottu> Sorry, I don't know anything about sponsorship
<sebner> grrr
<ScottK> pmjdebruijn: Dunno.  You should have if you didn't
<pmjdebruijn> ok, subscribing now
<pmjdebruijn> thanks for your help
<slytherin> what does it take to join u-u-s team if I am already a motu?
<ScottK> slytherin: Asking.
<slytherin> oh. I thought there was some procedure.
<ScottK> There is. That's it.
<persia> slytherin, You want to be UUS?  I'll do it now if you do.
<slytherin> persia: I have been thinking for some time. But it doesn't make sense to do it now as I have many things in TODO list.
<persia> OK.  Just let any of the admins know, and they'll add you when you want to join.
<slytherin> persia: sure.
<persia> Also, you might want to merge https://launchpad.net/~onkarshinde-ubuntu :)
<slytherin> persia: Seeing that page first time. :-)
<slytherin> calc: did you see my reply about jaxme build failure?
<ScottK> slytherin: It doesn't hurt to go ahead and join.  It doesn't get you any extra bugmail.
<soc> pmjdebruijn, hanska, ScottK: i tried to fix all comments, is this ok now? http://revu.ubuntuwire.com/details.py?package=ttf-droid
<slytherin> ScottK: Right. But then I may get distracted. :-D
<oojah> Hi, I've got some queries on handling man pages when packaging. First off, I'm not really sure about how the make install rules of a package to install a man page and the dh_installman complement one another. If I've got a package that installs example.1 to /usr/share/man/man1/example.1 then how does dh_installman come into things?
<broonie> oojah: dh_installman is a more specialised version for man pages - you should use it in preference to manual dh_install of man pages.
<ScottK> oojah: Did you try "man dh_installman" - Somewhat ironically, that's where you should probably look.
<oojah> Yeah, man dh_installman all makes sense, but what if the man page installation is already handled in the debian/rules install target like "$(MAKE) install DESTDIR=$(CURDIR)/debian/trafshow
<oojah> "
<calc> slytherin: here?
<slytherin> calc: yes
<calc> slytherin: you said something about finding out why jaxme ftbfs?
<slytherin> calc: yes, I had added comment on the cat-all MIR bug.
<slytherin> catch-all
<calc> heh iirc rt.jar causes build failures on OOo as well unless you use a patch
<calc> slytherin: did you see anything about why xom randomly ftbfs?
<slytherin> calc: No. The error says stack overflow. And it is failing on i386 machine as well. So nothing arch specific.
<slytherin> calc: jaxme and xom are the only packages remaining to be fixed.
<calc> i managed to build xom most of the time on my machine, it occassionally ftbfs, but i have no idea why it only happens sometimes
<calc> would that be a bug in it or the jdk?
<slytherin> hmm
<slytherin> can't really say
<calc> but it seems to ftbfs every time on the buildd
<calc> ok
<calc> if i could manage to make it fail often i could test it on debian to see if it is something wrong with or jdk, but it works for me most of the time so it would be hard to verify
<calc> s/or/our/
<calc> i'm preparing OOo 3.0.1-2ubuntu1 packaging atm, but will try to beat on those two after i am done
<calc> the current debs are broken and users are filing lots of bugs about them so it would be helpful to get them at least in the ppa asap
<slytherin> calc: Let me know which solution do you prefer for jaxme so that I can fix and upload it.
<calc> slytherin: option 2 sounds like it might be easier for you to do?
<slytherin> yes
<calc> slytherin: option 2 won't actually break anything will it?
<slytherin> calc: not really.
<calc> ok
<calc> yea that would probably be best then
<slytherin> Ok. It will be done in an hour or so.
<calc> thanks :)
<calc> then i just need to determine whats up with xom, heh :)
<calc> but its better if we don't fix them both before the new OOo is uploaded anyway
<calc> that way i won't kill the buildds with two builds in a row
<slytherin> but will OOo build without those two? As the build seem to have failed because of jaxme and xom.
<slytherin> Oh. I understood. You mean if we fix the packages right now, OOo will get built and then it will be rebuilt after you upload new version.
<calc> yea
<calc> better to be stuck in depwait until i upload the new version
<calc> the new one will be stuck at depwait but then i can determine what is wrong with xom
<slytherin> fine. let me know when you upload new version.
<calc> so it will only tie up the buildds for one day instead of two :)
<slytherin> I will keep jaxme ready.
<calc> you can go ahead and upload jaxme when you are done with it, xom is broken too so will keep it at depwait
<slytherin> ok
<slytherin> calc: there is no patch system. should I patch the sources inline?
<calc> slytherin: is it cdbs?
<slytherin> calc: no, debhelper
<calc> slytherin: i guess patching inline is ok then, but make sure to document what you did in the changelog :)
<slytherin> yup
<khashayar> I'm still trying to get a hang of how to proceed when I create packages for new upstream releases. Is this good it: https://wiki.ubuntu.com/SponsorshipProcess?
<khashayar> In this case, qtractor-0.3 was recently released, but only 0.2.1 is in jaunty (and debian, fwiw).
<slytherin> khashayar: you need to file a bug, attach the .diff.gz to the bug and subscribe appropriate sponsors team.
<calc> actually debdiff would probably be better
<calc> but agreed for the rest of the process :)
<khashayar> thanks!
<calc> khashayar: debdiff is a program that takes two diff.gz and makes a diff of them
<calc> that way the sponsor can more easily tell what you have changed in the packaging
<khashayar> I thought debdiff was only used when one updated a package with the same orig.tar.gz. No?
<james_w> DktrKranz: I filed a sync request for bash-completion, did you get to look at it yet?
<calc> khashayar: i might be wrong but i think it works across orig.tar.gz as well, if the output looks wrong then just go with the diff.gz :)
<calc> its been a while since i have used debdiff
<DktrKranz> james_w, not yet. I was planning to dig through ubuntu bug reports to triage them a bit and try to reproduce them with current Debian version, but please go ahead :)
<khashayar> Alright, thanks a lot. I'll see where it gets me.
<james_w> DktrKranz: I was doing some of that now, but I'm about to break for today, so there's plenty more
<james_w> there's also a bunch of fixes sat in bzr as well
<calc> khashayar: the process is the same except if debdiff works (can't recall) then you just run that at the end after you get your new diff.gz
<DktrKranz> james_w, cool. I'll do some in the next days (likely on weekend)
<khashayar> calc: Alright, I'll try that.
<slytherin> calc: khashayar: I think we stopped using debdiff for new upstream versions long time.
<khashayar> slytherin: alright, so I'll attach the diff.gz. It looked much better anyway :-)
<calc> slytherin: ah ok
<calc> khashayar: its usually really obvious if debdiff blew up on a diff :)
<calc> thinking back i probably tried to use debdiff in the manner i was stating above when it blew up ;-)
<slytherin> khashayar: previously you also needed to install interdiff when you were submitting diff between two upstream versions. But as I said we do not use that process anymore.
<calc> but its been a long time since i've updated a new upstream release of a package that way
<calc> i mainly stick to beating on OOo
<directhex> wheeee, openjdk for a mere 30 meg on disk
<slytherin> directhex: what?
<directhex> slytherin, IKVM.OpenJDK.dll!
<slytherin> ah. :-)
<slytherin> does it work well?
<directhex> slytherin, i suspect this release (0.38) is a big step up from the release in the archive (0.34) which was based on classpath
<slytherin> hmm
<soc> i treid to fix all problems which were mentioned in the comments and reuploaded it. someone interested in reviewing it? http://revu.ubuntuwire.com/details.py?package=ttf-droid
<directhex> slytherin, in real terms? no idea. ought to be reasonably functional for command-line apps. the AWT implementation is apparently only PoC
<persia> directhex, You got it to work?  Nice!
<directhex> persia, not only work......... lintian-clean!
<slytherin> directhex: Is it getting included on CD? Or is that a jaunty +1 plan?
<directhex> slytherin, nah, not my place to dictate what goes on the cd. i just thought it was an interesting project
<persia> I doubt ikvm will end up as the default JDK
<directhex> slytherin, it's certainly a bit slimmer than a regular openjdk install
<persia> Supposedly, Java will get refactoring with Java 7, but that's not for a bit yet.
<directhex> i'll have a little play in a sec, just gotta add README.source to the docdir
<directhex> persia, what kind of refactoring possible whilst maintaining backward compatibility? java's much less segmented than CLI
<directhex> stick an "is" in the middle of that somewhere if you like
<persia> directhex, I'm fuzzy on the plan, but my loose understanding is that much of what is now the "JDK" will instead become "modules" that are essentially libraries, so you'd have a dependency map, and only pull the parts you need.
<persia> I imagine one could define a "legacy" module that pulled all the old default APIs.
<directhex> persia, so learning from mono, then? excellent.
<directhex> persia, AFAIK IKVM 0.40 was doing something like that by itself - http://weblog.ikvm.net/CommentView.aspx?guid=f5cd40bc-d6ff-4fa1-8c0b-33a07f7ef967
<persia> directhex, ikvm is the forefront of experimentation :)
<Amaranth> IKVM is our one hope for a single VM for all this stuff :P
<directhex> Amaranth, i thought that was Parrot!
<Amaranth> Everyone is targeting the CLR these days
<directhex> Amaranth, i think CIL is better designed for multi-language use than java bytecode. it's easier to inject weird languages into it
 * slytherin plans of creating a meta-package ubuntu-mono-desktop that pulls in as many mono apps as possible. :-D
<directhex> slytherin, wait a sec, are you trying to beat my score for attacks-on-boycottnovell? :o :(
<Amaranth> We're soon going to have Javascript, Python, Mono, Java, and Ruby in our desktop
<Amaranth> It's going to suck
<directhex> Amaranth, i'll package ironruby once it's got a tarball release
<Amaranth> directhex: Different API
<slytherin> directhex: nope. that honour is yours. :-P
<Amaranth> directhex: It's not a drop-in replacement for ruby, is it?
<Amaranth> I know IronPython isn't a drop-in replacement for Python
<directhex> Amaranth, i think it is. it's being used to run tests
<directhex> ipy can drop-in for simple things, but nontrivial stuff you're right
<Amaranth> That's because Python is "batteries included"
<Amaranth> Even then, GTK# is not a compatible replacement for pygtk or the ruby binding
<directhex> how about php-gtk2? :o
<superm1> jdong, ping.  Any ideas on the VLC, patches for vdpau, how they're looking?
<superm1> jdong, nvm, i dont see it in normal git trees at all, so probably not ready yet
<directhex> dpkg-source: info: building ikvm in ikvm_0.38.0.2+dfsg-1.diff.gz
<directhex> i do wish this build didn't need >1 gig of ram
<directhex> does openjdk do that?
<slytherin> directhex: you mean build of openjdk? or builds using openjdk?
<directhex> slytherin, building openjdk
<slytherin> directhex: never tried. :-(
<directhex> slytherin, ikvm calls javac, with a seemingly required 1.5 gig reserved, to build its openjdk dir
<Amaranth> ooh zero punctuation got a new video player
<Amaranth> it's widescreen, even though the video isn't
<directhex> i.e. -J-Xmx1536M
<directhex> Amaranth, probably escapist-wide
<slytherin> directhex: is that much ram really needed?
<directhex> slytherin, "free" says yes :(
<directhex> slytherin, i'm 11% into swap, and i have 2 gig
<directhex> slytherin, and i tried slashing the number, with no success
 * directhex watches his gnome-system-monitor graph climb again
<directhex> slytherin, it peaks at 1020 meg used on my system, but better safe than sorry when settnig limits - just look at freecol
<slytherin> how do I make uscan do the repacking of upstream source as well if I have get-orig-source target in debian/rules. What will be the option to be passed to uscan?
<Amaranth> ooh i said that in the wrong channel
<Amaranth> ooh i feel stupid now but it was funny and you should all watch it so...
<directhex> slytherin, the trivial example: http://paste.debian.net/25480/
<directhex> slytherin, can you suggest a command-line java app in the archive to test?
<slytherin> directhex: how about bsh? It is shell for java based scripts.
<slytherin> persia: any help about that uscan problem?
<directhex> slytherin, you've found a bug for me. how helpful!
<slytherin> directhex: What bug?
<directhex> slytherin, more problems with signed assemblies. not the first i've had with ikvm.
<slytherin> :-)
<directhex> ikvm-0.38.0.2+dfsg/ikvm-0.38.0.2/openjdk/Configuration.java:    String default_awt_peer_toolkit = "ikvm.awt.NetToolkit, IKVM.AWT.WinForms, Version=0.38.0.2, Culture=neutral, PublicKeyToken=13235d27fcbfff58";
<directhex> GAH!
<directhex> bloody jeroen
<directhex> slytherin, sure bsh is X-less? the stack trace is full of java.awt
<slytherin> directhex: must be some non-essential functionality.
<slytherin> let me find some other application.
<slytherin> directhex: how about ant. :-D
<directhex> root@mortos:/usr/share/java# ikvm -jar ant-launcher.jar -version
<directhex> Unable to locate tools.jar. Expected to find it in /.virtual-ikvm-home/lib/tools.jar
<directhex> Apache Ant version 1.7.1 compiled on November 10 2008
<persia> slytherin, which problem again?
<persia> Oh, I see.
<persia> Just put uscan --repack in the get-orig-source rule.  Works for .zip, .bzip, .tbz, .tbz2, .tar.bz2
<slytherin> persia: When I do uscan I want the upstream tarball to be modified and repacked. I have get-orig-source target in rules file but don't know how uscan will use it
<persia> The problem with that it that it's not the same checksum that way: you probably want to do it manually with gzip -9nf
<directhex> hm. who feels like filing a bug against quilt? i'm enormously busy
<slytherin> persia: it is a different case here. upstream provides a .jar and I have to also remove some .class files while repacking.
<persia> uscan doesn't use the get-orig-source target: it needs to be called by `debian/rules get-orig-source`
<persia> Often the get-orig-source target includes a call to uscan.
<directhex> Usage: quilt [--trace[=verbose]] [--quiltrc=XX] command [-h] ...
<directhex>        quilt --version
<directhex> Commands are:
<directhex> /usr/bin/quilt: line 42: column: command not found
<soc> hi, i wouldn't be so annoying normally but my holidays are almost over and i want to get that package finally in, so that i can sleep well again ... http://revu.ubuntuwire.com/details.py?package=ttf-droid might be worth a look :-P
<slytherin> persia: but even after that it will not retrieve new upstream version, will it?
<persia> slytherin, You should construct the get-orig-source rule so that it does get the new upstream, edit as needed, and produce the orig.tar.gz.
<directhex> persia, sounds like ikvm!
<slytherin> persia: currently it extracts upstream version from latest changelog entry. How to I modify it to get new upstream version?
<persia> slytherin, OK.  Construct a watch file such that uscan --force-download grabs the latest .jar.
<persia> Then call uscan in your get-orig-source rule, and use the downloaded .jar as the basis for your .orig.tar.gz creation
<slytherin> hmm, will have to take a look.
<slytherin> persia: looks like the solution is to move the repack code to orig-tar.sh which gets called when get-orig-source is called.
<persia> I suppose.  I'm not a big fan of having get-orig-source call shell scripts: I prefer to just do it in make, but that could work.
<slytherin> anyway, I am too tired to try any of that.
<persia> Understandably: it's rather late :)
<slytherin> yes, I am I am trying to fix jaxme for last 1 hours.
<Laney> siretart: Hey, have any insight on the transcode ftbfs? bug #311102
<ubottu> Bug 311102 on http://launchpad.net/bugs/311102 is private
<Laney> bug #311202 sorry
<ubottu> Launchpad bug 311202 in transcode "FTBFS with new ffmpeg in jaunty" [Medium,Confirmed] https://launchpad.net/bugs/311202
 * siretart looks
<siretart> Laney: looks like transcode needs to be updated for the new version ffmpeg. have you checked if  there is a new upstream available?
<Laney> there is
<siretart> it seems the version of transcode we ship is pretty old. try updating it to 1.0.7 and see if that helps
<hanska> ScottK: 21:36 <BTS> clamtk 4.08-1 uploaded by David Paleino <d.paleino@gmail.com> http://packages.qa.debian.org/clamtk
<slytherin> calc: jaxme is taking too much time to fix. :-( I will look into it tomorrow.
<calc> ok no problem :)
<LaserJock> hi all
<LaserJock> anybody feel like a little packaging fun?
<quadrispro> anyone on bug #311023?
<ubottu> Launchpad bug 311023 in idjc "FTBFS with new ffmpeg in jaunty" [Medium,Confirmed] https://launchpad.net/bugs/311023
<quadrispro1> bobbo: are you around?
<bobbo> quadrispro1: yep
<quadrispro1> bobbo: great! I have a bug for you :)
<quadrispro1> bobbo: bug #311023 (we have some issues with quadr-o-matic, it doesnt want build anything for jaunty...)
<ubottu> Launchpad bug 311023 in idjc "FTBFS with new ffmpeg in jaunty" [Medium,Confirmed] https://launchpad.net/bugs/311023
<Laney> muhahaha ffmpeg
<bobbo> quadrispro1: I'll have a look
<quadrispro1> thank you!
<bobbo> quadrispro1: mind if I msg you?
<quadrispro1> bobbo: no problem :)
 * persia likes to see discussions about packages in-channel, so others can learn or comment: of course, if it's not package-related, ignore this :)
<Laney> yay for transcode building
<Laney> siretart: Would you mind reviewing/tweaking/uploading if I provide the .diff.gz on a bug? I'm not totally confident with this package...
<bobbo> persia: hehe, not packaging related, don't worry
<Laney> or anyone else?
<Laney> oh, rats, it failed anyway
<bobbo> If we rebuild a package with no Ubuntu changes (*-1build1) then want to make changes to it in Ubuntu, should the version number be *-1ubuntu1, or do we need to mention the old rebuild?
<Laney> why can't you do both?
<sebner> bobbo: -1ubuntu1
<bobbo> sebner: ok, thanks :)
<Laney> I don't see why that version cannot contain the last changelog entry
 * Laney suspects he misunderstands the question
<sebner> Laney:
<sebner> 1) you have a debian package
<maxb> -1ubuntu1 rather than -1build1ubuntu1, I expect
<vorian> in your case, since the last version was debian 7.7-1, then yes, it should be 07.7-1ubuntu1
<sebner> well
<sebner> first
<sebner> 1) -1
<sebner> 2) -1build1
<sebner> 3) -1ubuntu1
<Laney> but 3) contains changelog entries from 2) and 1)
<sebner> Laney: sure
<quadrispro1> bobbo: it's ready
<quadrispro1> hi sebner
<maxb> Whilst we're on the topic of versions - the PPA guide says to increment the revision and append ~ppaN - but what does that mean for a synced debian package without ubuntu changes?  Would 1.0-1 become 1.0-2~ppa1 is wrong if a -1ubuntu1 is made. So, would the hypothetical best ppa version be 1.0-1ubuntu0~ppa1 ?
 * sebner winks quadrispro1 
<maxb> erm, sorry for the grammar failure above :-)
<persia> maxb, Personally, I'd recommend using -0~ppaX where X increases for PPA versions of unpackaged code.
<LaserJock> only if there isn't a -1 though, right?
<persia> For PPA versions of packaged code, I'd think using ${existing-version}+ppaX would be safest.
<persia> LaserJock, For unpackaged code.
<LaserJock> if 1.0-1 already exists you'd want 1.0-1~ppaX I'd think
<persia> No, I'd want 1.0-1+ppaX, to sort above 1.0-1
<maxb> But, you want the ppa version to be greater than the existing version but less than any future one
<persia> maxb, Right.  It's a gamble, but since + has a very low sort value, there's a good chance that you're safe using +ppaX to an existing package.
<maxb> persia: interesting... and probably saner than what https://help.launchpad.net/Packaging/PPA#Versioning recommends
<persia> maxb, Perhaps you'd like to update that page?  It's just a wiki.
<LaserJock> persia: your right about ~ vs +, my bad
<LaserJock> *you're
<Laney> deja vu?
<Laney> I swear we had a similar conversation before (r.e. ppa versioning)
<persia> Actually, I don't like + so much anymore.
<persia> `dpkg --compare-versions 1.0-0ubuntu1 gt 1.0-0+ppa1 && echo true` doesn't give the result I want.
<persia> I'm not sure why though.  'u' should be higher than '+'.
<LaserJock> odd
<maxb> argh, I was following the same misconception as you. But actually, the sort order is ~ digit alpha other
<persia> Indeed.
<persia> Oh, bother.
<persia> In that case, I suppose -00ppaX might be safer.
<persia> and dpkg --compare-versions agrees with that.
<maxb> I'm fairly sure that 00 will behave identically to 0
<persia> Oh well.  -0ppaX then.  Still sorts lower than -0ubuntuX or -1, and I'm not interested in non-Ubuntu non-Debian upgrade path conflicts right now.
<persia> (and yes, 0ppa1 and 00ppa1 are considered identical)
<ScottK> hanska: Did you file a sync request?
<directhex> persia, i got a swing hello world app running in ikvm, but i can see why they call the awt implementation proof-of-concept
<directhex> persia, it's not particularly usable
<persia> heh.
<persia> ikvm is *all* proof-of-concept.
<ScottK> hanska: If so, what's the bug number?
<directhex> persia, how many of the 20k or so source packages in the archive aren't?
<directhex> persia, isn't linux just a filler kernel until hurd is ready? ;p
<sebner> hurd \o/
<LaserJock> directhex: I thought it was until the python kernel was ready? ;p
<directhex> LaserJock, never used perl-linux?
<persia> directhex, Umm...  But ikvm is *even-more-so*
<KIAaze> hi, I'm trying to package an application using an unpackaged library
<KIAaze> to do this, I tried creating a local apt repo as indicated here: https://wiki.ubuntu.com/PbuilderHowto#Building%20With%20Local%20Packages
<KIAaze> but I get this error when running dput:
<KIAaze> Successfully uploaded packages.
<KIAaze> Not running dinstall.
<KIAaze> mini-dinstall [-1215132784] ERROR: Unable to install "/var/cache/archive/mini-dinstall/incoming/hello_1.0_source.changes"; adding to screwed list
<directhex> persia, it's still worth having, IMHO. it's an interesting package
<directhex> persia, and it enables you to use java libs (albeit with an unpleasantly large dep on IKVM.OpenJDK.dll) in CLI apps, which is neato
<LaserJock> quick sanity check, are the nvidia drivers shipped on the CD?
<oojah> I don't suppose anybody would consider reviewing the package I just uploaded, ralcalc? It's a quick to use command line calculator. I would leave it to get processed in due course, but I'm sure I've commited every packaging sin under the sun so thought I should give myself more time to fix it. http://revu.ubuntuwire.com/details.py?package=ralcalc
<soc> someone interested in reviewing http://revu.ubuntuwire.com/details.py?package=ttf-droid ? it's a small package, with all fixes from the comments
<superm1> LaserJock, on the DVD
<LaserJock> oojah: the packaging looks pretty good on quick inspection
<superm1> they're not installed, but the packages are there
<LaserJock> superm1: but they aren't on the CD?
<superm1> LaserJock, no they're not
<superm1> you have to use jockey to turn them on
<LaserJock> dang
<superm1> CD is quite filled
<LaserJock> a friend of mine is trying out Ubuntu for the first time and I told him they were on the CD
<LaserJock> he's got no internet
<superm1> well that makes it more difficult
<LaserJock> he's also using gutsy
<LaserJock> I think I'll tell him to maybe get the Intrepid DVD or something
<superm1> in gutsy the kernel module is on the CD, but the driver isn't
<oojah> LaserJock: I guess that's a good start :)
<Laney> oojah: Remove the boilerplate from rules
<Laney> oojah: Do readme.txt and ChangeLog get installed in /usr/share/doc/ralcalc?
<oojah> Laney: ChangeLog I remember for certain, readme.txt I can't remember. readme.txt is all covered in the man page though tbh.
<Laney> It might be nice - I know I sometimes go to http://localhost/doc/<package> to see what's what
<oojah> ok
<Laney> you should just be able to put it in debian/docs
<oojah> Do I need to worry about http://revu.ubuntuwire.com/report.py/legal?upid=4445 ?
<Laney> not if that's listed in copyright
<oojah> Right.
<Laney> oojah: Run lintian over your binaries too and see if anything comes up
<Laney> (I don't know if it will, it's just a good check to do)
<oojah> Good point, I only ran it on the sources.
<Laney> I always forget
<pochu> pbuilder runs it for me
<pochu> on every build
<jmarsden|work> oojah: It's not a packaging issue, but... wouldn't something like   function = () { echo "scale=8; $@" |bc -lq ; }  # get you more power than ralcalc and the same "easy" UI, using bc underneath?  What is the intended user base for ralcalc on Ubuntu?
<oojah> jmarsden|work: A valid question :)
<jmarsden|work> So... you're packaing it just to learn packaging, basically, not because ralcalc is actually useful?
<oojah> I find it most useful because I always do calculations with a variety of SI prefixes.
<oojah> I use it all the time and others have found it useful enough from my ppa to blog about it and do translations.
<oojah> I doubt it'll ever have a huge user base, but there you go.
<jmarsden|work> Fair enough; I think I'll stick to bc, and use units when I am dealing with stuff than needs units (so I can ask what 8 megafurlongs per fortnight is in meters/second ;)
 * LaserJock <3 units
<oojah> It's a common conversion that one.
<directhex> my car gets 80 rods to the hogshead, and that's the way i like it!
<Laney> dpkg-deb: building package `transcode' in `../transcode_1.0.7-0ubuntu1_amd64.deb'.
<Laney> \o/
<oojah> I've done a new upload to fix what you suggested (and the lintian run on the binary!) and am now off to bed. Thanks very much for your comments everyone.
#ubuntu-motu 2009-01-08
<serialorder> i updated a po file but when I rebuild the package those updates are not included. I don't think the mo file is being remade. Anyone have any ideas on how I could fix this?
<jmarsden|work> serialorder: If you think the mo file *should* be being remade, then you'll want to read the Makfile(s) involved and find out why that is not happening, and perhaps edit debian/rules a little to make sure that *does* happen during your build target?
<jmarsden|work> However, I'm not sure if the whole "Ubuntu does its own translations" deal comes into play with things like this... if it does, I know nothing about how all that works!
<ScottK> jmarsden: That all happens on the buildds.  For local build tests it shouldn't come into play.
<jmarsden|work> OK, then the answer for serialorder is "read and understand your Makefiles, I think.
<jekil> how i can use dh_desktop?
<pochu> you only need it if you ship desktop files which define MimeTypes
<pochu> use it as "dh_desktop -p$package"
<pochu> in binary-install, IIRC
<jekil> thanks
<pochu> right, binary-install/$package
<pochu> yw
<directhex> does some poor bugger produce modules for Intel's x-fi sound cards for the ubuntu kernel? afaik they're far from entering mainline alsa
<soc> directhex: x-fi is from creative i thought ...
<directhex> sorry, i meant them
<directhex> i need more sleep, it seems
<jekil> pochu: and i must put my .desktop in /debian ?
<jekil> pochu: sorry, obviously yes
<pochu> jekil: and forward it to upstream if appropriate :)
<pochu> jekil: note that dh_desktop won't install the desktop file, you need to use dh_install or whatever to install it to /usr/share/applications/
<pochu> dh_desktop will take care of calling update-desktop-base in the post{inst,rm}
<jekil> pochu: thanks
<jekil> please sameonecan review/advocate? http://revu.ubuntuwire.com/details.py?upid=4448
<pochu> jekil: in debian/changelog, you should only put one changelog entry, and set the distribution to jaunty
<pochu> jekil: the Homepage in debian/control should go in the source stanza (where Standards-Version is)
<pochu> jekil: I don't have time for a full review, but the package looks good :)
<jekil> pochu: fixed and uploaded, thank you for your help
<pochu> jekil: you're welcome. good luck with it!
<masti83_> test
<pochu> james_w: hi :) that ppamadison script looks useful, I think it'd be suitable for u-d-t
<ScottK> TheMuso: Is speakup enabled in our Intrepid kernel?  I gather it was in Gutsy and then dropped in Hardy.
<TheMuso> ScottK: No its not. It was in edgy and feisty, and dropped for gutsy, and never to return, at least if I have anything to do with it.
<ScottK> TheMuso: Really?  OK.  I was just talking to someone who was going to use Fedora instead because of the lack.
<TheMuso> Meh good for them.
<ScottK> TheMuso: Is there a wiki page or something we have on what to use instead?
<TheMuso> They can use bad code all they want for all I care.
 * ScottK doesn't know about it at all.
<TheMuso> ScottK: Not really, wiki stuff for accessibility is lacking in that area.
<TheMuso> well wiki stuff for accessibility is lacking, period.
<TheMuso> ScottK: Unfortunately speakup last I checked suffers from bad code quality, and doesn't perform well on SMP systems or under heavy system load, as well as talking to serial ports directly, and not going through the needed kernel subsystems.
<ScottK> TheMuso: OK.  When I tell them no, what do I tell them we use instead?
<TheMuso> ScottK: We use gnome-orca, which is a screen reader for the GNOME desktop.
<pochu> Orca?
<ScottK> TheMuso: Thanks.
<TheMuso> pochu: yes
<pochu> ah, he already asked :)
<pochu> TheMuso: right, I didn't read your last message :)
<TheMuso> pochu: Right.
<StevenK> Orca certainly seems more pleasant than speakup
<StevenK> But you can't really compare user and system level code
<TheMuso> StevenK: Yep.
 * pochu waves good night
<agent47a> hi... i'm a noob trying to to help with Bug #293722 found here:  https://bugs.launchpad.net/ubuntu-manpage-repository/+bug/293722  .  I finished with the editing ctorrent.sgml .  I am using the workaround to build the binary without signing it: "debuild -uc -us"  But I don't know how to build the source.  debuild -S barfs with a fatal error "debsign failed".
<ubottu> Launchpad bug 293722 in ctorrent "Bad manpage for ctorrent" [Low,Triaged] https://launchpad.net/bugs/293722
<ubottu> Launchpad bug 293722 in ctorrent "Bad manpage for ctorrent" [Low,Triaged]
<ScottK> agent47a: debuild -S -us -uc
<agent47a> looks like debuild is run under debian subdirectory but debdiff runs in the package root directory.  is that typical?
<ScottK> debdiff diff debian package defined by two .dsc files you give it.
<ScottK> It doesn't matter so much where you run it.
<ScottK> Anyone got a patch system how to for Debhelper 7?
<ScottK> OK.  I give.  I'm tired anyway.
<ScottK> Good night all.
<jmarsden> Goodnight ScottK
<crimsun> ScottK: http://joey.kitenet.net/blog/entry/dh_implementation/
<ScottK> crimsun: Looking.  Thanks.
<crimsun> ScottK: sql-ledger is an interesting example if you're looking for integration with, say, quilt
<ScottK> crimsun: Thanks.
 * ScottK looks
<carandraug> hi everyone! I'm making my first package so I'm following the instructions in the ubuntu wiki with the program hello. In one of the steps, they mention to remove the *.ex, readme.debian, dirs, docs and info files from the debian directory. They say that's because the program's not complicated but the files can be needed for some packages. How do I know whether I should or should not remove them?
<hyperair> what are you packaging?
<carandraug> hyperair: I plan on package rubyripper in the future for a PPA. For now, I'm experimenting with the program hello, which they recommend in the tutorial
<carandraug> https://wiki.ubuntu.com/PackagingGuide/Complete
<hyperair> i see
<hyperair> okay, rubyripper doesn't have an init.d service right? so at least init.d.ex can be removed
<hyperair> basically you have to know what each of the .ex files is for and figure out if the functionality is required in your pacakge
<carandraug> hyperair: hmm.... can you give a me a link where I can read more about that, please?
<hyperair> heheh i don't think i managed to find anything of that sort. i sort of guessed what each one is for
<hyperair> usually the contents of the file tell you what it's for
<hyperair> in some kind of comment or whatever
<carandraug> hyperair: I see. I'll try to look inside the file then. Thanks
<jmarsden> man dh and man all of the dh_ tools should help you learn about this too
<hyperair> yeah that too
<hyperair> but i didn't read the dh_ manpages until very recently
<dholbach> good morning
<iulian> G'morning Daniel.
<dholbach> hiya iulian
<nellery> hi dholbach
<dholbach> hiya nellery
<nellery> dholbach: thanks for bringing up the issue with the developer applications!
<dholbach> nellery: we've been talking about it for a long time and I'm fairly happy with the proposal, I believe it will fix a lot of the issues that we see today
<dholbach> I haven't dug into the discussion yet today
<nellery> dholbach: it all looks good
<nellery> my only concern is that applicants may not be able to make it to the meetings
<nellery> due to time zone restraints
<dholbach> nellery: the plan was to rotate times and have it every 14 days
<dholbach> if that does not work out and there's very special requirements for meeting, I'm sure we can adjust with a one-off meeting or still discuss on the mailing list or something - we're going to be flexible
<dholbach> but the majority will be able to make it, I think
<nellery> dholbach: great, that would probably work out well.
<nellery> Thanks again
<dholbach> no worries
<didrocks> morning everyone!
<dholbach> hi didrocks
<Hobbsee> dholbach: you'd be able to get quorum, while meeting at a different time?
<dholbach> Hobbsee: quorum is a necessity
<Hobbsee> dholbach: I realise that, but i'm asking if it's actually going to happen, if you're meeting at a non-european-friendly time.
<Hobbsee> (although I realise that you'll mostly hold it in european timezones, but there will still be exceptions)
<dholbach> we will need to make sure - the meeting does not make sense otherwise
<Hobbsee> exactly
<persia> Well, it mostly must be in a European-freindly timezone, because a majority of the current councillors are in Europe.  That said, there's 14-18 hours of Europe-freindly timezones.
<Hobbsee> persia: indeed.
<Hobbsee> persia: i'm just asking in the case of australians, or similar people
<dholbach> for the special cases I'm sure we can work something out
<Hobbsee> persia: which is going to be directly during european night, in a lot of cases (11pm - 10am local, perhaps)
<persia> Trick is more balancing others: there are two, mostly diametrically opposed, slots that ought work for all MC members, although I'll admit neither is particularly ideal in Australia.
<dholbach> as I said in the mail: we're going to be flexible, if there's no way around using the mailing list, we use it
<jekil> please sameonecan review/advocate? http://revu.ubuntuwire.com/details.py?upid=4448
<evocallaghan> Hi
<evocallaghan> I'm having problems getting X to start on my distro I'm building, #xorg seems dead and #ubuntu is full of just end users. So sorry to ask in here as a last resort
<evocallaghan> OK here goes,
<evocallaghan> X fails to start saying it can't find fonts 'fixed'
<evocallaghan> Now the fonts exist in /usr/X11/lib/X11/fonts just fine
<evocallaghan> mkfontdir /usr/X11/lib/X11/fonts ; /usr/X11/bin/xset fp+ /usr/X11/lib/X11/fonts ; /usr/X11/bin/xset fp rehash
<evocallaghan> However this fails saying that xset can't open a display
<evocallaghan> Any ideas please?
<quadrispro> anyone on bug 188561?
<ubottu> Launchpad bug 188561 in macchanger-gtk "Close button of GtkAboutDialog doesn't work" [Low,Confirmed] https://launchpad.net/bugs/188561
<persia> evocallaghan, If you can replicate with Ubuntu, you're better off filing a bug.  If not, I'm not sure how we might help.
<evocallaghan> Hmm, I would have though there would be some skilled people in the area of xorg here that is all
<evocallaghan> persia: http://ubuntuforums.org/showthread.php?t=76046
<evocallaghan> So it happens on ubuntu as well
<evocallaghan> I will try to purge fonts like it says
<evocallaghan> nope :(
<agentblue9> i want to upgrade to the dev version from 8.10.  i'm still not sure how to do it ater looking at https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases ..  any hints greatly appreciated.
<persia> agentblue9, First off, thanks for testing, but expect things to break.
<persia> Try running `update-manager --devel-release`
<agentblue9> persia: thanks.  -d will also do, right?
<persia> Probably.
<agentblue9> persia: is it of any importance to do the 8.10 updates first before going to jaunty?  this is a fresh ubuntu 8.1 from cd.
<hyperair> dosen't matter
<agentblue9> hyperair: thanks!
<hyperair> you're going to be upgrading past that anyway
<hyperair> np
<agentblue9> ic, i'm going to click the Install Updates button now.  ;)
<hyperair> i think you should be clicking "Upgrade"
<hyperair> at the top
<hyperair> if you intend to upgrade to 9.04 that is
<agentblue9> hyperair: ah!  you're right.
<persia> agentblue9, I'd recommend doing the updates, in case someone already fixed an upgrade path issue, but it may not matter.
<hyperair> persia: upgrade path issue?
<persia> hyperair, Sometimes there's an issue upgrading a set of packages from one release to another.  Sometimes this can be fixed by an SRU.  Where possible, these are done.
<persia> Most of the upgrade path testing assumes application of available updates before upgrade.
<hyperair> i see
<agentblue9> persia: hmmm... i've already clicked upgrade.  oh well
<hyperair> you can always cancel
<agentblue9> ah... it gives a chance to cancel now.
<hyperair> it'll roll back the changes
<agentblue9> so tempted to go forward.
<hyperair> haha
<stefanlsd> agentblue9: btw, have you read the release notes?
<agentblue9> i think i went right past those.
<stefanlsd> agentblue9: have a look here - http://www.ubuntu.com/testing/jaunty/alpha2
<stefanlsd> agentblue9: known issues.  nvidia / ati may be a problem
<agentblue9> stefanlsd: d'oh
<agentblue9> i have a really old nvidia geforce2
<persia> agentblue9, Doesn't likely matter that much.
<stefanlsd> agentblue9: well, more specifically the propietry drivers may be a problem.  the opensource stuff should be ok, although you may not have accel
<agentblue9> ic... then i'm not too worried.
<hyperair> no accel means no compiz
<hyperair> anyway is DRI2 getting into jaunty, or has it already gotten in?
<hyperair> hmm looks like it's already in
<agentblue9> hyperair: compiz with flash 9 makes my firefox grey-freeze randomly in hardy.
<hyperair> pity.
<hyperair> wait a sec
<hyperair> are you upgrading to intrepid or jaunty?
<agentblue9> hyperair: talking about a different system.
<stefanlsd> -d must be jaunty
<hyperair> yeah
<agentblue9> upgrading from intrepid to jaunty.
<agentblue9> i wonder if freenx will work with jaunty
<mok0> hyperair, in codelite, what is the empty directory /usr/share/codelite/plugins/resources/ for?
<hyperair> for plugin resources
<mok0> hyperair: that are installed later?
<hyperair> yes
<mok0> hyperair: ok
<mok0> hyperair: advocated
<mok0> Oh, it'd be nice if dget would be called on a .dsc file when it's clicked in Firefox. Anyone know how to do that?
<hyperair> no idea
<hyperair> maybe a plugin
<hyperair> heh
<hyperair> should be functionality added to ubufox perhaps? =p
<hyperair> mok0: thanks
<hyperair> for advocating i mean
<mok0> hyperair: Thanks for _your_ work! :-) Now you need one more advocate
<hyperair> i'll wait for nhandler =)
<hyperair> after two advocates come along, is there anything else?
<directhex> mok0, dget's a bit commaand-liney for the console isn't it?
<mok0> hyperair: no, usually the 2nd advocate uploads the NEW queue.
<directhex> bah, for firefox
<mok0> directhex: yeah I guess
<hyperair> okay
<directhex> mok0, if there were a gdebi-esque tool for dsc, then you could just associate the file type
<mok0> hyperair: the archive-admin might reject it if issues are found
<hyperair> hmm
<hyperair> a GUI dget?
<directhex> mok0, i'd knock one together in c#, but i suspect people would eat my kidneys
<hyperair> heheh
<mok0> directhex: I would :-P
<directhex> hyperair, broadly useless, but yes, something to say "this is part of a source package, i'm getting the other bits, dawg, fo'shizzle"
<mok0> directhex: All the gui needs to do is to ask for a place to put the pacakge
<hyperair> mok0: don't you think a bash script + zenity would do?
<mok0> hyperair: err, I don't know zenity...
<hyperair> wait, dosen't dget only work on urls?
<mok0> hyperair: yes
<directhex> hm, true
<hyperair> yeah so you can't associate a script with the filetype
<directhex> okay, write an extension for it then. go go gadget xul!
<hyperair> heh i have no idea how to use xul
<mok0> The person writing such an extension would be a regular hero in the Debian/Ubuntu world...
<hyperair> agreed
<quadrispro> does anyone wanna have fun with a ffmpeg FTBFS? :D
<quadrispro> bug #311180 , it's waiting for a sponsor
<ubottu> Launchpad bug 311180 in mediatomb "FTBFS with new ffmpeg in jaunty" [Medium,Confirmed] https://launchpad.net/bugs/311180
<mok0> quadrispro: I'll take a look
<quadrispro> thank you mok0
<mok0> quadrispro: you are Allesio?
<quadrispro> mok0: yes
<mok0> quadrispro: you patched configure?
<quadrispro> yes
<mok0> quadrispro: why do you need to do that?
<Laney> ffmpeg doesn't care for compatibility
<mok0> quadrispro: it should be regenerated from configure.ac
<quadrispro> mok0: ah right, I can prepare a new debdiff
<mok0> quadrispro: of course that means editing debian/rules
<quadrispro> mok0: thanks a lot, i'm workin on it :)
<slytherin> geser: persia: Get ready for another circular build dependency problem . :-) - Enjoy the conversation here http://lists.debian.org/debian-java/2009/01/msg00001.html
<mok0> apt really ought to detect circular dependencies and either ignore them or complain
<directhex> yay, circular!
<directhex> when in doubt, bootstrap-binary it & pray for forgiveness?
<quadrispro> mok0: i have a question
<mok0> quadrispro: go ahead
 * directhex prepares his stock reply - "no, it shouldn't be purple; see a doctor"
<quadrispro> I think setting --with-ffmpeg-h in debian/rules isn't very helpful, because in aclocal the search path contains ffmpeg/, and this isn't correct (the correct path for avformat.h is 'libavformat/')
<quadrispro> ehm
<quadrispro> mok0: s/aclocal/configure.ac
<persia> slytherin, This is only a one-time thing, right?
<quadrispro> sorry
<persia> mok0, Sometimes you need them.  For example, gcc.
<mok0> quadrispro: you've fixed it in configure.ac so you need to run autoreconf in rules
<slytherin> persia: I hope. I haven't look through all the maven related packages. I am filing the sync requests as I build them successfully in pbuilder.
<mok0> quadrispro: that should regenerate aclocal as well
<persia> slytherin, If it's a one-time bootstrap for the package, it can usually be done by request.  If it's an each-time bootstrap, it needs re-engineering.
<mok0> quadrispro: I don't think you need --with-ffmpeg because the header files are in the standard place
<quadrispro> mok0: I didn't want mention aclocal, I talked about configure.ac :)
<quadrispro> mok0: yes, it's right
<slytherin> persia: I am tired of bootstrapping. I will see if I can built the package with some modification. Similar to what we did in case of jboss.
<quadrispro> mok0: so, isn'it necessary change configure.ac?
<quadrispro> is it?
<mok0> quadrispro: I don't think so
<persia> slytherin, Even better, of course :)
<quadrispro> AC_CHECK_HEADER($FFMPEG_SEARCH_HEADERS/ffmpeg/avformat.h,
<mok0> quadrispro: it's much easier if you can avoid it
<slytherin> ï»¿In that process I had a conversation with Torsten yesterday and found out that we need to sync some packages from experimental for the packages in unstable to build. :-) One of those package was not even uploaded to experimental till yesterday.
<quadrispro> mok0: mmm, ok
<mok0> quadrispro: unless of course configure stops the build
<mok0> quadrispro: Going to lunch so I'll be afk for a while-
<StevenK> quadrispro: They aren't under ffmpeg any more
<quadrispro> configure stops the build
<quadrispro> mok0: ah ok, bye ;)
<mok0> StevenK: That's what he's fixing
<StevenK> Which package?
<StevenK> Since I worked a bunch on the ffmpeg stuff
<quadrispro> StevenK: hi! mediatomb
<StevenK> Hm. I didn't see that one on the list
<quadrispro> StevenK: bug 311180
<ubottu> Launchpad bug 311180 in mediatomb "FTBFS with new ffmpeg in jaunty" [Medium,Confirmed] https://launchpad.net/bugs/311180
<quadrispro> StevenK: I think it's needed change configure.ac, not debian/rules...
<quadrispro> StevenK: the change to configure file has to be dropped from my patch, but it seems working fine
<quadrispro> i'm working on a new debdiff
<StevenK> quadrispro: I've not looked at mediatomb
<stefanlsd> If we have a merge and the only change is debian fixed the ubuntu1 bug, do we always request the sync or just say its not required?
<Laney> stefanlsd: I wouldn't at this point, it doesn't gain us anything (autosyncing is off anyway)
<stefanlsd> Laney: kk. which point would we?
<Laney> before DIF it would make sense as then we automatically benefit from Debian's changes
<directhex> and assuming debian hasn't been frozen snice before intrepid
<directhex> *cough*
<stefanlsd> heh. cool. thx
<Laney> stability release!
<directhex> Laney, jauntiness and stability are opposites!
<directhex> Laney, a jaunty hat might fall off at any moment!
 * Laney walks the jaunty walk
<directhex> hats can also be dapper
 * directhex thinks ubuntu should switch to a hat naming scheme, since it seems to already be hat-friendly
 * Laney -> lunch
<directhex> unhelpfully, i find no hat types starting with "J"
 * StevenK has too many hats
<directhex> are any of them jaunty and/or dapper?
<StevenK> directhex: I can go through them, if you want ...
<directhex> nah, sounds like effort
<StevenK> directhex: Meh, I point you at the teams I'm on in LP
<directhex> hm, netbook remix. i know who to bug if my wife has issues, then
<mok0> quadrispro: did StevenK fix the ffmpeg thing for you?
<StevenK> Oh, drat
<quadrispro> mok0: no, I'm working on it :)
<mok0> quadrispro: ok great
<maxb> Jaunty currently has mercurial 1.0.1, but 1.1.2, a new upstream feature release exists. Any opinions on whether it makes sense to try to get the new version into Jaunty at this point in the release cycle, or not?
<persia> maxb, How stable is 1.1.2?  How much would it improve the experience for users?  Are there other packages affected that need updating?
<maxb> Seems stable in my experience, and has already had a couple of point releases, so the inevitable teething troubles of a new feature branch should be worked out. There are new features in core, and there are extensions which require the new version. It's mostly compatible - rdepends would need testing, but likely wouldn't need updating.
<jekil> please sameonecan review/advocate? http://revu.ubuntuwire.com/details.py?upid=4448
<oojah> maxb: 1.0.2 is listed as having security fixes at least.
<maxb> the security fixes have been backported by debian, but you have a good point, there are relevant bugfixes in 1.0.2 if 1.1.x is deemed too much of a change
<mok0> jekil: This is really a bug fix
<mok0> jekil: you should create a bug on LP and attach a debdiff to it
<jekil> mok0: so, the updated packages don't use revu system?
<mok0> jekil: no
<jekil> mok0: ok, thanks
<mok0> jekil: if you need help with the debdiff etc just ask here. Remember to close the bug in changelog
<jekil> mok0: and after uploading the debdiff in the bug (thats already opened, i upload this to revu to close it) i must notify someone/somewhere?
<mok0> jekil: you close it in changelog by having this construct: (LP: #xxxxxx)
<jekil> mok0: all already done in the package uploaded to revu..
<mok0> jekil: then you subscribe ubuntu-universe-sponsors
<mok0> jekil: ah
<jekil> mok0: ok, the subscription to ubuntu-universe-sponsors is the point that i miss
<mok0> jekil: that will put it on u-u-s's Bug page
<mr_pouit> StevenK: could you please close LP bugs when you fix them? :(
<persia> jekil, Also, there's no benefit to pushing it to REVU if it's just an update to an existing package.
<mok0> jekil: then it will be processed
<StevenK> mr_pouit: Yeah, you keep filing them, and I keep not looking
<mr_pouit> StevenK: no, I stop filing them :p
<jekil> mok0, persia: thank you, i am sorry, i haven't understand the workflow, now it's ok, thanks
<mok0> jekil: NP. The process could be described better
<mok0> jekil: please archive the REVU upload then
<jekil> mok0: yes, now i archive. thanks for your help
<jekil> oh, if try to archive i get a taceback from revu http://pastebin.com/d77d27b79
<mok0> jekil: Hmm. Worked for me
<mok0> jekil: perhaps you don't have permission?
<mok0> jekil: anyway, problem solved (although the revu software seems to have a bug)
<anakron> HI all
<anakron> Hi persia
<persia> Hey anakron
<AnAnt> Anyone knows what 8.04.2 will be released ?
<persia> AnAnt, https://wiki.ubuntu.com/HardyReleaseSchedule is the document to watch.
<persia> subscribe to that, and you'll see when the various point release dates are confirmed.
<AnAnt> thanks
<quadrispro> devfil: ciao! bug 188561
<ubottu> Launchpad bug 188561 in macchanger-gtk "Close button of GtkAboutDialog doesn't work" [Low,Confirmed] https://launchpad.net/bugs/188561
<devfil> quadrispro: ok
<mok0> Any C++ fans around?
<ScottK> mok0: I'd guess your odds are better on #kubuntu-devel.
<mok0> ScottK, I can try there
<DktrKranz> persia, probably I figured out that pbuilder issue I faced some days ago, it seems related to pkgbinarymangler (I use it in my default pbuilder configuration)
<persia> DktrKranz, but pkgbinarymangler should be on the buildds too: is it just a conflict between pkgbinarymangler and some pbuilder internals?
<DktrKranz> persia, probably. I'll try to reproduce two build logs, one without it and one with it, just to see difference. I'll try to debug something with pdebuild, then
<quadrispro> thanks for the upload, devfil
<opera> who can tell me how to join ubuntu-cn
<opera>  who can give me a link
<opera>  i can't find it in the list
<savvas> opera: you mean #ubuntu-cn ?
<opera> yes
<opera> discuss ubuntu in chinese
<savvas> opera: type: /join #ubuntu-cn
<savvas> and press enter
<opera> but ,every time i join it through other give a link ,and how can i join it  own?
<directhex> <savvas> opera: type: /join #ubuntu-cn
<opera> \
<rhpot1991_laptop> any motu-srus around?
<mok0>  /join #ubuntu-cn
<mok0> heh
<slytherin> !merge
<ubottu> https://wiki.ubuntu.com/UbuntuDevelopment/Merging
<bddebian> Heya gang
<slytherin> any archive admins around?
<soc> mok0: hi, i fixed the things you mentioned in the comments, would you like to review it again?
<soc> http://revu.ubuntuwire.com/details.py?package=ttf-droid
<mok0> soc: sure
<mok0> soc: I took a look earlier, actually.
<mok0> soc: what I wrote about the Vcs-* fields was not correct
<mok0> soc: in debian/control
<soc> yes, the next comment mentioned that
<mok0> soc: I suggest you move these refs to README.Debian
<soc> refs?
<mok0> URLs
<soc> atm it looks like that:
<soc> Homepage: http://www.ascendercorp.com/pr/2007-11-12/
<soc> Vcs-Browser: http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=data/fonts
<soc> Vcs-Git: git://android.git.kernel.org/platform/frameworks/base.git
<soc> is that right now?
<mok0> soc: no, those fields are reserved for packaging repos
<soc> packaging repos?
<mok0> soc: yes, developers are starting to keep their packaging work in VCS
<soc> ah ok
<soc> remove all three?
<soc> into README.Debian?
<mok0> soc: no, only the VCS-* lines, but put the URLs in the README.Debian file
<soc> ah ok
<mok0> soc: I think the homepage field is ok
<mok0> soc: another thing I wandered is: what is the debian/bug directory for?
<soc> ok, i'll upload again
<soc> oh, cool, i have really fast internet today
<mok0> soc: debian/bug/presubj looks like info that should also be in README.Debian
<soc> mok0: i think that is somehow used with reportbug
<mok0> soc: ah
<cody-somerville> dholbach, I have e-mails in the moderation queue for ubuntu-motu and motu-council I think
<dholbach> cody-somerville: only one for ubuntu-motu
<cody-somerville> ok, thanks
<cody-somerville> Can you add that e-mail to auto accept?
<dholbach> just listadmin'ed that mail through
<dholbach> the next time I'll do it
<dholbach> cody-somerville: thanks for giving that session about xubuntu
<cody-somerville> dholbach, np
<cody-somerville> thanks
<savvas> Where do we place man pages? In debian/binaryname.8.man ?
<vorian> savvas: yes, but no need for the .man part
<savvas> ah great, thanks :)
<vorian> no problemo
<vorian> savvas: you will also need to use dh_installman in rules
<savvas> I know vorian, I have it set in rules to cycle through all dh_ commands :)
<vorian> ah, ok then :)
<vorian> james_w: did you want to look at the sugar-hulahop merge?
<mok0> soc: advocated
<vorian> james_w: i'll leave it be for now
<soc> mok0: thanks!
<james_w> vorian: I've reviewed it, I just popped out to get lunch before testing
<james_w> vorian: thanks for checking
<vorian> no problem james_w :)
<stefanlsd> james_w: do those libev changes seem sane?
<soc> mhh, cloud someone advocate http://revu.ubuntuwire.com/details.py?package=ttf-droid again?
<james_w> stefanlsd: haven't had chance to look yet, sorry
<soc> i fixed the optional things mok0 mentioned
<stefanlsd> james_w: np. not sure who the libtool experts are to check...
<james_w> stefanlsd: yeah, do you know why AC_CONFIG_MACRO_DIR et al were needed?
<james_w> did it just bail out with AC_CONFIG_MACRO_DIR unset?
<stefanlsd> james_w: trying again
<stefanlsd> james_w: those options were given by the autoreconf tools
<stefanlsd> james_w: it does build without it - but get this libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
<james_w> stefanlsd: hmm, yeah, "consider"
<james_w> I think it looks good though, let me test etc.
<stefanlsd> james_w: kk. tried without the mkdir m4 and it fails.  the autoreconf man page says it replaces the steps that we're being run.
<james_w> stefanlsd: do you have a debian chroot around?
<soc> pmjdebruijn: hi, could you advocate my package? mok0 advocated it, but i fixed the optional things he mentioned and reuploaded it again
<stefanlsd> james_w: not atm. something i actually wanna get thou. will get one.
<james_w> there's also a couple of "warning: ignoring return value of 'write', declared with attribute warn_unused_result" if you feel like patching
<james_w> stefanlsd: patch works fine on Debian, please forward it there.
<stefanlsd> james_w: thanks. will look at warning and forward to debian.
<james_w> stefanlsd: uploaded, thanks for your contribution
<stefanlsd> james_w: thanks for the help!
<slytherin> any archive admins around?
<pmjdebruijn> soc: sorry, I'm not a MOTU
<soc> ah ok
<RainCT> Uhm.. Which package do I need if I want to install KDE4 but without all the kubuntu-desktop stuff? (And, should I install from Intrepid or is there some more up2date PPA?)
<JontheEchidna> kde-core should install a minimal installation
<JontheEchidna> the latest stable release is in intrepid-updates
<JontheEchidna> with KDE 4.2 betas being here: https://bugs.edge.launchpad.net/~kubuntu-experimental/+archive
<ogzy> hi i have a deb related question,  I had installed directfb libraries from the hardy repo, but now i want to install the new release and will either compile from source manually or create the deb file, first wuestion is, how can i install to the same path of the previous version, i think the configure script should be run with prefix /usr right?, second question do i have to recompile other programs that are compiled directfb enabled before after
<ogzy> installing the new release
<RainCT> JontheEchidna: thanks
<RainCT> JontheEchidna: What do you recommend, intrepid-updates or the PPA? (/me wants to see cool stuff)
<JontheEchidna> imo the betas are just as stable as the stable release
<JontheEchidna> and in a few day's we'll have the first RC :D
<RainCT> okay, I'll install the beta then
<slicer> Hi. Will packages in debian experimental/unstable to automatically merged to Jaunty? .. If so, how often does that happen?
<ScottK> slicer: Packages are automatically sync'ed from Unstable if there are no changes to the package in Ubuntu in the first part of the release cycle (we're past it for Jaunty).
<ScottK> The last sync was ~25 December
<ScottK> Packages with Ubuntu changes have to be manually merged.
<ScottK> Packages from Experimental never get into Ubuntu automatically.
<slicer> ScottK: Ok, since we're now past the first release cycle, does that mean I have to request a package sync? It fixes a "cant-install" bug report in the package. (The package being "mumble").
<ScottK> slicer: yes.
<jpds> slicer: There's a "requestsync" script in ubuntu-dev-tools to do just that (if you don't know).
<slicer> jpds: I do, but it requires gpg signing, and I don't have my key here.
<Laney> slicer: Not if you use --lp
<jpds> slicer: There's an --lp flag which does not need gpg, it uses launchpadbugs and cookie file auth against Launchpad.
<Laney> \o
<slicer> Aha :) That I didn't know. Thanks!
<POX> ScottK: I saw your name in python-storm's changelog, do you want to maintain it in Debian? (Ubuntu's Maintainer is set to a mailing list)
<ScottK> POX: Not really.  I don't remember what I did to it, but it's not a particular interest of mine.
<POX> or anyone wants to maintain it? I can sponsor (although I use SQLAlchemy only)
 * directhex flogs a cpu on ebay
<woody86> Can anyone help me out? I already setup a PGP with launchpad, but I've reinstalled Ubuntu on my comp, is there any way to get my PGP back on this comp, or do I have to just create a new one?
<POX> +else
 * ScottK thinks perhaps mok0 is interested in it, but he's not here right now.
<Laney> woody86: Did you keep the private key?
<woody86> Laney- I know it's not on this comp, let me check my main rig, brb
<hyperair> does anybody know if the compiz fusion stackswitch plugin will enter ubuntu?
<woody86> Laney-  I saved the output of when I made the PGP key, and it has the fingerprint and everything, but I'm not sure which part is the pgp key
<woody86> Laney-  there's one part that says:
<Laney> woody86: It starts with -----BEGIN PGP PRIVATE KEY BLOCK-----
<woody86> Laney-  oh, the key block? yes I have that too
<Laney> good, you can import that into gpg/seahorse
<woody86> ok, thanks :) any easy way to do that?
<Laney> file->import in seahorse should do it
<woody86> ok, have to transfer those text files...
<woody86> Laney-  wait, the only thing I have is the PGP Revoke file, and it's not letting me import that
<Laney> not surprising
<woody86> Laney-  now, I created a new PGP, how can I replace the one on LP with this new one?
<Laney> yes
<woody86> or is there an easier way to import my old one onto my camp?
<jekil> i have fixed a bug, uploaded debdiff to bug report, and subribed ubuntu sponsor for universe to the bug (https://bugs.edge.launchpad.net/ubuntu/+source/obextool/+bug/133748), anythink alse? i must only wait now?
<ubottu> Launchpad bug 133748 in obextool "Obextool don't have menu entry" [Wishlist,Fix committed]
<fabrice_sp_> jekil, don't put Fix commited as status. Better Confirmed
<fabrice_sp_> also, mark the debdiff as patch
<quadrispro> anyone on bug 311020?
<ubottu> Launchpad bug 311020 in gnusound "Fails to find ffmpeg headers" [Low,Confirmed] https://launchpad.net/bugs/311020
<fabrice_sp_> jekil, and unassign yourself
<fabrice_sp_> and then wait
<fabrice_sp_> :-)
<maxb> Is there any easy way to find rdepends for a jaunty package if you don't have a jaunty install handy?
<jekil> fabrice_sp: thanks
<fabrice_sp> you're welcome ;-)
<ScottK> maxb: If you have a Jaunty pbuilder, use pbuilder login and use apt-cache rdepends from there
<fabrice_sp> maxb: or setup a chroot environnement
<maxb> I should probably set up a jaunty pbuilder for later, true. (At the moment I was just wanting to check whether an NBS is depended on)
<superm1> cody-somerville, rhpot1991_laptop has been trying to get an SRU through for mythexport for some time now, he's had my okay with the changes.
 * cody-somerville nods.
<cody-somerville> superm1, I worked with him earlier. I'm hoping we can get it approved ASAP.
<superm1> cody-somerville, okay cool great.
<cody-somerville> :)
<slayton> is there anyway to tell if the diff.gz obtained by running apt-get source contains any changes besides the debian dir? like changes to the source and
<directhex> filterdiff
<directhex> and a cluebat for people not using a patchsys!
<Laney> slayton: lsdiff -z foo.diff.gz
<slayton> thanks!
<pochu> nvidia-graphics-drivers-180 (180.22-0ubuntu1) jaunty; urgency=low
<pochu> * New upstream version.  First "stable" driver in 180 series. (LP: #315169)
<pochu> superm1: ^ is "stable" meant to be ironic? ;)
<sebner> lol
<pochu> hey sebner :)
<superm1> pochu, it's supposed to draw emphasis at least :)
 * sebner winks pochu 
<sebner> superm1: still not compatible with new xorg, right?
<superm1> sebner, it works with the new xorg, but you need IgnoreABI still
<soc> hanska: hi, could you review/advocate my package? i did some optional refinements and uploaded it again, so i lost mok0 advocation :-/
<hanska> soc: err... I'm not a MOTU/core-dev/...
<hanska> soc: I don't even use Ubuntu ^_^
<soc> ah ok :-/
<hanska> I could review your package though, and write my comment :)
<soc> damn ... i only have one day, then i'm away for the whole week ...
<soc> that would be nice of course
<soc> i have 0 advocations again, so i can do reuploads as much as i want :-)
<hanska> ok, url?
<soc> http://revu.ubuntuwire.com/details.py?package=ttf-droid
<hanska> soc: reviewing
<slayton> what entry do I need to make in the foo.intsall file if if I want to rename a file after its compiled? I tried using changing "debian/tmp/usr/bin/foo" to "debian/tmp/usr/foo debian/tmp/usr/bar" but then when I run dpkg -c i see /usr/bin/bar/foo
<ScottK> hanska: I think Bug 314843 is worth forwarding upstream, but a quick look didn't turn up an upstream bug tracker.
<ubottu> Launchpad bug 314843 in clamtk "clamTK should include scheduling options" [Undecided,New] https://launchpad.net/bugs/314843
<hanska> ScottK: yes, the "upstream bug tracker" is upstream's mailbox ;)
<ScottK> hanska: Right.  I'm that way on stuff I do too.  Would you be up for forwarding it?
<hanska> ScottK: sure, just a moment, I'm a bit busy right now
<hanska> thank you for pinging me, though.
<ScottK> hanska: No rush.
<pochu> slayton: you can't with dh_install AFAIK.
<slayton> pochu: what would be the proper way of trying to rename the file?
<pochu> LIMITATIONS dh_install cannot rename files or directories, it can only install them with the names they already have into wherever you want in the package build tree.
<pochu> ^ that's from the dh_install(1)
<pochu> slayton: you an use mv in debian/rules
<slayton> ok great I'll try that out
<slayton> pochu: I  tried that and now I'm getting a missing seperator error
<slayton> pochu: is there a specific place where I need to add the line? or do I need to use different syntax? I tried just adding the mv /src/foo /dest/bar
<hanska> soc: done
<pochu> slayton: you want something along "mv debian/tmp/usr/bin/foo debian/tmp/usr/sbin/foobar"
<pochu> slayton: so relative paths
<soc> hanska: ah ok
<soc> thanks
<soc> hanska: a) i will remove that forgotten file ...
<soc> b) what's the difference between that ttf-droid.install file and the instructions in rules?
<hanska> soc: about debian/bug/* ?
<soc> c) i got told that i should rename install and defoma-hints to ttf-droid.install and ttf-droid.defoma-hints
<soc> yes
<soc> could i not just move this instruction from install to the rules?
<hanska> soc: that's an useless suggestion -- it's just in case you add another binary package in future
<soc> ah ok
<hanska> soc: it would be better if you moved the lines in rules to the .install :)
<soc> ah ok
<hanska> soc: you could add something like
<soc> how should that look then?
<hanska> debian/bug/script  /usr/share/.../
<hanska> debian/bug/presubj  /usr/share/.../
<soc> i haven't really understood the different syntax between install and rules
<hanska> install is called by dh_install
<hanska> (check its manpage)
<soc> ah ok
<soc> so the rules should look like this?
<soc> include /usr/share/cdbs/1/rules/debhelper.mk
<soc> install/ttf-droid::
<soc> 	dh_installdefoma
<soc> and the rest goes to install?
<hanska> soc: yes, but you're using "-D" in the install lines, so you should ensure that the dirs get created first
<hanska> (dh_install doesn't do that)
<hanska> soc: you can then add a debian/dirs file with /usr/share/bug/ttf-droid/ inside, and stop
<hanska> :)
<hanska> soc: uhm, I suppose I wasn't that clear.
<Laney> dh_install does create dirs
<soc> mhhh there is no source.lintian-override on my system ...
<soc> weird ...
<hanska> Laney: thought it didn't
<soc> only the right one, source.lintian-overrides
<Laney> dirs is only for making empty directories
<hanska> Laney: not fully true
<hanska> Laney: however, are you sure'
<hanska> let me try :P
<hanska> Laney: \o/
<hanska> Laney++
<Laney> :>
<soc> hanska: running debuild instead of debuild -S creates some files in the debian dir, should i delte them again?
<hanska> Laney: maybe I was just remembering some old debhelper compatibility :)
<soc> for instance ttf-droid.postinst.debhelper
<hanska> soc: "debuild clean" is your friend
<soc> and ttf-droid.prerm.debhelper
<soc> http://pastebin.com/m5dd2f70c
<soc> should i include that file?
<soc> or does debuild include that file in the package automatically?
<hanska> # Automatically added by dh_installdefoma
<hanska> ;)
<hanska> debuild clean should remove it.
<hanska> then you just do "debuild"
<soc> ok
<soc> hanska: ok, thanks
<soc> so what about that rules file now?
<soc> should i move things again between rules and install or should i leave it as is?
<hanska> soc: move the install lines in debian/ttf-droid.install
<hanska> soc: just ensure that the script is +x
<hanska> (and you'd have to do that in rules)
<soc> install should have +x?
<hanska> soc: "the script" --> debian/bug/script
<hanska> :)
<soc> ah ok
<soc> mhh ok, so how should install look like?
<soc> *.ttf		usr/share/fonts/truetype/ttf-droid/
<soc> debian/bug/*	usr/share/bug/ttf-droid/
<soc> would that be ok?
<soc> and the directories are created automatically?
<soc> and rules just:
<soc> include /usr/share/cdbs/1/rules/debhelper.mk
<soc> install/ttf-droid::
<soc> 	dh_installdefoma
<soc> btw, should the orig.tar.gz include the debian diretory already?
<soc> or is this added via the diff.gz?
<maxb> No, the orig.tar.gz should include upstream's files only
<soc> ah ok
<tbielawa> greetings all
<tbielawa> has anyone had problems with python distutils escaping fakeroot and attempting to write to the local file system? I haven't had any luck getting it to play nice
<terli> I need help making users accept a license in my .deb file
<terli> could I get a quick rundown on the required steps?
<soc> terli: shouldn't you do that on the first start?
<terli> no, I want them to click next, check the box, and install.
<tbielawa> I believe you need to work with debconf http://www.fifi.org/doc/debconf-doc/tutorial.html
<soc> stalling the installation process is considered by many people as annoying ...
<terli> Well this package is more annoying when you have to accept the license on the command line
<soc> terli: hu? now i couldn't follow you ...
<terli> just be brief.
<terli> I've got my DEBIAN/copywrite and DEBIAN/config file ready
<terli> I mean /control
<terli> solly
<soc> terli: copyRIGHT i assume
<terli> yes that too, it's been driving me nuts googling debian copywright and needing copyright
<tbielawa> terli, check out the debconf link I pasted above. It's more involved than a brief IRC description could help you with. but fairly straightforard
<soc> yes, english is not that nice language regarding the pronounciation ...
<maxb> terli: The sun-java6 source would be the example to look at
<terli> it's only 40 mb
<terli> only going to take me 3 hours and piss my gamer siblings off stealing their bandwidthz
<terli> I'll look for it.
<soc> hanska: new upload: http://revu.ubuntuwire.com/details.py?package=ttf-droid
<terli> https://jdk-distros.dev.java.net/svn/jdk-distros/trunk/linux/ubuntu/sun-java5/debian/rules << at least 1000 million lines
<hanska> soc: that's fine to me
<tbielawa> terli. the link I posted earlier is a straight run through. You should check it out
<hanska> soc: however, you can make debian/rules even shorter
<hanska> :)
<soc> how?
<hanska> soc: do you know/use debhelper 7?
<terli> tbielawa: I don't know jack diddly, but I want a gtk screen to show the license
<soc> yes, i use it in that package i guess
<hanska> no, you're using CDBS
<hanska> #!/usr/bin/make -f
<hanska> %:
<hanska>         dh $@
<hanska> this is your debian/rules for dh7.
<soc> mhh weird ...
<hanska> try :P
<soc> but i use dh_installdefoma for instance?
<soc> and i include /usr/share/cdbs/1/rules/debhelper.mk
<hanska> no
<hanska> uhm, wait, seems like defoma isn't in the standard dh run
<hanska> soc: stick with cdbs then :)
<tbielawa> terli, I don't know if you're trying to write something for a personal project or to get into the repos. If you're aiming for the repos then use debconf, and when you use something like synaptic it will present you with a gui screen for your answer.
<soc> ok
<terli> personal
<terli> its a proprietary deb file for all ubuntu revisions
<terli> I'm packaging my own parallels installation
<soc> hanska: do you know some motu who could review my package?
<soc> i'm away after tomorrow and i would like to get it done before ...
<terli> can I just get a decent example
<hanska> soc: nope, sorry. I'm here just to help new contributors, and not really into Ubuntu at all :)
<soc> ah k ...
<tbielawa> The link provided has code examples included. Try going through it and then come back if you are cought up on any part of the process and we'll be able to help more :)
<soc> terli: you can't rely on gtk, because that is not installed on every system ...
<terli> its not any good.
<terli> soc: I just want a gui.
<terli> just a bloody gui
<soc> then use debconf
<soc> it will scale to the software available
<tbielawa> exactly, soc
<terli> I just want to take /DEBIAN/copyright and use it to present a single window with the copyright and a checkbox at the bottom correlating with a boolean variable indicating acceptance. the user has to scroll through it first.
<soc> if you run it with the commandline, it will use the commandline, if you run it via synaptic, you will get an gtk box and so on
<soc> debian/copyright is not meant for that
<soc> copyright is no script
<soc> it's just a single textfile
<terli> copyright is just a text file!
<terli> I want to use the text file as the source for the copyright, is just what i was saying.
<soc> ah ok
<tbielawa> terli, I don't think there's much more we can say. We've told you exactly what to do at this point.
<terli> no, you've pointed me to the temple of debian
<terli> *eyes cross*
<hanska> ...
<terli> *begins mumbling in ancient scripts as pidgin crashes*
<soc> try to find a package which does what you want
<soc> try maybe adobe reader or flash or something
<tbielawa> so no suggestions for python distutils escaping fakeroot? daaang :(
<ScottK> tbielawa: What exact problem are you having?
<ScottK> Because no, I haven't had it.
<tbielawa> ScottK, I'm running a typical "python setup.py install" as a build action. Building with -rfakeroot.
<ScottK> OK.
<tbielawa> I expected fakeroot to contain what happened to my debian/package/ folder, but it's attempting to still install an init script into my root filesystem.
<tbielawa> (good think I don't package as root)
<ScottK> Note that fakeroot doesn't make a chroot, it just fools the system about is it root.
<ScottK> I think that's as expected.
<james_w> tbielawa: fakeroot protects you, the setup.py is broken
<james_w> tbielawa: if you pastebin it we can probably spot the problem
<tbielawa> I can patch setup.py and remove the leading "/".
<tbielawa> I'll pastebin. thanks for helping. brb
 * ScottK needs to run off anyway.
<tbielawa> I must run as well. ScottK, thanks for tipping me off to the subtility of fakeroot. Now I don't feel bad patching the setup.py
<tbielawa> http://pastebin.ubuntu.com/102418/ but there it is if anyone wants to dissect it :)
<james_w> tbielawa: probably just the leading / as you say then
<james_w> normally the issue is re-implementing part of install() and forgetting self.root
<terli> *exits the temple of debian in long shoddy robes covered in scratches and torn in many places*
<terli> ok,
<terli> now how to get my package to reference the script for debconf?
<terli> its just not working
<terli> soc, I wrote my script, how do I make the preinst reference it
<soc> terli: sorry, erli, i'm the wrong man, i started packaging 2 days ago :-)
<soc> hi ... i could need someone to advocate my package ... http://revu.ubuntuwire.com/details.py?package=ttf-droid
<terli> well I started packaging today
<maxb> <terli> now how to get my package to reference the script for debconf?  <-- what does that mean?
<terli> patented software needs a copyright.
<terli> and I'm going to force it to display at installation time, since the user *is* using a deb file for it.
<maxb> yes... you said that earlier
<maxb> Be I don't understand the specifics of what you are asking about
<terli> I've been told to use debconf for it
<terli> it's not working at all.
<terli> I wrote a .templates, a .config file, and attempted to alter preinst
<savvas> have you set up the rules file terli ?
<maxb> terli: have a look at a minimal example that I wrote for myself: http://jabberwock.vm.bytemark.co.uk/~maxb/debconfdemo/
#ubuntu-motu 2009-01-09
<terli> bloody good example.
<soc> terli: "patented software needs a copyright." wth?
<soc> what has copyright to do with patents?
<directhex> hear hear
<terli> what does db_get do
<terli> soc : copyright, license, you name it
<terli> legal shmega
<directhex> terli, they're all very different things
<terli> patented meaning proprietary
<directhex> terli, terms aren't interchangable
<terli> right, right, but my brain is of the sort that can replace tomatoe with table in a second
<terli> what does db_get do
<LaserJock> doesn't that get stuff from the template?
<terli> so if I have a file named templates
<terli> with two entries in it marked parallels/accept_licence and parallels/license
<LaserJock> right
<terli> accept_ being the boolean and license being the text itself
<LaserJock> yep
<terli> db_get parallels gets both?
<terli> no. can't be.
<LaserJock> well, look at the example
<LaserJock> db_get debconfdemo/accepted
<LaserJock> if [ "$RET" = "true" ]; then
<LaserJock>     exit 0
<LaserJock> fi
<LaserJock> so it grabs debconfdemo/accepted and then tests if it returns true or false
<crimsun> be careful with forcing the user to accept the agreement prior to proceeding. you're in a position to design it properly now. the major point of contention will be blocking distribution upgrade progress.
<crimsun> i.e., i install foobar, update && full-upgrade, walk away for a week, and find the upgrade is blocking on my input
<terli> crimsun, your a god, but this package will never, ever, ever make it into the repo.
<terli> it's proprietary and binary.
<LaserJock> so?
<terli> so the only upgrade possible is manual.
<crimsun> sure, that's fine, and there are plenty of examples that did in fact use a hard-stop query, like the sun-java[56] in multiverse
<LaserJock> terli: I'm saying prorietary and binary packages are allowed
<terli> Nobody maintains this package, and I'm not capable of complying with the universe rules.
<terli> , now, if you want to upload it for me, thats a different matter
<LaserJock> not I, been there, done that, still reaping the "benefits" :-)
<terli> the source package I edited was sudo extracting a tar file in /usr/lib/programdir
<terli> made removing all of it a headache
<savvas> terli: what's the name of the software?
<terli> parallels.
<terli> I'm doing some work to get rid of my howto
<terli> and stop breaking dash/bash
<coppro> http://revu.ubuntuwire.com/details.py?package=metakit <-- comments would be appreciated
<terli> subprocess pre-installation script returned error exit status 255
<terli> http://pastebin.com/m238dc41a
<terli> er, umm
<terli> http://pastebin.com/m699a61f3
<terli> there
<soc> could someone review/advocate my package? ... http://revu.ubuntuwire.com/details.py?package=ttf-droid
<soc> it should be totally clean and nice now ...
<terli> Template parse error near `.', in stanza #2 of ./templates
<slicer> The requestsync script in intrepid misbehaves a bit if you're a member of the launchpad betatesters group :)
<slicer> Specifically, it submits the bug report 5-6 times, then crashes.
<coppro> use it to submit a bug against launchpad?
<coppro> :P
<TheMuso> /c/c
<slicer> Ok, what should I do with the duplicates? Is there a way to delete them, or do I need to mark them as duplicates?
<slicer> It seems a bit silly now with 5 identical reports in a row.
<coppro> in what?
<slicer> bug 315291
<ubottu> Launchpad bug 315291 in mumble "Please sync mumble 1.1.6-5 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/315291
<slicer> bug 315292
<ubottu> Launchpad bug 315292 in mumble "Please sync mumble 1.1.6-5 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/315292
<slicer> etc etc up to 315295
<slicer> I'll mark them duplicates for now, that should at least remove them from the trackers.
<terli> is there a db_display variable?
<terli> I need someone to tell me three db_ commands
<nschembr> I'm looking for a little help, OK everyone need help:) I'm looking for someone who works with the init scripts.
<directhex> which init scripts?
<nschembr> Let me look.
<nschembr> somewhere before /etc/initramfs-tools/scripts/init-bottom/ in the init process
<nschembr> how about someone working on the netbook remix
<maxb> nschembr: You are not being very specific about what you need help on - specific questions are better because they allow people to see whether they can actually help or not, quickly
<terli> hey , could someone show me how to put my license in a debconf tag?
<directhex> terli, a EULA-style you-mist-agree license?
<directhex> terli, an old sun-java6 package should provide something to copy
<terli> yes
<terli> no
<savvas> the non-free virtualbox has a license agreement if I recall correctly
<directhex> i just remember java needing it. the sun distributor license or somesuch
<terli> I have it on my screen
<terli> it's not working
<directhex> it doesn't have a job? for shame, my taxes are paying for it to lounge around at home!
<terli> it's no use to me
<directhex> and why is that?
<terli> its all nice and all that
<terli> hmm
<terli> I ran the script from a terminal
<terli> it just ran through, didn't prompt me or anything
<terli> but its not crashing
<Hobbsee> had you already accepted the licence once, and are now trying to accept it a second time?
<terli> no, I'm building the bloody package
<Hobbsee> oh, right.
<directhex> ran which script from a terminal?
<terli> quiet.
<terli> ok, now it failed to install, but that's my fault
<terli> I can feel it
<terli> the preinst is configured to db_go parallels
<terli> the parallels file is configured to:
<terli> db_input critical license; db_input critical license_accepted;db_go; db_get license_accepted;if [ "$RET" = "true" ]; then
<terli>     exit 0
<terli> fi
<maxb> <terli> the preinst is configured to db_go parallels <--- are you saying you actually have a line "db_go parallels" in the preinst?
<terli> yes?
<maxb> because that would be meaningless
<maxb> db_go doesn't take an argument
<terli> how do I get preinst to pass control to my script?
<maxb> you don't
<terli> and does db_stop belong in there?
<maxb> You've misunderstood how debconf works. You shouldn't have a 'parallels' file.
<terli> I have preinst , a file called parallels and one marked parallels.templates
<terli> preinst is supposed to use debconf to run parallels , which is a script that uses the parallels.templates file to show license details
<maxb> uhm, no
<terli> then explain how it's supposed to work.
<maxb> You don't use debconf to run things
<maxb> You use debconf to interact with some abstract UI
<terli> I don't think you understand.
<terli> you are supposed to help me, not contradict me.,
<maxb> Part of helping is pointing out misunderstandings
<terli> what should i do for preinst to get my script implemented
<terli> it's just a file called parallels that starts with a  line marked #!/bin/sh, think of it as any other script file.
<directhex> you don't write a script, you write a debconf template. preinst calls debconf using that template, and bails if your haven't accepted it
<terli> no, I've relocated the details of what debconf does to a different file.
<maxb> Well, don't do that
<maxb> Doing that goes against all standards of how to use debconf
<directhex> to what end? now you're talking about making that different file available outside the package, which is enormously messy
<terli> well, then, I suggest you inform me about the correct way.
<directhex> he tried, you told him off for it
<terli> the different file is IN the package
<terli> it's IN /debian
<maxb> The correct way was the way I did it in the prewritten example I gave you
<maxb> Which is the same way sun-java does it
<directhex> please look at debian/dlj.templates and debian/JB-jdk.preinst in sun-java6
<directhex> you can't use preinst to call things in data.tar.gz
<terli> so I have a line marked db_get parallels/license which corresponds to a template marked parallels/license in the file parallels.templates
<terli> direct hex, everything is in the folder marked debian in the root of the archive.
<directhex> the semantics are more complex than that though. a binary package is split into multiple parts. the actual data section, the files to which you'd be agreeing to a license, are not the same as the metadata - that way you can't install it if you don't agree with the license
<terli> the license is in the metadata, and in the data.
<terli> two copies.
<terli> you agree to the copy stored within templates
<terli> it's identical to the other copy
<terli> but you don't have to explicitly agree to the other copy, you already did that with the first one during installation.
<directhex> but you don't want to use the template, you want to run a script. and the script does not form part of the control.tar.gz section of the package, which contains metadata like templates and preinst
<terli> the script isn't in the control.tar.gz
<terli> it's in debian!
<terli> preinst isn't in control.tar.gz either
<directhex> yes, it is.
<directhex> after you compile the source package, anyway
<directhex> which is the point
<terli> I don't have a source package.
<directhex> however, it's 1:50am, and you clearly already know best, so i'm going to bed.
<terli> I'm using DEBIAN folder and usr folder.
<maxb> oh, argh, do you literally mean DEBIAN, uppercase?
<terli> literally.
<maxb> Are you seriously attempting to MANUALLY assemble a debian binary package without a source package being involved?
<terli> There is no source.
<terli> it's all binary blobs to begin with.
<directhex> a source package doesn't mean source. you think sun-java6 includes source?
<directhex> or nvidia-glx?
<directhex> directhex@mortos:/tmp$ ls sun-java6-6-10/
<directhex> debian  jdk-6u10-dlj-linux-amd64.bin  jdk-6u10-dlj-linux-i586.bin
<directhex> that's a source package
<terli> well , this one doesn't.
<directhex> wheeeeeeee
<directhex> bed.
<maxb> terli: You are seriously making things hard for yourself.
<terli> I don't know what you mean by easy.
<terli> I don't know the correct way to build the package, because I don't have the requisite files.
<maxb> Well, you seem to be ignoring the minimal example I gave you, and the example of sun-java, and trying to forge your own way by a different path
<terli> I didn't ignore your example
<terli> I couldn't use it
<terli> waitr
<maxb> why not?
<terli> you didn't give me a different example from my own!
<terli> my list of files IS identical to yours.
<terli> I put the script in preinst
<maxb> I never had a DEBIAN
<terli> and now I just have templates and preinst
<terli> well I don't know where you put it then
<terli> THIS package's source had a debian.
<maxb> debian/ and DEBIAN/ are *different*
<terli> I mean DEBIAN.
<StevenK> You shouldn't be playing in DEBIAN/
<terli> I don't know the difference.
<terli> it's a *debian* package, anyway.
<maxb> Well, either read up about it in the Debian Policy Manual, or just trust us that if you are messing with a DEBIAN/ directory you're doing it wrong
<directhex> you want to generate a SOURCE PACKAGE. christ, we could be done by now. a SOURCE PACKAGE does not require source for parallels, before you start, it just means a rational sane way of building all the required files in the right places using a plethora of helper tools. a source package consists of whatever you have from upstream, plus a debian/ folder. that's it.
<terli> well, I've gotten far enough that the installer is saying, template parse error near `text` in stanza #1
<terli> well, directhex, I don't know how that works.
<terli> can I just rename DEBIAN to debian?
<directhex> terli, if you wanted to zip a file, would you use a zip tool, or a hex editor?
<StevenK> Nope, you can't
<terli> if I wanted to zip it I would use zip
<terli> or tar
<directhex> terli, right now you're using vi.
<terli> I used dpkg -b to generate my package from the folders specified in the wiki...
<terli> I tried to use data.tar.gz and control~, really I did, but I couldn't get it to make the . folders.
<directhex> if you ever see data.tar.gz or control.tar.gz, ur doin it wrong. those files are generated as part of package creation, by dpkg-buildpackage
<maxb> terli: What wiki are you reading? You've apparently found your way into some deep dark internals documentation
<terli> I did.
 * Hobbsee reads the backscroll, and raises an eyebrow
<maxb> What, only one eyebrow? :-)
<terli> I had to open the archive in archive manager, extract it, then edit the contents.
 * directhex lowers Hobbsee's eyebrow with his poking stick
<terli> then re-compress it to a archive.
 * directhex falls off his desk
<directhex> UR DOIN IT WRONG
 * Hobbsee raises the other eyebrow at that
<Hobbsee> well, no wonder it isn't working.
<terli> I don't know what other way there is, I wasn't taught anything about any of this.
<crimsun> (you silly people. i would have used Hobbsee's stick to zip.)
<terli> and it works fine, I just can't get debconf to parse my note/eula thingy
<terli> did you know, before I was using their archive(the official one) , and having to manually replace sh with bash because the maintainer screwed up and made his script call /sh instead of bash
<maxb> terli: You are poking about in internals that developers don't bother to deal with directly. I (and probably most others here) have no idea how the templates are supposed to be packed into the binary deb, because we use tools that do it for us
<maxb> Oh
<terli> maxb: I have no idea where the tools are.
<terli> but if you don't know how
<terli> then something has gone seriously wrong
<maxb> Finally it becomes clear *why* you're approaching it this way
<maxb> It was not clear to me until just now that you were actually trying to repackage an existing .deb file
<terli> exactly!
<directhex> dpkg-repack - puts an unpacked .deb file back together
 * maxb headdesks
<maxb> I wrote my own one of those too
<terli> sorry, I've already deleted it.
 * maxb wonders just how much of his ~/bin/ has packaged equivalents, if you know where to look :-)
<terli> anyway, it's clear to me that in one way, I clearly am superior to you(I'm fooling around with sith bathrooms in the debian temple), and in another way, I havn't the vaguest idea what I'm doing.
<terli> db_input critical license
<terli> db_input critical license_accepted
<terli> db_go
<terli> db_get license_accepted
<Hobbsee> terli: dude, take the attitude elsewhere.
 * maxb awards terli the ultra-bizarre-metaphor prize
<terli> Hobsee; I don't have the vaugest idea how I'm supposed to package this without your help.
<Hobbsee> terli: there is no reason anyone *has* to help you, and the more you show your attitude, the more likely it is that you'll be ignored.
<Hobbsee> terli: well then, you should clearly try to be polite, stop telling people to be quiet like they're your dog, listen to what they say, whether you agree with it or not, and stop saying you're superior, no?
<terli> yesno, yes, ok.
<terli> I'm waiting.
<maxb> Well, it's past time for me to be asleep, so don't wait for me.
<Hobbsee> oh, and maybe you already wore out your welcome with your comment on being clearly superior, so you may find that no one's going to deal with you anyway
<Hobbsee> so, wait away.
<terli> Well, you did see me admit in one and the same sentance that I don't know what I'm doing.
<terli> Not knowing what I'm working with is humiliating and frustrating.
<nschembr> I've  worked on a project to use aufs as the root file system. I have posted the howto, https://help.ubuntu.com/community/aufsRootFileSystemOnUsbFlash
<nschembr> At this point I'm stuck.  I think it should be integrated into the main init script. I think this would help the  people building netbook distro's.
<nschembr> Is anyone working on netbooks or the init process.
<anakron> Hi all
<maxb> nschembr: I realize I'm being incredibly obsessive, but: There's no such thing as Ubuntu 8.4
<maxb> Sorry, personal irritation of mine :-)
<nschembr> maxb: Attention to detail noted and corrected. :)
<maxb> I'm not sure how this fits with netbooks. Surely having your documents vanish when you reboot is a bit of a pain
<persia> Actually, none of the Ubuntu Mobile flavours use stacked filesystems post-install anymore.
<persia> The live session uses a stacked filesystem.
<rhpot1991_laptop> cody-somerville: ping, I updated bug 297019
<ubottu> Launchpad bug 297019 in mythexport "mythexport relies on ffmpeg from medibuntu" [Undecided,Fix released] https://launchpad.net/bugs/297019
<dholbach> good morning
<fabrice_sp> Godd morning dholbach! :-)
<dholbach> hiya fabrice_sp
<iulian> Morning dholbach, fabrice_sp.
<dholbach> hiya iulian
<fabrice_sp> 'morning iulian !
<didrocks> morning dholbach, fabrice_sp, iulian o/
<dholbach> hiya didrocks :)
<didrocks> dholbach: just to keep you inform all is going very well for localized UDW preparation on your last day proposal :)
<dholbach> didrocks: perfect - can you follow up on the mail thread so the others know as well?
<dholbach> didrocks: I'll start writing up the announce in a sec
<dholbach> I wasn't feeling very well yesterday evening, so I do it today
<didrocks> dholbach: I will do it later in the week-end (we are fixing the precise schedule)
<didrocks> dholbach: oh :( do you feel better today?
<dholbach> yeah, it's all good today :)
<dholbach> didrocks: I was just thinking that the others might want to plan something similar so let them know about the plan early
<didrocks> dholbach: ok, will do it today :)
<dholbach> super
<dholbach> thanks muchly
<didrocks> you're welcome :)
<fabrice_sp> Hi didrocks \o/
<stefanlsd> hey guys.  where can i see the queue / status for the build servers building jaunty stuff?
<iulian> stefanlsd: https://launchpad.net/ubuntu/jaunty/+builds
<stefanlsd> iulian: thanks!
<tbielawa> greetings, all!
<slytherin> persia: there? need some guidance.
<persia> Here.
<persia> Again, I like *contentful* pings :p
 * directhex pings persia with a large textbook
<iulian> Heh
<iulian> persia: Btw, just out of curiosity. Will you have some spare time to vote on my application this weekend or even today?
<persia> iulian, I'm nearly done with review: I was hoping to finish yesterday, but didn't quite.  Should be in the next few hours.
<iulian> persia: Oh, that's great!
<iulian> Thanks.
<persia> Sorry it's been so long: there's really no excuse on my part.
<iulian> No worries.
<slytherin> persia: The problem is related to batik. The current version in Ubuntu is 1.7.dfsg-0ubuntu1. Where as Debian version in experimental is 1.7-1. According to dpkg 1.7.dfsg-0ubuntu1 > 1.7-1 so I will not be able to upload a merge from Debian. :-(
<persia> Do the orig.tar.gz files differ?
<slytherin> persia: yes they do.
<slytherin> persia: our version has some code from fop as well (inline with what was done for 1.6). But that code is not needed any more.
<slytherin> The main problem is how the buildd will treat the version from Debian. If it think that it is less than what we currently have then it will never get published.
<persia> OK.  Then create 1.7.dfsg1-1ubuntu1.
<persia> It's not ideal, but it's probably what we need until 1.8 comes out.
<slytherin> persia: right. That is what just came to my mind. This problem will go away when we have 1.8.
<persia> Right.  We just need to do some fakery to force use of the Debian orig.tar.gz, as I presume it's better.
<persia> If nothing else, it makes it easier to merge later.
<slytherin> by the way do we have any set policy for/against sync/merge from experimental? Debian experimental has fop 0.95. And it is unlikely to enter unstable until lenny is released.
<directhex> slytherin, not just permitted, but more or less required during the lenny freeze
<directhex> slytherin, most of the jaunty mono stack is smerged from experimental
<slytherin> directhex: good then. I am wondering when will be lenny released.
<directhex> slytherin, it'll come bundled with copies of duke nukem forever
<slytherin> :-)
<stefanlsd> hehe
<persia> Best way to help lenny release is to help close the remaining RC bugs: they may well be bugs in Ubuntu as well, so it's not wasted effort.
<directhex> i think i proposed a debian BSP a few months ago, but nobody seemed interested
<persia> I thought we did one a few months ago: I remember a number of Debian bugs being discussed.
<persia> Let's do another one this weekend.
<Laney> directhex: Break off from the u-uk bug party in feb to do some debianing
<Laney> :>
<directhex> there's a u-uk?
<Laney> but of course
<Laney> we are planning on participating in the global bug jam
<Laney> I expect to see you there!
<directhex> is there a secret handshake involved?
<directhex> or masks?
<Laney> The secret incantation is /join #ubuntu-uk
<Laney> if you can manage that then....
<Laney> onto the initiation rituals
<directhex> mmm, sounds hard. never mind then :/
<Laney> boo
<directhex> is it a sign i'm getting old if a major factor in which brands i buy for a new pc is the warranty?
<persia> No, it's a sign that you've reached the threshold of your performance requirement: you no longer expect it will be cheaper or better to get a new machine when that one breaks.
<stefanlsd> i get dell with 3 year next business day warranties. i cant be bother to go fix get parts to fix and replace hardware anymore
<directhex> stefanlsd, the price diff between a dell with 1year rtb, and a self-build with a few lifetime warranties, on the spec i want, is already a few hundred quid
<stefanlsd> mm. sounds alot. but if u think of the time and effort lost with self built. if u have the time, i guess self built will be easier
<stefanlsd> well, cheaper anyways
<directhex> it's a hobby!
 * directhex looks at power supply warranties
<persia> In addition to being a hobby, once you have a base set of components, you only replace some bits.  Frequently if you get a replacement for a failed component after a couple years, they send you a better one.
 * directhex sets a 3 year psu warranty as a minimum
<directhex> it's always the psu that pops
<stefanlsd> is there a way to make bzr diff   -> quilt diff patches?
<persia> Sure.
<Laney> stefanlsd: quilt has `quilt import'
<persia> Just extract the bzr patch, start the quilt patch creation process against the pristine source, apply the bzr patch, and save the new quilt patch.
<persia> Oh, that's even better :)
<stefanlsd> oh cool. thanks. will check out quilt import
<stefanlsd> i do all my merge stuff in bzr. makes life soo nice
 * Laney is old school
<Laney> I await james_w's session with baited breath
<stefanlsd> quilt import ffmpeg-headers.diff
<stefanlsd> Importing patch ffmpeg-headers.diff (stored as ffmpeg-headers.diff)
<stefanlsd> wow. and thats it. fixed the paths and everything
<Laney> quilt is magical
<directhex> hm, 5 year warranty from corsair. that's good. but they're uncheap
<directhex> hm. /me reduces selection to choice of 8
<slytherin> directhex: by the way, how much space is saved on CD now with the mono 2 transition?
<directhex> slytherin, not enough yet, as not all libs have been done
<directhex> a few meg afaik
<slytherin> directhex: what is your estimate?
<directhex> the estimate was ~18 meg
<directhex> current figures... dunno, slangasek might though
<ia> hello. could you tell me, please, if ./configure shows "<package> not found but required" message, then <package> should be added in Depends, or in Build-depends or in both fields in debian/control file?
<persia> ia, Typically, Build-Depends.  It ought go to Depends from the ${shlibs:Depends} line.
<ia> persia: ok
<james_w> sebner: are you on beautifulsoup?
<sebner> james_w: I wanted to do it next but have also other things to do if you want to take it
<james_w> sure, I can do that
<james_w> you were quicker than me on all the others, so I wanted to check
<sebner> heh
<sebner> james_w: I'm sorry :)
<james_w> sebner: you better be :-p
<james_w> sebner: I smiled at you requesting the contributor give reasons for the sync at this stage in the release cycle :-)
<sebner> james_w: well, people learn and grow up
<DktrKranz> james_w: link please! :)
<sebner> james_w: but most times I checked upstream myself and since there were no heavy changes I ACKed. Besides FF if far away :P
<sebner> DktrKranz: nah :P
<james_w> sebner: yeah, there's no problem at this point
<sebner> james_w: btw, we should add a note to the wiki -> Future MOTUs beware! There will always be wars and brutal fights for ACKing sync requests :P
<james_w> heh :-)
<Flimm> I'm packaging my own program, how should I handle translations of the package description?
<directhex> debian/control? don't.
<sll> hi room! I'm trying to do a deb package. do you know where can I find a good tutorial to do it? I read some tutorials but all show diferents way and for smal applications too.
<Flimm> directhex: how will it get translated then?
<slytherin> sll: which tutorials did you read?
<Flimm> sll: what are you trying to package?
<slytherin> Flimm: why do you need to translate them?
<directhex> Flimm, i wasn't aware debian/control supported translation
<Flimm> Well the Debian Description Translation Project seems to translate the descriptions somehow. http://ddtp.debian.net/
<Flimm> But it seems like the translations are only in the repo, not in the packages themselves
<directhex> seems that way. they ARE apparently supported in jaunty though -> http://archive.ubuntu.com/ubuntu/dists/jaunty/main/i18n/
<Flimm> Ok, another question, what's the best way to package po translations?
<james_w> vorian: hi, I'd like to clarify what license your manpages for ncpfs are under
<sll> ok, I read spanish tutorials, and I think the problem is that I don't know about rules file. I'm trying to package this sources http://hangar.org/wikis/lab/pd/pdvjtools/src/
<sll> they are externals/objects for puredata
<sll> can you recomendme any tutorial about deb packaging?
<pochu> !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
<pochu> . o O ( how is backports related to the packaging guide? )
<sll> ubottu: thanks :P
<ubottu> Sorry, I don't know anything about thanks :P
<stefanlsd> james_w: heys. i think we can try sync imview again
<james_w> is it built everywhere?
<stefanlsd> where would i check that exactly?
<stefanlsd> i've checked here - https://edge.launchpad.net/ubuntu/jaunty/+builds
<pochu> for Debian? buildd.debian.org
<pochu> (I guess it's for Debian as you're talking about a sync)
<james_w> https://edge.launchpad.net/ubuntu/+source/imagemagick/7:6.4.5.4.dfsg1-1ubuntu2
<james_w> so...yes
<stefanlsd> pochu: it was a dep we were waiting for.
<stefanlsd> cool
<james_w> stefanlsd: still fails to build for me
<stefanlsd> james_w: let me check
<james_w> thanks
<stefanlsd> actually straight after this libavg merge thats giving me hassles :)
<coolbhavi> james_w, the previous version too was a ftbfs
<james_w> coolbhavi: yeah, it's still the same version
<coolbhavi> james_w, yup ... the latest version of the dependency isnt helping too
<Laibsch> Hi
<Laibsch> Can somebody please upload my patch from bug 254228 to intrepid-proposed?  It fixes a quite serious error in sqlite3
<ubottu> Launchpad bug 254228 in sqlite3 "division error in sqlite 3.5.9-5" [High,In progress] https://launchpad.net/bugs/254228
<Laibsch> Sorry, wrong channel
<Laibsch> This is a core package
<Laibsch> from main
<Laibsch> I'll give you another SRU request in a minute to chew on ;-)
<vorian> james_w: BSD is fine with me, it'll keep all the manpages together
<james_w> vorian: cool, thanks
<vorian> no problem
<vorian> thanks for asking
<vorian> :)
<Laibsch> Can you please release wordpress from -proposed to -updates?  (bug 227547)
<ubottu> Launchpad bug 227547 in wordpress "ubuntu wordpress should suppress the "please update" warning" [Undecided,Fix committed] https://launchpad.net/bugs/227547
<DktrKranz> Laibsch: this is usually done by pitti, but is tagged as verification-done, so it's just a matter of time.
<DktrKranz> s/but/bug/
<Laibsch> OK
<Laibsch> Thanks
<DktrKranz> if you think it's extremely important, you can ask him in #ubuntu-devel
<Laibsch> no, it's not the most important one
<Laibsch> I've already asked about another SRU (which is much more serious) in #ubuntu-devel about a minute ago
<Laibsch> That one is still to be uploaded to -proposed, though
 * DktrKranz looks back when he was a motu-sru member :)
<Laibsch> why did you loose the priv?
<DktrKranz> lack of time by my side :(
<DktrKranz> Universe needs people testing -proposed uploads, it's a shame we fix bugs and no-one is there to report it works :(
<Laibsch> Well, I'm testing stuff
<Laibsch> ;-)
<persia> As much as it needs more -sru people, it needs more people in the testing team.
<DktrKranz> ... or more peoploe running development versions
<Laibsch> yeah, that is a problem
<DktrKranz> many fixes I've seen going via -proposed/-updates could easily get fixed in time for the release.
<Laibsch> I don't want to run development
<Laibsch> stuff
<Laibsch> But I help myself with Booting from USB and even more important with virtualbox
<Laibsch> Those were some very important improvements for bug testing lately
<DktrKranz> That's fine, but I realized I discover more issues using development version daily
<Laibsch> that is of course true
<Laibsch> But one has to do productive work, too, from time to time ;-)
<Laibsch> or work that pays bills
 * DktrKranz rethinks about gnat-4.2 transition made via SRU, what a pain!
<Laibsch> I'm spending too much time with bug testing as it is, too much fun ;-)
<DktrKranz> Ubuntu hasn't bugs, bugs are introduced by feature to avoid people to get bored.
<slytherin> slomo: just curious ... is there plan to sync/merge libdvdread and libdvdnav from Debian experimental?
<stefanlsd> james_w: yeah. still getting the build problem on imview.
<james_w> stefanlsd: it looks like a pretty bust configure.in
<stefanlsd> james_w: yeah. we prob could fix it and redo the .h files, but i think the point was the transition and imagemagick handling that stuffs. i'll check with lool.  he said his built...
<james_w> stefanlsd: yeah, but imview's configure.in isn't that smart
<james_w> doesn't set -I based on anything from imagemagick for instance
<stefanlsd> james_w: yeah. i think a .h somewhere is looking for magick/api.h and its changed to ImageMagick/api.h  or something to that affect. need to confirm
<james_w> stefanlsd: no, magick/api.h is still there you just need -I/usr/include/ImageMagick/
<stefanlsd> james_w: kk. cool. will try it out. also just wanna check with loic. (would prefer a sync)
<khashayar> james_w: about LP 314823: I was being confused about the diff.gz. So disregard of my second comment. The diff.gz that is attached works just fine. Would you mind taking a look at it when you have time? Thanks.
<ubottu> Launchpad bug 314823 in qtractor "qtractor needs to be updated to 0.3.0" [Undecided,New] https://launchpad.net/bugs/314823
<khashayar> I had a few things explained to me about diff.gz's by persia in #ubuntustudio-devel :-)
<lool> stefanlsd, james_w: I pushed imview to my ppa yesterday (the one from jaunty yesterday), it ftbfsed, then I pushed a fixed imagemagick, hit rebuild on imview, and imview built on all arches; then I pushed imagemagick to jaunty
<lool> You can check the Debian bug I referenced in the upload for details of the .pc file renames and the -dev renames
<lool> And xine-lib for an example package with decent build-deps
<lool> (which should work with old and new imagemagick
<lool> (and older)
<rhpot1991_laptop> morning cody-somerville
<james_w> lool: yeah, but we're looking at the -3 upload where one of the changes is to fix it with imagemagick from experimental
<james_w> ah, -> -devel
<lool> james_w: Yup
<lool> james_w: I also updated the bug
<lool> james_w: I agree the configure is sucky
<stefanlsd> lool: as a fix (prob ugly), uncommenting #           CPPFLAGS="$CPPFLAGS "`Magick-config --cppflags`  does get it to build.
<lool> stefanlsd: *cough*
<slayton> which of the deb helper scripts applies the patches under debian/patches?
<lool> stefanlsd: But it's better than using AC_CHECK_LIB IMO
<lool> (either use Magick-config or pkg-config, but don't check directly for headers or libs)
<stefanlsd> lool: oh. it still uses that for other stuff. heh.
 * RainCT is trying out KDE 4 beta. if someone wants to hear my rants about it, tell me to enable verbosity :P
<stefanlsd> lool: am i on the right track here?   http://paste.ubuntu.com/102772/
<lool> stefanlsd: Hmm no; PKG_CHECK_MODULES() wants as first arg the base name of the vars in which to store the _LIBS and _CFLAGS and second arg the list of pkg-config modules you need
<lool> stefanlsd: Check xine-lib's configure.ac for an example
<sebner> RainCT: sudo apt-get remove kde*, gnome ftw :P
<lool> You don't need the whole MAGICKNAME, LDFLAGS, and IMLIBS; instead you simply PKG_CHECK_MODULES(MAGICKNAME, DispatchImage, [have_imagemagick=yes], [have_imagemagick=no])
<lool> Err s/DispatchImage/ImageMagick
<stefanlsd> lool: kk. thx. cant seem to find too much documentation of PKG_CHECK_MODULES.
<lool> stefanlsd: You just PKG_CHECK_MODULES(FOO, [bar baz], [stuff run if bar baz are present], [stuff run if not])
<lool> That will set FOO_CFLAGS to pkg-config --cflags bar baz, and FOO_LIBS to pkg-config --libs bar baz
<RainCT> sebner: yeah.. visually it gets 10/10 points, but somehow it's quite slowish (on the new laptop! o_O)
<lool> (And will AC_SUBST them too BTW)
<lool> stefanlsd: So you just run the PKG_CHECK_MODULES and do an AC_MSG_ERROR if not present (because you require imagemagick to build)
<lool> if it's optional you don't AC_MSG_ERROR but you export some AM_CONDITIONAL which says that imagemagick support shouldn't build
<lool> stefanlsd: With PKG_CHECK_MODULES, you almost only have to do the PKG_CHECK_MODULES; it's really easy
<lool> stefanlsd: Do you have xine-libs's configure.ac?
<stefanlsd> lool: yeah, i do.
<lool> It's the same thing, but they use the Wand .pc, not the ImageMagick.pc one
<lool> Also it has a flag to build without imagemagick (AC_ARG_WITH([imagemagick] ...)
<lool> stefanlsd: So 1) it checks whether imagemagick was requested on configure command line; 2) if not disabled or if not specified it checks Wand.pc with PKG_CHECK_MODULES
<lool> 3) if it was requested and isn't present, it fails (AC_MSG_ERROR); otherwise it's disabled
<lool> 4) it sets the HAVE_WAND AM conditional to use in the build rules (Makefile.am)
<lool> stefanlsd: Note: AC_SUBST(WAND_CFLAGS) and AC_SUBST(WAND_LIBS) aren't needed
<lool> It's done by PKG_CHECK_MODULES already
<lool> So it's 10 lines to handle all cases; if you like you can do simpler by not handling any configure flags and always failing when im is missing; you don't need a conditional either in this case; but it's less elegant of course
<lool> stefanlsd: Is this any clearer, or am I confusing you further?
<stefanlsd> lool: thanks. that was great. i think its getting a bit clearer :).   Wand.pc is provided by whatever libary provides wand i presume?  do all libs provide .pc files?
<stefanlsd> and the problem with this configure is not that they use AC_CHECK_LIB, but they mix pkg-config and AC_CHECK_LIB and set variables that PKG_CHECK_MODULES would just do instead?
 * RainCT goes back to GNOME :P
<pochu> \o/
<RainCT> pochu! :)
<vorian> boo
 * vorian runs
<RainCT> vorian: man! you scared me!
<vorian> i was booing
<perlluver> vorian, loves KDE
<vorian> for realz perlluver :)
<perlluver> :P
<lool> stefanlsd: AC_CHECK_LIB requires the library path to be set properly, so it's an issue when IM is installed in special locations, or requires LDFLAGS to be located; they might have handled that, but it's overly complex to do it by hand and trivial with pkg-config (transparent even)
<lool> stefanlsd: Yeah, the mixture of a high-level tool which can do the job to test whether you can use the low level calls didn't make sense really
<lool> stefanlsd: No, not all libs provide .pc; IM did for a while
<lool> When you have one, it's best to use it unless you care for supporting older version of the lib which didn't have it
<stefanlsd> lool: cool. thanks very much for the help.
<soc> mok0: thanks for advocating again ...
<soc> mok0: afaik i need 2 advocates?
<mok0> soc: yes
<RainCT> LOL (@ xkcd.com)
<jpds> RainCT: Do you know that there's a spanish one?
<soc> RainCT: lol ...
<soc> mok0: mhhh, hopefully i find another advocate today, because i'm not at home anymore tomorrow ...
<mok0> soc: otherwise someone will pick it up sooner or later
<soc> mok0: yes, but if there are any additional comments, the package will lie arounf until the next weekend i fear ...
<mok0> soc: perhaps RainCT has time to take a look
<fabrice_sp_> Hi. IS there anyone to review DVDStyler? IT's at http://revu.ubuntuwire.com/details.py?package=dvdstyler and has already been reviewed by mok0 and siretart. Thanks!
<mok0> fabrice_sp_: I'll take a look in 10 minutes
<fabrice_sp_> oooh, you're there. Great! and thanks in advance ;-)
<mr_pouit> jdong: have you had some time to work on Bug #243451?
<ubottu> Launchpad bug 243451 in x264 "Please Upgrade x264 and libx264" [Low,Confirmed] https://launchpad.net/bugs/243451
<mok0> fabrice_sp_: what's that file "debian.patch" in $topdir?
<fabrice_sp_> mok0, it comes from upstream. It's a patch to apply if you want to build it in Debian
<mok0> fabrice_sp_: ok
<fabrice_sp_> mok0, I still have to convinced upstream to produce a tarball without debian building stuff
<mok0> fabrice_sp_: good work!
<fabrice_sp_> thanks ;)
<mok0> fabrice_sp_: uscan says there's a newer version available
<fabrice_sp_> really?
<fabrice_sp_> mok0, I will check then
<mok0> fabrice_sp_: (beta I think)  Newer version (1.7.2~b3) available on remote site
<fabrice_sp_> yes: it's the next beta version
<mok0> fabrice_sp_: I have just a couple of comments
<fabrice_sp_> (b3)
<mok0> fabrice_sp_: maybe it's not worth updating the package to a beta version
<fabrice_sp_> mok0, ok. Nothing big, I hope :-)
<mok0> fabrice_sp_: no just details
<fabrice_sp_> mok0, it's too early for the moment, to upgrade to beta. By experience, things get broken with dvdstyler
<mok0> fabrice_sp_: ok. You're the expert on that app
<fabrice_sp_> :-D
<mok0> fabrice_sp_: 2 minor comments. I will advocate your next upload
<mok0> (remind me if I forget)
<fabrice_sp_> mok0, great! I'll upload the fixes ASAP then. Thanks (and I will remind you if you forget, don't worry :-) )
<mok0> fabrice_sp_: ;-)
<slytherin> mr_pouit: What is the difference between gst-plugins-bad and gst-plugins-bad-multiverse?
<fabrice_sp> mok0, fixes uploaded :-)
<fabrice_sp> (I know: it's before you forget :-) )
<soc> mok0: ok, i will ask him ..
<soc> RainCT: could you advocate my package? http://revu.ubuntuwire.com/details.py?package=ttf-droid ...
<slayton> are there docs about how to automatically apply patches during the debuild process?
<slytherin> slayton: what do you mean? The patches are applied automatically.
<james_w> slayton: https://wiki.ubuntu.com/PackagingGuide/PatchSystems might be of help
<james_w> https://wiki.ubuntu.com/MOTU/School/PatchingSources as well
<slayton> so if I want to patch an already distributed deb can I just dget the package, add my patch the the patches dir, update the change log and rebuild? Is there any syntax I have to worry about in the patch name? Is there a file that lists all the patches to apply?
<ScottK> slayton: It depends on what patch system, so you need to look at the links james_w gave you.
<coolbhavi> slayton, It will be in /debian/patches/series normally
<mok0> slayton: there's usually a file in debian/patches listing the ones that should be applied
<ScottK> coolbhavi: That's only for quilt.  For dpatch it's 00list and simple.patchsys has no list at all.
<mok0> slayton: depends on what patch system is being used; there are at least 3
<coolbhavi> okay ScottK ...:)
<slayton> thanks eveybody!
<RainCT> slytherin: the license? :P
<slytherin> RainCT: so the source is same right?
<slytherin> RainCT: I mean there is no upstream tar ball for -multiverse package. So I am assuming that it is duplicated source.
<RainCT> slytherin: Maybe. Each has its own source package, but that's all I can say without downloading them
<RainCT> soc: I'm looking :)
<mok0> ScottK?
<ScottK> mok0?
<mok0> ScottK, looking at pyrocket that you've advocated. I'm trying to fix the watch file, and discovered that upstream tarball is named pyrocket_0.5.orig.tar.gz
<ScottK> OK.
<ScottK> It's been quite some time since I looked at that one.
<mok0> ScottK, Is that OK? I've never seen that before
<ScottK> mok0: IIRC upstream is also the packager and very interested in getting it into Ubuntu.
<mok0> ScottK, I guess the author really wants to be Debian-friendly
<ScottK> mok0: Yes.
<ScottK> It's unusual, but no harm in it.
<mok0> ScottK, OK, I'll fix the watch file and upload it
<mok0> ScottK, looks good to me too
<ScottK> Great.
<fabrice_sp> Got my first advocate to dvdstyler (\o/ mok0). Anyone to make additional review on that package? it's at http://revu.ubuntuwire.com/details.py?package=dvdstyler
 * slytherin really hates it when packages from debian unstable need packages from experimental for building. :-(
<ScottK-desktop> slytherin: If they do, it's an RC bug against the package, please file it.
<slytherin> ScottK-desktop: these are the evil arch all java packages. The build failures are revealed only in Ubuntu.
<ScottK-desktop> slytherin: Yep.  I got two python packages fixed in Debian yesterday for very similar reasons.
<mok0> Going to dinner, see y'all later
<slytherin> ScottK-desktop: Frankly, I am tired. Even if I file bug it is unlikely to get fixed anytime soon.
<RainCT> soc: I don't like the short description. Looks great otherwise :)
<RainCT> soc: if you can tell me a better short description I'll upload :)
<soc> short description? the 60 char line?
<RainCT> soc: yes
<soc> mom
<RainCT> soc: first error: it contains the name of the package
<soc> ah ok
<slytherin> ScottK-desktop: All this could be avoided if Debian wouldn't allow binary uploads.
<soc> "A font optimized for high-dpi devices and extensive language support"
<RainCT> although now that I check, most font packages have similar descriptions
<soc> maybe that?
<soc> "A font optimized for handheld dpi devices with an extensive language support"
<soc> better
<slytherin> ScottK-desktop: By the way, please help me understand why it is an RC bug?
<ScottK-desktop> Package is unbuildable.
<ScottK-desktop> Think about post-release security support.
<ScottK-desktop> The package has to build on more than the maintainer's machine.
<RainCT> soc: what about "and with" instead of "with a"? (I'm test building, btw)
<soc> "A font for handheld devices with an extensive language support"
<ScottK-desktop> slytherin: Debian Bug 511242 is for one of the ones I dealt with yesterday.
<ubottu> Debian bug 511242 in pyke "python-setuptools is missing in build dependencies" [Serious,Open] http://bugs.debian.org/511242
<RainCT> soc: great
<soc> is that line ok?
<soc> the other ones were too long
<ScottK-desktop> RainCT: I'd drop the "A" at the beginning
<RainCT> soc: Yeah. The "A" is usually not included though, see http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis
<RainCT> ScottK-desktop: /me too :)
<soc> "Font for handheld devices with extensive language support"
<ScottK-desktop> "Handheld device font with extensive language support"
<soc> "Handheld device font with extensive style and language support"
<soc> is that ok?
<RainCT> Yep, I'll change it to that then
<hanska> ScottK-desktop: I'm uploading clamtk 1.5.8-1 to sid.
<soc> mhh, or should i re-upload?
<RainCT> soc: not necessary :)
<soc> ah
<RainCT> actually, it's easier for me if you don't :P
<RainCT> so that I don't need to download it again ;)
<ScottK-desktop> hanska: Did you just do clamtk 4.08-1?
 * ScottK-desktop is confused by the version numbering.
<slytherin> james_w: you are last uploader for jspwiki, have you filed a bug in debian that dpatch is missing from build dependencies?
<hanska> ScottK-desktop: oops, sorry, confused myself, that's wicd 1.5.8-1 :)
<soc> do think it should be necessary to rename install and defoma-hints to ttf-droid.install and ttf-droid.defoma-hints again?
<hanska> sorry for the noise
<hanska> (I just saw my sponsor committing s/UNRELEASED/unstable/ to the repo...)
<soc> mok0 mentioned that ...
<RainCT> soc: I am of those who prefer "install" and "defoma-hints" for single-binary packages :P
<ScottK-desktop> hanska: No problem.  If you think it should be sync'ed into Ubuntu, please file a sync request bug and then subscribe ubuntu-universe-sponsors to the bug.
<soc> ah ok
<soc> then everything should be nice
<james_w> slytherin: yes
<hanska> ScottK-desktop: yes, I'll do, as soon as I re-checkout ubuntu-dev-tools
<soc> RainCT: so if the package will be accepted, it will go into universe?
<soc> or how will that work?
<ScottK-desktop> hanska: OK.  I did get clamtk done.  It was sync'ed about an hour ago.
<james_w> slytherin: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507177
<ubottu> Debian bug 507177 in jspwiki "jspwiki: missing build-dependency on debhelper" [Important,Closed]
<hanska> ScottK-desktop: great, thank you.
<RainCT> soc: Yes. After uploading it will go to the NEW queue for an archive admin to check the licensing, and then it'll enter universe if everything's OK
<james_w> slytherin: I just titled the bug wrong, and so the maintainer got it wrong
<slytherin> james_w: I am talking about dpatch, not debhelper.
<soc> ah ok
<james_w> slytherin: but, the upload also commented out the dpatch calls, so it could be synced.
<james_w> slytherin: but I'm not entirely sure that wasn't a mistake as well.
<soc> if the admin has questions about licensing etc, he could ask me, mok0, hasnka, pmjdebruijn, we had quite some discussion adn research until we got it right ...
<slytherin> james_w: I will see if Debian version builds. If it does then I will file a sync bug.
<RainCT> soc: most probably he'll just reject it in that case and you'll automatically get a mail
<james_w> slytherin: I imagine it will, but checking whether the patches that were dropped were needed seems more important
<RainCT> soc: btw, you may also consider submitting this to Debian
<slytherin> james_w: yes, checking that now
<RainCT> soc: it isn't as difficult as it may seem :)
<soc> RainCT: i was planning that
<soc> i already filed a ITP
<RainCT> soc: lintian just told me that debian/bug/script is missing the executable bit
<RainCT> soc: excellent :)
<soc> but i thought it might to faster if it gets into ubuntu, so the debian people can sync it from there ...
<slytherin> james_w: one of the patch is irrelevant. The other will be if package builds.
<soc> RainCT: mhh weird, i had the +x set ...
<slytherin> james_w: A quick look says the other one is still relevant. And the package contains .jar files. :-(
<RainCT> soc: well, that shouldn't really make a difference to them, afaik they have no rules to automatically accept packages from Ubuntu (like we do with those from Debian)
<soc> ah ok
<soc> what should i do to get it into debian?
<RainCT> soc: upload to mentors.debian.net and ask for review on the ML (info on the website)
<RainCT> soc: congrats on your first package being uploaded to Ubuntu! :)
<RainCT> soc: Uhm.. that Dust theme mentioned in your LP profile looks great. Count with a review from me if you ever happen to package it :P
<soc> coll, thanks :-)
<soc> mhh ok, i'll look into it
<RainCT> soc: is it ready for use already'
<RainCT> ?
<soc> yes, even using it with that QGtkStyle
<soc> i'll ask the author which version he would recommend
<soc> and then i'll try to do a package ...
 * RainCT hugs soc :)
<POX> RainCT: I never accepted a new package without some fixes first (and I'm not talking about cosmetic changes) and some of them were already accepted in Ubuntu (including yours, IIRC), so I doubt there will be automatic sync... :-P
<POX> (and I sponsored >200 packages)
<ScottK> POX: I think it goes both ways.  Pyke got into Debian just fine ....
<POX> yeah, RC bugs happen in packages prepared by DDs as well :)
<soc> RainCT: ok, against which package should i file the bug to package Dust?
<soc> ubuntu-meta?
<RainCT> argh.. why does IRC reconnect every time I switch from wifi to ethernet connection or the other way around? :/
<RainCT> soc: no package
<RainCT> soc: just against the Ubuntu distribution
<soc> ah ok
<POX> I think more important reason why Ubuntu package cannot be synced in Debian is that Ubuntu packages usually have a mailing list set as maintainer and even if they don't, there's no guarantee that maintainer wants to receive bugs from Debian
<POX> soc: is your package Python related?
<soc> POX: no, just some fonts
<soc> RainCT: dust is already in universe
<soc> it is in community-themes
<RainCT> soc: ah, cool. So I guess you can strike that point from your list :P
<soc> mhh, i didn't see that as well until now
<soc> i'll have to check which version is in there ...
<soc> because the current 0.2 release had some bugs already fixed in trunk ...
<soc> maybe i file an update request ...
<maxb> RainCT: Because you change IP address, no?
<RainCT> maxb: nope, both are connected to the same router
<RainCT> soc: what name does the package have
<RainCT> ?
<ScottK-desktop> RainCT: You reconnect to the router with a different IP/Source port combination.
<soc> RainCT: which package?
<RainCT> soc: for dust
<soc>  it is in community-themes
<RainCT> soc: ah, thanks
<RainCT> ScottK-desktop: and applications need to reconnect because of that?
<ScottK-desktop> Sure, it's a new connection.
<RainCT> bah, that sux :P
<RainCT> Btw, pbuilder-dist.new should be ready for use now. If anyone is bored please try it :)
<slayton> if I delete a file from the debian/<package>.install file, will it be excluded from the final packaged deb?
<RainCT> slayton: most likely, yes
<slayton> but not for sure?
<RainCT> slayton: if the package is weird and also installs it from debian/rules or something then it will still be there. but that would be *very* weird :P
<POX> ... or upstream's script (Makefile?) which is invoked in debian/rules installs it
<RainCT> yeah, that'd be another possibility
<POX> or clean rule is broken
<POX> or... ;)
<Laney> https://wiki.ubuntu.com/StableReleaseUpdates doesn't say anything about waiting for -sru ack (between 3 and 4 in "Procedure"). What is the actual procedure here?
<ScottK> Generally for Main you upload and ubuntu-sru reviews it in the queue, but for Universe you get the ack first.
<Laney> ScottK: Just one ack?
<ScottK> Yep
<Laney> good, that's easy then
<soc> RainCT_: should i archive ttf-droid now?
<soc> or how does that work?
<slytherin> in what file should I add pointer to /usr/share/doc/dpatch/README.source.gz  for specifying the patch system in use?
<slayton> RainCT_: thanks!
<ScottK-desktop> slytherin: debian/README.source
 * ScottK is suprised to discover that Ubuntu Top Uploaders has him at #12.  
<ScottK> Need to slow down.  I've been #15 for the last three releases.
<vorian> haha
<cody-somerville> where is that page?
<JontheEchidna> isn't that page down?
<StevenK> Yeah, did the page move?
<superm1> does it take into account SRU's?
<ScottK> http://thc.emgent.org/utu/utu_jaunty.php
<ScottK> superm1: Ask emgent.  I know it doesn't include backports.
<JontheEchidna> #18, not bad
<superm1> woah i'm falling behind this time. 19? psh.
<superm1> 18 last time and 12 before..
<agentblue9> Hi, I want to get more involved with packaging and MOTU and would like to find a mentor to work with.   I've contributed a debdiff to bug #293722 and would like to do a lot of bite-size things like this to gain experience.  Any guidance greatly appreciated. Thanks!
<ubottu> Launchpad bug 293722 in ctorrent "Bad manpage for ctorrent" [Low,Triaged] https://launchpad.net/bugs/293722
<soc> how long does it take until an advocated package appears in the repo?
<maxb> When you move a file from one binary package to another, is it documented anywhere precisely what the Replaces/Conflicts should look like?
<loic-m> Anyone to review the ecm package on REVU ( http://revu.ubuntuwire.com/details.py?package=ecm )? It's a small program, simrunbasuita has already reviewed it and I've made the suggested changes ;)
<slytherin> soc: the source first enters into NEW queue. When it is cleared from queue the package is built and the binary enters the new queue.
<slytherin> soc: https://edge.launchpad.net/ubuntu/jaunty/+queue
<soc> ah thanks!
<loic-m> Ecm is a neat program to remove error correction codes on isos for decreasing their size (and for better compression)
<soc> slytherin: btw, are there any plans to update openoffice to 3.0?
<StevenK> Openoffice 3.0 has already hit Jaunty
<StevenK> I think it's having trouble building
<slytherin> soc: calc: has already uploaded OOo 3. The builds are going on.
<slytherin> StevenK: not anymore.
<soc> https://edge.launchpad.net/ubuntu/+builds
<soc> ah ok
<soc> thanks :-=
<slytherin> soc: https://edge.launchpad.net/ubuntu/jaunty/+source/openoffice.org/+builds
<soc> btw, since when do we build for itanium?
<soc> (ia64)
<slytherin> soc: at least since hardy
<soc> mhh if lpia builds cÃ¶eanly, i386 should build too, i assume?
<soc> slytherin: ah ok
<sebner> norsetto: \o/
<soc> but it is not suported?
<slytherin> soc: community supported. Not officially supported.
<soc> ah k
<norsetto> sebner: Hola
<sebner> norsetto: how is live going in Italy? Much snow, what I've heard :)
<norsetto> sebner, yes, and good weather to go skiing too
<sebner> norsetto: in Austria? .P
<norsetto> sebner, nope, 100 km from my house
<sebner> norsetto: that far? Here is a big skiing area, just 10km away :P
<RainCT> uhm.. can someone explain to me what AllowTcpForwarding in SSH/SFTP is for?
<slytherin> RainCT: some context please? What is 'AllowTcpForwarding'? Is it a configuration parameter on server side?
<RainCT> slytherin: yes
<RainCT> slytherin: I've seen it here;
<RainCT> http://blog.markvdb.be/2009/01/sftp-on-ubuntu-and-debian-in-9-easy.html
<jpds> RainCT: man sshd_config
<RainCT> jpds: that doesn't help, I want to know what TCP forwarind is for :P
<slytherin> RainCT: Have you ever done port forwarding over ssh?
<RainCT> no
<RainCT> so that's what people use to "workaround" blocked ports, or what?
<jpds> RainCT: http://en.wikipedia.org/wiki/Tunneling_protocol#SSH_tunneling
<slytherin> RainCT: when you login to an ssh server, you can bind a local port to a remote host:port on the machine to which you are connecting.
<RainCT> ok, thanks
<slytherin> RainCT: the example command is 'ssh -L 10000:192.168.0.10:80 server'. This way when you access localhost:10000, you are actually accessing 192.168.0.10:80 in the network of the ssh server.
<RainCT> slytherin: ok, I see :)
<quadrispro> sebner: hi!
<quadrispro> sebner: what do you think about http://paste.ubuntu.com/102950/ ? (you are the last uploader)
<Laney> quadrispro: Please wait with smuxi
<Laney> we're (I'm) trying (hoping) to fix a small build problem
<quadrispro> ah ok Laney! I'm going to look for another merge to do
<Laney> I'll mark it on DaD
<quadrispro> it could be fine
<sebner> quadrispro: besides. the transition is b0rken. Please no further rebuilds!
<Laney> quite
<quadrispro> if you want, you can use my debomatic machine (setup by Dktrkranz) -> http://home.alessiotreglia.com
<Laney> what is debomatic :(
<quadrispro> Laney: https://launchpad.net/debomatic
<Laney> crazy, my panels just disappeared but they're still clickable
<soc> my package disappeared from the build queue (https://edge.launchpad.net/ubuntu/+builds ), how long will it take until it hits universe?
<Laney> soc: What does it say on the package page?
<maxb> It is currently here: https://edge.launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text=ttf-droid
<soc> oops, i didn't see it anymore ..
<soc> thanks
<soc> so is this a manual process or will it be built automatically, when a build server is free?
<Laney> You have to wait for an archive admin to review and accept (or reject) it
<Laney> then it'll build, then they have to accept the binaries
<soc> ah ok
#ubuntu-motu 2009-01-10
<jekil> please someone can sponsor ? https://bugs.edge.launchpad.net/ubuntu/+source/obextool/+bug/133748
<ubottu> Ubuntu bug 133748 in obextool "Obextool don't have menu entry" [Wishlist,Confirmed]
<crimsun> i thought we were out of the habit of assigning to u-u-s
<nhandler> crimsun: Yeah, u-u-s should be subscribed, not assigned
<Laney> jekil: You don't have to ask people to sponsor, someone will get to it in time
<Laney> (also you didn't mention the control changes in your changelog)
<Laney> (also, there is a new upstream release of this program, consider updating to it)
<Laney> iulian: congrats!
<iulian> Laney: Thanks.
<Laney> Done your first upload yet?
<nhandler> Congrats iulian
<nhandler> iulian: You might be interested in https://wiki.ubuntu.com/MOTU/New
<iulian> Laney: Not yet.
<james_w> congratulations iulian
<iulian> nhandler: Thanks, I'll have a look at it tomorrow morning. I'm pretty tired right now and I should go to bed.
<iulian> Thank you james_w.
 * iulian yawns
<nhandler> Is there anything that can be done to get a package that needs w32codecs into the repositories?
<ScottK> nhandler: Are there w32codecs that are distributable?
<nhandler> ScottK: I'm not sure. I'm also not sure exactly what parts of w32codecs the package needs.
<StevenK> And I thought w32codecs needed a Windows license to use legally ...
<ScottK> You need to be able to get a package's depends into the archive, so ....
<nhandler> ScottK: Ok, I just wanted to make sure there wasn't any other way before I told him that it can't get in with that depends
<StevenK> Depends: windows-license
<nhandler> StevenK: Why would I want that garbage getting pulled onto my machine?
<StevenK> nhandler: Because that's what w32codecs legally requires
<Hobbsee> nhandler: you can do like we do for stuff that needs libdvdcss2, fwiw.
<Hobbsee> it's a bit dirty, but...
<StevenK> It's quite dirty
<nhandler> Hobbsee: He is the upstream author of the application. I'm going to see if he can modify it to not Depend on w32codecs
<Hobbsee> nhandler: that works too
<Amaranth> StevenK: Not even a Windows license is enough, most of that stuff says you can't use it outside of Windows and/or outside of installing their program on Windows
<jdong> imp/win 30
<coolbhavi> I am getting smtp send error when i use the submittodebian command
<coolbhavi> please help anyone
<Hobbsee> are you using your own smtp server?
<coolbhavi> Hobbsee, no
<coolbhavi> here is the error I get: http://pastebin.com/d709c8367
<Hobbsee> coolbhavi: they probably won't let you use their own smtp server, i suspect.
<coolbhavi> Hobbsee, why?
<StevenK> As long as the To address is something they accept, I don't see why not
<Hobbsee> because letting any joe random use your smtp server is a bad idea?
<Hobbsee> that's true
<fabrice_sp> Hi. The package flashblock  depends of CVS image, ignoring the normal release versions (jaunty => flashblock-1.3.11a~snapshot20081113, author = 1.5.7.1). Won't it ibe better to repackage it?
<StevenK> Hobbsee: Sure, but joe random can use your SMTP server to send you mail
<Hobbsee> this is true
<coolbhavi> Hobbsee, Okay so now should I open an account?
<StevenK> Which SMTP server is it using?
<coolbhavi> submit@bugs.debian.org
<StevenK> That's an e-mail address, and not an SMTP server.
<coolbhavi> okay! sorry wait a min please
<coolbhavi> Connecting to fiordland.ubuntu.com via SMTP...
<StevenK> That's why.
<StevenK> fiordland isn't going to like you using it to send mail to a bugs.debian.org, address
<StevenK> s/,//
<coolbhavi> okay! now which address to change?
<StevenK> coolbhavi: There should be an option to set it, I'd suggest you try rietz.debian.org
<coolbhavi> okay!
 * Hobbsee notes that one needs to authenticate to fiordland.ubuntu.com before sending, it appears.
<StevenK> Oh?
<Hobbsee> or else i'm not reading requestsync right
<StevenK> Which line?
<crimsun> fabrice_sp: please ask in #ubuntu-mozillateam
<fabrice_sp> crimsun, will do. Thanks
<foobarmus> Hi... I'm looking for a little guidance on the REVU process (new to it, but have read a few of the docs, and uploaded my package -- wondering what comes next)
<foobarmus> Also saw a comment on one of the other "new packages" the other day saying it was going to be uploaded to intrepid -- wondered if that was a typo or if there is some kind of shadow process for getting packages included in older universe repositories?
<highvoltage> iulian: congrats on being a motu!
<dpreacher> hello
<savvas> Hobbsee: are you living in antarctica?
<Hobbsee> savvas: of course.
<savvas> no, seriously, i was looking at map locations: https://launchpad.net/~hobbsee
<Hobbsee> I figured.
<savvas> :)
 * Hobbsee is clearly located in Antarctica.
<savvas> it must be so.. cool hehe
<savvas> better yet, cold!
<Hobbsee> very!
<Hobbsee> Warm jackets are a must!
<emgent> someone please stop coolbhavi ?
<Hobbsee> emgent: from what?
<tuxmaniac> emgent: what did he do now?
<emgent> Hobbsee: launchpad.. him continue to notify sync and merge, but dont take time for review and test it..
<Hobbsee> emgent: sigh.  send a mail to him, asking him to stop if he doesn't have the time to review and test?
<emgent> we should ask to implement launchpad user ban... ehehe
<Hobbsee> emgent: if that fails, mail the MC / MOTU list about it
<emgent> Hobbsee: yeah.. but not reply..
<Hobbsee> emgent: oh, so you've tried this, and he hasn't replied?
<emgent> not now..
<savvas> https://launchpad.net/~bhavi ?
<emgent> i mailed yesterday
<emgent> savvas: yea
<tuxmaniac> savvas: yep :-)
<sebner> emgent: I acked some syncs from him ^
<emgent> the real problem is that him dont work in one bug.. him start to work in N bug..and mass notify sync/merge/fix in launchpad..
<emgent> sebner: have you saw drupal sync request ?
<StevenK> This sounds like someone we knew
<Hobbsee> oh dear.
<Hobbsee> StevenK: it's not the same guys
<Hobbsee> -s
<sebner>  emgent seen yes, reviewed no
 * Hobbsee eyes https://bugs.edge.launchpad.net/ubuntu/+source/gitmagic/+bug/315748
<ubottu> Ubuntu bug 315748 in gitmagic "Please sync gitmagic 20090101-1 (universe) from Debian unstable (main)." [Wishlist,New]
<emgent> it`s wrong..
<StevenK> I figured, but the behaviour patterns are disturbing
<Hobbsee> emgent: he's clearly still active, but hasn't responded to your mail.  I'd try emailing the MOTU list, and CCing him, and seeing if that has any effect.
<emgent> Hobbsee: yeah will try it if him dont reply to me today.
<emgent> danke, i go to eat
<emgent> brb people
<tuxmaniac> Hobbsee: is there something wrong with that bug 315748 ?
<ubottu> Launchpad bug 315748 in gitmagic "Please sync gitmagic 20090101-1 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/315748
<Hobbsee> tuxmaniac: well, as for why he's giving it an ubuntu version, in the build log, i'm not sure.
<tuxmaniac> aah Ok
<Hobbsee> tuxmaniac: but that suggests he doesn't actually know what he's doing, and the difference between a sync and a merge.
<StevenK> No, it's because he's uploading it to his PPA
<StevenK> The buildlog comes the PPA
<Hobbsee> i figured that, but he should be able to upload the debian version to a ppa
<StevenK> Maybe he doesn't know how
 * Hobbsee has also got no idea if he's actually changed anything else
<StevenK>  gitmagic (20090101-1ubuntu1) jaunty; urgency=low
<StevenK>  .
<StevenK>    * Build test.
<Hobbsee> emgent: re drupal6, launchpad says we have no ubuntu changes on it, fwiw
<Hobbsee> eyeballing it, it's probably OK
<savvas> what's the difference between sync and merge? because I recently asked for amarok 2.0 :P
<emgent> Hobbsee: pong exim4 -> postfix
<tuxmaniac> savvas: merge is when you have local changes in Ubuntu and you want to update a package from Debian
 * Hobbsee snorts at both bugs on the drupal package.
<savvas> tuxmaniac: and sync when you want to get a new release package?
<StevenK> drupal6?
<StevenK> Since drupal is a different package again
<tuxmaniac> savvas: https://wiki.ubuntu.com/UbuntuDevelopment/Merging
<Hobbsee> StevenK: no, it's the same thing
<StevenK> And made me go, "Um? This was removed in ... Gutsy?"
<Hobbsee> StevenK: they go by api now
<Hobbsee> StevenK: as in, drupal5, drupal6, etc.
<savvas> oh, thanks!!
<StevenK> Bleh
<emgent> StevenK: why bleh ?
<tuxmaniac> savvas: no. sync is when you have an outdated package with no local Ubuntu changes and there is a better version in Debian. Youmight just want a sync.
<StevenK> emgent: Seperate packages for every API
 * Hobbsee looks at hte eyesore from multiple people that is https://bugs.edge.launchpad.net/ubuntu/+source/drupal6/+bug/229795
<StevenK> And that it's written in PHP
<ubottu> Ubuntu bug 229795 in drupal5 "Sync Drupal 6.2 to Ubuntu" [Unknown,Fix released]
<tuxmaniac> savvas: ofcourse one must build and check if the new package has extra dependency or any changes that prohibits from building in Ubuntu
<emgent> Hobbsee: anyway it`snt a SYNC ubuntu use postfix and debian exim4 in default mode, also there are some scripts and dir to fix if i remember well.
<Hobbsee> emgent: mmmkay.  https://edge.launchpad.net/ubuntu/+source/drupal6 says it was autosynced currently, fwiw.  You may want to make ubuntu changes to it though, after the new one goes in
<emgent> at this point ya, will do
<Hobbsee> or just pull in the new version while you're at it
<Hobbsee> ;)
<StevenK> It needs Ubuntu changes?
<emgent> StevenK: correct
<emgent> it`s impossible think to sync Drupal form debian.. if debian use exim4 in default mode and ubuntu use postifx.
<emgent> after that there are more little fix to apply about dirs, debian use /srv/ and ubuntu not.
<emgent> i will take a look later.
<Hobbsee> emgent: ah, looks like you're thinking of drupal5.  Those bugs are for drupal6.
<james_w> is anyone here involved with the edos page for Ubuntu?
<james_w> ah, gaspa, it looks like you may be involved with the edos page, is that correct?
<james_w> gaspa: if so, has there been some restructuring recently?
<gaspa> james_w: what?
<james_w> gaspa: is http://hattory.no-ip.info/issues/edos/ anything to do with you?
<gaspa> yep, it's mine
<james_w> did you make some changes in the last couple of days
<james_w> ?
<gaspa> couple of days? no. Before the new year.
<james_w> the links from harvest no longer go to the right place, and the csv file has gone?
<james_w> thanks for running it though btw
<gaspa> uhm
<gaspa> I see
<gaspa> in fact there's no csv files.
<gaspa> james_w: thanks for the signal, I'm taking a look
<james_w> thanks
<gaspa> james_w: JFY, do you use it, usually?
<james_w> yeah, it's a useful tool
<gaspa> cool :) I'm refactoring the cache code, and trying to move all into python modules.
<gaspa> so they can be re-used in other stuff.
 * gaspa feel a little more useful to the world, now. :)
<gaspa> james_w: run by hand seems to work. honestly I'm not understanding...
<gaspa> feel free to ping me if it brokes again.
<nhandler> Should the short description in debian/control begin with a capital letter?
 * RainCT doesn't think so, but that depends on who writes it
<Laney> qno
<Laney> -q
<Laney> Since the synopsis is a clause, rather than a full sentence, we recommend that it neither start with a capital nor end with a full stop (period). It should also not begin with an article, either definite (the) or indefinite (a or an).
<nhandler> Laney: Is that from the Debian policy?
<Laney> developers' reference
<nhandler> :)
<Laney> http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis
 * RainCT should re-read all this stuff to know from where to quote when he answers something :P
 * nhandler thinks we need to create a Packaging FAQ
<RainCT> there is already one
<Laney> I just googled for debian/control short description :(
<RainCT> somewhere on wiki.ubuntu.com...
<RainCT> Laney: hehe
<nhandler> RainCT: I know, but iirc, it was very incomplete
<RainCT> nhandler: complete it then :)
 * RainCT runs
 * iulian looks around.
<nhandler> RainCT: I'll add it to my enormous todo list
<iulian> RainCT: Would you please modify my revu permissions so I can advocate?
<RainCT> btw, as soon as someone upload a new ubuntu-dev-tools revision, pbuilder-dist.new will replace pbuilder-dist
<RainCT> iulian: sure
<RainCT> iulian: oh, I didn't see you yesterday when I wanted to say this, so: congrats! :)
<sebner> iulian: congratulations, btw :)
<Laney> Replace pbuilder-dist with pbuilder-dist.new. \o/
<nhandler> RainCT: I think we should be do for a new upload soon. The changelog is getting pretty long
<RainCT> nhandler: yeah.. and then backport to intrepid
<iulian> RainCT, sebner: Thanks.
<RainCT> iulian: done (LP was slow and didn't want me to login.. :P)
<tuxmaniac> iulian: would you like to start of some review advocacy on REVU now? http://revu.ubuntuwire.com/details.py?package=gresistor may be a nice start ;)
<iulian> RainCT: Thanks :)
<iulian> tuxmaniac: Sure, I will have a look at it today.
<Laibsch> Hi there
<Laibsch> I'm trying to upload unchanged sources from debian experimental to my ppa for testing.  According to "https://help.launchpad.net/Packaging/PPA#Using%20packages%20from%20other%20distributions" this should be possible and I think I did it successfully once or twice in the past
<ScottK> Laibsch: PPA questions in #launchpad.
<Laibsch> OK, thanks
<anakron> HI all
<anakron> hi persia
<anakron> i wanna know what i can do if when i compile with cmake (my first time) appears 'Unknown CMake command "qt4_wrap_ui"'
<anakron> hi again
<anakron> hi Emmet
<anakron> Hi RainCT
<anakron> i wanna know what i can do if when i compile with cmake (my first time) appears 'Unknown CMake command "qt4_wrap_ui"
<anakron> which package i need to install?
<anakron> someone can help?
<azeem> anakron: packages.ubuntu.com has a search function to see in which package a particular file is in
<abedra> are there any plans to update git on 8.10 to current
<abedra> ?
<Brandon_> abedra: you may be able to package it up and submit it to the package maintainers for that project.
<abedra> Brandon_: yeah
<abedra> Brandon_: I will get it all packaged up
<abedra> Brandon_: I develop in rails day to day and the capistrano deployment tool doesn't work with git 1.5.x
<abedra> Brandon_: So it would be nice to have 1.6.x out in package form
<Brandon_> abedra: thanks for your contribution!
<anakron> hey
<anakron> azeem
<anakron> but i build dependencies
<anakron> and i cant compile it
<oojah> I don't suppose anybody would consider reviewing http://revu.ubuntuwire.com/details.py?upid=4467 if they've got time? I've already fixed a number of comments from irc.
<anakron> someone can help?
<anakron> i wanna know what i can do if when i compile with cmake (my first time) appears 'Unknown CMake command "qt4_wrap_ui"
<anakron>  i build dependencies and they are ok
<anakron> and i cant compile it
<oojah> anakron: I think you need to include the cmake module with that command in in your CMakeLists.txt.
<oojah> From http://cmake.org/cmake/help/cmake2.6docs.html I can see that qt4_wrap_ui looks to be in FindQt, so add "include (FindQt)" somewhere near the beginning of CMakeLists.txt.
<oojah> (probably)
<anakron> ok thanks
<Flimm> Hello, my program, epidermis, is now displayed as a Ubuntu package at https://launchpad.net/ubuntu/+source/epidermis/ what does this mean?
<Flimm> Nothing has been published yet on that page
<Flimm> Does this mean someone's considering adding Epidermis to the repos?
<RainCT> Flimm: I guess it's just Launchpad being weird
<rexbron> Hey motu
<rexbron> Anyone want better support for firewire audio recording devices? Please review libffado: http://revu.ubuntuwire.com/details.py?package=libffado
 * khashayar thinks ffado's the best thing since sliced bread. Please?
<slytherin> NCommander: is there any plan on updating linux-image-* for powerpc?
#ubuntu-motu 2009-01-11
<anakron> hi all
<anakron>  i wanna know what i can do if when i compile with cmake (my first time) appears 'Unknown CMake command "qt4_wrap_ui"
<anakron> ping persia
 * persia prefers contentful pings
<anakron> :) hi
<anakron> i have some problems for reproduce a bug of qterm
<laga> persia: i'd word that a bit more strongly.
<anakron> jeje
<persia> laga, Well, I usually just ignore them.  When the third comes in 12 hours, I figure it's worth a note.
<persia> anakron, I know almost nothing about qterm.  Also, you may have better luck getting someone to help you reproduce a bug in #ubuntu-bugs.
<anakron> mm ok :)
<persia> nellery, Just FYI, MC voting is majority, so despite my dissent, you'll likely get added to the group once the remaining council member votes.  Don't worry about waiting for that resolution to proceed with other activities.
<nellery> persia: ok.  It's an interesting point to bring up... I'd always considered universe contributors to be generally necessary, and that becoming a member was just an added bonus
<nellery> has this ever been brought up in the past?
<ScottK> nellery: There have been cases in the past where people tried to make UUC into more than "Member via MOTU Council for MOTU work", but that's really all it is.
<persia> It's been brought up several times.  The group exists simply because the CC didn't want to grant MC admin over UbuntuMembers (note that the majority of current MC have that anyway).
<persia> Personally, I'd like to see UUC be more, but that means essentially a blanket auto-ACK for any current member wanting to join the team, by simple request.
<persia> Since people seem to be processing applications by existing members (no idea why), I'll agree that there's no point to granting special permissions or anything.
<persia> In the last CC meeting, there was talk about not further delegating ubuntumembership to additional councils, and redirecting to the RMBs.  Depending on how that conversation proceeds, I may wish to take the position that MC shouldn't be approving members, instead redirecting to the RMBs.
<persia> Of course, that probably requires coordination with the other pre-delegated councils (e.g. Kubuntu Council, Edubuntu Council) for coordinated action.
<ScottK> persia: FYI, for a Kubuntu member there are PPA's and such that they gain upload rights to, so we've had Ubuntu members who got involved in Kubuntu ask to become Kubuntu members and it's been (reasonably, IMO) done.
<ScottK> So it's a little different than UUC.
<persia> ScottK, Well, I'd like to see UUC more like that, as a proponent of making UUC special, but in the current incarnation, there's no value to it.
<persia> The part about Kubuntu Membership that I was referencing was that Kubuntu members are inherently Ubuntu members.
<ScottK> Right, but if we want that, then we need to select for it and we haven't been.
<persia> Ignoring the lack of Gubuntu branding.
<ScottK> Yes.
<persia> Well, all current non-MOTU members of UUC are at least around and doing stuff, but yes, it would need a review.
<persia> The team as it exists is poorly defined, in part because it was unexpected, and there's several ways to define it.
<persia> With the current model, UUC can't be defined as special without breaking mako's directive that membership-through-development shouldn't be different.
<persia> I suspect Kubuntu-member oughtn't be defined as special for the same reason, but that's far too sensitive an area for me to want to poke.
<ScottK> Right, Kubuntu membership predates that, so I think it's grandfathered.
<persia> Yes, let's call it grandfathered.
<persia> As long as KC has a sane procedure for current Ubuntu Members (and I think they do), it should be fine.
<ScottK> Seems to me they do.
<persia> Still, with RMBs (which didn't exist at the time of UUC creation), and with the growth in the community causing apparent tribal development (as is natural), I'm not sure we wouldn't be better off removing previous membership delegations (including to the MC), and pushing everyone to the RMBs.
<persia> Then tribes can develop within that group, but there's a fairly standard basis for all members.
<persia> Of course, this requires that RMBs be representative: members from each tribe in each region.
<ScottK> If I were an aspiring MOTU I'd find that incredibly demotivating.
<persia> How so?
<ScottK> Instead of getting recognized within the framework to which I was accustomed, I'd be going to a group of strangers.
<persia> Well, the point would be to reduce the perception of them as strangers.
<persia> And to have members of one's tribe represent one's suitability to the RMB.
<ScottK> Well unless i have an incentive to interact with them before I want to be a member...
<ScottK> OK.  What's a tribe in this context?
<persia> a tribe is a set of people that consider people outside that context as strangers.
<ScottK> OK.  Makes sense.
<persia> Classes might include Kubuntu folk, who look to the KC, or MOTU, who look to the MC, etc.
<ScottK> So in those terms it'd be having to go outside my tribe for approval.
<ScottK> To me that's more intimidating and less comfortable than staying within.
<ScottK> ergo, demotivating.
<persia> My thought is that it's better for a tribe to bring a prospective member to the RMB for approval, than to have each tribe approve separately, if there is a desire to have a single identity associated with "Ubuntu Member".
<persia> So members of one's tribe escort one to the RMB, rather than telling one to proceed alone.
<persia> Those with strong tribal affiliations would likely have an easier time than those who don't associate with a given tribe.
<ScottK> Right.  We have problems like that here  already.
<persia> The LoCos do that fairly agressively now, where endorsements from other LoCo members are present.
<persia> Yes, we have lots of those sorts of problems.  We also do fairly poorly at intertribal communication.  There are individuals who participate in several tribes, but that is no longer sufficient.
<agent47a> I'm an aspiring MOTU.  Honestly not following the conversation very well. :)  I'm looking for bitesized stuff to do and learn here: https://launchpad.net/ubuntu/+mentoring .  Just wondering if this is the best approach.
<persia> agent47a, That's a very good approach.
<persia> agent47a, Another thing I found motivating was to look for bugs that annoy me, and hunt them down until they were dead, to make my system work perfectly.
 * ScottK too
<persia> The former will get you more help, and the latter may be more satisfying.  In either case, if you get stuck, or need help, feel free to ask here, regardless of what other discussions are underway.
<agent47a> persia: cool.  thanks!
<ScottK> agent47a: https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=bitesize&field.tags_combinator=ANY&field.has_no_package.used= may a
<ScottK>  interest.
<ScottK> Sorry, but blame the LP devs for that, not me.
<persia> ScottK, The issue is that in many languages, it's a small step from "stranger" or "other" to "enemy".  I presume that link is related to something in human psyche, and so would prefer to avoid too much of it, as much as we need to have functional tribes to maintain cohesion with our increasing size.
<ScottK> I agree.
<ScottK> There is something very fundamental in the human mind that divides people into "us" and "them".
<persia> Creating a hierarchy, such that tribes then bring people to the RMBs, rather than having tribes independently approve, helps define the model that we are part of a larger body, regardless of how well we define ourselves within a tribe.
<agent47a> i was thinking of trying to package performous: http://www.performous.org .  As my first foray into packaging, is this advisable?  What's the best way to check that I'm not already duplicating an effort?
<ScottK> But you don't send the new people out into the jungle to meet with strange tribes.  It should be the experienced people.
<bluesmoke> persia: I tried hunting down bugs that annoyed me once, I think I ended up spending a year on a menu editor and 2 years on a window manager :P
<persia> That is annoying for KC, MC, etc.  It's also annoying for people joining, but I think it matches the federated city-state better.
<bluesmoke> oh...
<persia> ScottK, Well, sorta.  You bring the new person with you on a visit, to introduce them around, but along with experienced people.
<ScottK> agent47a: Look for a bug tagged needs-packaging about it.
<ScottK> Right.  I do that now between Kubuntu and MOTU and Server Team and MOTU.
<persia> agent47a, I'd recommend working on bugs first, and developing some preferences for packaging styles, before packaging something from scratch.
 * ScottK too
<persia> Amaranth, And we've all benefited.  Thank you :)
<ScottK> persia: I agree with the goal, I just don't know that that's the best way to achieve it.
<agent47a> persia: ic
<Amaranth> persia: Just saying, hunting down your personal annoyances can be a big task :P
<persia> ScottK, Neither do I.  I've just been reflecting on it since the CC decision not to grant IRCC membership authority on the basis of functional RMBs.
<Amaranth> I'll be working on said window manager once I finish some projects I can't do from Ubuntu, btw
<ScottK> Well I know people have gotten Kubuntu membership based on IRC support participation.
<ScottK> I'm not sure what an IRC membership would be for.
<persia> ScottK, Well, presume someone does a lot of channel coordinate and operations work, for say 25 channels (there is an *explosion* in LoCo channels, and IRCOps are thin in some places).  They do this for several months, and expect to do it in the future.  They want an @ubuntu.com for this.
<ScottK> OK.  I'll buy that.
<ScottK> But I'm going to guess that those channels are related to something.
<persia> So, based on this, the IRCC asked the CC for the ability to grant memberships to people who met the criteria (note that there is some IRCC representation in RMBs, so it's not "I want to do that too").
<ScottK> IRC doesn't stand alone.
<persia> Well, yes.
<persia> Alternately, I could imagine the LoCo Council asking for membership grant, which would likely be denied on the same basis.
<ScottK> Well LoCo's by definition already have a regional focus.
<persia> Yes, but don't assume that the "Regional" in RMB has anything to do with location.  On several occasions the CC has directed people to pick the RMB based on convenient time for the meeting, rather than location.
<persia> While I haven't tracked others closely, I know that the AsiaOceania board has seen people from 5 continents.
<ScottK> I've seen that.  I've found it odd.
<persia> Based on that, I've presumed that it's just poor nomenclature.
<ScottK> Of course post archive reorganization, MC might be bringing people toghether from different developer tribes.
<persia> Quite possibly.  At least there should be some sane definition of developer tribes which matches reality.
<Amaranth> Any idea when we're actually going to get archive reorg?
<Amaranth> It's been almost a year since it was an active topic :/
<ScottK> I understand we're blocked on LP won't do some stuff it needs to.
<ScottK> It's been a discussion point at the last two UDS.
<ScottK> it appears to me that things are headed in that direction.
<persia> My understanding is that the necessary LP bits are now at least planned.
<Amaranth> I was at the one in prague, most exciting/boring session ever :P
<persia> The last UDS discussion covered a lot of implementation details.
<persia> I expect that the specification will become more clear in the next week or two: I know the spec is approved for jaunty, although it's not entirely clear what that means.
<Amaranth> I just want to be able to upload compiz :P
<ScottK> Amaranth: Per package upload rights for MOTU are already possible.  You can ask the tech board.
<Amaranth> Ooh
<Amaranth> First I have to get MOTU again
<ScottK> I think they decided not to do it for non-MOTU, but I don't recall for certain.
<persia> There's a precedence for the TB to reject an application for per-package uploads by non-MOTU, for packages in main.
<ScottK> OK.  That's the one I didn't remember how it was resolved.
<persia> I'm not sure that any clear statement was made about per-package uploads for universe by non-MOTU: I think discussions on those lines were routinely pushed into ArchiveReorganisation.
<ScottK> Well since he wants Compiz, I think he needs MOTU then.
<persia> ScottK, It's not yet entirely resolved: TB needs to rule on the renewed application now that it comes from a MOTU.
<persia> Amaranth, For returning MOTU, just send an email to MC saying why you want to be MOTU again, and what you plan to do in the future.  I think these just get approved, although I need to double-check the procedures.
<persia> Amaranth, Or, wait a bit, and maybe it won't matter.  Unless you want MOTU for some other reason (and you'd be welcome), I'd suggest at least waiting until the next revision of the ArchiveReorganisation spec.
<Amaranth> Honestly all the packages I want to work with have ended up moving to main so...
<persia> In that case, you're better off waiting.  Given the timing (February was mooted as a possible date at UDS), being MOTU may not be useful for you.
<persia> Of course, if I'm wrong, and it's going to be a long time, then of course, renew your MOTUship, and apply to be a per-package uploader.
<Amaranth> I dunno, I suppose there are a couple packages in universe I'd want to work with
<Amaranth> and of course new packages have to start in universe
<persia> Well, there are certainly a lot of advantages to being MOTU, but there was some reason you gave it up in September, so you'll have to decide.
<ScottK> I think I'm going to head off to bed.  Good night all.
<persia> Good night ScottK
<Amaranth> It'll probably be a month before I'm ready to get back into all this anyway, I suppose I'll check again then
<persia> That sounds like the most sane of plans.  If nothing else, there should be an answer to the question "What does ArchiveReorganisation mean?" at that point.
<Amaranth> persia: I didn't know it was auto-renew and I wasn't active in Ubuntu at the time
<Amaranth> err, self-renew
<persia> Oh, in that case, you may as well reapply :)  No point stopping being MOTU by accident.
<agent47a> Regarding bug #270984.  What's involved in updating the man system tool?  I tried to get the source via "apt-get source man" but came back empty-handed.
<ubottu> Launchpad bug 270984 in man-db "man should support retrieval of remotely available manpages via wget/curl" [Undecided,Confirmed] https://launchpad.net/bugs/270984
<agent47a> i think ubottu answered my question :)  "man-db"
<persia> Yep, and ubottu is usually faster than the rest of us :)
<binarymutant> when is the deadline for jaunty?
<persia> binarymutant, There are several deadlines.  For which action?
<binarymutant> to get a package thats not in the repos already ready to be uploaded
<persia> FeatureFreeze is 19th February, which is probably the closest, but that's the deadline to have it uploaded, rather than the deadline to get it ready.
<binarymutant> if I get the required advocation before Feb 19th could the package be uploaded to the repos?
<persia> Most likely.  In fact, if you get the required advocation before then, and your advocate doesn't upload, something is wrong.
<binarymutant> very cool, thanks for the info persia
<agent47a> I nx'ed into jaunty running freenx 0.7.3 (NX sources 3.3.0) and noticed that the arrow keys do not work as expected.  When pressed while in a textbox or in gnome-terminal, a metacity error pops up.  "No command 33 has been defined"  Anybody else experienced this?
 * Hobbsee wonders why that's a question for here, as freenx doesn't seem to be in the repository
<persia> agent47a, Does the same happen with intrepid?  It may be a result of work done to change how keycodes are tracked
<tritium> 8.10 uses /dev/.static/dev?  http://paste.ubuntu.com/103400/
<tritium> Any thoughts as to what's going on there?
<persia> tritium, At a guess, there may be some device nodes that need to be present before udev starts, which live in a /dev that gets remounted.  Note that I'm guessing based on vague memories of documentation I read when I switched from devfs to udev some time back.
<tritium> persia: was there a significant change between 8.04 and 8.10 regarding how device files are handled?
<persia> tritium, Not to my knowledge.
<tritium> Those errors puzzle me, as I was able to install and use dvb-utils just fine in 8.04, and xine and VLC could see my DBV card.  Now, neither can see my card.
<tritium> DVB, even
<tritium> Well, thanks for looking at the paste, persia.
<persia> I would have expected that sort of thing with 8.04 as well.  The package ought do better than call makedev, it probably needs migration to also support udev.
<tritium> Ah, I'll poke around the postinst, to see what it's doing.  Thanks again, persia.
<tritium> persia: yeah, in its postinst script:
<tritium> if [ ! -e /dev/.devfsd ] ; then
<tritium> cd /dev && /sbin/MAKEDEV dvb
<tritium> fi
<persia> tritium, Right.  That looks like something that's just never been migrated to udev.  Take a look for it installing udev rules, or dh_installudev|dh_installdev
<tritium> I appreciate the help, persia.
<persia> No problem.  As long as you're going to fix the bug, I'm happy to help you find it.  Seems the least I can do.
<tritium> I will fix it, if I am able.
<AnAnt> Hello, is there a way to provide an alternate firefox homepage URL ? There used to be a firefox-homepage alternate in Hardy I think
<gouchi> hi
<gouchi> the application I try to package is using CodeBlocks to compile
<gouchi> must I move the compilation tool to autotools / make ... to comply with debian/ubuntu policies ?
<gouchi> or can I keep CB ?
<iulian> I would like to backport git-cola from Jaunty to Intrepid and AFAICS from the https://help.ubuntu.com/community/UbuntuBackports for no-source-change backports, MOTUs and core-devs are allowed to upload directly to -backports, however they will need an archive admin approval.
<iulian> The package builds and runs fine on Intrepid. Can I upload it to intrepid-backports appending ~intrepid1 to the version and writing something like "Backport to Intrepid; no source changes" to debian/changelog?
<persia> gouchi, You can keep codeblocks.  Just change debian/rules to make the appropriate calls.
<gouchi> cool
<gouchi> thanks for the tips
<persia> iulian, Best to file a backports bug, get some backport tester reports, and then push it, in collaboration with the backporters.
<persia> !backports
<ubottu> If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<jpds> persia: Can we upload directly? Or do we have to poke an archive admin as usual?
<jpds> "Ubuntu Backporters (MOTU and core-dev as of Nov 2008) are allowed to upload directly to -backports".
<persia> jpds, For no-source-change backports, it's best to have an archive-admin do it, for all the same reasons we don't upload syncs directly.
<iulian> persia: OK, thanks, will do that.
<persia> for source-changing backports, it's all the more important to have a backports bug, and tester feedback, of course.
<quadrispro> anyone on bug 316033?
<ubottu> Launchpad bug 316033 in mozplugger "Please merge mozplugger 1.12.0-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/316033
<tuxmaniac> someone seen nellery around?
<persia> tuxmaniac, He was about earlier.
<RainCT> asac: What is the /usr/share/mozilla/extensions directory for? Is it used by all Mozilla browsers or what?
<asac> no
<asac> its a hoax
<RainCT> lol
<asac> its used by some mozilla-extensions that tried to establish a substandard
<asac> e.g. they ship their extensions in that dir and link to the app extensions/ directories
<RainCT> asac: Ah, right. How does the mozvoikko extension work then if it has no symlink?
<RainCT> (http://packages.ubuntu.com/jaunty/i386/mozvoikko/filelist)
<asac> does it work?
<RainCT> asac: I don't know. You didn't complain about this on bug #297169, that's why I'm asking
<ubottu> Launchpad bug 297169 in mozvoikko "mozvoikko depends on iceweasel, should depend on firefox" [Undecided,Confirmed] https://launchpad.net/bugs/297169
<asac> i expect submitters to test stuff
<asac> and look at debdiffs only ;)
<asac> but could be that it really works
<asac> maybe some distro got this added as a legacy location for the extensions
<asac> must have been quite late in 3.0 cycle - if so ;)
<RainCT> hehe.. yeah, I usually look at such stuff because there were a lot of uploads which changed the dependency and the description to firefox but left the symlink in the iceweasel dir :P
 * RainCT checks
<asac> right. we should do a thorough reveiew
<asac> of extensions
<RainCT> (that's also why I wrote the /Merging wiki page, btw :))
<asac> feel free to help out ;)
<asac> thanks!
<asac> RainCT: i think we could at least try to submit the Description stuff to debian
<asac> they could name both: Firefox/Iceweasel
<asac> and with some care we can make the packaging in such a way that it works at both places
<RainCT> uhm.. how can I force a package to install with missing dependencies? (dpkg --force-depends -i ..   doesn't work)
<asac> also those debian folks should stop from prefixing stuff with target app name (e.g. iceweasel-superextension)
<RainCT> asac: +1
<asac> i never understood this. frequently extensions work not only on iceweasel but on seamonkey too ... they then default to "mozilla-" prefix; which doesnt make sense as its not usable in tbird, xulrunner or other mozillas
<persia> RainCT, --force-depends is specicifically designed to permit it: note that if something uses a dependency in a maintainer script, that causes other issues.
<RainCT> persia: oh, right. it complains but then it configures it, hadn't seen the last line :). thanks
<persia> Right.  Just converts dependency errors into warnings.
<RainCT> asac: "Mozilla-laajennus Voikon kÃ¤yttÃ¶Ã¶n" - if that's the extension, then it works
<RainCT> although I don't see why they want a spell checker extension instead of just using the inbuild spell-checker..
<asac> thx
<asac> i think ... i think that this one uses a more enhanced thing than hunspell
<asac> i had a bug open asking for using that by default
<asac> but we cant unless its something better everywhere and upstream adopts it
<asac> RainCT: ^^
<iulian> persia: I just noticed that you forgot to mention mok0's feedback when you sent the mail to MC and TB (https://lists.ubuntu.com/archives/motu-council/2008-December/001889.html).
<iulian> It doesn't matter now :)
<persia> iulian, OOps.  Sorry.  I did read that, and consider it.
<persia> Probably just me trying to do it when I really should have been asleep, but I didn't want to make you wait another day.
<iulian> There is no problem.  I was too excited when I got that mail and didn't notice that mok0's feedback is missing.
<iulian> Yeah, I appreciate that.
<persia> Really?  I'd think the LP group notification mail would be more exciting, or at least it was for me.
<persia> Did you put up your wiki page yet?
<persia> Do try to get it up before UWN goes out, as you will be listed, and it's better if it can be a link.
<iulian> persia: I was at school then and IIRC I saw the LP group notification mail.
<persia> Ah, that makes sense.  The notification mail is a bit more public :
<iulian> persia: Oh, honestly I forgot about the wiki page. I will do that today or tomorrow.
<persia> You might check with the News team to find out when they publish, to get a deadline.
<iulian> persia: Do they have an IRC channel?
<persia> #ubuntu-news
<persia> Dunno if they're online now though.
<RainCT>  
<persia> RainCT, Now try that with a unicode non-printing space :p
<RainCT> uoops
<RainCT> wow, persia joking \o/
<iulian> OK. I'm writing something on the wiki now.
<StevenK> Haha. persia does joke ...
<RainCT> that must have been the holidays.. P
<sebner> yeah, persia joking \o/
<iulian> Yay.
<StevenK> Obviously, neither of you were at UDS ...
<persia> There's some correlation to time-since-last-idle-for-significant-time.
<pmjdebruijn> lo
<pmjdebruijn> what currently the preferred way to patching packages?
<pmjdebruijn> In the past I've read about several different ways to patch packages... I'm wondering whether a single method is preferred above others...
<RainCT> pmjdebruijn: if the package comes from Debian, use whatever it is already using
<pmjdebruijn> RainCT: it's a new package
<pmjdebruijn> so I'd need to modify debian/rules
<pmjdebruijn> that's why I'm asking
<RainCT> well, then you can choose
<pmjdebruijn> no method is preferred?
<RainCT> Not afaik. The most popular ones are simple-patchsys (for cdbs), dpatch and *urgh*quilt*urgh*, though
<azeem> urgh?
<Laney> s/urgh/love/g
<RainCT> Laney: rather the opposite :P
<RainCT> although, now that I've had to touch it 2 or 3 times I'm starting to see that it may even be not that bad :P
<proppy> hi
<RainCT> hi proppy
<persia> pmjdebruijn, Also, if you're managing your package in a VCS, you may not want to use a patch system at all.
<pmjdebruijn> huh?
<pmjdebruijn> my package isn't in vcs
<pmjdebruijn> but I thought that was frowned upon
<pmjdebruijn> directly patching
<pmjdebruijn> RainCT: http://matrixhasu.altervista.org/index.php?view=use_dpatch I've used that in the past... would that be okay?
<RainCT> pmjdebruijn: if you are not using cdbs, yes
<RainCT> btw, does anyone know what the rationale for simple-patchsys was?
<laga> it's simple?
<RainCT> laga: it's exactly the same as dpatch (using cdbs), just without the 00list, which I've come to see as something really useful (considering that diffs can't handle file renames)
<laga> RainCT: it doesn't need the patch header either AFAIK
<azeem> RainCT: dpatch can (in theory) run arbitrary code during patching, as it executes the patches as shell scripts
<azeem> at least that was the case in the past
<RainCT> Oh. So why not just fix dpatch?
<azeem> fix how?
<laga> redesign it and call it simple-patchsys?
<RainCT> redesigning it and calling it dpatch2 :P
<azeem> s/simple-patchsys/quilt/
<RainCT> anyway, I should go work on my research project..
<azeem> yeah, it's Sunday after all :P
<iulian> persia: I've written something on the wiki page. It's not complete anyway. Honestly, I don't like writing about me. ;)
<iulian> Hope it's good for now.
<persia> iulian, Anything is fine :)  You did a nice job introducing yourself and your work in both your applications, so I figured the wiki page would be easy.
<slytherin> does anyone know when is slomo expected to be hear. I was planning to sync/merge libdvdread and libdvdnav from experimental and thought that I should first get his opinion.
<slytherin> s/hear/here
<iulian> persia: Excellent.
<bersace> Hi everyone
<iulian> Hmm, why doesn't dupload send announcements when uploading to ubuntu, even though I've removed "dinstall_run => 1" from the configuration file.
<azeem> iulian: cause ubuntu doesn't use dinstall
<azeem> iulian: where do you expect announcements to go?
<iulian> Ah, right, didn't know that.
<iulian> I thought it uses like Debian.
<azeem> I don't think this does anything in debian either
<iulian> Isn't that when you get an ACCEPTED/REJECTED e-mail?
<azeem> iulian: no, you get them always
<azeem> I think dinstall_run is some 90s thing about mailing debian-devel-changes or another obscure list with your .changes
<azeem> or something
<azeem> obsolete nowadays
<iulian> azeem: Ubuntu's format changed a little bit regarding the notification email. I was confused because from Debian I get an email with the name of the files uploaded.
<iulian> Even though I'm not really sure about this.
<azeem> Debian and Ubuntu use completely different archiving software
<iulian> Indeed.
<fabrice_sp> Hi, Dvdstyler package (http://revu.ubuntuwire.com/details.py?package=dvdstyler) has had his first advocate. Can someone else review it? Thanks.
<Laney> I seem to remember a way of getting debuild to list files that are installed by upstream's install rules but don't make it  into any .deb. Anyone know what this is?
<azeem> Laney: dh_install --list-missing
<persia> I think it's dh_install --list-missing
<Laney> I thought I could turn it on as a default?
<Laney> but this is good for what I need right now, thanks
<Laney> fakeroot debian/rules list-missing, nice
<savvas0> can someone upgrade the jaunty linuxlogo from 5.04-1 to 5.04-2 (debian unstable)? They fixed a bug about it: https://bugs.launchpad.net/ubuntu/+source/linuxlogo/+bug/291958
<ubottu> Launchpad bug 291958 in linuxlogo "linux_logo -L num always returns debian logo" [Undecided,Confirmed]
<fabrice_sp> savvas0, just open a syn request bug
<savvas0> fabrice_sp: can I rename the bug report subject instead?
 * Laney smacks RainCT 
<Laney> pbuilder-dist bug
<Laney> missing " on line 219
<ScottK> savvas0: You can.
<fabrice_sp> saivann, I don't know if it's politically correct, but I would say, yes. Let's wait for a MOTU to answer
<fabrice_sp> (ScottK did :-) )
<savvas0> oki doki
<ScottK> It's pointless to make a new bug that then someone has to go back and remember to clost this one manually.
<jpds> Laney: Fix pushed.
<Laney> jpds: nice work
<Laney> jpds: Er, you needed to add a quote, not remove the other one
<jpds> Laney: Why? "arguments.append('--components %s' % components)"
<Laney> because the components are one argument
<Laney> e.g. --components "main restricted universe multiverse" vs --components main restricted universe multiverse
<RainCT> jpds: there are more than 1 component, so a quote was missing
<jpds> RainCT: Ah right.
<slytherin> do we prefer the new machine readable copyright format for new packages?
<persia> slytherin, Yes.
<persia> Be nice if it was finalised, or approved or something though.
<RainCT> is there already some application to validate copyright files or not yet?
<Laney> I don't think so as there's no valid format yet
<Laney> s/valid/stable/
<RainCT> fabrice_sp: ah, I'm not sure if that's what you were talking about, but yes, you can not only change the title of bugs, but if that's to improve them you are encouraged to do so
<jpds> Laney: That should do it :)
<RainCT> (well, and if it's not to improve them I'll hit you if you change them :P)
<fabrice_sp> lol
<RainCT> jpds: you also like --overwrite? ;P
<fabrice_sp> in this case, it was to transform a normal bug en sync request
<RainCT> fabrice_sp: yes, that's fine
<slytherin> persia: is the format even in RC state or something?
<Laney> heh, bzr didn't like that --overwrite
<persia> Dunno.  I've seen a few packages go through with the draft, and nobody seems to object.
 * Laney had to merge
<slytherin> hmm
<RainCT> persia: well, it contains all the requires information, so there's no reason why someone could object to it
<slytherin> by the way, does anyone know why cheese is in universe? it was in main in hardy and IIRC, it is included by default in netbook-remix
<fabrice_sp> RainCT: and in this case, you just add a comment with the sync request or you change the description (and loose the bug)?
<RainCT> slytherin: just guessing, but perhaps there's a better application now? (cheese has a rather bad performance imho)
<RainCT> fabrice_sp: you can add the sync info at the top of the description
<slytherin> RainCT: I am not even aware of any other application of that sort. And if cheese had bad performance then it should have not been in main in first place.
<fabrice_sp> ok Thanks to clarify that!
<slytherin> RainCT: could you please grant me motu powers on revu? I don't see any link to advocate a package.
<RainCT> slytherin: and you haven't noticed until now?   *evil REVU Coordinator look*
<slytherin> RainCT: because I didn't look into any package till the point of advocacy.
<RainCT> slytherin: ah well, if that's the case then I can forgive you :P
<RainCT> ok, done
<slytherin> RainCT: thanks
<RainCT> np
<RainCT> ohh.. mok0 is about to catch me in the "top commenters"
<slytherin> if a motu is doing a new package, ideally it should still go to revu, right?
<RainCT> slytherin: yes, that's encouraged
<Laney> it still needs to get one +1
<RainCT> (s/needs/should, but yes)
<Laney> right
<ScottK> slytherin: I've always gotten reviews and never regretted it.
<slytherin> :-)
<RainCT> slytherin: Wait, I change my comment. Packages should not get through REVU
<RainCT> slytherin: they should get through mentors.debian.net ;)
<persia> Depends on the package really.  For something advantageous to Debian, yes, but for things naturally Ubuntu-only, not so much.
<slytherin> Well, that means it will be probably jaunty +2 before it lands in Ubuntu. :-P
<persia> Even so, pushing to REVU before mentors isn't bad.
<RainCT> slytherin: not necessarily, I usualy get fast reviews
<RainCT> and even more if I get the package in through some team (python, games or whatever)
<slytherin> RainCT: java team is really moving slow with regards to sponsorship these days.
<persia> slytherin, if you get a delay in your sponsorship, and you're getting close to Feature Freeze, feel free to push to Ubuntu.  Just be sure to make the tar.gz the same.
 * RainCT images himself reviewing a package from ScottK and feels strange :P
 * ScottK makes plenty of stupid mistakes in his packages.
<slytherin> persia: Well, I didn't submit for sponsorship as I don't have any hope. I will make it for Ubuntu first and then as I get time put into sponsorship inDebian.
<persia> RainCT, The first time I reviewed a package by a MOTU, I was surprised at how many things I caught.  Just little stuff, but we all make mistakes.
<RainCT> hehe yes, but nevertheless it's somehow funny/weird (especially reviewing stuff from people who sponsored you before)
<persia> slytherin, Just put a copy on mentors.debian.net, update the ITP, and make a request.  It might not happen soon, but it might happen sooner if you request sooner :)
<persia> RainCT, I know what you mean.  Mine was in fact one of my sponsors :)
<ScottK> These twists do get odd.
<RainCT> persia: btw, out of curiosity, how long have you been around?
<ScottK> I've sponsored uploads into Ubuntu for my Debian NM application manager.
<RainCT> XD
<persia> RainCT, I've been a user since Warty, started submitting patches in Breezy, and became MOTU in Gutsy.
<nhandler> persia: I didn't realize that you had just become a MOTU at the time you were mentoring me ;)
<RainCT> persia: errr.. really? \o/
<RainCT> ah, but before gutsy's release
<RainCT> so you became a MOTU and like 1 month later I started contributing
<persia> RainCT, About that, yes.
<persia> nhandler, Yes.
 * slytherin pats himself on the back for sponsoring a package.
<RainCT> and I though big master persia would have been there for ages.. :P
<nhandler> persia: When did you get on the council?
<persia> nhandler, 11 months ago.
<sooth> What is the name of the utility that quickly creates a package. You wrap the install command with it.
<sooth> ?
<jpds> sooth: checkinstall?
<ScottK> dh_make
<persia> jpds, Please, no.
<jpds> persia: Just checking.
<directhex> persia, that's pretty obviously what sooth wanted, though
<directhex> system killer though it may be
<sooth> jpds: Yes, thanks.
<slytherin> directhex: is there any status page about mono2 transition?
<directhex> slytherin, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO ?
<sooth> Is there something else I should be using. It is for a python egg.
<sooth> Is there something else I should be using? It is for a python egg.
<POX> sooth: stdeb
<klasikahl> howdy... i've got some questions/issues with the -virtual kern tree.  i am curious if anyone here would be able to answer my questions
<slytherin> sooth: it depends on what you want to do with the package.
<sooth> POX: Thanks. (Ironically, it is not packaged)
<sooth> slytherin: Personal use.
<slytherin> sooth: then please go ahead with checkinstall.
<sooth> slytherin: Okay, thanks.
<POX> sooth: what module do you need?
<POX> pygments?
<slytherin> persia: if you see doko around then can you please remind him to look into (if he has not already looked) why java stack is broken on hppa.
<sooth> POX: Something called pisa. http://www.htmltopdf.org/
<directhex> slytherin, you don't have super u-u-s powers do you?
<slytherin> directhex: I am not in team yet. Why?
<slytherin> directhex: but that doesn't prohibit me from sponsoring a package.
<directhex> slytherin, my ikvm sync request. t'was a challenge, but it's finally in experimental
<directhex> slytherin, with super openjdk powers
<coppro> uus is a sigma particle :P
<directhex> ooh, sebner could do it. /me pats sebner
<slytherin> directhex: you are a motu, right?
<persia> slytherin, I'm rather tempted to wait for lamont's investigation as to whether we need to support hppa at all :)
<directhex> nay
<directhex> just a contributor
<slytherin> persia: hmm.
<slytherin> directhex: I will only check that it builds. Rest I believe debian uploaders must have already checked. is that fine?
<directhex> hm, no, sebner's leaving us to shoot windows users
<directhex> slytherin, i only ever tested in jaunty during development, so frankly i'm impressed that it built on experimental
<sebner> directhex: I can at least do a testbuild but nothing more
<directhex> slytherin, i did a test build earlier, but feel free. hope you have gobs o' ram
<directhex> -rw-r--r-- 1 jms jms 13M 2009-01-11 14:48 /var/cache/pbuilder/jaunty-amd64/result/ikvm_0.38.0.2+dfsg-1_all.deb
<directhex> -rw-r--r-- 1 jms jms 16K 2009-01-11 14:41 /var/cache/pbuilder/jaunty-amd64/result/libikvm-native_0.38.0.2+dfsg-1_amd64.deb
<slytherin> directhex: I have 1.2 GB of RAM on a powerpc 1.3 GHz G4. Is that good enough for build?
<directhex> slytherin, can you build openjdk on that?
<slytherin> directhex: never tried.
<directhex> slytherin, javac is called with -Xmx1536M during build, so...
<slytherin> directhex: ahh, you told me. sorry can't help there.
<directhex> slytherin, when i started adopting this package, i thought there was a memory leak..... the only leak is called "javac"
<slytherin> what command does dch use to invoke editor? In my case it is always opening vi basic which does not have syntax highlighting.
<sooth> slytherin: VISUAL, EDITOR env variablese
<sooth> variables
<slytherin> sooth: I don't have any of those set.
<sooth> slytherin: Set them?
<nhandler> slytherin: Just put them in your .bashrc
<persia> slytherin, I suspect it uses sensibleeditor if the environment variables are unset.
<sooth> persia: That's what the man page says.
<nhandler> But setting EDITOR and VISUAL is still a good idea. Many tools use those variables
<sooth> But sensible-editor checks those env variables doesn't it.
<sooth> ?
<slytherin> persia: right. and it is a binary not an alternative option.
<sooth> slytherin: There is select-editor
<sooth> Which is overridden by VISUAL and EDITOR.
<slytherin> I will set those variables
<fabrice_sp> I have a question about backports: what is the point of backporting a package in -backport if it has been backported in a ppa?
<slytherin> fabrice_sp: not everyone wants to use ppa. the packages in ppa are not signed and there is no gurantee that they even had minimal QA that a backport package had.
<RainCT> slytherin: unsigned is not necessarily true
<oojah> And backports is a lot more official looking than random-ppa.
<fabrice_sp> I backported hugin 0.7.1 (jaunty) to Hardy and Intrepid in my ppa, and closed a lot of bug report because of that (the reportees tested the ppa's version)
<slytherin> RainCT: how do you sign packages in PPA?
<RainCT> slytherin: PPAs are now signed, but LP is still catching up with signing all existing ones
<fabrice_sp> so, I should open a backport request, then?
<RainCT> slytherin: this was announced not much time ago
<slytherin> fabrice_sp: closing bugs against package in your ppa is very wrong.
<slytherin> RainCT: I must have missed.
<fabrice_sp> I closed them because the jaunty version fixed the problem
<fabrice_sp> not my ppa one
<slytherin> then, that is fine
<slytherin> depending on severity of bugs, it should either be an SRU or a backport
<maxb> PPAs aren't signed *yet*
<fabrice_sp> There is a way to bypass the problem, so it's not really a SRU, but it's a must have, so it will be a backport. Anyway, it's difficult to have a new version as a SRU
<maxb> last I heard from the people on #launchpad, signed PPAs are blocked on additional hardware being installed to run the mass key-generation on
<oojah> https://launchpad.net/soyuz/+bug/125103 <- cprov says "signed ppas should happeen next week" or "the infrastructure for signing keys should happen next week" depending on how you read it.
<ubottu> Launchpad bug 125103 in soyuz "ppa archives are not signed" [High,Fix released]
<slytherin> fabrice_sp: you can backport the fix in an SRU. No need for whole new version.
<fabrice_sp> slytherin, the hardy version is 0.7~beta4 and the jaunty one, 0.7.1, so it's very difficult to find the fix for the more than 6 problems I closed with that version
<slytherin> fabrice_sp: contact upstream :-)
<fabrice_sp> :-) I think upstream will tell me to install the latest version (beta 4 wasn't the last beta, so not sure about the answer).
<sooth> packages.ubuntu.com lists python-reportlab as having version 2.2 but I cannot seem to get it from the jaunty repositories after adding it to my sources.list and doing apt-get source python-reportlab. Can anyone else see it?
<sooth> Ah never mind. My mistake with apt-pinning.
<nhandler> sooth: Try using pull-lp-source from ubuntu-dev-tools if you are only interested in the source
<sooth> nhandler: Does that retrieve the dev version from bzr?
<sooth> nhandler: Thanks, that tool will save make my life easier in the future.
<nhandler> sooth: It doesn't work with bzr, but you can specify what Ubuntu version it should use (default=jaunty)
<binarymutant> if my python package is not compatible with python3 should I change the dependency requirement from  >=2.3 ?
<ScottK> binarymutant: If you use python-support or python-central to build your package, they'll handle that for you.
<binarymutant> thats cool thanks :)
<ScottK> They should build packages that depend python <<2.6.
<binarymutant> thanks for the help
<ScottK> No problem.
<james_w> Debian bug 511530
<ubottu> Debian bug 511530 in wnpp "ITP: mmpong -- massively multiplayer pong game" [Wishlist,Open] http://bugs.debian.org/511530
<directhex> o_o
<RAOF> I'm all for it
<jorgenpt> haha
<jorgenpt> mmpong ftw
<directhex> free software developers in "failing to see what makes games fun" shocker o_o
<jorgenpt> ;-)
<lifeless> wow, mmpong - did you read the details
#ubuntu-motu 2010-01-13
<strycore> *python script
<persia> What sort of python script.  One that packages for you?
<DktrKranz> persia: when I needed sponsorship, I saw packages on mentors.d.o took very long to be reviewed, while those reviewed by a team was taken into account a lot faster
<strycore> persia, it's for my tweekers project ( https://launchpad.net/tweekers )
<DktrKranz> teams have a well-defined workflow, so they are usually quicker in welcoming new members
<persia> DktrKranz: Makes sense.  I tend to work closely with some individual for non-team work (but I haven't done any Debian work in quite some time, and need to get back to it)
<DktrKranz> persia: yeah, being in touch with one ore more DDs helps a lot, but in cases when this is not possible, my experience says teams are quicker to review stuff, and overall quality is way much better
<persia> DktrKranz: I generally prefer collaborative work myself (which is why I tend to be more active in Ubuntu than Debian).
<DktrKranz> maybe we should try that way, as a suggestion
<persia> Makes sense.  Feel like updating the wiki page on New Packages ?
<DktrKranz> persia: I will. I'll mention some Debian teams which fit the most REVU packages (perl, python, GNOME, KDE, and some)
<freeflying> persia: DktrKranz either team maintain package or individual's need go through NEW Queue, don't see any difference there
<persia> freeflying: Nice thing about teams is that one can often get extended peer review prior to NEW, which can speed NEW.
<persia> Also, team-maintained packages tend to get better attention for transitions, etc.
<persia> Of course, having a standard sponsor (or being a DD) obviates some of that :)
<persia> And this is drifting fairly far off-topic :)
<randomaction> porthose: I see you've put some work into bug 389654, do you feel like finishing it? I can offer you some help if you need it.
<ubottu> Launchpad bug 389654 in lyricue "Please upgrade lyricue" [Wishlist,Confirmed] https://launchpad.net/bugs/389654
<freeflying> persia: btw, do still have a i18n channel
<persia> freeflying: I've never been involved in an i18n channel, so I can't say with any authority.  Sorry.
<freeflying> persia: thx dude
<porthose> randomaction, hehe  actually I forgot about it, please feel free :)
<DktrKranz> freeflying: well, Debian NEW queue is shorter than what we historically remember these days
<freeflying> DktrKranz: yes, I experienced, before might need 3 weeks, recently maybe 3 days
<DktrKranz> things will even improve, stay tuned :)
<Laney> DktrKranz: more developments?
<Laney> DktrKranz for ftp-assistant?
<DktrKranz> help is always appreciated
<DktrKranz> things move quicker because ftpmaster+ftpteam are 8 members
<DktrKranz> but more won't harm
<Laney> just wondered what "things will even improve" meant :)
<DktrKranz> more features dak side
<DktrKranz> I fixed a little bug in lintian autorejects, now it works better (with more REJECTs), for your happiness :)
<Laney> zlib being rejected for embedded zlib? :)
<DktrKranz> that's lintian fault :)
<Laney> heh heh
<DktrKranz> fix was packages weren't checked properly because orig tarball was not available for unpack
<DktrKranz> s/fix/bug/
<AnAnt> Hello, how can I cleanup pbuilder's aptcache from only from *OLD* packages ?
<persia> AnAnt: try logging in with --save-after-login and running `apt-get autoclean`.
<Laney> AFAIK pbuilder doesn't store the cache in the chroot
<Laney> maybe it bindmounts it though
<Laney> but if not then you can pass --aptcache to --login and then it should work as persia says
<Laney> oh, he left already...
 * persia has used pbuilder about twice over a larger number of years, and defers to anyone with actual experience with the tool
<Laney> When I get around to setting up LVM again then I will go back to using sbuild
<Laney> I find it friendlier
<persia> You find sbuild friendlier?
<Laney> yep
<Laney> mainly with the build products it generates
<persia> For the first few cycles I used sbuild, I only had 20G under LVM, and the rest done differently.
<persia> I know some people who use LVM on an external drive for sbuild, and non-LVM internall.
<Laney> the initial cost to setup the apt caches is not insignificant though
<Laney> I have a spare drive that I could use for it and my Windows partition :)
<hyperair> Laney: pbuilder copies the cache by default, but you can make it use hard links.
<Laney> copies where?
<persia> The initial cost to setuo the apt caches?  How do you mean?
<hyperair> Laney: from /var/cache/pbuilder/aptcache?
<Laney> persia: sbuild doesn't do any caching (or is that wrong?)
<hyperair> Laney: anyway there's pbuilder --autocleanaptcache
<hyperair> sbuild doesn't do any caching, from what i've heard
<Laney> tidy
<Laney> I only use it with pbuilder-dist
<hyperair> pbuilder-dist probably has support for that as well
<persia> sbuild can do caching, if one populates the apt cache for the source.
<hyperair> i don't usually run --autocleanaptcache for my ubuntu pbuilders
<persia> But most people seem to use some sort of proxy configuration or local mirror with sbuild.
<Laney> that's right
<Laney> I set up apt-cacher-ng or whatever it's called
<hyperair> i only use it for debian, because i only have one chroot for it (sid).
<hyperair> if i use --autocleanaptcache, it's going to clean out the debs for my older ubuntu versions.
<persia> Does pbuilder have an interface that lets you set up a cron job like http://pastebin.ubuntu.com/356116/ ?
<persia> (note that one wouldn't use "clean" if one wanted to cache in the chroot)
<Laney> pbuilder --update
 * hyperair generally uses cowbuilder these days
<hyperair> it takes up more disk space, but at least i no longer have to have my comp hang for a few minutes while pbuilder extracts the tgz
<Laney> i had some problem with hardlinks and different filesystems when I used cowbuilder
<hyperair> use a proper filesystem that supports hardlinks then >_>
<Laney> didn't investigate, the <1s that pbuilder takes to untar doesn't bother me
<hyperair> huh?! <1s?!
<hyperair> what kind of hard disk are you using?
<Laney> a tasty raptor
<hyperair> 275M    /home/pbuilder/base-lucid-amd64.cow/
<hyperair> that's writing out 275M in less than one second.
<hyperair> i refuse to believe you can hit that kind of speed with anything short of a solid-state
 * Laney shrugs
<persia> It's caching.
<hyperair> there's only so much you can cache >_>
<persia> The disk is probably still writing, but the filesystem is available to userspace.
 * persia is currently caching about 670M
<hyperair> caching reads or caching writes?
 * hyperair gets a laggy mouse for a good 5 minutes when using pbuilder
<persia> hyperair: Sorry.  cached in general.  I only have about 300M in dirty pages loaded (which should write out at some point, but I set the timeout fairly high to avoid waking the drive unnecessarily)
<hyperair> hmm
<hyperair> i think i should set my timeout higher too
<hyperair> there's a pm-utils-power-save or something in lucid right?
<hyperair> that does this kind of magic, doesn't it?
 * persia was fiddling with powertop but probably
<hyperair> how do you check the dirty pages anyway?
<hyperair> the amount of dirty pages i mean
<persia> But the point was that 270M wasn't unthinkable with 2G+ RAM available.
<hyperair> hmm true
<hyperair> you could even make pbuilder extract onto a tmpfs coem to think of it
<persia> I guess, but I don't really see the point of that.
<persia> tmpfs is usually limited to RAM/2, which can be tight for some packages (unless you have lots more RAM than I)
<persia> And if there is RAM available, the system should do cache-on-write, so you shouldn't notice too much performance difference
<persia> (or if you do, something needs tuning)
<hyperair> heh right
<hakaishi> Hi! Anyone up to review qt-shutdown-p? It is a small simple program to shutdown the computer. http://revu.ubuntuwire.com/p/qt-shutdown-p
<sivang> hey all
<highvoltage> hi sivang
<bddebian> Heya gang
<sebner> hoia bddebian :)
<bddebian> Heya sebner
<geser> Hi sebner and bddebian
<sebner> hihu geser :)
<bddebian> Heya geser
<hakaishi> Hi! Anyone up to review qt-shutdown-p? It is a small program to shutdown the computer. It uses qdbus to send a shutdown request to the session manager or to hal or alternatively uses sudo shutdown -P now. http://revu.ubuntuwire.com/p/qt-shutdown-p
<jariq> Could someone please review package ipwatchd - http://revu.ubuntuwire.com/p/ipwatchd - and ipwatchd-gnotify - http://revu.ubuntuwire.com/p/ipwatchd-gnotify
<cemc> when I'm using pbuilder to rebuild a package from universe, can I do a 'one-time' build with enabled universe repos? so it doesn't change the base tgz, but still uses universe?
<kamalmostafa> How can I specify debian/control Build-Depends for a situation where the package requires a version of libfoo-dev (>= 1.2.3) but (<< 2.0)?
<geser> libfoo-dev (>= 1.2.3), libfoo-dev (<< 2.0)
<kamalmostafa> geser: okay, i thought I tried exactly that and had no joy.  I'll try it again!
<kamalmostafa> geser: yup, that did the trick.  Thank you.
<kamalmostafa> Moto please...   Package fraqtive needs retry builds due to the -lGL mesa problem:  https://launchpad.net/ubuntu/+source/fraqtive/0.4.5-1
<ScottK> Doing.
<ScottK> kamalmostafa: I didn't forget about the TI stuff, just busy with $WORK right now.
<kamalmostafa> ScottK: no problem -- it isn't going anywhere ;-)
<ScottK> kamalmostafa: Done (building now)
<kamalmostafa> ScottK:  I'll hang on to the trees and you just let me know whenever is convenient for you to review them.   tnx for the rebuilds.
<ScottK> OK.  No problem.  Thanks for noticing
<sivang> who can approve my ubunt-dev again?
<sivang> I am goping to be hacing on stuff for Maemo
<sivang> that are for ubutu, as in , allow folks to develop for Maemo on ubuntu
<sivang> so, can I get my upload rights back ?
<ScottK> sivang: You need to apply to the MOTU Council.
<sivang> ScottK: how to do that?
<sivang> ScottK: is there a docuent to read about it?
<ScottK> It's on the Ubuntu wiki.  I don't recall exactly where.
<fabrice_sp> tsimpson, are you using the patched version of xchat you submitted in bug 507072 ?
<ubottu> Launchpad bug 507072 in xchat "Add support for freenode ircd-seven CAP command" [Undecided,New] https://launchpad.net/bugs/507072
#ubuntu-motu 2010-01-14
<zooko_osg> FYI: Tahoe-LAFS project plans our final push to get Tahoe-LAFS released in time to be included in Lucid: http://allmydata.org/pipermail/tahoe-dev/2010-January/003564.html
<zooko_osg> ScottK: please notice how cool Tahoe-LAFS is today --^
<zooko_osg> Okay, gotta leave work and head home.
 * ScottK notes that there are idle buildds on all archs: https://launchpad.net/builders
<micahg> ScottK: is that a challenge? :)
<ScottK> Yes.
<micahg> are we still updating sun-java6 or is that done with?
<ScottK> I think Canonical needs to deal with Sun Java, but I think the intent is still to have it go away.
<persia> sivang: You may be interested in https://wiki.ubuntu.com/UbuntuDevelopers If you're reapplying for a development status you had previously, an abbreviated procedure may be available: contact the relevant approval team.
<ScottK> geser: You TIL debian-xcontrol.  I'm trying to get rid of boost1.38 build-deps and this does not build with 1.40.  Looking in Debian I see it's never, ever made it into Testing and I'm thinking removal might be the best option.  What do you think?
<statik> what does TIL mean?
<crimsun> "touched it last"
<crimsun> i.e., "you were the last person to work on source package foo"
<RAOF> aka: âtag, you're it!â
<micahg> are we allowed to update sun-java6 from unstable?
<persia> micahg: I don't see any reason why we couldn't, although I wouldn't recommend sun-java6 for end-user installation.
<micahg> persia: well, until it's removed from archive, we should keep its security up to date, right?
<micahg> or switched to partner
<persia> I guess.  I tried to do that for sun-java5 for a while, but it ended up being very difficult to keep track of stuff.
<micahg> how so?
<persia> I don't think it could switch to partner, as such.  Population of multiverse and partner are handled not only by different policies, but by different organisations.
 * micahg doesn't want to make things worse
<persia> The big issue I had wasn't bringing it into the current development target, it was that having done so I ended up being TIL, and expected to get the SRUs done.
<micahg> TIL?
<persia> Writing the TEST CASE entries for the bugfixes was more than I could handle.
<persia> touched-it-last
<persia> The person who most recently indicated that they cared about the package.
<micahg> ah, I thought there's an exception to that on the SRU page now
<micahg> it just has to install
<persia> If there's an exception for sun-java, then it ought be easy.
<micahg> k
<persia> Just update it, and then do the SRU processing.
<micahg> so, I figure I'll request a sync for lucid and once it's there, make the diffs for Intrepid->karmic
<micahg> hardy was already done by doko
<persia> But, again, I think most users would be better served by openjdk.  I know that at UDS Jaunty, engineers from Sun were present and suggested that openjdk was the right choice.
<persia> I also spoke with some Sun engineers at UDS Karmic (about other stuff), but everything was targeted to use openJDK.
<micahg> well, there's no exception for that
<micahg> so that would be a nightmare to backport...
<persia> I didn't see anyone from Sun at UDS Lucid, but that may be because they believe it to be a solved problem.
<persia> OpenJDK doesn't need backporting as much: it's open-source, with open tracking of security issues.
<micahg> but it's still in the archive...
<persia> Well, file a bug to remove it then (but first do the SRUs for previously supported releases).
<persia> I don't expect we want to support it for the entire Lucid timeframe, as I'm fairly sure Sun isn't going to offer us support.
 * persia double-checks
<micahg> persia: there's a blueprint already working on moving it to partner: https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-dropping-sun-java6
<micahg> so I should just focus on the older releases then, right?
<persia> micahg: Interesting: looks like the plan *is* to move to partner.
<micahg> right
<persia> Personally, I think the SRUs are the only important bit, because for hardy we didn't have a 100% compliant OpenJDK (although it was about 95% compliant)
<crimsun> 3[A[A[A[A[A[A33nope
<persia> crimsun: ?
<persia> micahg: I don't think the last issues that made OpenJDK a complete solution were solved until Karmic (although fixing plugin-finder might make it even better), but Jaunty and Hardy would definitely benefit.
<crimsun> sorry, no love for my wireless device
<micahg> maybe I should try the openjdk version...
<persia> Hrm.  I may be reading things wrong, but it looks to me like Java 6 was released in early 2007 and Sun offers 3 years support from the release date for free downloads (according to http://www.sun.com/software/javaforbusiness/support.jsp)
<micahg> is there a 7 yet?
<persia> So, either Sun is extending support until Java 7 (based on OpenJDK) is available, or the 3 years of support counter gets reset for each update.
<persia> 7 has been being planned for some time.  I'm not aware of the current status.
<persia> Yeah, I think free sun-java6 should be going out of support soon: "Use the traditional Java SE free-of-charge and have access to updates for three years from the time of Java SE product family release" really seems to imply the first release, rather than updates.
<persia> (but I'm not authoritative: ask Sun for a real answer)
<fabrice_sp> :CAP REQ IDENTIFY-MSG
<fabrice_sp> sorry
<dholbach> good morning
<slytherin> ttx: busy? need to discuss something about likewise-open
<ttx> slytherin: shoot
<slytherin> ttx: My friend has successfully joined a Ubuntu laptop to Windows domain. Now when he logs in using domain user he is does not see network-manager applet in panel. Any idea what could be wrong?
<ttx> hmm, I'd say missing admin rights
<ttx> i.e. the WINDOWSDOMAIN\user isn't in the required group
<slytherin> he has added the user to sudoers list. When trying to launch nm-applet from command line he sees some dbus related warning.
<slytherin> from warning it looks like NM is not letting non-local user launch the applet.
<ttx> slytherin: did he check he can sudo ?
<ttx> slytherin: hm
<slytherin> yes, he can. He can launch synaptic and install packages.
<ttx> slytherin: maybe NM has funny ways to look at the user list
<ttx> slytherin: if getent shows his user, then NM should be ahappy about it
<ttx> slytherin: is that 4 or 5 ?
<slytherin> 5
<ttx> I'd say it's an NM bug
<ttx> the rest of the system seems happy with that user
<ttx> slytherin: testing a lucid alpha2 livecd to check if the new 5.4 works better would be great though
<slytherin> ttx: nah, that would be too much to ask. It is not as if he has nothing better to do. :-)
<slytherin> ttx: I am wondering if settings in file /etc/dbus-1/system.d/NetworkManager.conf are causing problem
<jariq> Could someone pls review package ipwatchd - http://revu.ubuntuwire.com/p/ipwatchd ?
<hakaishi> Could someone please review package qt-shutdown-p http://revu.ubuntuwire.com/p/qt-shutdown-p
<slytherin> Does anyone know why maven in repository uses source=1.3 by default?
<geser> ScottK: although I've only done rebuilds of debian-xcontrol, I think that its removal sounds sane
<shriekout> hi
<shriekout> how seek 'config.log' in launchpad?
<shriekout> http://launchpadlibrarian.net/37879616/buildlog_ubuntu-karmic-i386.cubrid_8.2.1.0215-ubuntu3_FAILEDTOBUILD.txt.gz
<geser> can you reproduce this in a pbuilder? (as this would be the fastest way)
<shriekout> hmm..
<shriekout> how reproduce?
<geser> try to build it in your pbuilder and see if it happens there too
<geser> if it only happens on the buildd (or you don't have a pbuilder to test) you need to do a new upload which "cat config.log" (so it appears in the build log) if configure fails
<geser> (I had to do this already at least once, it's no fun to do debugging this way)
<shriekout> success... my desktop
<shriekout> ...
<geser> in that case try "./configure --with-jdk=/usr/lib/jvm/default-java || cat config.log" in your rules (and reupload)
<shriekout> thanks. :)
<geser> but I can give you the error on amd64 if you're intersted
<shriekout> thanks... :)
<shriekout> reuploaded... i read https://wiki.ubuntu.com/PbuilderHowto
<shriekout> thank geser :)
<ScottK> geser: Thanks.  Removal requested.
<barry> ScottK, POX did i remember incorrectly, or were one of you updating python-setuptools to version 0.6.10 to get the latest version of setuptools?  i uploaded a ppa for lucid for python-munepy but it fails to build because it's trying to download distribute-0.6.10.tar.gz.  i haven't tried it yet, but i'm guessing putting that in my ppa will fix the problem
<ScottK> barry: That's the one that we said needed to be looked at to see if it was a sync or a merge.  IIRC you were going to look at it.
<ScottK> stdeb was the one that could be sync'ed and I did that.
<barry> ScottK: cool (thanks for the stdeb one).  i was on leave yesterday, so i'll look at that today
<coolbhavi> hey all I am working on merge of jigdo but patch is not applying http://launchpadlibrarian.net/37884143/buildlog_ubuntu-lucid-amd64.jigdo_0.7.3-3ubuntu3_FAILEDTOBUILD.txt.gz here is the dsc https://edge.launchpad.net/~bhavi/+archive/crickinfo/+files/jigdo_0.7.3-3ubuntu3.dsc anyone pls help
<dholbach> highvoltage: so it seems we need more publicity for the docs, the sessions (although we've been slacking there for a bit now) and developer week? :)
<highvoltage> dholbach: heh, indeed. I was just thinking that I could blog about it
<highvoltage> dholbach: and sorry for all the noise
<dholbach> no worries... I was interested what we could probably improve :)
<slytherin> coolbhavi: What all Ubuntu changes need to be carried over?
<benc1> how hard is it to make a self package that uses an old package and just update the source?
<coolbhavi> slytherin, the patch needs to be carried over
<slytherin> benc1: depends on the package, sometimes 'uscan; dpkg-buildpackage' is all you need.
<highvoltage> dholbach: there's probably a news item or something I missed, but what happened with the 'future of motu' discussions at UDS wrt to the archive reorganisation? Is motu still going to be around for the packages that no one else cares about?
<coolbhavi> slytherin, I refreshed the patch yet its not applying
<slytherin> coolbhavi: Can you paste the build log in plain text somewhere?
<strycore> Hi
<coolbhavi> slytherin, sure
<dholbach> highvoltage: as far as I know ScottK and cjwatson wanted to write something up about it
<strycore> Ok to change the ML link in https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases from karmic to lucid ?
<benc1> slytherin: I want to update this package to ejabberd 2.1 http://packages.ubuntu.com/karmic/ejabberd
<dholbach> strycore: sounds reasonable
<coolbhavi> slytherin, http://paste.ubuntu.com/356587/
<cjwatson> highvoltage: https://wiki.ubuntu.com/Specs/LucidMOTU is persia's draft which we need to get round to finishing up
<cjwatson> highvoltage: yes, motu will still be around
<highvoltage> thanks for the link cjwatson
<strycore> I'll also change links for the development forums and the archive status page
<vish> dholbach: hi.. off topic here , but couldnt find you on -bugs.   the 5-a-day stats are not updating? ;)   I'v changed my lp name nearly a month ago and it is still stuck with my old name and stats :(
<dholbach> vish: http://qa.ubuntu.com/reports/five-a-day/ Last updated at: Thu, 14 Jan 2010 12:32:46 +0000
<dholbach> vish: do you think you can talk to bdmurray about it?
<vish>  yeah sure, it says that but , its not really updating ;) i'll mention to bdmurray
<dholbach> ok perfect, thanks
<vish> thanks :)
<slytherin> coolbhavi: Can you also paste the patch file somewhere?
<coolbhavi> slytherin, its too big to be pasted :( so I ve provided the dsc
<benc1> can someone give my hints how to self update a package to support recent version of a server?
<slytherin> coolbhavi: unfortunately I can not download in the network I am. use pastebinit.
<benc1> there is a debian package but I'm not sure it is safe to use
<coolbhavi> slytherin, http://fpaste.org/GBSB/
<coolbhavi> slytherin,  http://paste.ubuntu.com/356587/ <-- Buildlog
<coolbhavi> slytherin, It patches 2 files first one is getting patched correctly 2nd file the error is coming
<coolbhavi> at line 653
<slytherin> coolbhavi: Have you checked if scripts/jigdo-lite exists and the location has not changed in upstream source?
<coolbhavi> slytherin, yes
<coolbhavi> slytherin, if not there would have been an error like patch hunk failed
<slytherin> I am wondering what malformed patch means.
<dholbach> edited by hand maybe?
<coolbhavi> dholbach, no
<dholbach> or missing newline at the end or something
<dholbach> best to regenerate the patch and try again :)
<coolbhavi> dholbach, I just changed the line which the patch is going to be applied
<dholbach> so you edited it by hand :)
<Quintasan> Hiho
<coolbhavi> i.e from 468 to 470 only that no i changed dholbach
<dholbach> coolbhavi: I personally would regenerate the patch
<coolbhavi> dholbach, how to do there are lots of lines there
<coolbhavi> dholbach, might be my question was dumb .. but please help
<dholbach> how did you generate the first patch before you edited it?
<slytherin> coolbhavi: Found the problem. Looks like you did not use dpatch-edit-patch to edit the patch.
<coolbhavi> slytherin, first part I did that thing
<slytherin> coolbhavi: there is no @DPATCH@ just before line 653
<dholbach> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#dpatch
<coolbhavi> 2nd part wasnt sure
<coolbhavi> okay got it
<dholbach> don't edit a patch by hand - there's always a tool to generate it for you :)
<coolbhavi> dholbach, okay thanks
<slytherin> coolbhavi: What you can do is remove the lines from 653 to the end. Then you can use dptach to edit the patch properly.
<coolbhavi> slytherin, the old patch isnt applying to edit
<coolbhavi> now how to refresh?
<slytherin> coolbhavi: I told you - remove lines from 653 to end from the patch
<coolbhavi> slytherin, now what do I do? http://paste.ubuntu.com/356624/
<slytherin> coolbhavi: Can't help much without access to the source (which I can not download at the moment). How about you start from scratch?
<coolbhavi> slytherin, I have deleted line 653 onwards hmm
<slytherin> coolbhavi: Sorry, but got to go home. Will try to help later if I am online.
<coolbhavi> dholbach, can you please help me?
<slytherin> coolbhavi: I suggest that starting from scratch will save time.
 * coolbhavi feels quilt is magic
<dholbach> coolbhavi: just regenerate the patch
<dholbach> it's no use trying to edit the patch by hand
<dholbach> there's too much you can get wrong easily
<dholbach> I know that quilt is a pain, but still better to use it than to edit the patch by hand
<dholbach> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#quilt (example package: xterm)
<coolbhavi> dholbach, previous patch doesnt apply now how to regenerate using dpatch? dpatch-edit-patch isnt working
<dholbach> where did you get the patch from?
<coolbhavi> from the merge
<coolbhavi> ../grab-merge.sh
<dholbach> does applying the patch not work at all or is it just the last hunk?
<coolbhavi> dholbach, just last hunk from 653 onwards
<dholbach> then use the .rej file and fix whatever's to fix manually
<coolbhavi> dholbach, wait a sec pls
<dholbach> sure, take your time - I'm having a look at something else at the moment
<coolbhavi> dholbach, m not finding any .rej in the source now
 * coolbhavi feels weird
<dholbach> coolbhavi: then have a look at the patch file and apply the changes of the last hunk by hand
<coolbhavi> did that so m getting that malformed patch error
 * coolbhavi tells dholbach that he is in a dizzy and goes to dinner
<lfaraone> If package "autokey" uses GTK in karmic, and in sid/lucid it'll be renamed to "autokey-gtk", with "autokey" being a redesigned-by-upstream-QT-based-interface, how should the transition be handled, if at all?
<maco> i think you'll need transitional packages
<maco> have an autokey-qt in lucid
<maco> oh wait
<maco> hrmph
<dholbach> coolbhavi: how do you get that error when you do changes to the file manually (not to the patch, but to the file that is being modified by the patch)
<maco> have autokey-gtk conflict/replace autokey
<ScottK> maco: Why?
<maco> ScottK: is that how you do it?
<maco> if you want to make sure that an upgrader who has autokey installed gets switched over to autokey-gtk, i thought that was how?
<ScottK> I'd say leave it be.  If upstream has redone their primary interface, users should get that.
<maco> (i havent done this before, obviously)
<ScottK> If someone wants the old gtk stuff, they can go look for it.
<lfaraone> They're continuing to offer autokey-gtk, and are still releaseing new updates, but their focus is autokey (QT).
<ScottK> Simpler answer is don't deviate from Debian over this.
<lfaraone> ScottK: well, I'm the maintainer in Debian, so we can do whatever we want :P
<ScottK> Ah.
<lfaraone> (it wasn't in lenny, so we don't have to worry about a transition over there)
<ScottK> My advice would be not to do anything.
<ScottK> Make autokey the primary one and let people hunt down -gtk if they want it.
<lfaraone> (right now autokey-gtk isn't uploaded, I'm procrastinating since it'd mean a new source package. (due to the way upstrem distributes it))
<ScottK> In general I think users are more interested in getting the latest stuff than what toolkit it was implemented in.
<ScottK> With V3 source packages you can put multiple upstream tarballs in one source package.
<lfaraone> ScottK: if I use v3, do I have to use quilt for patches? argh, all I need is simple-patchsys...
<ScottK> Up to you
<lfaraone> ScottK: right now the upsream packages conflict with each other due to different conffile formats <_<;
<ScottK> Oh
<lfaraone> ScottK: I mean, it's for a silly reason, but it'd take some engineering which goes beyond my python knowledge to fix. (they'd have to change the module names,
<lfaraone> which breaks backwards compatibility, since they use pickle to store data. )
<barry> ScottK: woot!  okay, i'm going to look at the distribute changes after lunch, but adding a distribute/python-setuptools package to my ppa fixed my munepy ppa build problem on lucid.  so that's good :)
<ScottK> barry: Only sort of.  It's better to patch it so it doesn't try to download stuff at all.
<coolbhavi> dholbach, when applied inline its fine
<hyperair> to whoever uploaded codelite for me, thanks
<jpds> hyperair: That would be dholbach.
<hyperair> how do you tell?
<jpds> Launchpad knows all.
<jpds> hyperair: https://edge.launchpad.net/ubuntu/+source/codelite/2.1.0.3584+dfsg-0ubuntu1
<hyperair> ah
<hyperair> hehe
<hakaishi> Hi! Could someone please review package qt-shutdown-p? http://revu.ubuntuwire.com/p/qt-shutdown-p
<micahg> mr_pouit: are you around?
<mr_pouit> micahg: yep
<mr_pouit> I think I have to sponsor a sru abour xfpm and I forgot ;]
<micahg> mr_pouit: I wanted to let you know it was a problem with my notification system
<micahg> I was still using notification daemon
<micahg> about the xpm icons
<mr_pouit> ah, ok
<micahg> mr_pouit: I did have a weird xfpm quit this morning, but I think it's a one-off situation, I'll open a bug if it happens again
<micahg> mr_pouit: do you need the bug # for the SRU?
<mr_pouit> micahg: yeah, because I can't find it anymore ;>
<micahg> mr_pouit: bug 455089, but I don't think it has the latest debdiff...
<ubottu> Launchpad bug 455089 in xfce4-power-manager "power manager does not appear after resume" [Low,Fix released] https://launchpad.net/bugs/455089
<micahg> let me update the debdiff quick
<micahg> mr_pouit: updated
<mr_pouit> okay, test-building & uploading
<barry> ScottK: ping
<ScottK> barry: Pong
<barry> hi ScottK, so i'm looking at the source package for distribute 0.6.8-1ubuntu2 in lucid.  iiuc, the issue is to try to determine what changes have been added to the ubuntu package from the debian package right?
<ScottK> barry: Yes.
<ScottK> I'd grab 0.6.8-1 and diff them to see.
<ScottK> Often debian/changelog has enough information for you to know if the diff is worth maintaining.
<barry> ScottK: i'm looking at the change log.  there are only two lucid specific changes that i can see: one is to fix lp bug 490731 which deletes the egg-info directory (if it's not a symlink) and the other is to build only for py25 and 26
<ubottu> Launchpad bug 490731 in distribute "python-setuptools: import setuptools returns ValueError: ("Missing 'Version:' ...)" [Undecided,Fix released] https://launchpad.net/bugs/490731
<barry> ScottK: i believe you even reviewed and approved the former
<ScottK> IIRC yes.
<ScottK> We need to build only for py26 now.
<barry> necessary if updating from 0.6c9
<barry> so i think both changes make sense
<ScottK> OK.  So then it's a merge.
<barry> cool.  what can i do to help?
<ScottK> Prepare an updated version that is the new Debian stuff plus our changes and then either attach a debdiff (from debian to your proposed package) or push a branch somewhere and attach to a bug for spsonsors to review
<barry> ScottK: cool.  i think i can do that (and will probably do the latter).  thanks
<ScottK> OK.  Then subscribe ubuntu-main-sponsors to the bug when it's ready
<barry> +1
<barry> ScottK: okay, i have another dumb question.  i've started by branching lp:ubuntu/lucid/distribute.  now what?  what i did was unpack sid's distribute_0.6.10.orig.tar.gz into that branch and then tried to build it using debuild.  it failed in sphinx (building the docs).  i'm not honestly sure what i did is the "right way" to upgrade the package though.
<ScottK> barry: I sent a mail to ubuntu-devel the other day saying I was taking a break from merges until I could figure out the new fangled UDD way of doing it.
 * ScottK is not the right guy to ask.
<barry> ScottK: understood! i guess it's time to go to the mlist :)
 * barry likes blazing trails
<ScottK> That or stare in the direction of james_w until he appears and saves the day
 * barry stares at james_w 
<micahg> barry: there a starter wiki page
<micahg> barry: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
<micahg> beyond that I don't know
<barry> micahg: thanks.  will read
<james_w> barry: you are merging from sid?
<ScottK> barry: While you're looking at distribute, do you think that instead of patching it for specific python versions it might be better to just take the output of pyversions -s?
<barry> james_w: that's what i'm attempting to do: update lucid's distribute package to sid w/o losing ubuntu specific changes
<james_w> barry: the page micahg pointed out is the way to do that
<barry> ScottK: that's probably a good idea
<james_w> bzr merge-package lp:debian/sid/distribute
<barry> james_w: awesome thanks.  ScottK i'll look at adding that change
<ScottK> barry: That change could go back to Debian too if it works out.
<barry> james_w: btw, i've been muddling through packaging a brand new package using the udd way.  i have a set of notes that i'll be emailing the list, but is there a wiki page for that workflow?
<barry> ScottK: right.  i'm not yet sure how to do that, but i'll ask when i get there :)
<ScottK> OK.
<ScottK> barry: Since doko is the maintainer in Debian it'll be easy to find someone to discuss it with.
<james_w> barry: no, but there should be, feel free to dump your notes in to a new page and we can work out cleaning it up if needed
<james_w> thanks
<barry> james_w: cool, will do both.  i actually think for a python package we're real close, but it's a bit like the intercontinental railway.  3000 miles and the rails only *almost* line up :)
<james_w> heh
<POX> barry, ScottK: you know that distribute is just one of hunderets of packages affected by #552595, do you really want to fix all of them?
<geser> I see you are talking about merging distribute, if I understood POX correctly the second Ubuntu delta to distribute can be dropped when python-central gets fixed
<POX> I think we have a solution for #552595 so just wait for Debian
<ScottK> POX: OK.  I think we should keep the workaround in distribute until we get the fixed pycentral from Debian.
<barry> POX, geser right.  there's a workaround in preinst for that one, right?
<barry> (currently)
<geser> yes, I didn't know at that time that this is a bug of python-central and not python-setuptools (from distribute)
<POX> where can I find list of files shipped by ubuntu packages?
<geser> packages.ubuntu.com
<POX> something like http://packages.debian.org/sid/all/python-setuptools/filelist
<geser> POX: http://packages.ubuntu.com/karmic/all/python-setuptools/filelist
<POX> got it (http://packages.ubuntu.com/lucid/all/python-setuptools/filelist)
 * barry needs to reboot a server and might lose connectivity for a short bit
 * persia idly mentions the existence of editpatch from the patchutils package (doesn't work so well for dpatch)
<ScottK> But that has it's own edit-patch
<blizzkid> hi all. Was just thinking, how hard would it be for a good devver to create a tool that takes the generic kernel config and strips out the hardware support not needed for a specific machine?
<blizzkid> That would build a semi-custom kernel adapted to one's hardare and keep in the needed other modules
<persia> blizzkid: It's not that hard, but the default config builds most of the stuff that isn't present on nearly every machine as modules, which achieves most of the same effects.
<persia> Not building the module conceivably saves a small amount of secondary storage (usually kilobytes per module), but then reduces flexibility.
<persia> But if you want real details on whether this would have any benefit and what needs to be done, you'd do better to ask in #ubuntu-kernel
<blizzkid> ok, persia, I'll do that
<directhex> blizzkid, not much point. the kernels are highly modular. the drivers you don't need simply aren't loaded
<blizzkid> directhex: hmm, then is there still a use for custom kernel vs generic?
<persia> Not so much
<directhex> blizzkid, i haven't compiled a kernel for about 6 years...
 * persia looks up the blog post that decided the Ubuntu kernel was the only one to use
<directhex> actually, i remember, the last kernel i compiled was 2.6.12
<directhex> how old is 2.6.12?
<blizzkid> that's been a while indeed
<directhex> i had to apply a random patch from a mailing list to make my sata controller work, and needed 2.6.12 to make my tv card work. this was on debian
<persia> Bah.  I can't find it: my archives are insufficiently complete from that long ago.
<blizzkid> lol persia
<persia> No, really.  There was this post back in 2004 or 2005 where one of the Ubuntu developers had been compiling their own kernel and something broke and they described at length why they weren't going to do it again.
<persia> Unfortuately, none of the archive tools I know can find it with my vague memory of it.
<blizzkid> that would be a nice read indeed
#ubuntu-motu 2010-01-15
<ajmitch> directhex: lucky you, I had to compile a kernel only 2 days ago
<ajmitch> though it was just grabbing the ubuntu kernel, modifying 1 file to add a USB device ID, and push it through pbuilder
<freinhard> hi!
<freinhard> is it possible to write a debian/watch file for google code? doesn't provide directory listing
<jpds> freinhard: It is.
<jpds> See: pidgin-facebookchat
<freinhard> jpds: great, works!
<freinhard> would be nice if someone could comment (and maybe advocate) http://revu.ubuntuwire.com/p/ctemplate
<persia> freinhard: From a quick glance, you have some unanswered lintian reports (you don't need Section: in the source stanza) you're forcing debhelper 7, but using CDBS: what feature from debhelper 7 do you require? You don't need .dirs files for directories identified to dh_install, you haven't included a symbols file to check for ABI shifts.
<persia> There's likely more, but that's a batch to dig at for now :)
<freinhard> persia: just reuploaded witout the unneeded second section line
<persia> OK.  How about the rest?
<freinhard> just removed debhelper and i'll check the .dir files
<persia> removed debhelper?  Check the debhelper changelog: you may want something newer than the 5.0.30 that cdbs pulls.  Also, be sure to adjust debian/compat if you're supporting older debhelper.
<persia> Also, there's a lintian bug that some people work around by adding an unversioned debhelper build-dependency.  If you end up with the complaint that there's no build-depends on debhelper, and you do have build-depends on CDBS, you can ignore it because CDBS depends on debhelper.
<freinhard> in fact i've no idea which debhelper and compat i need. build on karmic, that's all i know. upstream requires 4.0.0 but no idea if this is still valid
<freinhard> s/build/builds/
<persia> upstream shouldn't require any version of debhelper: it's only used in packaging.
<persia> Check the debhelper changelog (in reverse order).  The first time you see a feature you think you're using, set that as a minimum version of debhelper.
<persia> If you get back to the version that CDBS requires (5.0.30 for karmic), stop, and don't bother with a versioned depends.
<freinhard> i know, they provided some two years old debian/ folder which, except for the controls and .install files, i dumped
<persia> Similarly, it's likely worth checking the CDBS changelog to see if you need a specific version.
<freinhard> the only thing i can do is to require karmics current cdbs version. i know that it builds on karmic and i can't test anything else.
<persia> Well, don't bother with a versioned build-dep on cdbs then.
<persia> If someone tries to backport it, they may file a bug.
<freinhard> that's what i wanted to hear :D
<freinhard> any package where i can have a look how the debian/symbols file works?
<persia> https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols is an excellent write-up (which stefanlsd really ought push into the PackagingGuide at some point)
<persia> Dunno about sample packages.
<freinhard> if i don't depend on debhelper anymore, can i drop the debian/compat file?
<persia> No.
<persia> You need to tell debhelper which version of the files you're using.
<freinhard> ok so i just ignore the lintian warning about debhelper and keep the compat file
<persia> But if you're using CDBS, you can drop it to compatibility level 5, unless you're depending on some special feature of debhelper that requires a newer compatibility level (and you oughtn't be if you checked the changelog and aren't adding a versioned dependency)
<persia> Yes, that's the lintian bug I mentioned earlier, that it fails to detect when debhelper will be installed by CDBS.
<persia> As I said before, some people work around this with an unversioned debhelper build-dependency, but I usually just leave it there, because I know lintian is wrong in this case.
<persia> Fixing it is tricky because the real fix would involve lintian building a recursive build-depends tree based on a current apt-cache for the target listed in debian/copyright and checking that, which would be slow (and quite possibly completely wrong in cases where special targets (e.g. UNRELEASED) are being used).
<freinhard> so this will probably never happen.
<persia> If you're super picky, you can set up a lintian override file that explains why lintian is brain-dead in this case and overrides the warning, but since it's not critical, it doesn't really require an explanantion in an override file.
<freinhard> no,i'm not picky at all. if it works, i'm fine with it ;)
<persia> Well, it's a tricky problem.  Needs someone who cares enough about CDBS and lintian and hiding the warning to spend a lot of time on it.
<persia> Most such people would rather fix other stuff in lintian or make CDBS more flexible instead.
<freinhard> lintian complains about leading spaces in the description when i run it on one of the resulting .deb files
<freinhard> is the description indented with one or two spaces?
<freinhard> i guess one...
<persia> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description describes the syntax for Description fields.
<persia> Sometimes you want one space, sometimes two.  It depends on what you're doing.
* ScottK changed the topic of #ubuntu-motu to: Ubuntu 9.10 released! | Lucid Alpha 2 Released! | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://is.gd/2y76G | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS/ | http://qa.ubuntuwire.com/debcheck | latest rebuild failures: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi | Outstanding merges: http://people.ubuntuwire.com/~lucas/merges.html
<SoftwareExplorer> I'm tying to make a debdiff for bug 461104. I get the messageNOTICE: 'ubiquity' packaging is maintained in the 'Bzr' version control system at:http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk Please use:bzr get http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk to retrieve the latest (possibly unreleased) updates to the package. What one should I use?
<ubottu> Launchpad bug 461104 in ubiquity "Timezone combo doesn't always change (doesn't retranslate) if I change language" [Undecided,Confirmed] https://launchpad.net/bugs/461104
<ScottK> SoftwareExplorer: For that package you're better off to work from bzr and ask to have your branch reviewed.
<persia> SoftwareExplorer: ubiquity development is a bit special, because the ubiquity branch doesn't quite match the ubiquity package (because the ubiquity package includes chunks of d-i).
<persia> SoftwareExplorer: https://wiki.ubuntu.com/Ubiquity/Contributing might be a good place to start to untangle things
<persia> SoftwareExplorer: https://wiki.ubuntu.com/Installer/Development has more pointers.
<SoftwareExplorer> The main reason I was going to try to do this bug is that it seems to already have a patch for the python. Is this not a good bug to try to fix for my first time?
<persia> Probably not.  That's an odd source package and runs in a tricky-to-test environment.
<persia> Speaking of my experience, I ran into lots of difficulties when I first tried to change ubiquity, even after several years of experience with packaging and bugfixing in Ubuntu.
<SoftwareExplorer> Ok. Well, at least I was able to confirm the bug.
<persia> Alternately, if you have a real interest in how the installer works, more help in that area would likely be appreciated :)
<SoftwareExplorer> I'm just trying to start learning to package. I don't really have a specific interest yet, mostly I just want to help.
<ScottK> SoftwareExplorer: Were glad to have you.
<ScottK> kamalmostafa: If you're around, now's not bad.
<persia> ScottK: By the way, did you ever get an answer to your question about plymouth and art?
<persia> (or am I misremembering the channel in which you asked?)
<ScottK> persia: I did not, but davmor2 said he'd file the bug.
<ScottK> persia: I think it was -devel, but thanks for remembering.
<persia> In another context, I was told that the filename was hardcoded in the ./configure call in the plymouth source package.
<kamalmostafa> ScottK: just a moment
<ScottK> OK.
<ScottK> persia: That's "special"
<persia> I wondered if it might make sense to have that be some well-known-location and use alternatives for the different flavours, but I'm not likely to dig into that.
<persia> Indeed :)  It broke several flavours.
<ScottK> It also FTBFS on ports.  Dies in configure
<persia> no artwork?  :)
<ScottK> The error message isn't helpful
<ScottK> I didn't get a chance to investigate
<persia> It's the --with-logo=/lib/plymouth... that handles the artwork there.
<persia> ScottK: Seems the issue is: configure:11953: error: Package requirements (libdrm libdrm_intel libdrm_radeon libdrm_nouveau) were not met:
<persia> I'm guessing that string needs adjustment for any ports DRM that support it (but I'm not at all familiar with how DRM works for ports)
<ScottK> Ah.  No, they wouldn't be, would they.
 * ScottK neither.
<ScottK> Maybe tseliot knows.
<persia> Maybe we should have been having this discussion in -devel :)
<persia> (but tseliot isn't there either)
<ScottK> kamalmostafa: What have you got?
<kamalmostafa> ScottK: ok, first off, I'm not at all sure that I actually did what you asked for, but here goes...
<ScottK> kamalmostafa: That's fine.  Learning is a big part of the point of this.
<kamalmostafa> Lets start with libtifiles:  https://code.launchpad.net/~kamalmostafa/ubuntu/lucid/libtifiles/libti-backmerge
<ScottK> ok
<kamalmostafa>   - Merged libtifiles2 --> libtifiles
<kamalmostafa>   - I did not re-autoconf (ran into problems) so kept ubuntu versions' conf (autoconf-1.10.1)
<kamalmostafa>   - Significant changes to debian/copyright files.  Is it okay?
<kamalmostafa>   - I may have missed some instances of "2-removal" (po stuff? doc stuff?)
<kamalmostafa> First question:  Is the debian/changelog version number correct?
<kamalmostafa> I bumped up the "libtifiles2" version number by one "ubuntuN" unit to construct 1.1.2-0ubuntu2 but it looks weird as the next revision above libtifilesÂ (1.1.1-1).   ..
<ScottK> Bumping the version number was right.
<ScottK> As first glance it looks pretty good.
<ScottK> I don't think there's a way to do the changelog that wouldn't end up looking a bit odd.
<kamalmostafa> Yeah, I fought it out with the version numbering for quite awhile -- this was the only way to convince Lucid to use *this* libtifiles instead of the one that appears newer from libtifiles2.
<ScottK> kamalmostafa: It does look like there are some things you can do to minimize the diff from debian.
<ScottK> kamalmostafa: Exactly.
<ScottK> As an example, you have ordered the build-depends differently.
<ScottK> That's a pointless diff and you should change to follow Debian.
<ScottK> OTOH, the more precise debhelper version requirement in the Ubuntu package is good to retain
<ScottK> You should make standards version and home page the same as Debian
<kamalmostafa> But here's the thing... All those settings are what I lifted from "libtifiles2".
<kamalmostafa> I mean to say -- that's the debian/control from "libtifiles2", except modified for the new name "libtifiles".
<ScottK> Yes.
<ScottK> So I think there's a little more work to do to make our diff from Debian only the meaningful ones
<ScottK> For example I'd also use the Debian descriptions unless you think the Ubuntu ones are enough better to be worth sending a patch to Debian.
<ScottK> It looks like debian/rules could be better aligned similarly.
<ScottK> kamalmostafa: This is a very good start.
<kamalmostafa> Okay that seems like a reasonable endeavor for e.g. debian/control, but what about the generated files in the root directory -- those are sure going to differ greatly from Debian.  Is that going to be a problem?
<ScottK> I just looked in the debian dir so far.
<ScottK> For that we'll keep one or the other, I don't know yet which.
<kamalmostafa> :-)  Oh, you don't want to look up at Makefile.in  ;-)
<ScottK> I'm banking on keeping "the one that works".
<ScottK> Those should disappear on the next upstream release.
<kamalmostafa> Well, as it stands, I think it actually "works" -- the two packages together do build in PPA and install on my Karmic machine.   But yes, I'll make another pass over the debian/* files to reduce the diff.   I'm for leaving the generated stuff alone though.
<ScottK> OK.  Let's see.  You're off to a good start.
<kamalmostafa> ScottK: you still looking at tifiles? or ready to move on to a ticalcs?
<ScottK> kamalmostafa: I suspect if I did, I'd just tell you the same thing.  Want to take another pass at them both first?
<kamalmostafa> Sure that's just fine, one side note:  What about libticables2?  (libticalcs-dev depends on libticables2-dev).   Is it going to need the same "2-removal" treatment?
<ScottK> Yes.
<ScottK> We'll want to switch to the Debian package names and if there are any reverse-build-depends they'll have to be changed
<ScottK> Looks like tilp2 is affected as well.
<kamalmostafa> What a mess.  Well, since those ones aren't breaking (yet), how about we just deal with tifiles & ticalcs as "stage 1", and then deal with the rest as "stage 2".  Will that work?
<ScottK> Yes.
<ScottK> libticables2-dev will be NBS (Not Built from Source) once we upload the new libticables, but won't actually be removed until it had no reverse-build-depends
<ScottK> (or depends)
<kamalmostafa> Okay, good plan.  Thanks for the review Scott -- I'm off to dinner, then will make another pass at these two.  Will let you know when ready for the next review.  All good?
<ScottK> Ye[
<ScottK> Yep
<dhillon-v10> hi all, I am working on this merge and bzr says that there are conflicts in control and changelog, I understand the changelog part but my question is shouldn't there be conflicts in more than that or is that okay
<crimsun> dhillon-v10: generally that means the merge is clean
<dhillon-v10> crimsun, this is a merge from main so I was hoping something super complicated that I can't do but it seems plausible :)
<RAOF2> There will only be conflicts where the both Ubuntu and Debian have made changes in the same place; unless we're both fixing the same bug independently, that should be fairly rare.
<dhillon-v10> RAOF, crimsun thanks :)
<dhillon-v10> RAOF2, oh btw what does >> mean in version numbers, is it greater than
<RAOF2> Yup, greater than.
<RAOF2> Strictly greater than, in fact.
<dhillon-v10> RAOF2, thanks again
<micahg> does debcommit automatically use --fixes lp:xxxxxx?
<crimsun> yes
<micahg> yay!
<micahg> indeed
<crimsun> example: http://pastebin.com/d66dc32c3
<crimsun> O:-)
<dhillon-v10> crimsun, I did the merge here: https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/507778 does it look right
<ubottu> Ubuntu bug 507778 in acpid "Please merge acpid (1:2.0.0-1) from Debian testing" [Undecided,New]
<JontheEchidna> jdong: ping on an SRU
<JontheEchidna> wondering if I can get approval for bug 350902
<ubottu> Launchpad bug 350902 in kdepimlibs "[ubuntu 8.10] kio_imap4 hangs" [Medium,In progress] https://launchpad.net/bugs/350902
<jdong> sure, gimme 5 minutes
<JontheEchidna> Thanks
<slytherin> Why do we have a 'unapproved' queue for -proposed uploads. We never upload packages to -proposed without a SRU approval? So what is point of another approval?
<micahg> slytherin: according to the wiki process, upload is supposed to occur before approval
<slytherin> micahg: AFAIK, approval form SRU team is required before upload.
<jdong> well...
<micahg> both https://wiki.ubuntu.com/StableReleaseUpdates#Procedure and https://wiki.ubuntu.com/ArchiveAdministration#Stable%20release%20updates seem to imply you don't
<jdong> in the old days, ubuntu-sru tended to be a subset of ubuntu-archive
<jdong> and archive admins found it much more natural to use queuediff to process SRU's as they're clearing the upload queues
<jdong> hence upload and reference LP #, wait for approval
<jdong> but MOTU-SRU (at first didn't have, later didn't know of) the tools, and preferred using LP team subscriptions
<jdong> hence for MOTU, it tended to be ACK before upload
<jdong> now, I guess upload-and-wait is the correct procedure? :)
<micahg> well, if it's different the docs should be updated...
<jdong> well I think for now, the right thing to do is to update the docs and slap the people who don't follow it
<jdong> (innocently looks away)
<micahg> jdong: approval first?
<jdong> upload first
<micahg> jdong: that's what it says :)
<slytherin> jdong: And what happens when when Martin Pitt gives approval, package is uploaded and is waiting in queue? Whom do I need to bug about it.
<jdong> slytherin: archive admins, in that case
<ScottK> slytherin: What package?
<jdong> wow, what a big debdiff :)
<slytherin> ScottK: evolution-mapi.
<ScottK> slytherin: What bug?
<jdong> oh that's not a debdiff
 * jdong obviously needs caffeine
<slytherin> ScottK: bug 472552
<JontheEchidna> jdong: would you prefer a debdiff?
<ScottK> I can accept it if pitti approved it.
<ubottu> Launchpad bug 472552 in evolution-mapi "Please upgrade evolution-mapi to 0.28.1" [Medium,In progress] https://launchpad.net/bugs/472552
<ScottK> Looking
<jdong> JontheEchidna: haha no no, it's fine, I got it now :)
<JontheEchidna> :)
<jdong> silly midnight blind clicking
<JontheEchidna> I was a bit unclear on the process too. Generally pitti just uploads and accepts at the same time :P
<jdong> JontheEchidna: haha yeah, since the unification of the teams I guess there's been a bit of a shakeup :)
<jdong> the dust will settle soon
<jdong> JontheEchidna: ok you've got an ACK, carry on!
<JontheEchidna> jdong: thanks
<ScottK> slytherin: Done.
<slytherin> ScottK: thanks. Do I need to add that response in bugs 'please test package from -proposed'?
<ScottK> slytherin: No.  Did that as part of the process.
<slytherin> great
<slytherin> ScottK: I am wondering if I should request for standing exception for evolution-mapi.
<ScottK> No opinion.  I'm not on the SRU team.
<ScottK> You'd have to ask the tech board for the exception.
<slytherin> I meant for micro releases actually
<slytherin> Ok. I will mail them.
<jdong> is there a standing-exception... yeah what ScottK said :)
<slytherin> ScottK: You forgot to add comments on other bugs fixed in evolution-mapi upload. Should I do that?
<ScottK> slytherin: Add a comment that test results should go in the bug I marked.
<slytherin> Ok
<slytherin> Or I could add comment and set the bugs is verification-needed.
<slytherin> s/is/as/
<jariq> Could someone please review new package ipwatchd ? http://revu.ubuntuwire.com/p/ipwatchd
<persia> jariq: Regarding point 4 of my previous feedback: why do changes in debian/rules need to wait for an upstream release?
<jariq> persia: hm.. i thought you were talking about "rm -f" in Makefile in upstream package
<persia> Well, it's a good idea to fix that too :), but your debian/rules is also a makefile.
<persia> Mind you, without all the other stuff, it becomes minor enough not to warrant another upload, I just wondered.
<persia> My personal preference is to have the logs show if anything unexpected happens, just so that when something does fail, I can figure it out.
<persia> On the other hand, the way you're doing it might save kilobytes of storage space over the package lifetime.
<persia> (and it's exceedingly unlikely that failure to remove some stamp files would interrupt a build)
<persia> Bah, your package is in good enough shape that it needs a real review.
<persia> I'll hit it if I get time while I'm doing reviews tonight, but there's nothing I can tell you in a couple minutes that would improve it.
<jariq> persia: ok thanx a lot.. I'll take a look at that 'rm -f ' stuff meanwhile
<persia> Really, it's so minor it's not worth updating the package to make the change.
<persia> It's just a stylistic thing.
<persia> Probably more important if the target was an interesting file that might not be there or might have been created at the wrong time.
<persia> But for stamp files, it doesn't matter at all.
<jariq> ok
<fabrice_sp> anyone has an idea why I'm getting this error: Function `gtk_tree_view_column_get_cell_renderers' implicitly converted to pointer at ignoregui.c:192
 * persia idly wonders if a dh(1) package using rules.tiny could just ship debian/rules as a symlink to /usr/bin/dh
<persia> fabrice_sp: In what context?
<fabrice_sp> line is GList *list = gtk_tree_view_column_get_cell_renderers (col);
<fabrice_sp> and function is declared as GList *             gtk_tree_view_column_get_cell_renderers (GtkTreeViewColumn *tree_column);
<fabrice_sp> (my upload of xchat is FTBFS in amd64)
<persia> OK.  What's the type of the col variable at the time of the function call?
<fabrice_sp> GtkTreeViewColumn *col;
 * persia has no idea given that code
<fabrice_sp> the same for me :-/
<fabrice_sp> it's not a FTBFS as is, because the build is fine, but some sort of check is run on code after the building
 * fabrice_sp never saw that before
<persia> So it's a make tests failure?
<fabrice_sp> it seems to be an "automated build log filter"
<fabrice_sp> http://launchpadlibrarian.net/37913661/buildlog_ubuntu-lucid-amd64.xchat_2.8.6-4ubuntu3_FAILEDTOBUILD.txt.gz
<persia> Check the rules file.  Some rules files will run a test suite.  It may be that someone patched something and forgot to update the test suite.
<fabrice_sp> hmm, actually, the message gives some links
 * fabrice_sp should have looked at that before :-/
<fabrice_sp> point to http://wiki.debian.org/ImplicitPointerConversions
<persia> Also, look at line 1732 of the build log.
<persia> The error is reported there, it's just not enough to kill the make.
<fabrice_sp> ok
<persia> It looks like some header is missing, because the compilation claims "ignoregui.c:192: warning: implicit declaration of function 'gtk_tree_view_column_get_cell_renderers'"
<persia> So it may never be seeing " GList *             gtk_tree_view_column_get_cell_renderers (GtkTreeViewColumn *tree_column);" for some reason.
<persia> Maybe a scoping error also.
<fabrice_sp> make sense. I'll have a look later. Thanks!
<persia> Good luck.
<fabrice_sp> thanks ;-)
<persia> Note that this really only affects ia64, but it's worth checking for everything :)
<persia> (because amd64 will *try* to use 32-bit-safe pointers, if it can)
<fabrice_sp> I know: the problem is that it really blocks amd64 also :-/
<fabrice_sp> FTBFS
<persia> Doesn't it block all architectures on the buildds?
<fabrice_sp> no: only ia64 and amd64
<persia> If not, it's worth asking a buildd admin why not
<persia> That seems silly to me, but OK.
<fabrice_sp> have to go. Bye ;-)
<persia> Bye :)
<dholbach> good morning
<cemc> morning
<hakaishi> Hi! Could someone please review qt-shutdown-p (I'm waiting since days)? http://revu.ubuntuwire.com/p/qt-shutdown-p
<bdrung_> dholbach: please unsubscribe u-u-s (and subscribe yourself) when sponsoring a merge
<dholbach> bdrung_: why?
<dholbach> bdrung_: once the bug is closed it shouldn't matter any more who's subscribed, or does it?
<bdrung_> dholbach: when searching lp directly or when someone writes a comment
<dholbach> hum, generally the bug (that's been closed after upload) shouldn't turn up in bug lists any more... only if you search for all bugs ever
<bdrung_> dholbach: yes, but sometimes i search for all
<dholbach> what is your use-case?
<dholbach> I never bothered to do it and am not sure who else does :)
<dholbach> but yeah I could do it if it's really necessary
<dholbach> anybody else who has an opinion?
<persia> dholbach: The sponsoring procedure documents unsubscribing, and lots of people do it.
<dholbach> I see
<dholbach> maybe I'm the only lazy guy then ;-)
<persia> I wrote that bit, to cover two cases 1) often bugs will have other tasks not currently needing sponsorship, which clogs the LP view
<persia> and 2) sometimes bugs need later attention because something went wrong, so it's good for the original sponsor to be paying attention, but nobody else needs to care (unless there's an issue, in which case the submitter might again subscribe the queue)
<persia> dholbach: You're not the only lazy guy, just one of them :)
<hakaishi> Could someone please review qt-shutdown-p?  ';.;'  *pleeeease*  http://revu.ubuntuwire.com/p/qt-shutdown-p
<persia> hakaishi: Some reviewers have an informal policy that any package that gets reviews requested with less than 24 hours passing between requests get ignored.
<persia> Not that your package doesn't deserve review, but just a warning that asking too much may have the opposite effect.
<hakaishi> hmm... the last view days I asked just two times a day... I think this isn't too much to bear
<hakaishi> but, thanks
<persia> You may be right.  Depends on the reviewer.  I don't believe we have an active REVU coordinator this cycle, so I'm not sure there's any firm policy.
<hakaishi> okay, then I'll just try to ask every 24 hours and 5 minutes ^^'
<persia> That's what I used to advise people when I was REVU Coordinator.
<persia> Well, actually, I used to advise about every 30 hours, to have the best chance of catching different people at different times of day.
<hakaishi> okay, thank you! See you then ^^' (you seem to be online almost all the time)
<persia> I'm almost always online, but sometimes I have significant lag (rarely more than 100Ksec)
<freinhard> 0hi!
<freinhard> fixed all lintian warnings on http://revu.ubuntuwire.com/p/ctemplate and the last thing remaining is, what is that .symbols file for and where do i get usefull documentation or a package using it?
<slytherin> freinhard: http://wiki.debian.org/UsingSymbolsFiles
<freinhard> slytherin: no example there
<slytherin> freinhard: for example you can check gtk+2.0 package
<freinhard> slytherin: ok, undestood what that file does and what it is for.
<freinhard> slytherin: these files aren't manually created, are they?
<slytherin> freinhard: I haven't used it so don't know the details.
<persia> freinhard: https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols is fairly good documentation.
<persia> I tend to create the file at packaging time (using tools), so that the package FTBFS if the symbols don't match.
<freinhard> persia: not the shortest docs for a single file i've ever seen ;)
<persia> Well, no, but that's not a bad thing.
<persia> Consider all the documentation that exists on how to deal with debian/rules, when one can just use /usr/share/doc/examples/rules.tiny
<slytherin> persia: is that path correct?
<freinhard> slytherin: no it isn't, there's a debhelper missing
<slytherin> :-)
<persia> Good catch, both of you :)
<freinhard> ok, from the docs i see that exporting a single environment variable should trigger dpkg-gensymbols and i can gather the output for the symbols file after building the dsc with pbuilder?
<persia> freinhard: I've added some comments to ctemplate
<persia> freinhard: Right.  Once done, copy that file back into your source package, so it will compare the generated results against the defined results at build-time.
<persia> When upstream introduces new symbols without breaking ABI, add the right version hints.
<persia> When upstream breaks the ABI, create a new symbols file.
<freinhard> hmm didn't work with cdbs, looks like this gets called for debug packages only
<freinhard> persia: if the environment variable is set, dh_makeshlibs should have called dpkg-gensymbols?
<persia> freinhard: I don't remember having set an environment variable, but perhaps.  You might also try `touch debian/libctemplates.symbols` to generate a broken one and get the conflict output.
<freinhard> just tried that, still running
<freinhard> persia: where did you find a .la file?
<freinhard> persia: just checked the .deb file with gdebi and couldn't see one.
<persia> freinhard: I saw it listed in your .install file.
<persia> http://revu.ubuntuwire.com/revu1-incoming/ctemplate-1001150403/ctemplate-0.96/debian/libctemplate-dev.install
<persia> So if you're not seeing it in the package, then something else is wrong.  If you are seeing it in the package, you should change it so you don't (referenced to the squeeze release goal)
<bddebian> Heya gang
<persia> bddebian: !!!
<slytherin> Need help with oython. I am trying to install reviewboard which defines dependency on paramiko. I have already installed package form repository but reviewboard installer is not detecting it.
<bddebian> Heya persia!
<sebner> huhu bddebian :)
<bddebian> Heya sebner
<iulian> Hey.
 * sebner waves at iulian too
<^arky^> hi, who's the right person to answer a question on upstart event handling
<persia> ^arky^: I'm not sure there's any right person.
<persia> But it also depends on context.  If you're looking to put an upstart job in a package, we might be able to help.  If you're writing an upstart job from scratch, you might want to talk to the upstart team.
<^arky^> Then I will ask the question anyway, https://answers.edge.launchpad.net/upstart/+question/97511
<^arky^> need to write upstart job for gnome-orca package, upstart team looks like a good bet
<persia> Yeah, for that sort of thing, you probably need upstream support.
<^arky^> Yeah, I have bug 507953 created for this, how do I bring it to the notice of upstart team
<ubottu> Launchpad bug 507953 in gnome-orca "Upstart keybinding event to restart orca" [Undecided,New] https://launchpad.net/bugs/507953
<^arky^> think I'll subscribe upstart developers team and keep my fingers crossed
<persia> Um, surely there's a better way.
<persia> ^arky^: Try asking in #upstart (based on http://upstart.ubuntu.com/development.html)
<^arky^> persia: I already did
<^arky^> no response
<persia> Have you tried the mailing list?
<freinhard> persia: do i need to pass some magic commandline option to dh_makeshlibs to get the symbols output?
<persia> freinhard: I'm afraid I don't remember offhand
<persia> You can always run it manually if you do a local binary build (debuild -b) in a chroot (schroot -c or pbuilder --login)
<freinhard> what's the benefit of having /usr/lib/libfoo.so in the -dev package?
<geser> you can link against -lfoo
<freinhard> ok, my question should have been: why put libfoo.so in the -dev and not in the main package?
<geser> because you only need it during building other packages (or software in general)
<freinhard> thank you for clearing that up!
<sebner> huhu geser :D
<freinhard> still trying to figure out how to get that symbols file
<geser> Hi sebner
<freinhard> tried debian/(dev-packagename|package-name|parent-directory-name).symbols
<freinhard> none of them cause dh_makeshlibs to call dpkg-gensymbols
<freinhard> what does "if (-e" in perl check? exists?
<geser> have you also tried debian/libfoo1.symbols (or how exactly your library package is named)
<freinhard> yes, do they need to contain something? just put a empty file there
<geser> don't know, haven't need to use this yet
<freinhard> if a package contains a optional .vim syntax file that's usually goes to /usr/share/docs, should i install it to /usr/share/vim/vimcurrent/syntax/ ?
<freinhard> hmmi guess not, would imply having vim installed...
<freinhard> persia: about the copyright file: copied that from upstream svn, so i guess this should be fine?
<randomaction> What is the correct procedure for sponsored SRUs? Suppose we have a good debdiff and bug description. What happens next? ubuntu-sru ack or upload to -proposed?
<freinhard> http://revu.ubuntuwire.com/p/ctemplate could need some more review :)
<ScottK> randomaction: It's a bit confused, but I think the consensus is upload.
<randomaction> Also, what does opening a task for a stable release imply? It means you think that the problem is worth a SRU, right?
<ScottK> yes.
<randomaction> thank you
<ScottK> Although sometimes I'll open one against all affected releases and wontfix the ones I think we shouldn't do for clarity
<freinhard> anyone willing to sponsor my (almost ;) ) perfect ctemplates package? http://revu.ubuntuwire.com/p/ctemplate
<fabrice_sp> anyone knowing how to fix xchat in amd64? The log is there http://launchpadlibrarian.net/37913661/buildlog_ubuntu-lucid-amd64.xchat_2.8.6-4ubuntu3_FAILEDTOBUILD.txt.gz
<fabrice_sp> The line that fails is this one: GList *list = gtk_tree_view_column_get_cell_renderers (col); and I tried to include <gtk/gtktreeviewcolumn.h>
<fabrice_sp> bbl
<kamalmostafa> ScottK: Hi Scott.  I've re-done the libtifiles2 merge -- this time keeping the older Debian autoconf products and most of the debian/ file contents.  After folding in the one actual code change that Ubuntu picked up from the maintainer, the merge diff is really only a dozen lines or so:  https://code.launchpad.net/~kamalmostafa/ubuntu/lucid/libtifiles/libti-backmerge
<kamalmostafa> fabrice_sp:  I see that in that header file, the prototype you need is wrapped by #ifndef GTK_DISABLE_DEPRECATED  -- is that the problem perhaps?
<ScottK> kamalmostafa: Great.  I'm busy with $WORK right now.  I'll try and look at it tonight.
<kamalmostafa> ScottK:  That's fine.
<fabrice_sp> kamalmostafa, will have a look. Thnaks for the idea! :-)
<kamalmostafa> fabrice_sp: glad to help!
<kamalmostafa> Problem: After updating a .gmo file, my   bzr builddeb -S   fails:  dpkg-source: error: cannot represent change to .../po/fr.gmo: binary file contents changed
<kamalmostafa> Advice?
<fabrice_sp> kamalmostafa, update the source (.po file?), and modify the debian/rules to generate it again, if it's not the case
<kamalmostafa> fabrice_sp:  I'm not at all familiar with the po/ methodology.  There is a fr.po file (and a fr.gmo) already checked into this bzr tree.  I'm trying to replace them with the fr.po and fr.gmo from a later version of the same package.   So I don't think the .gmo needs to be generated again -- just needs to be rolled into this change.   I can "bzr commit" it no problem -- just can't build a test source package with "bzr builddeb -
<fabrice_sp> AFAIK, you can't commit a binary change
<kamalmostafa> bzr commit accepts it with no argument.  :-)
<kamalmostafa> Is it abnormal that a .gmo file would be checked in at all then?
<maxb> kamalmostafa: Yes, quite abnormal
<maxb> Unless it's by way of it being shipped in an upstream tarball, and thus imported.
<fabrice_sp> sorry: building classpath is killing my computer :-/
<maxb> In which case, what needs to happen is that the .gmo is unchanged whilst building the debian source package
 * fabrice_sp was going to say the same thing :-)
<kamalmostafa> maxb: okay, I think that does fit this situation -- both the "original" and my "target" packages were imported from upstream.
<fabrice_sp> generally, in that cases, I modify the clean target to delete the generated binary files, and build them
<fabrice_sp> even if the binary file comes from upstream
<kamalmostafa> So now when exactly will the new .gmo be regenerated?  (just part of 'make'?)
<maxb> kamalmostafa: OK. Make sure that _you_ don't commit any changes to those binary files - they should be left identical to those coming from the upstream import.
<maxb> Well, that's dependent on the specific package's buildsystem, but hopefully yes
<kamalmostafa> Got it (and I'll test it to make sure that happens).   So let me get it straight...  Its fine to change the .po, but leave the .gmo alone when building the source package;  the .gmo should get regenerated as part of the build anyway.  Yes?
<maxb> Correct
<kamalmostafa> maxb and fabrice_sp: Thanks very much!
<qnix> hi, is there a page about the Prevu tool ? Who said exactly it does in its automated backporting ?
<sistpoty> hi folks
<sebner> huhu sistpoty :D
<sistpoty> hi sebner
<freinhard> hi
<sistpoty> hi freinhard
<maxb> qnix: prevu is mainly just a wrapper around pbuilder. If you want to use it for anything complex, I recommend learning about pbuilder directly.
<freinhard> looks like people with sparetime! go for it: http://revu.ubuntuwire.com/p/ctemplate :D
<maxb> qnix: See also cowbuilder / cowdancer, which will save you so much time if you do lots of things with pbuilder
<qnix> ah, I already use cowbuilder.
<maxb> Then you don't really care much about prevu
<qnix> I thought prevu was something that fixes incompatibilities between different version of debhelper etc..
<qnix> Ok
<freinhard> selling stuff here is really really hard ;)
<maxb> qnix: Well, I admit I only looked at it last a couple of distributions ago, but it didn't do anything of that sort back then
<qnix> maxb: all right
<sistpoty> freinhard: I'm already looking at it, just not telling you :P
<freinhard> sistpoty: yay :D
<sistpoty> freinhard: commented on it, some tiny tidbits, but nothing really serious. Nice package!
<sistpoty> nixternal: from the try right now to fix gdcm it looks like I don't need ppc access after all... it ftbfs on amd64 now with the same reason (which I had slightly suspected)
<sistpoty> nixternal: so feel free to disable/remove my account
<freinhard> sistpoty: i was told that there should be a .symbols file for lib packages, but nobody seems to be able to tell me how to do it right.
<siretart> please don't add .symbol files if you don't understand them. a broken symbol file can be very annoying...
<nixternal> sistpoty: I will leave it, just in case you ever need it again :)
<siretart> hi folks, btw!
<nixternal> howdy sistpoty
<sistpoty> hi siretart and nixternal
<sistpoty> nixternal: ok :)
<freinhard> siretart: i undestood what it's good for but i didn't even get that far to produce any content for the .symbols file
<freinhard> sistpoty: thx for commenting
<siretart> freinhard: you can use dpkg-gensymbols for creating a first version
<sistpoty> freinhard: man dpkg-gensymbols might give some hints... however (and that's how I make it) unless libctemplate has many reverse dependencies, a symbol file is not too much needed in the first place
<freinhard> sistpoty, siretart: i thaught dh_makeshlibs calls dpkg-gensymbols if there is a libctemplate0.symbols file in the debian folder, but that didn't happen, or there was no output on commandline
<siretart> freinhard: it calls dpkg-gensymbols to check against the referencs .symbols file. you still have to generate and maintain the reference file
<sistpoty> ... grumble... gdcm... grumble... it looks like it should work but doesn't :(
<sistpoty> meh, I'm stupid, I really should read the context, now it's suddenly all clear
 * Laney spanks RainCT 
<Laney> you broke pbuilder-dist in 560
<RainCT> Laney: wha?
<Laney> /usr/bin/pbuilder
<Laney> should be sbin!
 * Laney fixes
<RainCT> uhm yeah sorry
<sebner> lol
<sebner> hi Laney
<RainCT> I wanted to get ride of the hardcoded path entirely but apparently forgot to do so :P
<Laney> hiya sebner
<sebner> Laney: side note: Eagerness rather than immaturity. I care for my stuff and tend to give 110% for it. Might seem odd for some though. Call it immaturity if you think (evil hard) life will change me
<sistpoty> sebner: huh?
<Laney> I was trying to defend you
<sistpoty> ScottK: I think I've got a fix for gdcm now, which should make it build on ppc (not tested, it ftbfs'd as I thought in the same way on amd64 now). problem is that it's a hack to fix debian 562775 and I'm not 100% sure if it will also cure rdepends
<ubottu> Debian bug 562775 in libvtk-java "FTBFS: Could not find vtk.jar file, VTK_JAVA_JAR is wrong, please set proper GDCM_VTK_JAVA_JAR replacement var" [Serious,Open] http://bugs.debian.org/562775
<sistpoty> (due to lack of knowledge about both cmake and java)
#ubuntu-motu 2010-01-17
<fabrice_sp> porthose, about bug 508668
<ubottu> Launchpad bug 508668 in cvsnt "Please sync cvsnt 2.5.04.3236-1 (universe) from Debian testing (main)." [Wishlist,Triaged] https://launchpad.net/bugs/508668
<fabrice_sp> -1 (testing) FTBFS but -1.1 (unstable) don't (was building the pacakge before going to lunch)
<randomaction> We can't sync -1 because we already have -1ubuntu1 ;)
<fabrice_sp> oh right randomaction :-)
<fabrice_sp> I'll update the bug report then ;-)
 * randomaction test-builds opensg. Last build errored out after 3h45min
<fabrice_sp> try to build im-sdk, and you'll see :-D
<kamalmostafa> fabrice_sp: hi Fabrice.  fyi I have corrected the patch for bug 507163 as you rightly suggested -- should be ready to go now.
<ubottu> Launchpad bug 507163 in qtoctave "qtoctave FTBFS: build requires "Qt version 4.5"" [Undecided,In progress] https://launchpad.net/bugs/507163
<fabrice_sp> kamalmostafa, I've seen that. I've just working on it ;-)
<fabrice_sp> (it should be ok, as it's an easy fix)
<kamalmostafa> fabrice_sp: now *that* is quick service!  :-)   thanks!
<fabrice_sp> lol
<fabrice_sp> Thanks to you to work on it ;-)
<fabrice_sp> by the way: remember to update the maintainer field ;-)
<kamalmostafa> did I miss that for the qtoctave fix?  oops!
 * kamalmostafa rushes off to go double-check the other three merges in the queue
<fabrice_sp> lol
<fabrice_sp> and also, to close the bug report in the changelog entry ;-)
<kamalmostafa> wow, i must have forgotten to have a cup of coffee before doing that one!
<fabrice_sp> :-)
 * fabrice_sp is test building qtoctave right now)
<kamalmostafa> And I see that I forgot update-maintainer on one of of my other merges also...  I'll fix it.
<fabrice_sp> ok
<fabrice_sp> is anyone using piuparts to check the 'instalability' of an upload before uploading?
<fabrice_sp> it fails in most packages because it fails to install the packages in the right order (lib before -dev,, for example)
<kamalmostafa> fabrice_sp: Okay my three pending u-u-s merge requests are all 'update-maintainer'ed and 'changelog-LP'ed (after fixing one!).   FYI, the 'inteltool' and 'clxclient' FTBFS fixes are trivial changes.   The other one at the top of the queue (bug 208913) has been pending for 8 days -- any guess why it might be so delayed?
<ubottu> Launchpad bug 208913 in aprsd "aprsd crashes when someone logs in from network amd64" [Undecided,Confirmed] https://launchpad.net/bugs/208913
<fabrice_sp> kamalmostafa, I've tried aprsd yesterday, but was unable to reproduce the pb
<kamalmostafa> I can help you reproduce it if you'd like.  I'm quite familiar with the package and this problem.
<fabrice_sp> oh really?
<fabrice_sp> yesm, then: I installed the package yesterday, stated it, but didn't find any port to 'use'
<kamalmostafa> yes, it is a ham radio package -- I have used it for years (on and off)
<fabrice_sp> :-D
<kamalmostafa> i'll uninstall my fixed version here, and we can walk through it if you wish.
<fabrice_sp> ok
<kamalmostafa> just a moment -- i'll push my running installation of aprsd off to the side here...
 * fabrice_sp installes again aprsd in his test chroot
<kamalmostafa> fabrice_sp: ok, i am ready when you are.  FYI, aprsd listens on several tcp ports for various programs which can connect to it.  One such port is "14500".  Clients which speak its protocol connect to 14500 and log in to aprsd by sending a text line like "user foobar pass whatever".   On 64-bit platforms (only) aprsd crashes while parsing the "user ..." line.   We will start aprsd manually from the cmdline, then connect to it wi
<kamalmostafa> fabrice_sp:  Oh, and you *are* using a 64-bit platform here, right?  Bug doesn't manifest on 32-bit.
<fabrice_sp> yeah: amd64 here
<kamalmostafa> ok, if aprsd is already running, kill it, then start just "aprsd" from the command line (no arguments).
<fabrice_sp> kill'd
<randomaction> fabrice_sp: re im-sdk, I think that correcting format strings may fix that segfault
<fabrice_sp> randomaction, I saw that Debian claimed to have fixed the issue. Didn't had time to actually really check the Debian version
<fabrice_sp> kamalmostafa, aprsd running
<kamalmostafa> fabrice_sp: assuming aprsd is running (blocked), start another terminal and run "telnet localhost 14500" and type "user foo<ENTER>"
<kamalmostafa> (Note there will be no character echo to the telnet session when typing "user foo<ENTER>")
<kamalmostafa> aprsd crashes with segfault
<fabrice_sp> ok
<fabrice_sp> reproduced
 * fabrice_sp will now test build your version
<fabrice_sp> by the way: just uploaded qtoctave
<kamalmostafa> note also that a *remote* user can also crash your aprsd this way -- aprsd binds to all network interfaces -- so this exposes aprsd to being killed by any remote user at any time.
<fabrice_sp> this program is 7 years old, right? (from 2003)
<kamalmostafa> yes, its getting pretty long in the tooth, but it is used very widely in the ham radio community.
<fabrice_sp> ok
 * kamalmostafa goes for more coffee (brb)
<geser> I once looked at this merge proposal (aprsd) and it wasn't obvious for me why it fixed it (and it didn't happen on ia32). Do you know why it crashes on amd64 but works on i386?
<randomaction> it assumes that pointers can be converted to ints
 * fabrice_sp is looking for the definition of size_t in amd64
<geser> is probably a signed long (64bit)
<kamalmostafa> size_t is unsigned.    ssize_t is the signed variant.  And yes, its' 64-bits wide on a 64 bit machine.
<kamalmostafa> geser: Hi geser.  Yes, I do understand it --  well... I did when I debugged and fixed it a couple weeks ago anyway ;-)   As I remember it, the problem is all about the value 'npos', which is getting used (poorly) as a sentinel value.
<geser> right
 * geser googles the definition of string::npos
<kamalmostafa> Looking at the diff in the merge request, see src/servers.cpp at line 967:    ifÂ ((Â rcÂ !=Â string::npos)     That broke when 'rc' was declared to be only 32-bits wide, since npos will be 64-bits wide on a 64-bit system.   Bottom line is that all the "string index" variables need to be 64-bits wide to match what's happening in the string::npos class.
<kamalmostafa> It all made much more sense in 'gdb'  ;-)
<geser> now I understand the problem (and the fix): comparing an unsigned variable of 32bit and 64bit (both set to '-1') doesn't really work
<kamalmostafa> geser:  yes, exactly.
<kamalmostafa> fundamentally, the problem (in my opinion) is the poor design choice to use -1 as the sentinel value at all here, but that's not aprsd's fault.  :-)
<fabrice_sp> in 2003, amd64 was not so frequent
<geser> kamalmostafa: a small hint: if your changelog entry was a little more verbose than "fix crash" it would be easier to understand what's exactly the problem and why it fixes it
<kamalmostafa> geser:  point well taken... this one certainly did warrant more explanation than I provided!  I'll be more verbose next time.
 * fabrice_sp just uploaded the patch
<fabrice_sp> kamalmostafa, for bug 508633, I prefer to wait for Debian, as the fix just consists in not having it built for this arch
<ubottu> Launchpad bug 508633 in inteltool "inteltool FTBFS on !x86 archs" [Undecided,Confirmed] https://launchpad.net/bugs/508633
<fabrice_sp> so better autosync the package when it get fixed in Debian (instead of diverging now)
<kamalmostafa> fabrice_sp: that's fine with me regarding inteltool.   The amd64 and i386 packages still get uploaded anyway (despite the build failure for all other platforms), correct?
<fabrice_sp> yes
<fabrice_sp> it FTBFS in arch where the package is of no use
<geser> should it be also added to P-a-S?
<kamalmostafa> geser: the package hasn't yet been fixed in Debian -- they're just talking about it.   don't we only subscribe p-a-s when its ready to be sync/merged from debian?
<fabrice_sp> geser, it would make sense, yes
<fabrice_sp> kamalmostafa, p-a-s are not archive admin :-D
<geser> kamalmostafa: P-a-s: Packages-arch-specific
<geser> see https://edge.launchpad.net/packages-arch-specific (and its branch)
<kamalmostafa> geser: okay, thanks.  I thought p-a-s was something else altogether.
<kamalmostafa> i will subscribe p-a-s to this.
<fabrice_sp> geser, dose it makes sense to update the ubuntu p-a-s branch? Or better wait for Debian?
<kamalmostafa> i see that p-a-s is a project, not a team, so I cannot subscribe p-a-s to the bug.  I'll leave it to you folks to handle.
<geser> hmm, I'm not sure if limiting the Architecture field is enough or if soyuz will try to build it anyways (until it's listed in P-a-s). Will have to ask soyuz people and/or buildd admins
<kamalmostafa> geser: Just limiting Architecture: as I did made it work properly in my PPA test...  On Karmic, I made a "no-change" PPA and it built for (i386,amd64,lpia) -- but after my change, the PPA only built for (i386,amd64).    (I had to use Karmic to do this test, since Lucid PPA's only build for i386 and amd64 anyway).
<ScottK> geser: Limiting the architecture field works.
<geser> ok
<fabrice_sp> do we support upgrade path from dapper?
<Laney> to hardy
<fabrice_sp> but not to lucid, then. Thanks!
 * fabrice_sp will ddrop an ubuntu change for obsolete :-)
<kamalmostafa> fabrice_sp and geser:  Thanks for all the help.  Question about the aprsd crash...  Might it qualify for an SRU, given the denial-of-service exposure that any remote use can crash it trivially?
<kamalmostafa> s/remote use/remote user/
<fabrice_sp> kamalmostafa, not sure: it's only amd64 and it has been known for almost 2 years . I would say it can wait 3 month :-)
<kamalmostafa> fabrice_sp: Okay, got it.  Thanks again!
<hakaishi> Hi folks! Anyone up to review qt-shutdown-p? It is a small program to shutdown the computer. It uses qdbus to send a shutdown request to the session manager or to HAL or alternatively uses sudo shutdown -P now. http://revu.ubuntuwire.com/p/qt-shutdown-p
<doctormo> How can I get my application to appear in the add/remove software center?
<randomaction> Can a developer's @ubuntu.com address be listed in Maintainer field? (update-maintainer script is refusing to alter it)
<fabrice_sp> randomaction, shouldn't be, as the mailing list if the official maintainer address
<fabrice_sp> In this case, you should update it by hand
<randomaction> ok
<randomaction> thanks
<geser> it's allowed
<geser> if the dev wants to be the contact then he can put himself in maintainer
<hakaishi> How can I add an image for a program in synaptic?
<geser> therefore the scripts checks on @ubuntu.com and not the list address
<doctormo> Hmm, older guides say to use X-AppInstall-Package in a .desktop file and put it in /usr/share/app-install/desktop/ but that doesn't make sense, how does it get in there.
<ajmitch> morning
<randomaction> I think I'll leave it as it is then
<geser> doctormo: you might need to look how app-install-data gets build (and where it pulls its data from)
<doctormo> geser: I think that what I want is not possible.
<Quintasan> Hello
<geser> Hi
<sebner> hola geser :D
<geser> Hi sebner
<dhillon-v10> Quintasan, hi :) did you close that bug we were working on the other day
<dhillon-v10> geser, hi :)
<Quintasan> dhillon-v10: hmm you mean that KVM thingy? well the MALLOC something variable helped but it's a veeeery dirty hack I think
<dhillon-v10> Quintasan, true :) so how are we going to solve it, or should we wait until nixternal find some time and help us out with it
<Quintasan> dhillon-v10: he got the exacly the same error, I expect his backtrace to be a little bit different though :)
<dhillon-v10> Quintasan, ahh yes, he reported that bug :) I guess we can wait for sometime and see if upstream kernel does something about glibc
<crimsun> geser: were you working on merging fuse from Debian testing?
<geser> crimsun: yes, bug #506958 (awaiting sponsoring)
<ubottu> Launchpad bug 506958 in fuse "Merge fuse 2.8.1-1.1 from Debian testing" [Undecided,New] https://launchpad.net/bugs/506958
<crimsun> geser: thanks, looking now
<ianto> Hello,  does anybody know the name of the command line application which searches whether or not a package exists in the Ubuntu and Debian repos and their version number?  Auto searches both sets of repos and it isn't apt cache.
<and`> ianto: rmadison packagename
<crimsun> note that it doesn't "auto [search] both sets of repos"
<chashall> hello maco are you there?
<ianto> and`: That's the one,  thanks :)
<and`> ianto: np
<crimsun> geser: looks good; have you verified that it continues to work on a local lucid system?
<geser> have you any hints how to test it (as I don't know if I use fuse or not), I've checked only so far if the package updates (inside a pbuilder, didn't have upgraded my system at that time yet)
<crimsun> geser: reading from and writing to an NTFS partition, sshfs, etc.
<geser> crimsun: I've restarted to make sure that any device permissions are still correct after a reboot, mounted my windows partition in nautilus and viewed a picture from it and copied a new one to it
<crimsun> geser: all right. I'll do some testing over NTFS and ssh this evening, then upload if no one has reservations/beats me to it. Thanks very much for looking at it!
<geser> and building zfs-fuse works too (it's in DEPWAIT on a newer libfuse-dev)
<ScottL> i've been packaging a new app (nedko's zynjacku and lv2rack) for the ubuntu studio devs and am having trouble getting the menu entry in the audio submenu on the ubuntu studio menu
<ScottL> i can get it in the audio/video menu but not into the audio submenu
<ScottL> anyone have any suggestions or ideas?
#ubuntu-motu 2011-01-10
 * Quex01 np: Johnny Rebel jr. - Ship those Niggers back [02:00]
<Quex01> BATH IN NIGGER'S BLOOD
<JontheEchidna> !ops
<ubottu> Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds!
<Quex01> AFRICA IS FOR APES, EUROPE IS FOR WHITE!
<Quex01> GARBAGE JUICE! SALMANELLY!
 * Quex01 np: Public Enemy - Anti-Nigger Machine [03:17]
<Quex01> hinnger i hate your face
<Quex01> NIGGERS ARE LIKE SALMANELLI !!! GARBAGE JOUCE!
 * Quex01 np: JEWTHANASIA (DEN) - 13. White Pride â JEWTHANASIA (DEN) [02:48]
 * Quex01 np: German Military Marches - Eger [02:40]
<nigelb> thanks elky ;)
<MTecknology> So... A package went from nginx to nginx-light, nginx-full, and nginx-extras; the three new packages replace each other; nginx became a dummy package to select nginx-full; I'm having some troubles though. Any help with getting it to work right?  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609254
<MTecknology> I know it's a debian question- but they seem to all be sleeping over there
<MTecknology> the best I can come up with is adding to nginx-* s/Conflicts/Replaces:/ and to nginx Replaces: nginx (<< 0.8.54-1) Breaks: nginx (<< 0.8.54-1)
<\sh> happy new year :)
<\sh> siretart: can you approve me for ubuntu fai team again? I'm expired ;)
<\sh> siretart: merci :)
<udienz> Hi, what happen with LP? LP send me a lot of bug emails that linked to debian bug
<udienz> a lot of status changes
<shadeslayer> i have a main package that needs sponsoring ...
<shadeslayer> currently building here : https://launchpad.net/~rohangarg/+archive/experimental/+builds?build_state=building
<shadeslayer> oh crap ... forgot something
<lfaraone> tumbleweed: T&S sent. this is the longest section, so feel free to send me part of it if you can't do it all in one sitting :)
 * Laney accidently destroyed ~90% complete T&S replies
<Laney> twice
<tumbleweed> heh
<tumbleweed> lfaraone: thanks
<Laney> Isn't NM fun!
<lfaraone> Laney: barrels. at least he's got a responsove AM.
<lfaraone> ;)
<Laney> I've actually done T&S (yesterday), but he doesn't seem to have updated the website
 * tumbleweed gets a cup of coffe and sits down to it (not like I was going to get any more work done today, anyway)
<lfaraone> tumbleweed: what's your day job, anyway?
<dholbach> good morning
<lfaraone> away
<tumbleweed> dholbach: hi. I see you don't own the ubuntu-sponsoring branch any more. Can we just land merges in it, or do you need to bzr pull on the other side? Also, can it be upgraded to 2.0?
<dholbach> tumbleweed, pull on the other side, but that could be automated, I guess
<tumbleweed> lfaraone: student (who really needs to work on my thesis more...)
<dholbach> tumbleweed, still I think we should be still using merge proposals
<dholbach> tumbleweed, hum... upgraded - let me see
<geser> dholbach: good afternoon :)
<dholbach> hi geser
<dholbach> geser, in Dallas this week :)
<tumbleweed> dholbach: great, as long as you are still reviewing & landing merges on it, that's really what matters.
<geser> figured it out by now, wondered why IRC is so quiet today
<dholbach> tumbleweed, I think if somebody in ~ubuntu-dev reviews and merges it, that's totally cool with me - that's why I moved the branch
<tumbleweed> ok, but until there's automatition, you'd probably be involved
<ari-tczew> hello all
<dholbach> tumbleweed, I'll try to have a look at the open merge proposal later on, but it'll be a busy day
<dholbach> tumbleweed, branch should be updated now
<lfaraone> tumbleweed: heh. I myself have midterms this week :P
<coolbhavi> hello ari-tczew
<coolbhavi> dholbach, hello
<dholbach> hi coolbhavi
<ari-tczew> hi
<tumbleweed> dholbach: thanks, no rush
<dholbach> tumbleweed, bdrung is on it
<tumbleweed> indeed
<bdrung> dholbach: merged. you can pull it.
<dholbach> done
<bdrung> thanks
<al-maisan> hello there, if I want to start a python using dh_make should I specify "single binary" or "indep binary"?
<al-maisan> s/python/python package/
<tumbleweed> al-maisan: indep for pure Python, single binary for python extensions (C, C++, pyx, etc.)
<al-maisan> thanks tumbleweed !
<directhex> ttx, i like the sound of your fosdem talk. which day is that on?
<al-maisan> I am trying to package a python extension with a cpp file that needs to be compiled; when I build the new package in pbuilder I get the following error:
<al-maisan> dev
<al-maisan> sorry:
<al-maisan> src/geohash.cpp:72: fatal error: Python.h: No such file or directory
<al-maisan> I guess I need to require python-dev
<geser> yes, perhaps even python-all-dev if you want to compile for all supported python versions
<al-maisan> geser: thanks, will try that.
<al-maisan> geser: that would be a "Build-Depends:" entry. Right?
<geser> yes
<al-maisan> great, thanks!
<ttx> directhex: saturday, 3:30pm I think
<ttx> directhex: http://wiki.debian.org/Java/DevJam/2011/Fosdem/TalkSchedule
<ttx> It's actually a trilogy.
<directhex> oh dear, i hope it doesn't clash
<directhex> i've got my talk "Mono packaging in Debian and Ubuntu - why we're always right" on saturday
<directhex> you might enjoy it
<ttx> haha
<iulian> directhex: Good one. :-)
 * iulian cannot go to fosdem unfortunately. :(
<kklimonda> now that's irritating - I can't create a pbuilder maverick chroot under natty
<kklimonda> my pbuilderrc: http://pastebin.com/H43MKA2B
<kklimonda> I run sudo DIST=maverick pbuilder --create
<tumbleweed> kklimonda: sudo -E DIST=maverick pbuilder --create :)
<kklimonda> let see if pbuilder-dist works better
<kklimonda> tumbleweed: no, I use sudo without -E for a reason
<kklimonda> it should work - it did in the past
<kklimonda> (I've had CC=clang for some time, and it did propagate to pbuilder chroot breaking builds ;) )
<tumbleweed> kklimonda: sudo's configuration file changed in natty to include env_reset, which means sudo pbuilder will use HOME=/root
<kklimonda> tumbleweed: oh..
<kklimonda> (no wonder my hooks didn't work)
 * kklimonda feels tired
<tumbleweed> heh
<ari-tczew> geser: could you rerun FTBFS script? a lot of packages are deprecated
<micahg> ari-tczew: Last update 2011-01-10 20:14:22 +0000
<ari-tczew> micahg: so there is another problem
<geser> ari-tczew: which one? and I don't have access to the machine where the scripts run
<ari-tczew> geser, micahg: nevermind, my bad
<ari-tczew> geser: another question: is it possible to rebuild all packages in universe which are on FTBFS page? buildlogs are deprecated
<ari-tczew> mass give back IIRC
<geser> ari-tczew: what you mean with "deprecated"? just old?
<geser> do you have a reason why you think they'll build now?
<ari-tczew> geser: I mean that now there is new FTBFS message
<geser> new FTBFS message? I seem to lack some context
<ari-tczew> geser: well, e.g. builder on LP has got buildlog from 01.11.2010 and it shows that there is problem with DSO linking. now if I build this package, I see another FTBFS message
<ari-tczew> I guess it's not hard to gotcha
<tumbleweed> ari-tczew: lucas just did a rebuild a couple of days ago. Not recent enough?
<geser> ah
<ari-tczew> tumbleweed: we discuss about FTBFS geser's script
<geser> ari-tczew: only buildd admins can do mass-give backs as far as I know
<geser> you can only click on the retry buttons of every package (or use the ubuntu-build script)
<micahg> ari-tczew: just look at lucas's rebuild result if you want to know what's more current
<ari-tczew> micahg: you don't understand. I mean that if someone looks on FTBFS geser's script, buildlogs show deprecated output.
<ari-tczew> it's not good.
<tumbleweed> ari-tczew: doing a mass give back just to get new buildlogs seems a bit crazy. If they aren't going to build, why rebuild them. The same issues are presumably present.
<tumbleweed> ari-tczew: you are misusing the word "deprecated"
<micahg> ari-tczew: that's standard fare for that page though
<ari-tczew> tumbleweed: the reason is working on correct FTBFS issue
<ari-tczew> now I have to build locally current existing package in archive
<tumbleweed> ari-tczew: I don't know about you, but I test build locally before I start working on an FTBFS
<ari-tczew> before any patching
<ari-tczew> no sense
<ari-tczew> it's not efficient
<tumbleweed> mass giving back just for fresh build logs isn't efficient either
<micahg> sure, there is, it might have been fixed, also sometimes it's easier to fix when you can see what's happening where it fails
<tumbleweed> (plus, you can play around in pbuilder, if you have a shell hookscript, and try a few fixes)
<geser> the FTBFS page only displays the current state of the archive, if the last build-attempt is from Nov 2010 than the page displays it, it can't do retries on it's on now and then to keep the logs "current"
<ari-tczew> ok you like wasting a time on pbuilder before patching, I don't want still discuss in no sense
<geser> you prefer to waste the buildd time?
<ari-tczew> it's machine
<ari-tczew> I'm human
<micahg> ari-tczew: yes, but those resources are shared by everyone
<ari-tczew> I only see that contributors are for machines, not machines for us to make work easier
<tumbleweed> ari-tczew: plus, as I said earlier, there are newer build logs available (lucas' rebuild)
<lucas> I agree with ari-tczew. contributor time is infinitely more valuable than cpu time
<micahg> is there room in the /topic for the new rebuild results?
<geser> ari-tczew: talk to the buildd admins if you want regulary mass-givebacks, they are in a better position to implement it (if they think that's a good idea)
<ari-tczew> tumbleweed: so this way I have to spend more minutes on looking also on lucas page udd
<ari-tczew> geser: who is admin of buildd?
<ari-tczew> where can I find them admins?
<tumbleweed> ari-tczew: I don't think it would take you *that* long. Personally I have no issue with stale logs, and I tend to test that a package can be built locally before giving it back.
<ari-tczew> tumbleweed: look from another hand
<ari-tczew> ok, you will notice that there is new FTBFS message
<ari-tczew> this information will stay only on your mind
<geser> ari-tczew: https://launchpad.net/~launchpad-buildd-admins
<ari-tczew> another day, another contributor will have a look on geser's FTBFS page
<tumbleweed> I seem to remember someone suggesting not sending FTBFS messages to uploaders from failed give-backs, but rather to the requster - that'd help
<ari-tczew> and he will be confused, because there is another FTBFS message!
<ari-tczew> what's going? - he thinks
<micahg> ari-tczew: as I said, that's standard fare for any buildd log failure
<ScottK> tumbleweed: That was me.  Someone should file a bug on LP about it.
<micahg> they should be taken with a grain of salt since new uploads could've changed the failure
<ari-tczew> micahg: I don't understand your words.
<ari-tczew> what's your point, quo vadis..
<micahg> ari-tczew: you'd have to constantly rebuild to have up to date logs
<ari-tczew> because they should be updated
<ari-tczew> flow of information
<ari-tczew> masacre, developers couldn't understand this thing
 * Rhonda suspects that ari-tczew is discussing now way longer (and using the resources of the others involved in the discussion) than the test build would had taken.
<ari-tczew> Rhonda: this is not a case of one package
<ari-tczew> and there is another point of discussion - who is more important - server or contributor's time?
<ari-tczew> and I see that a lot of people here prefer to wasting contributors time
<ari-tczew> maybe servers will take merges and FTBFS' fixes?
<Rhonda> No, that's not what lot of people her prefer nor did actually state. It would be nice if you'd not put words in other people's mouths.
<ari-tczew> It would be nice if you'd take off slippers from your eyes.
<Rhonda> Don't have any there, sorry to disappoint you.
#ubuntu-motu 2011-01-11
<highvoltage> u/join #weirdos
<ebroder> Somebody's been reading the blogs :-P
<stalcup> what's a blog?
<ari-tczew> bdrung: interesting case. update-maintainer from daily u-d-t couldn't work: update-maintainer: Error: No Maintainer field found in ./debian/control.
<ari-tczew> bdrung: get source of seahorse-plugins from Debian unstable and check it
<bdrung> ari-tczew: if you want to help, file a bug report and distillate a testcase (ubuntutools/test/test_update_maintainer.py)
<ari-tczew> bdrung: how can I run it?
<bdrung> ari-tczew: bug confirmed
<ari-tczew> (sorry for my lack of knowledge)
<bdrung> ari-tczew: build the package and see what is done.
<ari-tczew> bdrung: which package?
<bdrung> ari-tczew: ubuntu-dev-tools
<bdrung> the test are run on build
<bdrung> s/test/tests/
 * bdrung is currently very busy.
<ari-tczew> still confused
<ari-tczew> bdrung: do you need reported bug?
<bdrung> ari-tczew: either file a bug or propose a bzr branch merge that add a testcase which tests this issue
<ari-tczew> bdrung: I'll report a bug
<dholbach> good morning
<ari-tczew> hello dholbach
<ari-tczew> maco: should we forward your patch to Debian? bug 345727
<ubottu> Launchpad bug 345727 in seahorse-plugins "Seahorse-agent writes an empty ~/.gnupg/gpg.conf on first run, breaking email signing in KDE" [Medium,Confirmed] https://launchpad.net/bugs/345727
<nigelb> Laney_: people seem to walk into that channel and then leave :p
<nigelb> Laney_: (you know the one where you entered and said ':O' and left :p)
<Bachstelze> #ubuntu ?
<ari-tczew> maybe he was excited of number of developers in one place
<Bachstelze> that's what I feel like saying every time I go there
<Laney> nigelb: :P just wanted to see if it still existed
<nigelb> Laney: hehe
<nigelb> Laney: me and jonathan are trying to make it cool to hang out there ;)
<evaluate> dapal, ping?
<dapal> evaluate: pong, will look at the package later tonight :)
<evaluate> dapal, just wanted to let you know that I just had a look at the installation again, and it throws me a bunch of errors right now...
<dapal> ah :)
<evaluate> not sure why though, the first time it worked really fine...
<dapal> take your time to fix/look at it then, there's no hurry :p
<dapal> (and I'm a bit busy too)
<evaluate> ok, I will let you know if/when I find the issue
<Laney> look! a hanska!
<dapal> eeeek!
<evaluate> dapal, hmm, it seems that the script also uses some custom smarty stuff, so I guess I can't use the shared smarty library after all...
<dapal> uhm :/
<evaluate> so I'd either have to use the smarty lib they supply or create some patches so that it works with the shared one (if this is even possible -- I will have to look at it), but I think the first one would be much better IMO
<dapal> I agree
<dapal> if you can, make a diff between the customised smarty and the system one, just to understand what's different
<dapal> maybe the system one could be patched
<evaluate> dapal, thing is that they don't use the current smarty version that is in debian. they use 2.6.25 and debian has 2.6.26
<dapal> ah
<dapal> if the difference is only in the version, maybe you could try to patch CMS
<dapal> for simplicity, you could just leave the code there though
<evaluate> dapal, well, from what I can tell, they expect different function names from smarty. let me paste you something real quick
<evaluate> dapal, http://paste.debian.net/104313/
<Bachstelze> is there a standard procedure to request a sync? bug 694387 is fixed in a newer Debian version
<ubottu> Launchpad bug 694387 in wvdial (Ubuntu) "FTBFS in Natty" [Undecided,New] https://launchpad.net/bugs/694387
<Laney> !sync
<geser> Bachstelze: requestsync from ubuntu-dev-tools
<ubottu> Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess
<evaluate> dapal, also, it seems that the file that contains the different code gets loaded directly from the smarty core file, so I can't actually tell the shared smarty librari from debian to load my custom file, because it loads the default one automatically.
<dapal> evaluate: ok ok, keep the embedded one
<evaluate> dapal, btw, setting the permissions in the rules file doesn't seem to work...
<evaluate> dapal, finished and uploaded the new package. Whenever you've got time :-)
<hrw> hi guys
<ari-tczew> hi hrw
<kklimonda> ugs, update-maintainer takes 7 seconds to replace two lines..
<kklimonda> heh.. it runs rmadison underneath..
<kklimonda> bdrung: does it really make sense to make update-maintainer handle all cases under the sun? runnig rmadison twice makes it really slow, and the reason for that is apparently preventing developers from shooting themselves into feet
<ari-tczew> kklimonda: which u-d-t do you use? from archive or daily?
<kklimonda> ari-tczew: from archive
<bdrung> kklimonda: 7 seconds? it runs rmadison?
<udienz> Hello, dep5 have rev 155 can i used it now for new packages for Ubuntu?
<kklimonda> bdrung: the version for natty does
<ari-tczew> udienz: sure
<bdrung> kklimonda: natty still have the pre-rewritten u-m. please use https://launchpad.net/~udt-developers/+archive/daily until the next release of udt
<bdrung> real	0m0.048s
<kklimonda> bdrung: will do
<micahg> txwikinger: ping
<txwikinger> micahg: pong
<micahg> txwikinger: could you please look at bug 684510 re ichthux-meta
<ubottu> Launchpad bug 684510 in sword-language-packs (Ubuntu) "Remove sword-language-packs(BS) and ichthux-live(B) from Ubuntu" [Undecided,New] https://launchpad.net/bugs/684510
<txwikinger> micahg: ok.. I do
<micahg> txwikinger: thanks
<txwikinger> micahg: Yes.. I think the package should be dropped.. it is not needed
<txwikinger> You want me to write a comment into the bug report?
<micahg> txwikinger: the meta package or the binary?
<udienz> ari-tczew, when we must send a patch wih 'submittodebian'? if a patch apllied in debian packages or whan a patch has works well?
<ari-tczew> udienz: if it's non ubuntu specific, then forward.
<ari-tczew> udienz: btw. submittodebian is no only way
<ari-tczew> udienz: I'll comment your application tomorrow
<ari-tczew> udienz: or later if deadline is not tomorrow
<txwikinger> micahg: which meta package?
<micahg> txwikinger: ichthux
<txwikinger> no. ichthux should stay
<udienz> ari-tczew, i don't know it's a patch is ubuntu spesific or not. i mean a patch works if used debian experimental
<txwikinger> I will modify it to take out the sword language packages
<udienz> ari-tczew, aha thanks... feel free to comments when you free
<ari-tczew> udienz: "used debian experimental" - can't gotcha
<ari-tczew> what does it mean?
<micahg> txwikinger: great, thanks, let me know if you need a sponsor
<txwikinger> ok.. thanks micahg
<udienz> ari-tczew, i mean in debian ustable a packages works well by "dpkg-buildpackage" but not in debian-experimental
<udienz> i use gcc-4.5 and binutils-gold
<ari-tczew> udienz: how do you testing packages to get build?
<udienz> ari-tczew, yes, always. minimum 3 times, building via dpkg-buildpackage, pbuildr and ppa
<udienz> *pbuilder
<udienz> just make sure this package have bug
<lfaraone> tumbleweed: sent off your report to the front desk, they'll check it and send it along to DAM, who will say "yes", and tell DSA to create you an account.
<ari-tczew> udienz: if you're working of fix ftbfs with binutils-gold/gcc4.5 you don't need to sending every package to PPA. pbuilder natty is enough.
<ari-tczew> udienz: and one time is enough.
<ari-tczew> another case if you do: build package -> update pbuilder -> build package once again - that's fine then
<bdrung> tumbleweed: do you want to become uploader of u-d-t once you are DD?
<udienz> fixed bug 701476
<ubottu> Launchpad bug 701476 in stardict (Ubuntu) "[FTBFS] Source stardict 3.0.1-7 in natty" [Undecided,Confirmed] https://launchpad.net/bugs/701476
<tumbleweed> lfaraone: that was amazingly quick, thanks
<tumbleweed> bdrung: sure, I imagine I'll be involved in it for a while to come
<bdrung> tumbleweed: your merge proposals are still on my todo list.
<tumbleweed> bdrung: good good, I still have some stuff to do for the builders. been busy with NM and other things
<bdrung> tumbleweed: we should do at least one u-d-t release this month
<tumbleweed> yeah, sounds good, otherwise there's way too much untested code
<lfaraone> tumbleweed: hehe, 3 days is unheard of, you're right. but don't worry, they'll have you in the DAM queue for a week at least.
<bdrung> tumbleweed: my NM process took nearly a year. ;)
<lfaraone> bdrung: I was in it for 6 months.
<bdrung> tumbleweed: btw, we should try to create a testcase for every bug that is reported.
<lfaraone> to tumbleweed 's credit, he did apply in October.
<tumbleweed> bdrung: yeah, that's always a good idea (sorry timed out there, dodgy DSL line)
<DktrKranz> bdrung: I think you can even upload u-d-t to unstable this time
<bdrung> DktrKranz: then why did we upload it to experimental?
<DktrKranz> in case we need to fix things before squeeze, but I don't think it'll be the case anymore
<DktrKranz> anyway, it's fine to have it in experimental for another upload too
<ari-tczew> DktrKranz: so, people forgot that Debian isn't yet released?
<lfaraone> ari-tczew: noâ¦ people *can* upload to unstable if they want.
<ari-tczew> aha
<Laney> I imagine Debian will release quite soon, so no need
<DktrKranz> ari-tczew: basically, we didn't upload to unstable to be given the chance to upload fixes straight to unstable instead of targeting t-p-u, now that we're close to release, and there weren't lots of bugs reported, uploading to unstable could be an option
#ubuntu-motu 2011-01-12
<udienz> geser, i took your package (wavesurfer) thanks to mentions on m.u.c
<hyperair> was there a solution to the /usr/lib64/libX11.so.6: could not read symbols: Invalid operation
<hyperair> errors?
<geser> hyperair: what's the line before that? (or pastebin the whole error)
<hyperair> /usr/bin/ld: note: 'XFlush' is defined in DSO /usr/lib64/libX11.so.6 so try adding it to the linker command line
<hyperair> i mean yeah, sure -lX11 should do the trick
<geser> yes
<hyperair> but why isn't that flag included in gtk's .pc file?
<hyperair> running something like ./configure LDFLAGS=-lX11 feels dirty
<geser> why should it when your application uses symbols from -lX11?
<geser> and you shouldn't put -l... to LDFLAGS
<hyperair> er sorry
<hyperair> where should it go then?
<hyperair> LIBS or something?
<geser> LIBS when it's used my the Makefile
<Laney> LDADD?
<hyperair> =\
<geser> or patching the Makefile.am and add it to ..._LDADD
<hyperair> does X11 have a .pc file?
<geser> yes, x11.pc
<hyperair> alright
<kklimonda> hey, any idea if this http://pastebin.com/CpFaWxa9 is still a dfsg-compliant license?
<tumbleweed> kklimonda: sounds reasonable (although it really should include an explicit licence statement of some sort
<Laney> I don't think "MIT style license" means anything
<tumbleweed> it's pretty clear that the author's intention is to let you do what you want, however "not enforcing" doesn't mean "you can"
<kklimonda> tumbleweed: it does below
<kklimonda> tumbleweed: I'm concerned about the second paragraph
<tumbleweed> kklimonda: that refers to contributions submitted to the author, not derivaties in general
<kklimonda> tumbleweed: right - so it's like a copyright assignment without explicit assignment? :)
<tumbleweed> kklimonda: that is copyright assignment, I'd say
<Laney> it's bonkers and he should be notified of the WTFPL
<Bachstelze> but without a meaningful license, so I'd say not DFSG, bit IANdebian-legal
<kklimonda> I guess what's I'm wondering is if it's legally binding - I'm already not entirely sure how would Canonical's copyright assignment hold in the court and this one feels even less substantianal..
<kklimonda> Bachstelze: there is a normal MIT license below
<tumbleweed> kklimonda: copyright assignment is out of the scope of redistributability / DFSG-freeness
<Bachstelze> oh
<Bachstelze> basicalyl the same thing as the old Qt "GPL with exceptions" then
<kklimonda> I guess I should have pasted a whole license instead of the interesting bits: http://pastebin.com/PypEWBZ9
<Bachstelze> "here's the license, and here's how we modify it"
<kklimonda> right
<kklimonda> the copyright assignment has been the only thing I was unclear about :)
<kklimonda> thanks for helping
<manish> I have a small doubt about how to version packages to supersede existing packages
<manish> means so that it makes it an update of the package
<manish> 0.6-0manish2~0ppa1~maverick is lower version than  0.6-0ubuntu2~0ppa1~maverick ??
<manish> right?
<Bachstelze> manish: that would depend what the current version is
<manish> 0.6-0ubuntu1~0ppa1~maverick
<manish> is the current version
<manish> Bachstelze: so is 0.6-0manish1~0ppa1~maverick lower version?
<Bachstelze> manish: % dpkg --compare-versions "0.6-0manish2~0ppa1~maverick" "<" "0.6-0ubuntu2~0ppa1~maverick" && echo "yes, it is lower"
<Bachstelze> yes, it is lower
<Bachstelze> :)
<Bachstelze> because m < u
<manish> ah. Didn't know about this --compare-versions
<manish> yeah, that's what I was thinking
<Bachstelze> but obviouslt you shouldn't rely on it
<manish> but isnt ~ used for version resolution?
<Bachstelze> it's irrelevant, because the difference appears earlier
<manish> if not, then ~ is used for resolution?
<manish> there is a second issue
<manish> Bachstelze: in the .changes file the .orig.tar.gz file is not mentioned
<micahg> manish: FYI, how the version works: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
<manish> I can see in .changes file
<manish> Checksums-Sha1:
<manish>  a9e77d01398045b64d6108bc9e01463cb1a9c171 1690 zeitgeist_0.6-0ubuntu1~0ppa2~maverick.dsc
<manish>  b37853ce4adda8605d7fd56ea6843b4c55cd0243 4501 zeitgeist_0.6-0ubuntu1~0ppa2~maverick.debian.tar.gz
<manish> there is no mention of .orig.tar.gz so dput doesnt upload the orig tarball
<Bachstelze> yes
<manish> and the build system rejects the upload
<Bachstelze> you need to build it with -S -sd if you want to include the source tarball
<Bachstelze> (or is it -sa ?)
<Bachstelze> I can never remember
<manish> let me try
<Bachstelze> it's in the PPA help pages on LP
<geser> -sa (a like all), -sd is diff only
<manish> Bachstelze: geser I tried -sa works :)
<dapal> evaluate: tonight I hope to give a look to CMS ;)
<evaluate> dapal, whenever you have the time. I'm pretty busy myself this week, so I didn't have much time to test it properly either, but I hope I can take some time in the weekend to review it again and maybe fix some more problems if I (or you) can spot any...
<dapal> evaluate: ah. I have an exam next week -- better if I delay it altogether then :)
<dapal> evaluate: so, back to my books now :/
<evaluate> ok. good luck! :-)
<evaluate> dapal, also, I've put my eyes on another program that I'd find interesting to package, so I'll keep you busy for a couple more weeks :p
<dapal> evaluate: sure, what is it?
<evaluate> dapal, it's called bbclone (www.bbclone.de), it's a counter/statistics software for websites. I use it on all of my sites actually...
<dapal> ah, I don't know it. Seems like you're interested in web-app packaging :)
<evaluate> not necessarily, I just thought about these because I use them myself. btw, I just noticed that bbclone seems to be in stable already. Any idea why it isn't in testing/sid though?
<dapal> maybe it was removed.. let's see
<dapal> evaluate: it's been removed in July 2010
<dapal> evaluate: ROM; dead upstream, license issues, low popcon
<evaluate> dapal, I don't know what ROM is, but the latest update was done at "Sat, 01 Jan 2011 00:07:03 +0100", so upstream is far from dead, and the project is licensed under GPL3, so I don'tsee how that can pose any issues...
<dapal> evaluate: Request Of Maintainer
<evaluate> uhum
<dapal> evaluate: yes, I was looking at the website. Maybe it included some problematic thing, at the time
<dapal> evaluate: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590332
<dapal> ah, icons
<dapal> evaluate: I'd say that, if you're able to cope with the icons issue (if it still holds), you could just get the old package from stable, and continue from that one
<dapal> evaluate: so we also preserve the package history
<evaluate> hmm. I'll have a closer look at this. I'm interested in the package anyway and I also thought about sharing some patches with upstream...
<evaluate> btw, I just had a quick look at the local copy of the package that I have and I can't see any separate license for the images, so I'd guess they are also GPL3...
<dapal> it's better if you ask upstream :)
<evaluate> or I guess I could talk to the former maintainer of the package, maybe he could tell me what the actual problems with the icons were...
<dapal> :)
#ubuntu-motu 2011-01-13
<bdrung> tumbleweed: which is the branch that i should review first?
<stevecrozz> i have a package that i've been maintaining in my ppa for a while, but I need the help of a mentor to whip it into shape so I can propose it be included in Ubuntu's main package repository
<stevecrozz> please send me a message if you are willing to lend a hand or just help me out with some guidance
<Bachstelze> stevecrozz: everything you need is in the packaging guide, if you have questions, just ask here :)
<stevecrozz> Bachsteize: The package is uwsgi and there has been some progress getting it into debian, but I'm not sure if I should follow that or just go my own way
<Bachstelze> stevecrozz: it's generally better to get new packages in Debian first
<Bachstelze> then they are automatically imported to Ubuntu
<stevecrozz> Bachstelze: how do I go about getting the package into debian? are there some other people I should talk to?
<stevecrozz> the technical details of actually creating a package that builds have been sorted out already, i just don't really know where to go from here
<jmarsden> Bachstelze: Debian Import Freeze for Natty was 30 Dec 2010, so packages are not automatically imported from Debian at the moment, you need to request a sync.
<Bachstelze> jmarsden: right, I was speaking in general
<jmarsden> stevecrozz: You may wany to check out http://mentors.debian.net/ and see if you can find a mentor to help get your package(s) into Debian?
<JanC> stevecrozz: if somebody else is already working on getting it in Debian, maybe best to help that person?
<stevecrozz> yeah, its just been really slow, i'm not sure what the holdup is, but I'm trying to resume communication with that person now
<stevecrozz> but i'll try that and check out mentors.debian.net too
<JanC> peopel in Debian might be busy preparing for the new Debian release
<Bachstelze> more info on debian mentoring is here http://wiki.debian.org/DebianMentorsFaq
<tumbleweed> bdrung: syncpackage
<slangasek> RainCT: hi there, I see that you're the primary author of https://wiki.ubuntu.com/MOTU/Packages/REVU/CheckList - can you explain why it says that a 'needs-packaging' bug is a requirement for REVU?
<slangasek> I don't understand why that's a requirement in an Ubuntu context, and don't find it mentioned anywhere else
<RainCT> slangasek: Right, it's not really a requirement. I put it there because it's likely that reviewers will complain about it. Feel free to reword that sentence.
<slangasek> RainCT: ok, thanks :)
<bcurtiswx_> building w/o signing is bzr bd -?S what ?
<dholbach> bcurtiswx_, bzr bd -- -S -us -uc
<bcurtiswx_> dholbach, thanks
<dholbach> after the "--" you can pass any dpkg-buildpackage arguments you like
<bcurtiswx_> dholbach, Ok i'll man dpkg-buildpackage next time .. thx again
<dholbach> no worries
<geser> dholbach: isn't "bzr bd -S -- -uc -us" preferred? so that bzr-builddeb gets the -S
<dholbach> geser, james_w would know
<james_w> geser, there's some ugly code to cope with either
<tumbleweed> bdrung: I am now
<bdrung> tumbleweed: i started to review syncpackage-*
<bdrung> tumbleweed: 1) there are build errors: http://paste.debian.net/104566/
<tumbleweed> aah, so missing build deps I guess (/me builds)
<bdrung> backportpackage: check_call -> show correct error message
<bdrung> (check the return value)
<bdrung> 3) the source package object should gain more functionality: package1.debdiff(package2)
<bdrung> 3b) src_pkg.check()
<bdrung> 4) should pull-debian-debdiff really unpack sources?
<tumbleweed> ok, so that error message, I agree check_call is buggy (putting a list in %s), is that the only issue with it?
<tumbleweed> otherwise, it does theck the return value
<bdrung> instead of using check_call, use call and print a error message if the call doesn't return 0
<tumbleweed> bdrung: check_call in backport package is a local function, not subprocess
<tumbleweed> (well, wraps subprocess.call)
<bdrung> oh
<bdrung> i thought i would be subprocess.check_call
<tumbleweed> yeah, it's confusing :) (blame ebroder :P)
<bdrung> 5) archive.py: "d_source, d_version = os.path.basename(dscfile)[:-4].split('_')" doesn't work (the dsc could have a random name like foobar.dsc)
<tumbleweed> anyway, 3: sounds reasonable. 3b: what does that do? 4: it needs to unpack the package to walk the changelog (well, there we could play tricks here). I basically just copied the existing behavior
<bdrung> 4. ok
<bdrung> 3b: check -> verify
<tumbleweed> right
<bdrung> (for syncpackage)
<tumbleweed> 5. err, yes that is buggy, but there are still situations where we are going to need it, I think
<bdrung> 5. no. we have the dsc file, therefore we can get the information from the file content
<tumbleweed> ok
<bdrung> 6) the example package has a trailing space in d/rules
<bdrung> tumbleweed: 7) can't we generate the test source tarball on test time?
<tumbleweed> 6: yes. 7: yeah, I'm sure I considered this, but I can't think of any decent argumetns against it now.
<ari-tczew> RainCT: now gbrainy 1.6.1 is available ;-)
<Wallch_Developer> Does someone here uses Gnome and have time to review a project?
<ari-tczew> Wallch_Developer: maybe ask in the day @ #ubuntu-desktop ?
<Wallch_Developer>  i am still awake :P... ok i will also ask at ubuntu-desktop :)
<kklimonda> do you have to test software to actually advocate it? If it builds, installs, then there is a pretty good chance that the person who has packaged it also made sure that it works. Especially if the upstream is active and interested in getting package to Ubuntu. If the detailed testing is a requirenment for the package advocacy then getting some niche projects into Ubuntu is going to be nearly
<kklimonda> impossible.
<kklimonda> tumbleweed: are you still working on updating python-musicbrainz2 and packaging beets for debian?
#ubuntu-motu 2011-01-14
<bdrung> tumbleweed: your syncpackage branch make pylint unhappier: Your code has been rated at 9.33/10 (previous run: 9.40/10)
<kklimonda> bdrung: was it because he used the 2 letter variable name of death? ;)
<bdrung> kklimonda: to what do you refer?
<kklimonda> bdrung: to your comment about pylint being unhappy - I've found it, at least with the default settings, a little too prissy
<kklimonda> cd
<tumbleweed> kklimonda: yeah, I must do something about that
<ari-tczew> hello
<ari-tczew> I got an email from Mark Shuttleworth about Condorcet Internet Voting Service - what is it?
<soren> ari-tczew: It says quite clearly in the e-mail, I think.
<soren> ari-tczew: He's soliciting votes for the IRC council.
<ari-tczew> soren: english is not my native, I'd like to making sure before voting.
<ari-tczew> ehh, I don't know anyone from this list.
<Wallch_Developer> At revu.ubuntuwire.com i have seen many projects with this error: Package is for "maverick" but only packages for "natty" are currently accepted. .. My project  ( http://revu.ubuntuwire.com/p/wallch ) is for maverick.. Why i do not have this error? And how i am supposed to make it work with natty?
<ari-tczew> Wallch_Developer: revision should be targetted on natty in d/changelog
<Wallch_Developer> ari-tczew:  yes it says natty.. does this mean that it will work with ubuntu 11.04 Natty?
<ari-tczew> Wallch_Developer: I think so
<Wallch_Developer> ari-tczew: Nice! Ok thanks 8-)
<ari-tczew> Wallch_Developer: You're welcome.
<tumbleweed> Wallch_Developer: REVU is for packages destined for the current development release. For targetting stable releases only, there is a new alternative route https://wiki.ubuntu.com/PostReleaseApps
<Wallch_Developer> tumbleweed: So what am i supposed to do? Upload my project to the link you said? ;-)
<tumbleweed> Wallch_Developer: depends what you want
<tumbleweed> you want to get it into Ubuntu, and contribute to Ubuntu, keep on with the REVU approach. You just want it in the app store, chat to the app review board people
<tumbleweed> at any rate, if you are using REVU, target natty
<Wallch_Developer> tumbleweed: I just want my project to be advocated and next go to Ubuntu software center...
<tumbleweed> Wallch_Developer: REVU is slow, MOTUs have a lot of work to do. (I have looked at your package before, and inted to again) In the meantime, if you want to, help us out, we can always use help.
<Wallch_Developer> tumbleweed: In which way i can help?
<tumbleweed> https://wiki.ubuntu.com/MOTU
<Wallch_Developer> tumbleweed: Ok ! O:-)
<geser> ari-tczew: the voting system is the same as in the last DMB vote
<ari-tczew> geser: ok
<kklimonda> hmm, new voting? can someone tell me the From email for this message? I wonder if it end up in my spam folder ;)
<paultag> :)
<paultag> kklimonda: for the IRC stuff?
<kklimonda> paultag: yeah
<paultag> moment :)
<paultag> Sender: <andru@cs.cornell.edu>
<paultag> Reply-To: mark@ubuntu.com
<paultag> Subject: Poll: 2011 January IRC Council Poll
<kklimonda> hmm, I didn't get it at all :(
<kklimonda> oh well, better that than the malfunctioning spam filter
<paultag> kklimonda: it might take a while, someone else said they did not get it as well
<paultag> that voting system is pretty bad IMHO
<kklimonda> yeah, the mail I got for the previous vote has been in German
<kklimonda> with the really suspicious link pointing to a really suspicious-looking page ;)
<paultag> kklimonda: kannst du etwas Deutsch sprechen?
<kklimonda> my first reaction was "hey, someone's trying to scam me"
<paultag> kklimonda: from some south african, no less
<paultag> ha! I recycled a joke :)
<kklimonda> paultag: I don't really speak (or read) german, but I'm able to distinguish it when I see some german text.
<paultag> kklimonda: ahha, thought you might have that set as your language on LP and it did some voodoo ( which would be cool ), but it sounds like a bug ( wich is totally not cool )
<kklimonda> I'm probably wrong sometimes, and there is some language that looks similar to it but I guess I was right this time ;)
<paultag> ;)
<kklimonda> paultag: I think geser pressed the wrong buttons when he was creating the pool. I do remember him saying something like that soon after receiving the email.
<paultag> Ahhh, right
<paultag> makes sense
<geser> kklimonda: the "problem" was that I had german as my prefered language selected in my browser and the CIVS page used that default also for the mails -> german mails with the english text I put into the webform
<Laney> http://orangesquash.org.uk/~laney/haskell-installability/i386.png SO MUCH RED
<Laney> (warning: large pic)
<geser> nice :(
<Laney> uploaded 6.12.3 â¥
<kklimonda> Laney: they don't believe in stable abi?
<geser> Laney: will ghc6 build on armel?
<Laney> kklimonda: indeed not
<Laney> geser: hope so :'(
 * Laney will look at which libraries need updating for the Haskell platform 2010.2.0.0: help appreciated
<Laney> There are 9 to do (in Experimental): http://paste.debian.net/104618/
<philps> I am making a new package.  My postrm did not have #!/bin/sh (etc) at the top.  It is installed and now can't be removed.  Any ideas
<hyperair> it's in /var/lib/dpkg/info/$pkgname.postinst
<hyperair> edit it, add a #!/bin/sh there
<philps> okay thanks
<hyperair> and then uninstall it
<philps> yep.  understood
<philps> thank you so much!
<hyperair> philps: but if that really happens in a real life scenario, shipping a new postinst should do the trick. dpkg tries the new postinst, iirc
<hyperair> or was it the postrm
 * hyperair shrugs
<philps> yeah, it is actually a postrm
<philps> which it does not try the new one.  tried that
<philps> err, prerm
<philps> it is always amazing how useful IRC is.
<micahg> \sh: sorry, didn't get to zf this week, will get to it sunday hopefully
<\sh> micahg: take your time :)
<micahg> \sh: and dojo 1.5.0 is packaged now, so I can throw that in as well
<hakermania> Hey guys, which is the command to execute everything in "debug mode"? it's something like 'dpg command' but not exactly...
<Rhonda> dbg
<Rhonda> gdb
<hakermania> Rhonda: Thx! At last!
<Rhonda> I don't know wether it will really help you. Usage isn't easy, and from those that know how to use it I guess they should be able to remember its name (gdb == GNU DeBug)
<hakermania> Rhonda: I've used it again in the past, thx
#ubuntu-motu 2011-01-15
<Laney> once again I long for dw and nmu in Launchpad :'(
<geser> "dw"?
<Laney> depwait
<Laney> so I could schedule the haskell rebuilds now without worrying that it's not finished on armel yet
<geser> if you build-depend on the new ghc6 then the builds get into depwait
<Laney> of course, but that requires changing every package
<geser> is the Debian buildd "more" clever in this regard?
<Laney> it has this 'dw' support
<geser> so you can tell it to wait till a previous binnmu is done?
<Laney> dw libghc6-mtl-dev . armel . -m 'ghc6 (>= 6.12.3-1ubuntu2)' or similar
<Laney> will add a depwait with that constraint
<geser> nice
<tumbleweed> filed an LP bug? :)
<geser> and since there seems now to be a massive armel give-back you need to wait till the queue is empty before starting with those haskell-rebuilds to be sure they get build in the right order
<tumbleweed> doesn't give-back have 0 priority?
<Laney> https://bugs.launchpad.net/launchpad/+bug/245594
<ubottu> Ubuntu bug 245594 in Launchpad itself "Rebuilds of binary packages without source changes" [Low,Triaged]
<Laney> my ghc6 build doesn't seem to be starting
<geser> armel 1441 jobs (five days)
<geser> the LP API doc mentions "build.dependencies" as writeable but I don't know what happens it one tries to write it
<tumbleweed> aah, "private source" that wins all build-score wars by default
<ari-tczew> Daviey: what's the point of your comment 16 in bug 700198 ?
<ubottu> Launchpad bug 700198 in ia32-libs (Ubuntu Karmic) "CVE-2009-0793" [Low,Triaged] https://launchpad.net/bugs/700198
<tumbleweed> bdrung: poking my way through your u-d-t comments from yesterday. You suggested srcpkg.check(), but I can't really think of a decent API for it. It would need to return a list of mismatches for syncpackage, but that makes the function difficult to use anywhere else
<bdrung> tumbleweed: let's call it verify instead. wouldn't true and false be enough?
<tumbleweed> bdrung: hmm, that might actually be ok. IIRC the current code checks the filenames of the mismatches, to see if they are .orig... but I don't know why
<bdrung> tumbleweed: because only the orig files can lead to problems. so a function verify_orig() would be nice.
<tumbleweed> bdrung: what other mismatches will you get?
<bdrung> tumbleweed: having mismatching .debian.* files doesn't matter with the next upload.
<tumbleweed> but those contain version numbers, so they should be immune
<tumbleweed> unless we are bumping epoch but not anything else
<iulian> Hey bdrung.  I've just noticed the ubuntu-dev-team on Launchpad.  What was the reason behind registering it?  I apologies if this was already covered but I obviously was not aware of it.
<tumbleweed> iulian: it's just to own the daily builds
<iulian> Oh, alrighty.  Cheers tumbleweed!
<bdrung> iulian: what tumbleweed said and to have a lp group for the ubuntu-dev-team@lists.alioth.debian.org team
<bdrung> http://qa.debian.org/developer.php?login=ubuntu-dev-team@lists.alioth.debian.org
<tumbleweed> err, I thought that was u-d-t dev (slap face)
<bdrung> right, that are two different teams
<ari-tczew> ScottK: I uploaded clementine to lucid-backports.
<ari-tczew> ScottK: oh, I forgot about bug report.
<tumbleweed> bdrung: u-d-t: all addressed, I believe (test suite is getting rather slow :/)
<ScottK> ari-tczew: What bug?
<ari-tczew> ScottK: bug 703292, but I have to update patch to fix ftbfs on armel in natty first.
<ubottu> Launchpad bug 703292 in lucid-backports "Backport clementine 0.6-0ubuntu4 from natty" [Undecided,New] https://launchpad.net/bugs/703292
<ScottK> OK.  Let me know when it's ready.
<ari-tczew> Sure.
<ari-tczew> debfx: could you look on package rlplot? it's affected by FTBFS, you fixed last FTBFS, maybe you can fix it again.
<bdrung> tumbleweed: why did you put all files into example_package.py? having the example package extracted into one directory would be enough.
<debfx> ari-tczew: I've uploaded a fix for rlplot
<tumbleweed> bdrung: I needed a non-native package, generating them on demand during build is probably also useful for testing syncpackage type behavior
<bdrung> tumbleweed: that's not a reason for putting everything in example_package.py. you could create the orig and the source package from a directory in example_package.py
<ari-tczew> debfx: thanks
<tumbleweed> bdrung: and it's done
<bdrung> tumbleweed: DebianSourcePackage._source_urls: Invalid name "it"
<bdrung> tumbleweed: rmadison: Invalid name "p" (--> "process"?)
<bdrung> tumbleweed: trailing space in d/rules in test-data
<bdrung> tumbleweed: run wrap-and-sort in test-data :)
<bdrung> tumbleweed: in ubuntutools.test.test_archive Method could be a function -> convert to private (leading _) functions
<tumbleweed> pylint is a little too pedantic about variable names :/
<tumbleweed> it is a perfectly good name for an iterator
<bdrung> tumbleweed: having slightly longer names is a benefit.
<bdrung> tumbleweed: having only one char variables making the code hard to read. example: https://answers.launchpad.net/libkibi/+question/139749
 * tumbleweed agrees with that in general, but one or two of them are fine
<bdrung> things like "i" are ok
<bdrung> tumbleweed: you import SourcePackagePublishingHistory twice?
<tumbleweed> re method could be function, I disagree, much neater like it is (4 very similar functions, some need to be methods)
<tumbleweed> requestsync.lp and requestync.mail intentionally have the same names for different things
<tumbleweed> bdrung: pushed r979
<bdrung> tumbleweed: it makes to sense to me why archive.py uses ubuntutools.requestsync.mail. If functions from there are needed, they should be moved.
<bdrung> tumbleweed: maybe an object for rmadison?
<tumbleweed> it's not that they are needed, it's just convenient (it's only a tiny class that looks like a lpapicache SPPH)
<tumbleweed> what would you add to an rmadison class?
<bdrung> good question
<tumbleweed> I guess I'll move that SPPH thing, it's neater
<crying> Hey guys, where can I get grub help? I've messed it up a lot!
<Bachstelze> crying: #ubuntu is the place for technical help
<bdrung> tumbleweed: do you like writing man pages?
<tumbleweed> bdrung: that's called a loaded question :P I write them when I need to
<bdrung> tumbleweed: i hate writing (in general). that include writing man pages. there's a "byteprefix" man page on my todo list (last point before releasing libkibi)
<tumbleweed> bdrung: heh, empty NEWS, README, TODO, I see :)
<bdrung> tumbleweed: kibi/kibi.h is documented
<bdrung> tumbleweed: and debian/copyright has some information
<bdrung> tumbleweed: you don't want to help me writing the man page?
<tumbleweed> bdrung: aren't .la files deprecated?
<tumbleweed> bdrung: happy to help, just not too sure where to start, I'm probably more use as an editor
<bdrung> tumbleweed: IIRC, .la are deprecated. i only use the .la file for building the test program, which shouldn't link to the system libkibi.
<tumbleweed> bdrung: it's installed in the -dev package
<bdrung> tumbleweed: i want to have a man page for byteprefix, which describes the configuration. there is the BYTEPREFIX env variable, /etc/byteprefix and $xdg_config/byteprefix
<geser> bdrung: shouldn't a -L. (or whereever the build lib is) do it instead too?
<bdrung> geser: let me try it.
<tumbleweed> bdrung: ah, that's something I can work with. /me adds it to the weekend todo list
<bdrung> geser: to which automake variable should i add that?
<geser> LIBS I'd say, before the -lkibi
<geser> or how the lib is named
<geser> if you the test program you might need to set LD_LIBRARY_PATH so it uses your build lib instead of the system one (unless you do static linking)
<bdrung> geser: that was the reason why i used static linking
<hakermania> Guys, wallch is one step before advocating. Can someone please that uses Ubuntu with GNOME desktop to go and test it? Thank you, the link is Wallch
<hakermania>  
<hakermania> http://revu.ubuntuwire.com/p/wallch
#ubuntu-motu 2011-01-16
<iulian> bdrung: That makes sense.  Cheers.
<geser> micahg: do you know if some of the till recently "supported" firefox extensions will come back or should I install them in my profile? (like firebug, adblock-plus and notify)
<micahg> geser: I don't think they're coming back, the only extensions we're going to have going forward are the arch specific ones
<micahg> geser: unless Mozilla commits to stable branches ;)
<geser> ok
<hyperair> ari-tczew: ping
<ari-tczew> hyperair: pong
<hyperair> ari-tczew: i noticed you synced geany-plugins from squeeze
<ari-tczew> hyperair: dunno, perhaps. let me find it
<hyperair> ari-tczew: launchpad says you synced it from unstable 13 weeks ago.
<hyperair> 0.19-1
<ari-tczew> hyperair: yes, I see: geany-plugins	0.19-1	0.19-0ubuntu1
<hyperair> ari-tczew: geany-plugins in unstable had all the new plugins (introduced between 0.18 and 0.19) disabled, whereas they were enabled in 0.19-0ubuntu1.
<hyperair> ari-tczew: meaning that when you synced it, you pretty much disabled all the new plugin packages
<ari-tczew> hyperair: I don't remember the case. Unfortunately. What's next?
<hyperair> ari-tczew: please be more careful in auditing the ubuntu-specific changes in the future.
<hyperair> ari-tczew: 0.20 is out, and i'm uploading -0ubuntu1 to natty now.
<hakermania> I love this channel.
<hyperair> ari-tczew: please poke me before touching that package in the future.
<hyperair> ari-tczew: and please pay a little more attention to the debian-ubuntu delta, and make sure it can actually be dropped before syncing the package.
<ari-tczew> hyperair: I'm dealing with a lot of packages and I guess that in ~99% cases I'm right. Everyone could do mistake.
<hyperair> ari-tczew: i understand that it's a rare mistake. still, please be more careful in the future =)
<hyperair> ari-tczew: also, it's common practice to ping the last uploader of the package before touching it
<hyperair> in geany-plugins' case, i'm the last uploader.
<hyperair> nobody likes the carpet being pulled from under their feet.
<ari-tczew> hyperair: I'm careful as good as possible. You can track my done work. I can't remember any complaint since MOTUship.
<ari-tczew> (technicall complaint)
<ari-tczew> hakermania: why do you love this channel?
<hakermania> ari-tczew: There's always an open discussion about interesting things I haven't heard before :D
<ari-tczew> aha
<hyperair> ari-tczew: i understand that you're being as careful as you can. i'm just advising you on how you may prevent a similar slip to this one in the future.
<hyperair> ari-tczew: please don't get defensive.
<ari-tczew> hyperair: I'm easy. I just understand that there isn't a human which is 100% perfect in the world.
<ari-tczew> and I understand your bitterness.
<hyperair> ari-tczew: i'm not bitter about this.
<hyperair> i was just mildly surprised, and glad that i caught the mistake before Feature Freeze.
<hyperair> ari-tczew: i'm not looking for an apology or anything of that sort. i just giving you some friendly advice as a fellow ubuntu developer, that's all.
<hyperair> you mentioned that there isn't a human who's 100% perfect in the world. so there's always room for improvement, isn't there? =)
<ari-tczew> hyperair: OK, thanks for noticing and I didn't want to break anything.
<hyperair> =)
<ari-tczew> hyperair: Yes, always room are open for improvements.
<ari-tczew> room always *
<hyperair> =)
<ari-tczew> ScottK: clementine is ready. in lucid NEW. bug 703292
<ubottu> Launchpad bug 703292 in lucid-backports "Backport clementine 0.6-0ubuntu5 to lucid from natty" [Undecided,New] https://launchpad.net/bugs/703292
<hakermania> Who gave the idea for "purchased software" section in USC ?
<hakermania> A really bad idea.
<Bachstel1e> hakermania: here is not the place to rant about USC
<hakermania> Bachstelze: Oh, fine..
<hakermania> May I ask? When I install my DEB, in the installed software of USC it says "Change Desktop Wallpapers automatically" as title and "Wallch" as description. How do I do the opposite? My control file: http://paste.ubuntu.com/554859/ thx
<bdrung> hakermania: you can't.
<bdrung> tumbleweed: around?
<hakermania> bdrung: Is this automatically fixed when your package is advocated?
<bdrung> hakermania: "Change Desktop Wallpapers automatically!" is not the best short description.
<hakermania> bdrung: This is has to do with my own opinion I think.
<bdrung> hakermania: i don't think that an exclamation mark belong there.
<hakermania> bdrung: I've seen a lot of apps with (!)
<paultag> Hey MOTU. I need to file a package for removal from the archives. No rdepends or r-recomends. It's a bad package, and I got it removed from Debian already
<paultag> How can I file for it's removal? I'm guessing -dev-tools, but I'm not sure on procedure
<bdrung> paultag: -dev-tools?
<bdrung> we have no tool for requesting removal.
<bdrung> file it manually and either subscribe ubuntu-archive or ubuntu-sponsors
<bdrung> (depending of your upload rights)
<paultag> bdrung: as a bug? Is there a template I can follow?
<paultag> bdrung: no upload rights here
<bdrung> paultag: then ubuntu-sponsors. AFAIK there is no template.
<paultag> bdrung: great. thanks so much
<bdrung> hakermania: i failed to find the recommendations for writing the description.
<bdrung> hakermania: i would prefer a short description without exclamation mark (e.g. "automatic desktop wallpaper changer")
<bdrung> hakermania: can you show me a screenshot of USC with your bug?
<bdrung> hakermania: i tested it on maverick and Wallch is shown in the title
<hakermania> bdrung: wait, currently packaging
<hakermania> bdrung: http://i55.tinypic.com/2zy96h2.png
<paultag> bdrung: filed as bug #703718. Thanks!
<ubottu> Launchpad bug 703718 in Ubuntu "Requesting removal of source package `fluxconf' from Ubuntu" [Undecided,New] https://launchpad.net/bugs/703718
<bdrung> hakermania: it look consistent (short description on top, package name below)
<hakermania> bdrung: Is it right?
<bdrung> hakermania: hm, it looks inconsistent on my system. packages with a .desktop file use the desktop file name as title, but all other use the short description as title.
<Rcart> Hello. It seems like menumaker application is not available in debian.  I've searched with $rmadison -u debian menumaker,  with no result. This applicacion is a X Windows Managers menu generator and is not (apparentley) in Debian/Ubuntu
<Rcart> So, if it's possible, i'd like to package it (i'm learning) if i can
<bdrung> hakermania: i recommend to test natty and if it has the same behaviour, file a bug!
<hakermania> bdrung: To test natty? What?
<bdrung> Rcart: it's possible. just do it.
<bdrung> hakermania: test USC in natty.
<hakermania> bdrung: But natty will be available at 4/11
<hakermania> ?
<bdrung> paultag: you should state that there are no rdepends and no b-d on it.
<bdrung> hakermania: nope. Ubuntu 11.04 will be available at 4/11. Until then it's called natty. ;)
<hakermania> bdrung: Where can I find it?
<Rcart> bdrung: thanks, i'm already working on it.
<paultag> bdrung: sure.
<bdrung> hakermania: http://www.ubuntu.com/testing
<hakermania> bdrung: thx
<bdrung> hakermania: here are the latest cd spins: http://cdimage.ubuntu.com/daily-live/current/
<bdrung> hakermania: i recommend to install it in a virtual machine, run it from a live usb stick or install it on a separate harddrive
<paultag> bdrung: all set. thanks!
<hakermania> bdrung: This is what I'd do
<bdrung> Rcart: great. i recommend to get it into debian and then sync it to ubuntu.
<bdrung> paultag: ACK'd
<paultag> bdrung: cheers, thanks for your time :)
<Rcart> bdrung: do i need to contact the application author(s)?
<bdrung> Rcart: no, but establishing an upstream relationship is a benefit if you maintain the package
<paultag> Hey! It's dholbach's birthday today!
<sagaci> you can't sing happy birthday
#ubuntu-motu 2012-01-09
<psusi> wtf?  I keep trying to upload a package to my ppa and it gets through the dsc, the tar.gz, and then gets stuck 2k/3k uploading the .changes file...
<psusi> ahh I love it when the build queues are nice and short...
<KNRO1> Hello, I'm getting "invalid value" when I try to link a project to an existing Bazaar branch. This is the branch lp:~mutlaqja/libindi/indi-sbig and this is the URL to set the project branch https://launchpad.net/indi-sbig/trunk/+setbranch
<KNRO1> Any idea what's going on?
<geser> you might want to ask in #launchpad if you don't get an answer here
<KNRO1> looks like the names have to exactly match
<KNRO1> actually not..
<KNRO1> how can I ask to add a package to multiverse?
<KNRO1> or universe?
<geser> a new package gets usually automatically into universe (DFSG-compliant license) or multiverse (non-free license, but redistributable)
<l3on> Hi all... someone can tell me if I did the right thing in bug 899460 ?
<ubottu> Launchpad bug 899460 in mrtg (Ubuntu) "mrtg bug was fixed upstream but is not available in stable or unstable ubuntu or debian packages" [Undecided,Fix released] https://launchpad.net/bugs/899460
<geser> l3on: have you checked how hard it would be to extract a patch for a SRU? (not sure if it qualifies for SRU)
<l3on> geser, I'm working on that :)
<l3on_> geser, well.. It seems that the patch could be apply at current ubuntu version (oneiric, natty, maverick)
<l3on_> what's the best way to do that ?
<geser> check if a SRU would apply for it (not sure myself, I'd would probably ask ubuntu-sru for an opinion) and then prepare the SRUs
<l3on_> geser, I fixed mrtg for oneiric natty and maverick
<l3on_> I don't remember, I have to set 'natty-update' ?
<dupondje> Hi, somebody could check if syncing tulip (http://packages.debian.org/source/unstable/tulip) is a good idea?
<dupondje> package builds fine on Ubuntu precise here (pbuilder-dist)
<l3on_> hey guys, someone can change this status from Fix Relaesed to Confirmed, please ? (bug 899460)
<ubottu> Launchpad bug 899460 in mrtg (Ubuntu) "mrtg bug was fixed upstream but is not available in stable or unstable ubuntu or debian packages" [Undecided,Fix released] https://launchpad.net/bugs/899460
<l3on_> geser, still around ?
<geser> l3on_: yes, I'm around
<l3on_> geser, can you change the status for bug 899460 ?
<ubottu> Launchpad bug 899460 in mrtg (Ubuntu) "mrtg bug was fixed upstream but is not available in stable or unstable ubuntu or debian packages" [Undecided,Fix released] https://launchpad.net/bugs/899460
<geser> the distribution for upload is "$release-proposed"
<l3on_> yes I used it :)
<geser> l3on_: opened tasks for maverick, natty, oneiric. Feel free to assign them to you
<l3on_> How can I do it ?
<l3on_> did :)
<l3on_> s/did/done
<l3on_> ok geser and now same procedure? I mean:
<l3on_> status confirmed, assignee removing, ubuntu-sponsors subscribing ?
<geser> yes
<l3on_> Ok, thansk... :)
<tumbleweed> dupondje: what makes you unsure about syncing it?
<l3on_> hey guys, since bug 569827 is about deprecated 9.10, I can set it as Fix Released ?
<ubottu> Launchpad bug 569827 in python-psutil (Ubuntu) "psutil.cpu_percent() returns 0.0 although CPU Usage is higher" [Undecided,Fix committed] https://launchpad.net/bugs/569827
<l3on_> what's the best way in this case ?
<tumbleweed> l3on_: can we find the patch that fixed it, and SRU it?
<l3on_> tumbleweed, in 11.10 it works fine, bug is opened in Karmic Koala ! :)
<tumbleweed> l3on_: yes, I can see that from the bug, but nobody has pointed at the upstream commit that fixed it
<dupondje> tumbleweed: cause there seems to be blocked in debian to get it into testing
<dupondje> but those are build issues, which I didn't had when building it in pbuilder
<tumbleweed> dupondje: urm, debian bug 650653 seems to have failed the build on every architecture in debian
<ubottu> Debian bug 650653 in src:tulip "tulip: FTBFS: No rule to make target `doc'" [Serious,Open] http://bugs.debian.org/650653
<dupondje> weird, but it builded fine :)
<tumbleweed> I'll have a look in a bit. Just busy wit hsomething
<KNRO> Hello, how can I request to join the MOTU Science team?
<tumbleweed> is motu science still alive?
<tumbleweed> (it's great to see some interest in it, though \o/ )
<KNRO> tumleweed: well, MOTU in general then. I need to maintain a set of science packages and I've been doing package management for a long period now and have everything synced with upstream. I also happen to be the upstream developer as well.
<tumbleweed> are these packages that are maintained by the debian science team? if so I suggest joining them too
<KNRO> they are maintained by MOTU
<tumbleweed> which packages?
<micahg> we could create a science packageset if there's sufficient interest, I think we have one person with PPU right now for quite a few science packages
<tumbleweed> as to joining MOTU, you start by just doing things, and when people get tired of sponsoring uploads for you, you'll be told to apply for MOTU membership :)
<KNRO> INDI and 3rd party drivers... for example: I'm _already_ maintainer for this package: https://code.launchpad.net/libindi
<tumbleweed> looks like it's mostly being maintained by kubuntu people
<KNRO> the thing is, I'm also tired of asking for syncing with upstream.. and sometimes packaging is not done correctly. Plus, this is hardware related drivers for astronomical instruments, I do packaging, then I clean them on new clean system, and test with _real_ hardware.
<KNRO> I doubt anyone in MOTU now can do that
<KNRO> clean=install
<Resistance> libindi is maintained by Kubuntus
<tumbleweed> yes, packages like that could definitly use some love by upstream :)
<Resistance> not the MOTUs (directly)
<tumbleweed> right, kubuntu maintain it for kstars
<Resistance> ^
<KNRO> Tumbleweed: so I ask in Kubuntu then?
<KNRO> I'm also KStars developer :P
<tumbleweed> KNRO: yes, it's in main not universe, so MOTU can't touch it
<KNRO> tumbleweed: the _rest_ of the packages are in universe and multiverse.
<Resistance> tumbleweed:  if i'm reading the source package page for libindi right, then the Kubuntu Members group has access, and that'd require Kubuntu Council intervention to change?
 * Resistance is making wild assumptions, hence the question
<KNRO> only libindi is in main.. everything else is in universe...
<KNRO> Resistance: actually, I am put there as the maintainer. so I was able to make changes there to link to upstream.
<tumbleweed> libindi also recently made it into debian, so ubuntu might start using that packaging
<tumbleweed> (I don't know how much kubuntu people do their own thing vs pull from debian)
 * Resistance peeks at debian
<Resistance> tumbleweed is right, its in debian now
<KNRO> hmmmm, how would you know that?
<tumbleweed> packages.qa.debian.org/libindi
<KNRO> so if a package is in debian, it is just copied over?
<tumbleweed> no, it's more complex than that :)
 * Laney blinks at the name of the team
<tumbleweed> link-hover suggets it's the kde people :P
<tumbleweed> KNRO: most of ubuntu is unmodified debian, rebuilt
<KNRO> lol what KDE people specifically? I'm in KDE.
<tumbleweed> KNRO: another large chunk is minor modifications of debian package (often temporary)
<tumbleweed> and the remaining packages (like the current libindi package in Ubuntu) come straight from upstream, not debian
<KNRO> Tumbleweed: but if libindi now in Debian, they will no longer take it from upstream?
<tumbleweed> probably
<tumbleweed> unless there's a good reason not to, that'd be the best way to go
<KNRO> What about other packages in universe?
<tumbleweed> what about them?
<KNRO> how can I maintain them myself? or if I need to add a new INDI driver...etc...
<Resistance> don't the MOTUs hold priority over Universe?
<Resistance> (if i'm not mistaken)
<tumbleweed> Resistance: what do you mean by that?
<Resistance> tumbleweed: priority as in control over the Universe packages
<tumbleweed> Resistance: MOTU can touch anything in universe/multiverse, but should exercise a little caution when touching something that's also seeded
<tumbleweed> (around freezes)
<tumbleweed> KNRO: https://wiki.ubuntu.com/SponsorshipProcess
 * Resistance peeks at the u+1 dev schedule
<Resistance> oic
<micahg> well, MOTU should also be careful with seeded packages WRT new upstream releases that the flavors might not want (especially in an LTS)
<Resistance> i take it the freeze you mentioned tumbleweed is the Debian Import freeze?
 * Resistance is looking at the release schedule
<tumbleweed> Resistance: no, alphas and other freezes that build ISOs
<Resistance> well unless there's a time issue with the release schedule on the wiki, the next release (alpha) isnt until february, no?
<tumbleweed> Resistance: I was replying to your question over packages in universe that overlap with packagesets
<Resistance> ahh
<Resistance> i see
 * Resistance retreats to lurk mode once more :)
<KNRO> Sponsorship is not clear? I file a "bug" for package inclusion ?
<tumbleweed> KNRO: we prefer to bring in new packages via debian https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<tumbleweed> so I encourage you to engage with debian science / debian qt people
<KNRO> Tumbleweed: yes ok, what if Debian do not include these packages?
<KNRO> Do yo also import Universe packages from Debian?
<tumbleweed> most of universe is from debian
 * Resistance points at ZNC as an example
<KNRO> and multiverse?
<tumbleweed> yes
<KNRO> I have one package in multiverse...
<Resistance> the version in precise atm is based off of debian universe's version
<micahg> ~75% of universe is from Debian
<KNRO> ok so debian it is :)
<tumbleweed> KNRO: debian will almost always accept new packages
<micahg> *unmodified from Debian
<KNRO> if a package makes it to debian, no need to inform folks in ubuntu to include it ?
<KNRO> it's automatic?
<tumbleweed> semi-automatic. You don't need to poke anyone, but it needs manual review
<tumbleweed> however, we are now at Debian Import Freeze. So *anything* new from debian needs to be requested
<ScottK> micahg: 75% of the whole archive is unmodified from Debian, IIRC.  I think the percentage for Universe is higher.
<micahg> well, the graph on merges.ubuntu.com looks around 75%
<ScottK> OK.
<Resistance> micahg:  tumbleweed:  for the "znc" package, they found a vulnerability in one of the modules... when the upstream fix is released, what does one need to do to get that fix included in the ubuntu repos (its in universe)?
<micahg> I'm curious what the real numbers are
<micahg> Resistance: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
<Resistance> micahg:  if the upstream fix also changes the version number, what then?  (the ZNC devs are releasing the fix as 0.204 rather than 0.202 (current version) )
<micahg> Resistance: you need to get a patch (preferably from upstream VCS), to fix the issue, version updates for a CVE are usually not allowed
<ScottK> (except for in the development release - i.e. precise)
<micahg> right
<Resistance> i fully expect this to be dumped into precise at some point (unless the code release with the fix is after the freeze)
<Resistance> because the version of ZNC in question with the vulnerability is only in universe in precise (its in -backports for oneiric and natty)
<micahg> Resistance: after it's in precise, you can request new backports
<Resistance> well i found a patch...
<Resistance> should i file a bug against the source package or the project?
 * Resistance assumes the source package, but...
<ScottK> Yes.
<Resistance> the bug is now filed, complete with the patch from Debian, and a link to the upstream fix.  :)
<Resistance> i'll let someone else fix it
<tumbleweed> Resistance: why not do it yourself? :)
<Resistance> tumbleweed:  because i have class in 10 minutes? :p;
<Resistance> (and i fully expect to attempt to fix it after my last class is over, at 8PM :/)
<Resistance> in the mean time, i'm busy :P
<teratorn> hi, anyone have a clue what might be a simple up-to-date native shared library package I could use as an example to help in a new packaging effort?
<Laney> cyphermox: I think something went wrong with valatoys: http://packages.ubuntu.com/precise/amd64/libafrodite-0.12-2/filelist
<tumbleweed> dupondje: you'll notice that tulip builds with -b but not -B
<andreas__> hi, can someone sponsor this? https://bugs.launchpad.net/pytz/+bug/885163
<ubottu> Ubuntu bug 885163 in python-tz (Ubuntu Oneiric) "pytz dst() incorrectly handles Pacific/Apia day leap" [Undecided,New]
<dupondje> tumbleweed: how you mean ?
<tumbleweed> dupondje: it'll build when you are building the architecture-independant packages too, but not when you are only building the architecture-dependant packages (like the Ubuntu non-i386, and all the debian buildds do)
<dupondje> ahhh! ok
<tumbleweed> (pretty trivial to fix, if you want to provide a patch :) )
<dupondje> is there a way to test it in pbuilder ?;)
<tumbleweed> yes. --binary-arch
<tumbleweed> andreas__: meh, the debian python-tz is rather out of date
<tumbleweed> surely there are other important updates for it too?
<andreas__> tumbleweed: I don't know, I'm not the maintainer, I was focusing on fixing this bug which is rather important for me
<ahasenack> tumbleweed: I assume you were talking about the new version that is out there, that could have been uploaded to precise instead of the patched package?
<tumbleweed> yeah
<tumbleweed> we follow tzdata upstream releases, and SRU them everywhere
<ahasenack> yeah, I didn't do that because I'm not the maintainer and I wouldn't be able to verify the other changes
<tumbleweed> I assume we don't do this for python-tz, because of the handful of roather unimportant reverse deps
<ahasenack> and  because it's code
<tumbleweed> still, not that useful when it's out of date
<l3on> hey guys, is it today the freeze update ?
<l3on> or the 12th ?
<tumbleweed> oh, duh, it takes the tzinfo from tzinfo
<tumbleweed> err zoneinfo from tzdata
<ahasenack> tumbleweed: yes
<ahasenack> it's not duplicated
<tumbleweed> thankfully
<tumbleweed> bdrung: sponsor-patch should be able to guess the task from the UDD branch
<bdrung> tumbleweed: that makes sense.
<bdrung> tumbleweed: patches are welcome. :p
<tumbleweed> first... let me fix a bug in my last change there
<tumbleweed> ahasenack: SRU uploads should be targetted at $release-update
<ahasenack> aaarrrrghhhhhhhh
<ahasenack> I forgot that
<tumbleweed> np
 * tumbleweed 'll fix them up
<ahasenack> really? I love you
<tumbleweed> err -proposed
<ahasenack> yep :)
<ahasenack> want me to push a fix? I can do that
<ahasenack> in fact, I'll do it anyway, to remain consistent
<tumbleweed> I'm busy uploading lucid. You can fix the others
<ahasenack> ok
<ahasenack> tumbleweed: done and pushed for maverick, natty and oneiric
<tumbleweed> bdrung: fix committed
<tumbleweed> ahasenack: removed the .11.10 from the oneiric one. Unecessary. All uploaded, pending SRU team review...
<ahasenack> tumbleweed: ok, thanks again and sorry for that rookie mistake
<tumbleweed> pish, np
<tumbleweed> we generally make the rookies get everything perfect, though :)
<ahasenack> tumbleweed: without that 11.10 from the release, will the updated natty package still upgade to the oneiric one?
 * ahasenack checks
<tumbleweed> ahasenack: there was only one release with that version, so a .1 was fine
<ahasenack> so python-tz-2010b-1ubuntu0.11.04.1 to python-tz-2010b-1ubuntu2?
<tumbleweed> 2010b-1ubuntu1.1
<ahasenack> ok, that works
<micahg> siretart: with only lintian overrides and gbp configuration left, is there a reason to not sync libav-extra from Debian?
<siretart> micahg: did you check that all build dependencies are really the same?
<siretart> micahg: if they are the same, then syncing it would indeed make things easier
<micahg> I did a debdiff between the current version in Ubuntu and the one in Debian, the only diff was the versioning on the libav-source
<siretart> cool
<micahg> siretart: so, I'll test build and sync then
<siretart> thanks!
<siretart> it'll still need no-change rebuilds each time libav is uploaded, though
<siretart> or to be more specific, each time libav-source is updated
<siretart> but usually, future syncs of libav-extra should take care of that
<micahg> cool
<dupondje> siretart: there ?
<siretart> dupondje: almost gone, but what's up?
<dupondje> siretart: http://packages.debian.org/source/unstable/live-config
<dupondje> can be synced ?
<siretart> dupondje: I think it needs a merge rather than a sync
<siretart> dupondje: also, I don't think that the upstart job for live-config is correct yet. I still need to file a proper bug and ask upstart-devel how to fix that
<dupondje> siretart: all changes are in debian now, except a restart after reconfig of lxdm
<l3on_> hey guys, someone can tell me how to fix this kind of bug? (bug 898027)
<ubottu> Launchpad bug 898027 in pywbem (Ubuntu) "package python-pywbem (not installed) failed to install/upgrade: trying to overwrite '/usr/bin/wbemcli', which is also in package wbemcli 1.6.1-0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/898027
<l3on_> wbemcli should conflict with python-pywbem (or viceversa), is it right ?
<dupondje> btw
<dupondje> somebody knows what we can do with https://launchpad.net/ubuntu/+source/eggdrop/+changelog ?
<dupondje> the current version includes a SSL patch (delta with debian)
<l3on_> dupondje, I looked at this
<dupondje> we can merge it with the ssl patch, but the SSL patch is highly discouraged by upstream (eggdrop dev)
<Resistance> i found a patch for a vulnerability in the ZNC Source package in Precise, how do i add the patch to the source package and have it uploaded and added into the Precise repos?
<l3on_> Yes, you're right
<dupondje> and if I look at the bugreports
<dupondje> I see half of them caused by the bad ssl patch
<dupondje> so ...
<Resistance> tumbleweed:  'tis the patch i found for ZNC, and I want to apply it myself
<dupondje> kick out the patch and sync (but lose SSL) ?
<dupondje> or merge with a new crappy patch included still ...
<dupondje> )
<dupondje> Resistance: no new version released of ZNC for that ?
<l3on_> dupondje, I chose to do nothing
<broder> dupondje: what about "fix the patch"?
<Resistance> dupondje:  released in 0.204, which is in alpha, upstream fix referenced (and a debian patch) in LP bug #913836
<ubottu> Launchpad bug 913836 in znc (Ubuntu) "ZNC 0.202: vulnerability in bouncedcc module" [Undecided,New] https://launchpad.net/bugs/913836
<Resistance> dupondje:  patches exist for ZNC 0.200 and 0.202 in Debian, and was updated in Debian
<l3on_> . Note this patch does not have 64-bit or thread support
<l3on_> dupondje, so can it build on amd64?
<dupondje> 0.202-2 will get synced :)
<dupondje> @ Resistance
<l3on_> what about take directly dev version 1.8.x ?
<dupondje> l3on_: it is build at least ;)
<l3on_> lol
<Resistance> dupondje:  when, because I need it backported to Oneiric and Natty too (per my backport requests which were approved by broder, see LP bug #887758)
<ubottu> Launchpad bug 887758 in Oneiric Backports "Please backport znc 0.202-1 from precise to natty" [Undecided,Fix released] https://launchpad.net/bugs/887758
<Resistance> and if those backports have the same DoS vulnerability, i'd request a re-backport or a specific import :P
<dupondje> guess they do a last sync before freeze
<dupondje> but you can bug a syncrequest
<Resistance> where do i file that bug?
<Resistance> against Precise?
<Resistance> or just against Ubuntu?
<Laney> !sync
<ubottu> Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess
<Resistance> Laney:  LP Bug #914026.  Is that formatted right?
<ubottu> Launchpad bug 914026 in Ubuntu "Please sync znc 0.202-2 from Debian Sid to Precise" [Undecided,New] https://launchpad.net/bugs/914026
<Riddell> can we take a swap day for a conference leave day which is on a weekend?
<Riddell> oh hmm, wrong channel
<l3on_> Resistance, why you don't use 'requestsync' script ?
<Laney> Resistance: looks good (would be nice if you include the new changelog entries), but in future you might find it easier to use the requestsync script
<Resistance> Laney:  which package has said script?
 * Resistance is new at requesting syncs
<Laney> ubuntu-dev-tools
<jtaylor> I don't like the new command-not-found :(
<jtaylor> I was so used to just copy pasting the command from the output
<Resistance> Laney:  requestsync -d sid znc precise  <-- correct syntax?
 * Resistance might redo the request if he feels it necessary
<Laney> might be unstable instead of sid, and you don't need to specify precise (should be the default)
<Laney> no need to re-file though, just add the changelog entries to your bug and it's ok
<l3on_> and use '--lp' if you dont have a MTA configured
<Resistance> Laney:  changelogs from debian?
<Laney> yes
<Laney> it's nice for reviewers to see the new changelog entries
<Resistance> Laney:  so if ther's only one entry, just copy-paste from the changelog into the bug?
 * Resistance has the debian changelog here on screen
<dupondje> thre is an issue btw with changelog.debian.org :(
<Resistance> dupondje:  i did dget <path to .dsc>
<Resistance> :P
<dupondje> http://packages.debian.org/changelogs/pool/main/p/python-poppler/ vs http://packages.qa.debian.org/p/python-poppler.html
<dupondje> missing alot of changelogs :(
<Laney> it doesn't work with 3.0 (quilt) afaik
<jtaylor> that issue is quite old and very annoying :/
<Laney> patches welcome, etc
<Resistance> Laney:  could you take a peek at the bug again? (i.e. refresh)
<Laney> looks good
<Resistance> :)
<Resistance> now i need to apply the patch to my fork :P
#ubuntu-motu 2012-01-10
<Laney> VERSION:=${shell cat debian/changelog | head -1 | sed -e's/^maradns (//' | sed -e's/-[[:digit:]]\+) \w\+; .*//' }
<Laney> the archive is a source of wonder
<Laney> (resulted in make -f build/Makefile.linux all COMPILED=\""Linux system at Tue Jan 10 00:01:39 GMT 2012"\" VERSION=\"2.0.04-1ubuntu1) precise; urgency=low\"
<Laney> /bin/sh: 1: Syntax error: ")" unexpected
<Laney> )
<Resistance> Laney:  who would process the sync request, if you know?
<Laney> Resistance: a sponsor (did you subscribe ubuntu-sponsors?)
<Resistance> Laney:  negative, point me to the links?
 * Resistance is having issues with searching atm
<Resistance> (FFox exploding)
<Laney> SyncRequestProcess says
<Laney> "To request a sync, file a bug in Launchpad with the above information (the requestsync tool discussed below makes this simple). Once the bug is complete and correct, if you are not an Ubuntu developer, subscribe (NOT assign) ubuntu-sponsors"
<Resistance> ah
<Resistance> done (i think)
<Resistance> Laney:  which "email address" does it display when it refers to bug #523093?
<ubottu> Launchpad bug 523093 in Launchpad itself "private e-mail address gets stuffed into and published in changes file" [Low,Triaged] https://launchpad.net/bugs/523093
<Resistance> in that wiki for SyncRequestProcess (note my emails are public anyways)
<Resistance> (i think)
<Laney> your contact address
<Resistance> i see...
<Laney> the one that launchpad mails you on
<Resistance> i take it i cant have my ubuntu.com email show up?
<Laney> no you can't have that as your primary email sadly
<Resistance> (since it autoforwards to the primary LP address, according to pleia2)
<Resistance> thought not
 * Resistance wishes you could :P
<Resistance> anyone able to help me create a patch for a package?
<Resistance> anyone?
<kgoetz> hi all. are packages for this release being synced from unstable or testing? we just uploaded freeciv into debian and i'm wondering if i'll have to file a sync request
<Resistance> if by "this release" you mean Precise
<Resistance> its being synced from sid afaik
<Resistance> (note i'm not a MOTU, but from what i've seen everything's coming from sid)
<kgoetz> precise, yep :)
<kgoetz> hopefully freeciv will scrape in then, thansk :)
<Resistance> we hope :P
<Resistance> s/we/you/
<kgoetz> hehe
<Resistance> if there's a package i uploaded a patch for, and the bug is triaged, should I change the status from "Triaged", or just leave it?
<ScottK> kgoetz: Autosync was from Testing, but it's done for this cycle anyway, so a sync request will be needed.
<kgoetz> ScottK: thanks. i'll have a dig around on the wiki and work out what needs to be done :)
<Resistance> ScottK:  who checks the sync requests, and how often do those requests actually get checked/handled?
<Resistance> ScottK:  i ask because the sync i asked to be done for ZNC from Debian Sid includes a vulnerability fix
<Resistance> (if you're around)
<ScottK> Resistance: You should subscribe the sync bug to ubuntu-sponsors and it'll get reviewed as part of the sponsorship queue.
<Resistance> i did that
<Resistance> ohhhhhhhhh
<Resistance> wait a sec....
<Resistance> would that explain why a soyuz icon shows up next to the Ubuntu project in my LP page?
 * Resistance has been trying to figure out why that's there, because it wasnt there yesterday
<ScottK> Dunno.  Link please?
<Resistance> https://launchpad.net/~trekcaptainusa-tw
<Resistance> see also: https://answers.launchpad.net/launchpad/+question/184233
<Resistance> (me trying to figure out why the Ubuntu project has a soyuz icon next to it on his LP page)
<ScottK> It's probably 2012-01-04 	PPA package upload accepted
<Resistance> it *shouldnt*
<Resistance> because that's within my own PPA
<ScottK> Why not, I think it's not really a soyuz icon, but a uploaded stuff icon.
<ScottK> I agree.  PPA shouldn't count for that.
 * Resistance has never had any PPA uploads ever trigger a soyuz icon
<ScottK> Dunno.
<Resistance> the #launchpad people are stumped too
<Resistance> hence the question
<ScottK> Sync request wouldn't do it until it was processed and the sync done.
<Resistance> i highly doubt that my submitting patches would do that...?
<Resistance> indeed...
<Resistance> which is why i'm thoroughly confuzled :/
<ScottK> Once they are uploaded, it might.
<Resistance> (tis also late, so i should be headed to sleep anyways)
<ScottK> Sorry.  I'm not much help.
<Resistance> no problem :P
<siretart> dupondje: can you confirm that restarting lxdm is no longer necessary / work with the patch?
<EvilResistance> any MOTU able to confirm something?
<EvilResistance> it was my understanding 10.04 would EOL with 10.10... but https://wiki.ubuntu.com/Releases#Stable seems to suggest otherwise
<EvilResistance> nevermind
 * EvilResistance got the answer and misread something :P
<Rhonda> Why do you expect an EOL half a year later?
<Tm_T> EvilResistance: /;
<Tm_T> (; even
<EvilResistance> Rhonda:  misread something :P
 * EvilResistance facedesks
<EvilResistance> this is why i drink tons of coffee...
<EvilResistance> keeps me alert >.>
<Tm_T> EvilResistance: save the desk (and face)
<EvilResistance> speaking of coffee, i think mine's finished brewing
<EvilResistance> Tm_T:  if i ever make a fail statement like the one i just did, tell me to go get more coffee :P
<EvilResistance> because something is wrong with me if i'm making fail statements like that
<Tm_T> EvilResistance: nah, that was a tiny error that did no harm
<EvilResistance> Tm_T:  it messed with my brain :P  and considering i only got 5 hours of sleep, i think coffee is a prerequisite to me being able to focus :P
<Tm_T> my experience says you cannot replace sleep in the long run (:
<micahg> while (sleep == NEEDED) { drink_caffeine(); }
<EvilResistance> while (sleep == NEEDED && daysAwake <= 3) { drink_caffeine(); }
<EvilResistance> if (daysAwake >=3) { pass_out(); }
<EvilResistance> s/>=/>/
<EvilResistance> i once had so much caffeine in a multiple-day sequence i was up for 6 straight days... the 7th day i passed out :P
<jakewins_> Hey all! I'm putting together my first debian package (for the neo4j.org project) and have two cosmetic questions, hoping someone has the time to help out..
<EvilResistance> jakewins_:  what generally do ya need?
 * EvilResistance isnt an MOTU, but does packaging here and there
<jakewins_> One, when I install my .deb via the Ubuntu software center, after install, the "install" button remains available, is that expected? (or should it turn into "uninstall" or "reinstall" or something?)
<EvilResistance> *sips his coffee*  ahh... Tm_T give me 20 minutes, i'll be as awake as if i had slept 13 hours :P
<jakewins_> Two, the ubuntu software center doesn't pick up that the package is open source, it shows the license as "unknown"
<EvilResistance> jakewins_:  in my test installations of my binaries, i've seen that button thing as normal...  although Synaptic shows it as installed (yes, i still use synaptic)
<EvilResistance> and i also have had that same issue as you've stated wtih LICENSE stuff
<jakewins_> EvilResistance: Thanks!
<EvilResistance> this is why i put my packages into my PPAs (or my archive for packages)
<jakewins_> Does putting them in a PPA solve it?
<EvilResistance> well considering I use synaptic instead of software center, idrk.  but the debian/copyright file contains all the licensing details, and all my stuff is released either under the GPL or the LGPL (depending on what the project uses)... (more often than not, I use the GPL)
<EvilResistance> *checks something*
<EvilResistance> read this: https://wiki.ubuntu.com/SoftwareCenter#Determining_software_item_information
<EvilResistance> The license label for an item should be: âOpen sourceâ, if it is in Main or Universe; âProprietaryâ, if it is in Restricted or archive.canonical.com; âUnknownâ, if it is anywhere else (including Multiverse and standalone packages).
<EvilResistance> since its a standalone, it shows up as "Unknown"
<nabil> hi everyone
<EvilResistance> jakewins_:  ^  (see above)
<jakewins_> Ah, and the license label is set in PPA?
<EvilResistance> jakewins_:  fwiw, i'd ignore what the "license" field of software center says, and focus on what you have in the debian/copyright file... if its GPL or LGPL or one of the open-source licenses i think you're fine
<jakewins_> EvilResistance: Yeah, feel the same way
<jakewins_> Thanks for your help!
<EvilResistance> jakewins_: i havent had any *issues* with PPA things, but software center is just interfaces with apt... when i install things via PPAs, its usually via CLI (apt-get, aptitude, etc.)
<EvilResistance> or god forbid synaptic :P
<nabil> I think you must hear that really often, but I was wondering which is the easier way to start contributng for Ubuntu... I am kinda lost on the project...
<jakewins_> lol
<jakewins_> nabil: take a look at https://wiki.ubuntu.com/ContributeToUbuntu
<nabil> I can add that I am a junior engineer in computer sciences, kinda good at C, but does not have a good grasp on system dev
<EvilResistance> nabil:  there's multiple ways to contribute :)  depending on what you mean by contribute.  I contributed via support channels, #ubuntu, #ubuntu-server, ubuntuforums.org, etc.  if you want ot actually contribute to the coding and dev, start dealing with bugs and things
<EvilResistance> there's bitesize bugs too
<EvilResistance> (good for people starting out)
<jakewins_> One more question: If I want to move towards making this package available in the public repos, I'm assuming setting it up in a personal PPA is initial step
<EvilResistance> jakewins_:  define "available in the public repos"
<EvilResistance> you mean like in the repos from Ubuntu?
<EvilResistance> jakewins_:  i'd consider submitting your package to Debian for inclusion...
<jakewins_> Preferrably general debian repos
<jakewins_> Yeah
<nabil> ok EvilResistance, but even bugs looks hard for me
<nabil> very freakin specific
<EvilResistance> jakewins_:  because submitting a package to Debian is far easier than submitting directly to Ubuntu
<jakewins_> Makes sense
<nabil> I am now changing nick because nabil is already reserved
<jakewins_> So debian package maintainers is the people to talk to then I assume..
<EvilResistance> jakewins_:  also, when its included in Debian sid, it'll be included later in Ubuntu (probably whatever q-series is)
<EvilResistance> or perhaps even precise, but you have to go through the debian side
<EvilResistance> jakewins_:  #debian-mentors @ irc.oftc.net is the home of their packaging helpers
<EvilResistance> i've gotten more than enough help there building packages for both Debian and Ubuntu (although I come here to #ubuntu-motu or #ubuntu-packaging for Ubuntu-specific help)
<EvilResistance> Ramz00z:  yeah, i found that to be the case as well, its why most of my launchpad karma comes from specification tracking for projects rather than bug fixing :P
<jakewins_> EvilResistance: Great, thanks so much for your help!
<EvilResistance> jakewins_:  yep, feel free to stop by and poke the MOTUs if you need more help.
<EvilResistance> :)
<EvilResistance> Ramz00z:  fwiw, i didnt start out dealing with bugs until i reported a few
<EvilResistance> Ramz00z:  after that, i just kept helping out everywhere... in the IRC channels, on ubuntuforums.org, on askubuntu...
<EvilResistance> didnt actually move into the technical aspects including packaging until after I had at least 6 months of command line experience working with server administration
<EvilResistance> only branched out into bug fixing and patching yesterday :P
<Ramz00z> yeah that's what I was thinking
<EvilResistance> (otherwise, i report bugs like the back of my hand)
<Ramz00z> isn't being "expert" in Ubuntu far more important than being good at prog ?
<Ramz00z> because I am the latter but REALLY not the first...
<Ramz00z> Ubuntu is just ocean wide... imoo
<EvilResistance> being good at programming helps, but i'm by no means an expert
<Ramz00z> I use it to dev but I don't really go deep... I must know like 20 command lines top
<EvilResistance> i dont really need to know more than basic command line functions
<Ramz00z> I guess only core dev are experts ^^
<EvilResistance> and the functions of debuild, dpkg, aptitude, quilt (for patching packages), dget, backportpackage...
<Ramz00z> and even them may not know every side of the project
<EvilResistance> i may know a bunch about how Ubuntu works, and i may know some tricks to making things happen...
<EvilResistance> but i dont know anything
<EvilResistance> in comparison to me, the MOTUs are technically packaging gods
<EvilResistance> and probably some of the most knowledgeable Ubuntu experts I know
<Ramz00z> Becoming a MOTU is wayyyyyyyyyyyyyy down the road for me ^^
<EvilResistance> (save Mark Shuttleworth, who probably knows everything there is to know, or where to get support for everything)
<Ramz00z> I've been thinking about developping for Ubuntu for years now
<Ramz00z> never found a project that I could effectively help
<EvilResistance> well i've recently taken it upon myself to work directly with a few projects that have PPAs but no skilled packagers
<EvilResistance> (thereby ending up with incomplete packages and they have no idea why)
<EvilResistance> granted, i have a good number of PPAs of my own
<Ramz00z> I'm about to get slapped I guess, but what's PPA ? :$
<EvilResistance> (and most recently, i've gotten involved with NGINX and ZNC, but not via Launchpad
<EvilResistance> !ppa
<ubottu> A Personal Package Archive (PPA) can provide alternate software not normally available in the offical Ubuntu repositories - Looking for a PPA? See https://launchpad.net/ubuntu/+ppas - WARNING: PPAs are unsupported third-party packages, and you use them at your own risk. See also !addppa
<EvilResistance> Ramz00z:  ^
<Ramz00z> thanks
<Ramz00z> Didn't know they had a word to say "third party packages" ^^
<EvilResistance> heh
<EvilResistance> well the nginx project has its own PPA
<EvilResistance> for up-to-date stables
 * EvilResistance has helped once or twice with them
<EvilResistance> been focusing on ZNC lately (backporting, and updating it)
<EvilResistance> oh snap, its almost class time...
<EvilResistance> *runs*
<EvilResistance> (I'm a University student, but I still find time to contribute to ubuntu xD)
<EvilResistance> oh dear, i misread the time... class doesnt start for an hour :p
<Ramz00z> Evil I think you frightened every student out there ^^
<EvilResistance> Ramz00z:  nah, i think its one of the freenode servers exploding
<EvilResistance> i've seen this before :P
<Ramz00z> nice exploding then !
<Ramz00z> launchpad is not dedicated to Ubuntu, isn't it ?
<Ramz00z> because I see an Android Project there... oO
<tumbleweed> launchpad is run by canonical, primarily for Ubuntu, but there are many other projects on it too
<Ramz00z> ok Ubuntu is just one of the projects
<EvilResistance> and this is how i know it was an explodificated server that caused that mass death:  -RichiH/Wallops- Hi all. As you probably noticed, one of our servers just had a hiccup. It seems to be stable now, but we are investigating nonetheless.
<EvilResistance> what tumbleweed said :P
<Ramz00z> yeah they can investigate... Cause it won't disappear !
<Ramz00z> always hated networking...
<toabctl> what should i do to get a package from debian sid into precise (the package is currently not in precise, so it's a new package). i already filled a sync request with requestsync. is this enough?
<Laney> yes
<Laney> just watch your mail for followups from sponsors
<toabctl> ok. thx
<jtaylor> micahg: didn't you want to look at the numpy and svn merge requests?
<micahg> jtaylor: yes, sorry. did I say I'd look at svn  also?
<jtaylor> I don't think so, but it would be appreciated :)
<philsf> hi, in natty I used dh-make-perl + dpkg-buildpackage to package a perl app I'm developing, but now in oneiric it's not working. dpkg-buildpackage says it can  parse the dependencies. Can anyone hint me on what's wrong and how can I fix this?  Paste at: http://paste.ubuntu.com/799639/
<jtaylor> philsf: can you paste debian/control please
<philsf> jtaylor, http://paste.ubuntu.com/799645/
<jtaylor> philsf: remove the perl/ and science/ before all dependencies
<philsf> jtaylor, is this a bug in recent dh-make-perl versions?
<jtaylor> no idea, it may be a feature to get people to check the dependencies
<philsf> lol
<philsf> actually, this debian/control is from the lucid version. the oneiric d-m-p version doesn't work (see first paste). any ideas what it means?
<jtaylor> hm you could try clearing your cache
<jtaylor> ~/.cpan
<philsf> I tried this, already
<philsf> oh wait. I tried in another oneiric box. in this one I don't have a ~/.cpan. It shouldn't even work without a basic config, right?
<jtaylor> don't know
<jtaylor> I'm not familiar with perl
<jtaylor> can this changelog weirdness cause any trouble when we sync? http://anonscm.debian.org/gitweb/?p=pkg-java/libhibernate-jbosscache-java.git;a=blob;f=debian/changelog;h=e208d0e4c525f0027eef470d515ddc09288cfb45;hb=HEAD
<philsf> on any other box, if I remove .cpan and invoke the cpan shell, it promply autoconfigures cpan. in this one, this isn't happening
<jtaylor> latest-debian-changelog-entry-without-new-version
<philsf> jtaylor, oh, ok. thanks anyway
<EvilResistance> by default, if i have a debian/patches/ folder, will the package building systems automatically apply those patches?
<jtaylor> if its a 3.0 (quilt) package yes
<EvilResistance> and where can i determine if its a quilt package?
<jtaylor> debian/source/format
<philsf> jtaylor, fwiw, I found out this is caused by a bug in dh-make-perl in the oneiric version. the version in debian testing 0.74-1 fixes it. btw, thanks for the pointers
<EvilResistance> jtaylor:  i forgot to say thanks :P
<l3on> cjwatson, around ? I'm looking at shogun that FTBFS ...
<l3on> full log is here â http://debomatic.debian.net/precise/pool/shogun_1.1.0-1ubuntu1/shogun_1.1.0-1ubuntu1.buildlog (16 MB)
<l3on> a snippet of build fail is here: http://paste.ubuntu.com/799742/
<l3on> the problem is in configure...
<jtaylor> didn't we already have this?
<l3on> that generates these variables:
<l3on> LINKFLAGS_STATIC_INTERFACES =  -L../../shogun -lshogun
<l3on> LINKFLAGS_MODULAR_INTERFACES=  -L../../shogun -lshogun
<l3on> LINKFLAGS_RUBY   = -lruby1.8 -fPIC -shared -ldl
<l3on> LINKFLAGS_RUBY_MODULAR  = -lruby1.8 -fPIC -shared -ldl
<l3on> ok, ruby1.8 is my test
<jtaylor> cmake?
<tumbleweed> there are .0 files after -lruby-1.9.1
<tumbleweed> .o
<l3on> tumbleweed, I see
<tumbleweed> oh, that's clag, not g++. Don't know how strict that is
<l3on> jtaylor, no cflag
<l3on> that variables should be POSTFLAGS
<jtaylor> what buildsystem?
<jtaylor> linkflags looks like cmake
<l3on> debomatic
<tumbleweed> l3on: that's not what jtaylor meant :)
<l3on> lol :D
<l3on> I'm new here, so pay patience :D
<l3on> anyway, I'm trying to patch configure, using that variables as POSTFLAGS
<l3on> do you think is the right way ?
<jtaylor> Makefile.template looks like the right place
<jtaylor> tumbleweed: can this changelog cause problems when syncing? http://anonscm.debian.org/gitweb/?p=pkg-java/libhibernate-jbosscache-java.git;a=blob;f=debian/changelog;h=e208d0e4c525f0027eef470d515ddc09288cfb45;hb=HEAD
<l3on> jtaylor, mmm but I didn't see the answer there
<jtaylor> the versions are unordered
<ScottK> jtaylor: Isn't the Debian version number lower than the Ubuntu one.
<tumbleweed> yes, it is
<tumbleweed> jtaylor: you'll need to bump the debian version number
<tumbleweed> do a manual sync
<jtaylor> ubuntu does not have that version in there
<tumbleweed> oh, so it's just a b0rked changelog?
<tumbleweed> then we're fine
<jtaylor> yes
<tumbleweed> still, file a WTF bug in debian :)
<jtaylor> can you fix published changelogs?
 * tumbleweed fixes bugs in old changelog entries
<tumbleweed> but normally whitespace
<tumbleweed> yeah you don't want to make big changes
<tumbleweed> I suppose it has to be left as is
<l3on> ah ok, I see maybe the problem in Makefile.template
<l3on> see what's happen with last patch and, in case, patch Makefile.teplate
<l3on> thanks for help :)
<jtaylor> its a weird build system
<l3on> guys is it correct:
<l3on> X-Python-Version: >= 2.5
<l3on> is I use dh_python2 ?
<l3on> (and is it right for ubuntu ?)
<jtaylor> yes
<l3on> ah ok :)
<l3on> thanks.
<l3on> so jtaylor ... this change can be dropped:
<l3on> -XS-Python-Version: 2.6
<l3on> +XS-Python-Version: 2.7
<l3on> if debian has set:
<l3on> X-Python-Version: >= 2.5
<jtaylor> debian converted to dh_python2 ?
<jtaylor> which package?
<EvilResistance> i take it that I can't get a PPA build bumped up in priority after its submitted?  I'm trying to release an updated version that patches out a vulnerability in the package, and its leaving me with a 20 hour wait time to build
<l3on> always shogun, and yes, it use dh_python2 it's strange
<l3on> s/it's strange//
<jtaylor> you can drop the XS-Py-V
<l3on> ok, thanks :)
<jtaylor> did you see that package already has an as-needed patch in ubuntu?
<l3on> jtaylor, yes I saw... but it does not work...
<l3on> but it's the same way I patched configure
<philsf> I just reported a bug in dh-make-perl (LP: #914479), that has a patch available in debian. can someone please review it and see if I need to provide anymore information?
<Laney> philsf: Are you trying to get this fixed in Oneiric? If so, it would be good if you could make a debdiff that can be sponsored.
<philsf> Laney, I don't have experience in packaging, so a debdiff is a little out of my league for now. Is there anything else I could do?
<tumbleweed> whould you like to get some experience? :)
<philsf> tumbleweed, I'm always always interested, but time is very short. is there a quick way for me to do this, or a for dummies tutorial I could read?
<tumbleweed> I'll happily walk you through a first debdiff. There's lots of documentation, but nothing short adnd to the point for this
<philsf> tumbleweed, if you think this bug applies for an SRU request, I'm game.
<tumbleweed> the patch is pretty trivial, so it should be easy enough
<tumbleweed> the apt-file issue is another bug and should be dealt with separately
<philsf> ok
<philsf> so, I never made a debdiff or prepared a patch, but I know how to get a source and compile a .deb.
<tumbleweed> so, first, this bug is already fixed in precise (where 0.74 is published https://launchpad.net/ubuntu/+source/dh-make-perl ), so you can mark it fix released, and nominate the bug for oneiric
<philsf> hmm, so this means it's also broken in precise, for the reason of the other bug (that should have been reported separately). is this correct?
<EvilResistance> tumbleweed:  if i have a fork of a package, but its not hugely different from the package that exists in Debian or Ubuntu, is there an *easy* way to merge package version changes into the fork?
<tumbleweed> philsf: it's broken for a different reason in precise, with different symptoms, right?
<tumbleweed> I'd just edit those bits out of this bug
<philsf> tumbleweed, right. should I then report another one, and link to the apt-file bug (later)?
<tumbleweed> yeah
<tumbleweed> EvilResistance: depends on how you forked it. VCS are handy for this kind of thing.
<EvilResistance> tumbleweed:  just changed what the core install actually includes (i.e. the debian/<binary>.install for a single multi-binary source package, whereas the rest of the code and what not remains the same)
<philsf> tumbleweed, how can I nominate for oneiric?
<tumbleweed> philsf: do you get a "Nominate for series" button below the yellow bar? (I can't remember if everyone sees that these days)
<philsf> tumbleweed, no. only "also affects project" and "... distribution"
<tumbleweed> meh, ok, you have to ask for nominations on IRC then
<Laney> I think it got taken away
 * tumbleweed 'll do it now
<tumbleweed> Laney: what does one have to do to be able to nominate then? join bugcontrol?
<tumbleweed> philsf: right, so a debdiff is just a patch that'll apply to a source package
<Laney> pretty sure you have to be a bug supervisor, yes
<tumbleweed> start by grabbing the source: pull-debian-source dh-make-perl oneiric
<tumbleweed> yeah, people used to abuse nominations a lot. I'm sure I did too, when I was a user who didn't know what it was for
 * philsf may also be guilty of that
<philsf> Error: Failed to download: dsc could not be found anywhere
<Laney> pull-lp-source ;-)
<tumbleweed> true, :)
<philsf> lol, ok done
<tumbleweed> right, now apply the patch you have, but throw away its changelog entry, and write your own (with dch -i)
<philsf> should I edit the changelog out of the patch before applying?
<tumbleweed> you could also do that
<tumbleweed> it should target oneiric-proposed as the distribution
<tumbleweed> and the version number should be smaller than the one in precise and bigger than the one in oneiric. We recommend 0.73-1ubuntu0.1
<tumbleweed> (see https://wiki.ubuntu.com/StableReleaseUpdates  for all the details)
<philsf> ok, changed version and target in changelog, nothing else so far. wil try patching now
<tumbleweed> "dch -e" should let you edit it, and substitute your name and e-mail address in
<philsf> oh, that's better
<tumbleweed> the changelog entry should close the LP bug
<tumbleweed> (the syntax is LP: #XXXX)
<philsf> ok, not a very creative changelog, but I guess it works
<philsf> patched, and changelog created for new version
<philsf> what now?
<tumbleweed> debuild -uc -us -S
<tumbleweed> cd ..
<tumbleweed> debdiff old.dsc new.dsc > debdiff
<tumbleweed> review the diff, attach to the bug
<tumbleweed> (oh, and building a deb and testing it is probably not a bad idea)
<EvilResistance> that last statement there is definitely true
<philsf> ok, will build
<philsf> dpkg-buildpackage -b -uc -us?
<tumbleweed> that'l lwork
<tumbleweed> we tend to use clean environments (pbuilder / sbuild) for most building, but there's nothing wrong with a quick-and-dirty build for testing something like this
<philsf> unmet deps. :(
<tumbleweed> ah, that's another place where build systems help
<philsf> so, how do I do this properly?
<philsf> should I apt-get build-dep ?
<tumbleweed> you want to set up a pbuilder?
<jtaylor> I recommend mk-build-deps -r -i, easier to remove them all again
<tumbleweed> +1 to mk-build-deps over apt-get source
<philsf> do I run it inside the source dir, or where the .dsc is?
<tumbleweed> in the source dir
<philsf> ok, build deps installed, and package building (in test phase)
<philsf> dh_auto_test: perl Build test returned exit code 255
<tumbleweed> yay
<philsf> did I patch it wrongly? I entered the source dir and patch -p1 < ../patch
<philsf> but before I tried without -p1, wonder if it matters
<tumbleweed> just busy replicating it here
<philsf> ok, brb in 5min
<tumbleweed> hrm, this test seems to be hammering the internet. Naughty test
<tumbleweed> philsf: I see test failures at "t/dists.t line 82."
<Laney> there are fixes to that file in git
<tumbleweed> ah, thanks laney. I got sidetracked in another #
<philsf> so, what should I do now? does this complicate the patch?
<philsf> after that error, I'm retrying the build and t/cache.t is taking forever.
<Laney> it seems like the test suite had bugs
<Laney> you probably need the last change on http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/dh-make-perl.git;a=history;f=t/dists.t;h=f13e477a52ec0158b2f8bdcfb0cebd7a765beabc;hb=HEAD
<Laney> and possibly other ones too
<philsf> oh boy...
<Laney> hey, at least the problem has (probably) already been fixed for you :P
<philsf> lol. I thought it would be a simple patch-and-conquer. :/
<tumbleweed> the simple-looking ones always turn out harder than they look :)
<philsf> this last diff seems larger than the original patch
<tumbleweed> well, the origional patch was 4 characters + a test :)
<philsf> but AIUI the samller the patch, the better the chances it will be accepted for SRU
<philsf> for my purposes, downgrading to the natty version works around the bug
<tumbleweed> I don' tsee that being an issue here
<philsf> but we also can't be sure this other diff will be enough, and it's already kind of late for me here
<philsf> thanks for your time, but I think I'll get back to this tomorrow (maybe)
<tumbleweed> philsf: sure, night
<philsf> tumbleweed, thanks again. and sorry for your time
<tumbleweed> np
<l3on> finally shogun built fine !
<cjwatson> jtaylor,Ampelbein: I'm afraid you read the d-i internals docs wrongly a few days back.  udebs must not depend on non-udebs, and vice versa.  Doing so will fail.
<cjwatson> jtaylor,Ampelbein: udebs may Build-Depend on debs, though (in fact, they may *only* Build-Depend on debs)
#ubuntu-motu 2012-01-11
<kpennalt> Hello all
<kpennalt> I'm having an issue with the alpha release of 12.04, and I was wondering if this is an appropriate place to ask for help?
<EvilResistance> kpennalt:  #ubuntu+1
<EvilResistance> would be better
<EvilResistance> but you should be able to ask here too
<kpennalt> appreciate the advice - I'll try the other channel first
<cjwatson> next time somebody who can use syncpackage has a sync request to do, would you mind doing it with requestsync instead just the once and letting me know?
<cjwatson> I'm working on converting the requestsync backend to syncpackage, and would appreciate a real test case
<tumbleweed> cjwatson: if sponsors can syncpackage it themselves, will the archive admins still be handling requestsync bugs?
<cjwatson> Hopefully not
<cjwatson> But I'd like to keep that code around for a while to deal with any that come through sponsors who are less up-to-date
<tumbleweed> yeah, I'm sure there'll be a few..
<Laney> there are some syncs in the queue currently
<tumbleweed> well, we haven't gone out of our way to annunce syncpackage...
<cjwatson> Laney: one, and it's one I need to check with Kubuntu people first
<cjwatson> unless you mean you just added some
<Laney> no
<Laney> I see quite a few though
<Laney> the sponsor queue, not the AA one
<cjwatson> ah
<cjwatson> OK, I'll review/steal one off the sponsor queue then
<cjwatson> excellent, https://bugs.launchpad.net/ubuntu/+source/git/+bug/913977 worked
<ubottu> Ubuntu bug 913977 in git (Ubuntu) "Sync git 1:1.7.8.3-1 (main) from Debian unstable (main)" [Undecided,Fix released]
<Laney> nice
<cjwatson> committed to ubuntu-archive-tools
<Laney> can any developer (with access) use mass-sync now?
<StevenK> I'd hope not.
<Laney> I don't see how it's any worse than sponsoring syncs manually
<cjwatson> Laney: Yes, should be possible
<cjwatson> StevenK: What Laney said
<cjwatson> Laney: Although as tumbleweed says, the entire "feed sync requests to ubuntu-archive" system should basically be considered deprecated at this point
<Laney> right. I wasn't suggesting that (although we really ought to announce this), just that mass-sync might be convenient for more general use.
<cjwatson> StevenK: You aren't confusing mass-sync with auto-sync, are you?
<cjwatson> Laney: mass-sync's interface is a right mess.  It's probably easier to just use syncpackage directly.
<cjwatson> Most people aren't in the position of needing to use it in bulk after somebody else has reviewed bugs one by one.
<StevenK> cjwatson: Oh, mass-sync is not sync-source -a?
<cjwatson> StevenK: That's auto-sync.
<Laney> fair
<StevenK> cjwatson: Right, complaint withdrawn
<cjwatson> StevenK: Launchpad doesn't have any particular access control on Archive.copyPackages AFAICT, which is the backend for auto-sync; but I put a guard in the API script itself.
<StevenK> We ought to
<cjwatson> (Obviously you can remove that if you know what you're doing, but I'm more worried about the people who don't.)
<cjwatson> I'd have called auto-sync mass-sync, but the name was already in use
<cjwatson> StevenK: Mm.  Archive owner?
<cjwatson> (That's what auto-sync currently checks for.)
<StevenK> cjwatson: But that doesn't work either
<cjwatson> Why not?
<StevenK> cjwatson: copyPackages is called by mortals
<cjwatson> Example?
<StevenK> And we'd like the security team to use it instead of whatever create delayed copies
<cjwatson> Surely the security team would use copyPackage, not copyPackages.
<cjwatson> The latter being the mass interface that e.g. doesn't send notifications.
<StevenK> Oh, right
<cjwatson> Naming FTW
<StevenK> Damnable interfaces that are almost identicaly named
<StevenK> Right, archive owner for copyPackages sounds okayish
<cjwatson> Feels like copyPackage should be as it is now and copyPackages should be launchpad.Edit.
<cjwatson> (Which is archive owner or admins.
<cjwatson> )
<cjwatson> That said I don't know how derived distributions are using copyPackages.
<StevenK> Possibly. Sadly, my head is full of CSS garbage so I can't really comment.
<Laney> I was still thinking about extending syncpackage to support syncing multiple sources at once. That would have to use copyPackage then, although I imagine the batches used would be small enough not to be a problem.
<Laney> maybe a -y flag would be better
<cjwatson> Laney: This is one reason the naming is misleading.  Even if syncpackage supports syncing multiple sources, it should use Archive.copyPackage one at a time, because you still want the notifications.
<Laney> cjwatson: Sure. The consideration would have been the impact on LP vs. the utility of the notification email.
<cjwatson> I doubt LP will particularly notice the impact of multiple copyPackage calls vs. one big copyPackages call.
<Laney> right, particularly at the sizes individual developers will be using it at.
<cjwatson> Unless it's actually a full auto-sync, which I still maintain belongs in a separate tool even if it shares more code with syncpackage than it currently does.
<Laney> One of the main benefits is being able to open up this task to non-canonical AAs, which you still get.
<Laney> Seems like a sane change to me.
<cjwatson> Laney: Right.
<cjwatson> Laney: Also security.  The processes involved in supporting sync-source.py mean, as a side-effect, that archive admins can currently almost certainly forge uploads from any developer if they try hard enough.
<cjwatson> (I mean Canonical-employed AAs.)
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/remove-sync-source/+merge/88190 up now to kill it with fire
<dupondje> where could I find a list of packages that are included on cd ?
<cjwatson> broder: So, what do we need to do to have backports no longer going through archive admins?
<cjwatson> broder: backportpackage looks mostly OK, but (a) I think it should probably use debuild -nc if you're going to be using it for actual uploads, (b) does it need to handle correct versioning of successive backports of the same package?, (c) do you (plural) reliably have privileges to upload the result?, (d) there's still a warning in backportpackage(1) about uploading to Ubuntu although I guess ~ubuntu-backporters can ...
<cjwatson> ... disregard that
<cjwatson> (I know there's the queue admin issue as well, but I don't mean that bit of the process for the moment)
<tumbleweed> cjwatson: -nc has already been committed to the repo
<dupondje> dpkg-architecture -qDEB_HOST_MULTIARCH doesn't work in pbuilder ?
<cjwatson> tumbleweed: oh good
<Laney> cjwatson: I'm not sure if anybody found out what the actual effective ACL of -backports is.
<Laney> I understand it to be ~motu, but that could be folklore
<Laney> ScottK: any clue?
<ScottK> I'm reasonably certain that's more than folklore, but I've been core-dev so long, I've no actual knowledge.
<ScottK> Upload a backport from a Main package and see.  I can always reject it.
<Laney> sure.
 * cjwatson digs through LP code
<cjwatson> It seems unlikely.  The do-you-have-permission-to-upload type methods don't generally take pockets.
<Laney> I think it was ScottK that told me this initially, so that might explain why he believes it to be the caseâ¦
<ScottK> It probably was me.
<Laney> all backports uploads go to unapproved, yes?
<ScottK> I thought we tested it, but I could be wrong.  Not sure who the other part of we was either.
<ScottK> They do.
<Laney> right. uploading.
<ScottK> To what series?
<Laney> oneiric-backports
<micahg> ScottK: backports?  that was me :)
<ScottK> Ah.  Right.  I remember now.
<micahg> UDS-N
<cjwatson> The checks are (1) can *anyone* upload to this pocket (i.e. not RELEASE for stable release, or whatever); (2) ACL for sourcepackagename; (3) ACL for packageset/distroseries; (4) ACL for component
<cjwatson> AFAICS
<cjwatson> lib/lp/soyuz/model/archive.py:verifyUpload
<Laney> Rejected:
<Laney> Signer is not permitted to upload to the component 'main'.
<Laney> so I wouldn't be a fully effective backporter.
<cjwatson> Right.  So I propose:
<cjwatson>  (1) Somebody should file a Launchpad bug to let us have per-pocket ACLs, if there isn't such a bug already.
<ScottK> Laney: Most backports aren't uploaded by hand.  It's relatively rare.
<cjwatson>  (2) We look into changing mass-sync.py to use backportpackage (i.e. called by archive admins).
 * ScottK looks at Laney for (1).
<cjwatson> ScottK: Right, but I was asking whether we could have backporters use backportpackage and upload directly rather than going through ubuntu-archive.
<ScottK> I see.
<ScottK> I missed the first part of the conversation.
<cjwatson> I want to kill the backdoor interface currently used by backport-source
<cjwatson> It was piggybacking on top of sync-source, and that's in the process of dying
<cjwatson> Unfortunately (2) would mean that archive admins would have to sign backports, which is less than ideal
<cjwatson> (1) isn't trivial; the ArchivePermission model would need to be extended
<cjwatson> But seems like the right answer, ultimately
<Laney> Would per-pocket ACLs be required for -security moving to copyPackage too?
<Laney> required in as far as there could be security team members without core-dev
<micahg> Laney: there are 3 at present
<Laney> micahg: how do you handle copies from the security PPA? Have an archive admin do them (using syncSource?)?
<micahg> Laney: no, we can copy into -security ATM as long as the API doesn't time out
<Laney> so long as you have upload access to the package?
<StevenK> They have a script that calls an LP API method that has a hardcoded -security check.
<StevenK> Which is disgusting.
<Laney> oh, yikes
<micahg> Laney: no, ubuntu-security owns the security pocket AFAIK
<Laney> StevenK: so that method checks the person is in ~ubuntu-security?
<StevenK> I don't recall, and I'm juggling eggs.
<Laney> k
<Laney> micahg: could you check your script to see which API method it pokes?
<micahg> archive.syncSource
<StevenK> While I wait for 'make' -- we, as in LP devs, want to kill that method.
<StevenK> Shortly followed by destroying delayed copies.
<l3on> hey guys I worked on merging zabbix 1.8.9
<l3on> there is a new version 1.8.10 that fixes a CVE, should we adopt it ?
<broder> cjwatson, Laney, ScottK: changing to per-pocket upload ACLs would contradict the TB's decision about pre-release backports
<broder> (on a train at the moment; wifi is spotty; may come and go)
<laney_> since when did a univeristy need internet access anyway?
<tumbleweed> sounds like your sysadmins are learning from ours
<broder> cjwatson: i'm not sure what you meant by "(b) does it need to handle correct versioning of successive backports of the same package?"
<cjwatson> broder: contradict TB> hm, you'll have to remind me how?
<cjwatson> broder: backport-source currently has a thing where if you try to backport the same thing twice you'll get ~oneiric1, ~oneiric2, etc., presumably for rebuilds
<cjwatson> backportpackage only does ~oneiric1
<broder> cjwatson: https://lists.ubuntu.com/archives/technical-board/2011-November/001137.html
<broder> TB's decision was that the upload ACL for backports should match the rest of the archive
<dupondje> dpkg-architecture -qDEB_HOST_MULTIARCH doesn't work in pbuilder ?
<broder> cjwatson: i haven't run into successive backports like that in practice, but it sholudn't be too hard to modify backportpackage to handle it
<cjwatson> broder: "as opposed to <thing we determined just now is untrue>" ;-)
<cjwatson> I think I'd like to revisit that given that it was based on a false premise
<cjwatson> and I find the notion of something that a team must approve but cannot directly perform to be a bit bizarre
<cjwatson> I can imagine that we might have wanted to fix the situation where MOTU could upload any package to -backports, but we've just determined by both code inspection and experiment that that isn't the case
<broder> sure :)
<broder> so i guess in that case the goal would be for ubuntu-backporters to be able to upload anything? that certainly seems acceptable to me
<cjwatson> If they're the sole approver for -backports in practice, then that seems sensible
<cjwatson> but if you like, I'll run that by the TB list
<broder> i guess i haven't really dealt directly with enough TB decisions to have a sense of when that's appropriate - whatever you think is reasonable is fine with me
<Laney> cjwatson: #914779
<Laney> bug #914479
<ubottu> Launchpad bug 914479 in dh-make-perl (Ubuntu Oneiric) "dh-make-perl cache is broken in oneiric" [Undecided,New] https://launchpad.net/bugs/914479
<Laney> erm
<Laney> bug #914779
<ubottu> Launchpad bug 914779 in Launchpad itself "Pocket maintainers cannot always upload to their pocket" [Undecided,New] https://launchpad.net/bugs/914779
<cjwatson> ta
<cjwatson> ScottK: do you have an opinion on bug 848916
<cjwatson> ?
<ubottu> Launchpad bug 848916 in webkitkde (Ubuntu) "Sync webkitkde 1.1.0git80efcf77-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/848916
<cjwatson> I've been deferring it until I got a chance to talk with somebody who knew about Kubuntu to ack it ...
<ScottK> cjwatson: It's got no external rdepends or reverse build depends and the reason not to sync has gone away (Debian badly versioned an svn snapshot at one point).
<ScottK> No objection from me (seems like a good idea)
<cjwatson> OK, great - thanks
<ScottK> You're welcome.
<cjwatson> Thinking about it, I think I initially deferred that bug because I first saw it when oneiric was frozen and it seemed like a "no way" then
<ScottK> There was a time when syncing it would have been really bad because it would have replaced a release with a pre-release svn snapshot.
<ScottK> Nice that's over.
<roaksoax> hi/win 3
<l3on> Hi all... hey guys, there some my merging bugs still pending... is there a motivation why they do not get attention by sponsors, or it's just the queue ?
<micahg> l3on: just the queue
<micahg> l3on: patch pilots will be back next week as well
<l3on> ah ok :) thanks micahg, so I can continue about merging :P
<micahg> l3on: please, also, did you get an answer to your zabbix query?
<l3on> micahg, nu, I have written again in -devel about some mins ago... still waiting
<micahg> l3on: so, to answer your question, you can just wait until 1.8.10 is uploaded to Debian if you believe it'll happen soon
<l3on> micahg, Ok, in fact I emailed maintainer, wait for a reply...
<l3on> I also have the 1.8.9 debdiff, it introduces a patch to fix FTBFS with ld --as-needed, should I request an upload in Ubuntu ?
<micahg> l3on: if you believe 1.8.10 to be coming soon, maybe upstream the ld --as-needed fix to Debian
<l3on> ok, I'll do it
<Laney> cjwatson: Backporters who are also core-devs could also do (1). I think that's everyone active except me.
<cjwatson> Laney: well, yeah, it winds up much the same thing.  Still, the fact that backporters isn't a subset of core-devs indicates that the model needs fixing, IMO
<Laney> Right, but it's better than requiring archive admins to be more involved
<micahg> also, the number of main backport requests should be on the lower side as they'd be more likely to break things
<broder> hmm. i'm actually kind of curious about that
 * broder runs to hte udd-mobile
<broder> http://pastebin.ubuntu.com/800727/
<cjwatson> Laney: Isn't that equivalent to (2) anyway?
<cjwatson> Laney: I suppose you might subscribe ubuntu-archive to the backports you approve, or something
<cjwatson> Seems a bit roundabout though :-)
<cjwatson> Should backportpackage gain an option to close bugs, like syncpackage has?
<Laney> indeed, just that I wouldn't block it on the permissions bug being fixed though
<cjwatson> (It could do that by putting the bugs in the changelog, which might be more sensible than API closures)
<cjwatson> Laney: oh, right, I don't want to block this on that either way
<broder> Yeah, since we're already adding a changelog entry for backports, I think I'd just as soon do this with changelog closers than separately
<cjwatson> Having mass-sync.py run backportpackage isn't particularly worse than what we have now, and we can incrementally improve from there
<cjwatson> (Except for archive admins who aren't core devs, but realistically, I don't think they're processing backports anyway)
<ScottK> cjwatson: bugs in changelog won't clost backports bugs.
<cjwatson> Oh really?  Bugger
<ScottK> That'd be another LP change.
<Laney> as in you could do 2 right now, and remove the AAs already
<cjwatson> I guess that sort of makes sense
<cjwatson> Ish
<Laney> apart from the queue bit I suppose
<micahg> broder: I wonder how many of those are ScottK backporting clamav :)
<broder> micahg: 71 :)
<cjwatson> Laney: Right - but we need something equivalent to mass-sync.py until nobody's processes involve subscribing ubuntu-archive to sync/backport bugs any more, anyway
<Laney> only backporters should be doing that
<broder> cjwatson: Switching to backportpackage for AAs does have the problem that you now have 2 AA actions to process a backport
<broder> Since it would land in UNAPPROVED
<cjwatson> True, but they often enough land in NEW anyway
<steven> admin
<cjwatson> My motivation is not so much reducing AA workload as weaning us off shell access
<cjwatson> I'm willing to accept some small inconveniences as part of that (not large ones, though)
<broder> More random backports stats, for people who are as easily entertained as me: http://pastebin.ubuntu.com/800738/
<micahg> o/
<micahg> weird, from intrepid-maverick, main backports outnumbered universe
<micahg> oh, except for lucid
<ScottK> clamav moved to main in Intrepid. ...
<l3on> micahg, patch forwarded to upstream and debian :)
<micahg> l3on: thanks
<micahg> ScottK: ah, that explains it :)
<ScottK> I suspect it explains some fraction of it.
<micahg> well, it won't explain karmic
<jtaylor> hm python and python2.7 provide argparse
<jtaylor> it should only be provided by one of them or?
<jtaylor> hm yes as you know can't build the rdepends anymore :(
<Resistance> so... my sync request for ZNC was approved... broder, if i wanted to have natty and oneiric backports updated for the new release, would i just submit a new backport request bug, and add both natty-backports and oneiric-backports to the bug?
<Resistance> stating that the backport request is to address a vulnerability in the version that already exists and contains a fix?
<broder> yeah, that sounds right
<Resistance> mmm
<Resistance> i'll get to that as soon as i clean my ext4 partition
<Resistance> got to get the livecd image onto this USB stick here
<Resistance> broder: should i flag the backport as a security vulnerability thereby making it a higher priority, or is that not necessary?
 * Resistance is writing the backport request now
<broder> i don't know that that accomplishes anything
<Resistance> because on the sync request i flagged it for the Sec team to review (because ZNC 0.202-2 fixes a DoS vulnerability)
<broder> is it other people's experience that youtube-dl is busted in anything older than oneiric?
 * tumbleweed only uses it on sid and precise, so no idea
<broder> my inclination is to just upload srus of the version in oneiric to the older releases
<tumbleweed> sounds reasonable
<Resistance> broder:  whats the bug number for that bug which blocks backported build-deps from being used to build packages for backports (in the archive)?  Its on my Linux machine (currently broken due to unclean ext4 partition), not on this machine i have in front of me
<tumbleweed> have you tried searching lp? :)
<Resistance> tumbleweed: with no success, i'll try again though
<tumbleweed> search bugs.launchpad.net/launchpad
<broder> Resistance: i don't know - i'd have to go find it
<Resistance> found it
<dupondje> dpkg-architecture -qDEB_HOST_MULTIARCH doesn't work in pbuilder ?
<dupondje> a build that uses it in debian/rules seems to fail, while it build fine on launchpad ...
<Resistance> broder: Bug #914996 is the new backport request, for when you get around to it.
<ubottu> Launchpad bug 914996 in Oneiric Backports "Please backport ZNC 0.202-2 from Precise to Natty" [Undecided,New] https://launchpad.net/bugs/914996
<Resistance> also tagged it for Oneiric backports too
<tumbleweed> dupondje: I see no reason why it wouldn't work
<dupondje> tumbleweed: well its strange
<dupondje> try building espeakup
<dupondje> I get: gcc-4.6.real: error: /usr/lib/libespeak.a: No such file or directory
<jtaylor> espeakup needs fixing for the last espeak update
<jtaylor> I have a branch on lp
<jtaylor> I'm waiting for the change in debian before I apply it
<dupondje> jtaylor: the current version in ubuntu doesn't build neither
<jtaylor> I know
<jtaylor> it builds on debian as espeak is not yet updated there
<jtaylor> I'm waiting until its done there and going to sync
<dupondje> ok :)
<jtaylor> the fix is simple
<jtaylor> the same as the libjack multiarch fix
<broder> tumbleweed: ugh. actually, i feel slightly questionable about this because youtube-dl does more than just youtube these days
<broder> and the other sites aren't broken
<dupondje> jtaylor: there is no bug for it on debian ?
<jtaylor> its not broken in debian
<dupondje> well not YET I guess ?
<jtaylor> yes
<dupondje> so its usefull to get it patched before it breaks :)
<jtaylor> you can't
<jtaylor> not cleanly at least
<dupondje> hehe ok :)
<dupondje> btw another thing
<dupondje> what to do with requestsync when the changelog on debian is fucked (aka 404)
<jtaylor> write it per hand :)
<ScottK> (copy/paste not write)
<dupondje> i'm lazy :)
<ScottK> The lazy way is try again a few days later.
<jtaylor> I had such an issue once, it never when away
<jtaylor> debian changelogs are weird since a while
<tumbleweed> dupondje: that shouldn't happen any more
<tumbleweed> grab a more recent ubuntu-dev-tools
<dupondje> http://packages.debian.org/changelogs/pool/main/y/yacas/current/changelog
<dupondje> just doesn't include last changelog ...
<tumbleweed> it now gets the changelogs from launchpad
<tumbleweed> broder: youtube is still its primary reason for existance
<tumbleweed> hrm, I see debian doesn't have it in *stable, but it is currently in testing
<broder> fair enough. i'm inclined to agree, but wanted to see if someone else thought that way as well
<tumbleweed> I seem to recall it being in volatile in the past
<tumbleweed> broder: I do feel for things like this that once we've started doing it, we need to keep it up
<tumbleweed> otherwise there's no trust from the users that youtube-dl in stable releases will work. (I'm sure I keep a git checkout somewhere for when it's broken in debian)
<l3on> do you know if it's possible change status to bug via lp-python api ?
<tumbleweed> ye
<tumbleweed> s
<l3on> tumbleweed, I got a bug, and I can add attachment.. but now?
<l3on> I saw api, after a quick look I can see the way
<l3on> I'm playing with this: https://bugs.staging.launchpad.net/ubuntu/+source/forked-daapd/+bug/896668
<ubottu> Ubuntu bug 896668 in forked-daapd (Ubuntu) "Please merge forked-daapd 0.19gcd-2 (universe) from Debian unstable " [Undecided,Fix released]
<tumbleweed> so, what's the problem?
<l3on> I would like 'confirm' that bug and add subscription :)
<l3on> and remove assignment as well
<tumbleweed> status is an attribute of the bug_task, not the bug
<tumbleweed> you should be able to work it out from the documentation: https://launchpad.net/+apidoc/1.0.html
<l3on> ok, thanks :)
<lfaraone> I have a universe package (pianobar) which is badly broken due to external changes. Can I  upload a new upstream version, packaged in Precise, which fixes this bug (among other things?)
<lfaraone> Fixing the bug in a cherrypick has proven difficult.
<broder> I would upload the fix and be explicit about what you're doing in the bug description, and let ubuntu-sru make that call when they review it
<ScottK> lfaraone: We're a month before feature freeze, so a new version is no problem.
<lfaraone> ScottK: Sorry, I meant to oneiric.
<ScottK> If it's very badly broken that's sometimes acceptable, so as broder said.
<ScottK> Make sure it's in precise first.
#ubuntu-motu 2012-01-12
<lfaraone> ScottK: just synced it, and uploaded the new package.
<lfaraone> (to -proposed)
<ScottK> K.
<psusi> how do you invert true/false in shell?  like if !false ; then echo true ; fi?
<broder> add a space after the bang
 * psusi facepalms
<EvilResistance> broder:  can you do a check on whether i included all the info needed for a backport request?  Bug #914996 if you could take a gander
<ubottu> Launchpad bug 914996 in Oneiric Backports "Please backport ZNC 0.202-2 from Precise to Natty" [Undecided,New] https://launchpad.net/bugs/914996
 * EvilResistance wants to make sure everything is in order
<broder> EvilResistance: sorry, can't today - i'm tied up with other stuff until the beginning of next week
<EvilResistance> ok
<broder> i'll just be around to make random snarky comments :)
<EvilResistance> anyone else who's a MOTU able to?
<broder> s/MOTU/ubuntu-backporters/
 * EvilResistance doesnt need it processed, just needs to know everything's there
<EvilResistance> right.
<EvilResistance> :P
<jmccrohan> Debian maintainer here. A new version of my package entered Testing today, but I belive the Precise sync happened on Monday. Would someone be so kind as to manually upload my package?
<jmccrohan> Or is that possible?
<EvilResistance> jmccrohan:  what package?
<jmccrohan> lcd4linux
<EvilResistance> jmccrohan:  link to the packages.debian.org page for me please
<EvilResistance> whilst i fiddle with my DNS resolver
<jmccrohan> http://packages.qa.debian.org/l/lcd4linux.html
<EvilResistance> you can request a sync, too, if you want :P
<EvilResistance> that'd be what you'd ideally need to do
<EvilResistance> or have someone do for you
<jmccrohan> EvilResistance: Ok. How do I do that? (Totally unfamiliar with process)
<EvilResistance> um... lemme dig in my logs
<jmccrohan> File a sync request that is. Just a bug report against the package?
<EvilResistance> someone referenced a script to help
<EvilResistance> unstable is sid, right?
<EvilResistance> (in debianworld)
<EvilResistance> jmccrohan:  i'm assuming you'd know the answer to that :P
<EvilResistance> jmccrohan:  also, there's a script in ubuntu-dev-tools called requestsync
<EvilResistance> that can be used to streamline the request for sync process
<jmccrohan> EvilResistance: Yup. unstable is perpetually Sid.
<EvilResistance> jmccrohan:  you okay if I send you a privmsg?
<jmccrohan> EvilResistance: Sure.
<EvilResistance> ScottK:  around?  i assume not, but it never hurts to ask :P
<ScottK> Why would you assume that?
<EvilResistance> the hour :P
<ScottK> Meh.  Sleep is for the weak.
<EvilResistance> i assume you're getting the updates for bug 914996?
<ubottu> Launchpad bug 914996 in Oneiric Backports "Please backport ZNC 0.202-2 from Precise to Natty" [Undecided,New] https://launchpad.net/bugs/914996
<ScottK> Probably not, I think I forgot to subscribe to it.
 * ScottK looks
<EvilResistance> well there's new references to the prior backport request
<EvilResistance> for ZNC 0.202-1 (from Precise, back when it was fresh out of Debian Unstable to the precise repos)
<ScottK> I see now.
<EvilResistance> ScottK:  the build-deps of `swig` and `swig2.0` conflict in Ubuntu, cause dpkg failures, which in turn lead to build failures
<ScottK> Got it.
<ScottK> I'll try and take a look at it tomorrow if broder doesn't get to it first.
<ScottK> Generally we want debdiffs, but I understand you're in a bad spot and it's a security issue ...
<EvilResistance> mmm
<EvilResistance> indeed
<EvilResistance> although i had indications this system was on the road to death...
<EvilResistance> bad blocks, bad sectors, etc.
<EvilResistance> they keep popping up too
<EvilResistance> ScottK:  you'd also have to guide me through the process of generating a debdiff, if my system were usable.  i'm familiar with git diffs, but not deb diffs
 * EvilResistance curses his computer, digs around for his LiveUSB
<ScottK> It's not that hard.
<micahg> if you can generate a source package, you can generate a debdiff
<EvilResistance> micahg:  if my system hadnt explodified itself, i'd be able to do both
<EvilResistance> hence why i need to find my liveusb
<EvilResistance> okay, now that i'm in the linux environment, and i installed the tools, someone want to explain how i'd generate the debdiff?
<ScottK> EvilResistance: You've got devscripts installed?
<EvilResistance> ScottK:  mhm
<ScottK> Did you grab the old version of the package and then make a new version of your package?
<ScottK> EvilResistance: ^^^
<EvilResistance> not yet, considering i'd theoretically have to merge ZNC 0.202-2 with ZNC 0.202-1 in order to get the diffs...
<EvilResistance> s/diffs/changes/
<EvilResistance> oh crap i just realized what the hour is...
<EvilResistance> i should sleep, i have to be up at 06:45 (its 01:38 atm)
<EvilResistance> i'll make the debdiff later
 * EvilResistance needs sleep right now
<ScottK> EvilResistance: OK. It's just debdiff old.dsc new.dsc > somename.debdiff
<dholbach> could anyone imagine giving a session at UDW about working with Debian? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable
<dholbach> we still a bunch of slots open and this time we also have the possibility to have 30m sessions
<Laney> I see opportunities for two 30m sessions there: working /with/ Debian and working /in/ Debian
<Laney> one is like how to set up reportbug and stuff and the other is how to maintain your stuff in Debian and find sponsors and so on
<Laney> dholbach: #debian-ubuntu ?
<dholbach> Laney, that sounds like a great idea
<dholbach> sure, I can ask there as well
<Laney> I could possibly do one of them
 * tumbleweed could too
<Laney> but a more 'pure Debian' person might have a differently interesting perspective
<tumbleweed> hard to find "pure Debian" people in Ubuntu :)
 * Laney looks at Rhonda :P
<dholbach> Laney, tumbleweed: which slot would suit you for a "working with debian" session? you'd be quite the double act :)
<Laney> 1830 or 2000 on wednesday could work
<tumbleweed> both work for me too
<tumbleweed> I see we have a shorter "week" this time
<Laney> UDHW
<Laney> claiming 1830
<dholbach> tumbleweed, yes, the days are longer and with shorter sessions we offer more topics
<dholbach> but yeah it's shorter
 * dholbach hugs Laney and tumbleweed
<dholbach> you rock
<tumbleweed> Laney: which half do you want?
 * Laney proposes Ubuntu Backports: ARB isn't the only way ;-)
<tumbleweed> broder: ^
<Laney> I'll see if anyone from the other channel steps up
<Laney> but I just put us both to share working with debian for now, as dholbach just said
<tumbleweed> worksforme
<dholbach> <3
 * Laney thinks ajmitch ought to be roped into doing something
 * nigelb seconds that motion
<nigelb> Laney: did you get your lp patch in?
<Laney> nobody reviewed it yet
<Laney> the db change needs to land
<nigelb> Ah, epic week. Right.
 * Rhonda peeks at Laney
<Rhonda> Laney: You are a DD, so you know how it works.  Done.
<nigelb> haha
<Rhonda> If you want to know what it is like to work in Debian, look at the bugreports opened by Jari Aalto against gitolite â¦  I have no nerves for much these days unfortunately.
<tumbleweed> against .*
 * nigelb looks
<Rhonda> tumbleweed: Right, but gitolite is a current good example of reopening bugs which both upstream an the maintainer agrees that they aren't (multiple times, I am at four closes to the same bug right now), removing wontfix tags, and the likes.
<Rhonda> !fun
<ubottu> Information about games on Ubuntu can be found at https://help.ubuntu.com/community/Games and http://www.icculus.org/lgfaq/gamelist.php and http://www.penguspy.com/
<Rhonda> ubottu: I wasn't talking to you :)
<ubottu> Rhonda: I am only a bot, please don't think I'm intelligent :)
<Rhonda> ! is a bad choice for a prefix character for a bot in a technical channel, me thinks.
<ubottu> Rhonda: I am only a bot, please don't think I'm intelligent :)
 * tumbleweed prefers addressing bots by nick. After all, we all have tab completion
<Rhonda> 'sactly
<ts2> Rhonda: starting a sentence with punctuation is the bad choice ;)
<tumbleweed> it's IRC, we don't use full sentences
<nigelb> wow
<Rhonda> ts2: Since when is !fun a sentence?  :)
<nigelb> heh
<nigelb> Rhonda: that is one epic bug.
<nigelb> Also, I see you are maintainer for gitolite \o/
 * nigelb is a happy downstream user.
<ts2> Rhonda: since... always
<Rhonda> A sentence contains at least of subject and verb?
<Rhonda> Do I have to fire up wikipedia for the definiton?  ;)
<Rhonda> "A sentence can also be defined in orthographic terms alone, i.e. as simply that which is contained between a capital letter and a full stop."
<Rhonda> There was no full stop involved. And no capital letter. There you go.
<tumbleweed> Rhonda: jaalto isn't a problem unique to debian, though
<Rhonda> tumbleweed: I know, likewise with â¦ kmos? What was his nick? He was send over from "you" to "us". :)
<tumbleweed> that predates me (or at least my awareness of it)
<tumbleweed> but, yes, I don't think we've worked out how to ban people successfully (and I don't think we want to)
<Rhonda> I remember that one person who was banned from ubuntu irc channels and then ranted to me in a query asking me whether I am pleased.  I wasn't even aware of the ban at that time
<Rhonda> Sorry for not replying by mail, this is easier for me right now.
<Rhonda> my son sent a wrong message now using irssi history, don't be confused
<Rhonda> Btw., 30m sessions, last time it was hard for me to keep it under an hour when speaking about the BTS (which is a huge topic, I am aware of that)
<Rhonda> the week is only three days this time?
<Rhonda> short week :)
<Laney> I am a DD, but I have an Ubuntu background. Thought it might be interesting to have someone without (so much of) one speak about Debianâ¦
<ScottK> dholbach: You might ask zack if he wants a slot to recruit people interested in Ubuntu development to work in Debian in addition.
<dholbach> ScottK, thanks for the suggestion - I think I pinged him the last time and he said something along the lines of: try a mailing list and you might reach more folks than just me :)
<ScottK> OK.
<blueyed> Is there a tool for easily backporting/uploading a package to a PPA (debian/changelog entry, debuild -S -sa and maybe dput)?
<blueyed> backportpackage probably..
<micahg> blueyed: yes, backportpackage is it
<EvilResistance> ScottK:  for Bug 914996, the debdiffs need to be made for... what, the difference between ZNC 0.202-1 in backports and ZNC 0.202-2 in Debian?
<ubottu> Launchpad bug 914996 in Oneiric Backports "Please backport ZNC 0.202-2 from Precise to Natty" [Undecided,New] https://launchpad.net/bugs/914996
<ScottK> EvilResistance: No.  Debdiff required to go from Precise to Oneriric/Natty for 0.202.
<EvilResistance> ScottK:  the package needs changing in Precise too, per the specified changes I stated in the sync request before I can effectively do that
<ScottK> I see.  Then it needs a merge, not a sync.
<ScottK> Once those changes are done it needs no additional changes to be backported to the earlier releases?
<EvilResistance> correction
<EvilResistance> it needed syncing first because 0.202-2 did not exist
<EvilResistance> everyone here said it required a sync first
<EvilResistance> if you dig around in the logs, the diffs between -1 and -1build1 remove the conflicts
<EvilResistance> within the main archive
<EvilResistance> short of me uploading -2build1 to REVU with the statement "Fixes build errors in 0.202-2 from Debian"
<EvilResistance> the archive admins would have to do that
<EvilResistance> or a MOTU
<micahg> EvilResistance: are you saying the precise upload is broke?
<EvilResistance> micahg: the precise upload has been broken since the import of 0.202-1
<EvilResistance> i caught that error when backporting in PPAs, and removed the 'swig' build-dep
<EvilResistance> in Debian, 'swig' and 'swig2.0' don't conflict
<EvilResistance> in Ubuntu, they do
<micahg> no, they don't in precise
<EvilResistance> micahg:  are you *absolutely certain* about that?
<micahg> yes
<EvilResistance> then the backported versions need the change
<micahg> yes
<EvilResistance> in Ubuntu Oneiric/Natty, 'swig' and 'swig2.0' conflict
<EvilResistance> i mention that in the backport request
<micahg> default swig is 1.3 in <precise and 2.0 in precise
<EvilResistance> micahg:  Bug 914996
<ubottu> Launchpad bug 914996 in Oneiric Backports "Please backport ZNC 0.202-2 from Precise to Natty" [Undecided,New] https://launchpad.net/bugs/914996
<EvilResistance> and I quote from the thing:
<EvilResistance> hanges Required for Ubuntu:
<EvilResistance> debian/control: Remove conflicting `swig` build-dep, which conflicts with `swig2.0` build dep. Removal will allow packages to build, except on natty (due to backported build deps not being able to be used for backports). (refer to previous backport of ZNC 0.202-1, Bug #887758)
<ubottu> Launchpad bug 887758 in Oneiric Backports "Please backport znc 0.202-1 from precise to natty" [Undecided,Fix released] https://launchpad.net/bugs/887758
<EvilResistance> the issue with the natty build is outlined in bug...
<EvilResistance> um...
<EvilResistance> Bug 888665
<ubottu> Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665
<micahg> EvilResistance: I saw, I don't have time to deal with it at the moment, maybe someone else can (if you provide a proper diff on top of the new version in precise, that could speed things up)
<EvilResistance> so basically i'd need to modify the package in order to provide the diff :P
<micahg> EvilResistance: you can take the diff from the last upload and try to apply it
<EvilResistance> micahg:  that's actually easy, assuming i modify debian/control
<EvilResistance> micahg:  they did add two .py files for the znc-python binary
<EvilResistance> the diffs wont apply unless i pull in that code
<EvilResistance> (unless i generate the debdiffs myself)
<EvilResistance> (which i can do)
<EvilResistance> might be easier for someone else to do this, because of the two files that do not exist in the backport
 * EvilResistance is running into numerous issues
<blueyed> Precise's pbuilder should know about precise, shouldn't it?
<blueyed> Oh, it's my ~/.pbuilderrc going wrong.
#ubuntu-motu 2012-01-13
<Resistance> anyone able to answer a question from #u-packaging, preferably a MOTU who understands the intricacies of the repos and stuff?
<softcoder> anyhere know if the megaglest package will be pulled into 12.4 (as its data package has) even though arm and powerpc archs fail to build?
<softcoder> if not could someone here tunr off arm and power archs so it will be fixed?
<Resistance> softcoder: its in the 12.04 repos
<Resistance> i'm not sure there's reasons for them to arbitrarily remove a package...
<softcoder> why isn't it showing here: https://launchpad.net/ubuntu/precise/+search?text=megaglest
<Resistance> esp. if i386 and amd64 build
<ajmitch> softcoder: it's in precise, it was only uploaded 5 hours ago. it wouldn't surprise me if the search index is updated less often than that
<Resistance> what ajmitch said
<Resistance> fwiw...
<Resistance> i recommend just trying to find teh source packages yourself
<Resistance> i.e.
<ajmitch> actually, it may be in the binary NEW queue, let me check
<Resistance> https://launchpad.net/ubuntu/<release>/+source/<package>
<Resistance> replacing <release> and <package> respectively
<Resistance> ajmitch: the i386 and amd64 are marked as [NEW] on the source page
<ajmitch> https://launchpad.net/ubuntu/precise/+queue - binary packages still have to be approved by archive admins
<softcoder> ahh ok thc!
<softcoder> thx guys!
<softcoder> for checking
<EvilResistance> ScottK:  around?
<ScottK> Sort of.
<EvilResistance> regarding that backport request... i dget'd znc 0.202-2, i can create a diff with the required change in debian/changelog, which i had to do because applying the debdiff of 0.202-1build1-to-0.202-2 failed because of the missing files or some other crap...
<EvilResistance> is there any other required debdiff thing that i need to do, or would that manually-generated diff file work?
<ScottK> I suspect that's OK, but I'd need to see it.
<EvilResistance> i'll give you the pastebin version for review, note that to generate the debdiff i had to add a changelog entry and debuild -S it to make the .dsc, but you can omit that when it actually gets backported... http://pastebin.com/4RLkXPR8
<EvilResistance> also, my main system is Natty, hence the 'natty' distribution entry
<ScottK> that's fine, but for a backport with changes like this you do need to provide a changelog entry.
<ScottK> target should be natty-backports and oneiric-backports (we need two)
<ScottK> Versions should be 0.202-2~oneiric1 and 0.202-2~natty1
<EvilResistance> i'll create two diffs shortly
<EvilResistance> ScottK:  should I just attach them to the bug?
<ScottK> Yes
<EvilResistance> should i mark it as a patch?
<EvilResistance> (LP's saying it looks like a patch)
<EvilResistance> ScottK:  the two diffs are uploaded to bug 914996
<ubottu> Launchpad bug 914996 in Oneiric Backports "Please backport ZNC 0.202-2 from Precise to Natty" [Undecided,New] https://launchpad.net/bugs/914996
<ScottK> EvilResistance: Looks fine.  For future reference debian/changelog entries should be wrapped at 79 chars.
<EvilResistance> ok
<EvilResistance> my mistake :p
<EvilResistance> now, since i havent had any food since lunch... i'm going to have some pizza :P
<ISK> Hey
<ISK> Hey, I packing GNU parallel, How to I do to register an ITP?
<ISK> Hey, I packing GNU parallel, How to I do to register an ITP?
<cjwatson> ISK: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518696
<ubottu> Debian bug 518696 in wnpp "ITP: parallel -- build and execute command lines from standard input in parallel" [Wishlist,Open]
<ScottK> EvilResistance: znc backports are done.  Thank you for your contribution to Ubuntu.  Please see how I edited debian/changelog for future reference.
<Rhonda> Somehow my maverick uploads to my PPA get lost.
<Rhonda> Successfully uploaded wesnoth-1.9_1.9.14-1~ppa1~maverick1_source.changes to ppa.launchpad.net for ppa-wesnoth-devel.
<Rhonda> The other three uploads are there (oneiric, natty and lucid), but not maverick â¦
<EvilResistance> ScottK:  yeah, i just did
<EvilResistance> ScottK:  the only thing failing (which i expected) is the natty backports, but i noted that their building is blocked by a crit,triaged bug in LP
<EvilResistance> Rhonda:  how long ago was that uploaded if I might ask?
<EvilResistance> it takes PPA uploads about 5 - 10 minutes before they're usually pushed into the PPA and the builders
<Rhonda> EvilResistance: Like, 4 hours?
<Rhonda> EvilResistance: https://launchpad.net/~rhonda/+archive/wesnoth-devel/+packages for the other uploads and the delay so far
<Rhonda> I didn't receive any mail, so no reject mail neither.
<cjwatson> Rhonda: Silly question, but double-check that you signed it?
<softcoder> can i ask for an artchive admin to approve (or examine and approve) megaglest
<softcoder> its in the new queue and replaces glest
<cjwatson> hm, I thought I'd processed that.  will do
<cjwatson> I know I remember syncing it
<softcoder> i checked 1 min ago and was still in the new queue
<cjwatson> oh, it needed an Ubuntu modification, that's why it didn't happen semi-auto
<cjwatson> softcoder: accepted
<softcoder> yes because miniupnpc are different between debian and ubu currently
<softcoder> thx
<l3on> Hi all.... some one can help in adding SONAME to a package ?
<tumbleweed> l3on: what are you trying to do?
<tumbleweed> package a library?
<l3on> tumbleweed, I'm trying to package a library
<l3on> buildlog is here â http://debomatic64.debian.net/unstable/pool/oasys_1.5.0+hg2291-1/oasys_1.5.0+hg2291-1.buildlog
<tumbleweed> l3on: what do you need help with?
<l3on> tumbleweed, E: liboasys: sharedobject-in-library-directory-missing-soname usr/lib/liboasys-1.5.0.so
<l3on> I'm looking at Makefile:
<tumbleweed> it should be called liboasys1
<tumbleweed> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
<l3on> tumbleweed, thanks I will look at that
<EvilResistance> softcoder:  there's a queue... have patience
<EvilResistance> oh cjwatson dealt with it :P
<EvilResistance> Rhonda:  i see a maverick version there :/
<EvilResistance> did you fix it?
<softcoder> as in doctors patients :)
<Rhonda> EvilResistance: But not 1.9.14, that is 1.9.13
<Rhonda> cjwatson: dput doesn
<Rhonda> cjwatson: dput doesn't allow upload of unsigned, so yes.
<EvilResistance> whens the freeze on new packages for ubuntu occur?
<jtaylor> 16 feb.
<EvilResistance> jtaylor:  that's in 3 days?>
<jtaylor> +31
<EvilResistance> oh feb
<EvilResistance> not jan :P
 * EvilResistance facepalms
<EvilResistance> good, i was worried because i have a package sitting in mentors.d.n waiting review/inclusion in Debian, if its included / approved sooner rather than later, i'd request it gets synced in :P
<EvilResistance> (a *new* package)
<jtaylor> hm no idea if really new packages still get in
<EvilResistance> well considering its destined for whatever the non-main repos are, i'm assuming the MOTUs know the freeze dates for non-main repo stuffs
<Laney> they do without any special effort until feature freeze
<Laney> beyond a sync request
<jtaylor> doesn't it need to go through some review?
<jtaylor> or is that just during autosync?
<jtaylor> and after muto sync acc is the same
<Rhonda> EvilResistance: You wrote to the mentors mailinglist too, not just upload it to mentors.d.n, right?
<EvilResistance> Rhonda:  the #debian-mentors @ oftc told me what to do
<EvilResistance> so yes i did :P
 * EvilResistance has been hanging out there almost as much as he hangs out on freenode
<Laney> semi automatically pushed through the queue by a script, i believe
<ScottK> EvilResistance: This is freenode.
<EvilResistance> s/freenode/here/ then :P
<softcoder> hmm getting timeout errors all days from launchpad
<softcoder> all day not days
<Q-FUNK1> https://bugs.launchpad.net/ubuntu/+bug/916303
<ubottu> Ubuntu bug 916303 in Ubuntu "ITP: smartcardpp -- C++ library for accessing Smart Cards" [Undecided,New]
<Q-FUNK1> do I need anything else before I can upload to universe?
<EvilResistance> um...
<EvilResistance> whoops wrong chan
<EvilResistance> sorry
<tumbleweed> Q-FUNK1: getting it into Debian first is preferred
<EvilResistance> ^
<EvilResistance> tumbleweed:  i've got a package that i'm repairing in the Debian mentors.d.n list, if they support it and get it into Debian, will that new package autosync into Ubuntu?
<EvilResistance> or do i have to request the sync myself?
<Q-FUNK1> tumbleweed: true.  anything else?
<tumbleweed> Q-FUNK: getting a review from another MOTU before uploading is recommended.
<tumbleweed> EvilResistance: we are past Debian Import Freeze, so it'll need to be requested
<Q-FUNK> tumbleweed: actually, according to the upload guide, it's a must.
<tumbleweed> Q-FUNK: I thought so too, but https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages seems to say otherwise
<tumbleweed> still, that doesn't look ubuntu-specific, getting it in Debian isn't a bad idea
<EvilResistance> tumbleweed:  anything i should be concerned about if i want to have that package imported into Ubuntu?  i.e. should I have a MOTU review it?  or is the fact it got into Debian good enough?
<Q-FUNK> tumbleweed: we intend to get it in debian at some point, but since I'm already a motu here but not a DM or DD, it's easier to start here.
<tumbleweed> EvilResistance: if it builds on Ubuntu, that's good enough
<EvilResistance> tumbleweed:  that is to say, builds in Precise?
<EvilResistance> (it really doesnt have any builddeps afaict except for python)
<tumbleweed> EvilResistance: yes
<Q-FUNK> tumbleweed: another thing is, the window to get this into precise is getting shorter and yet we have a series of 6 packages that need to be uploaded and built in a precise order.
<tumbleweed> yeah, I see the urgency :)
 * tumbleweed would offer a review and debian sponsorship, but not for 6 packages that could be enormous :)
<tumbleweed> anyway /me -> bed
<ajmitch> night tumbleweed :)
<tumbleweed> night
<Q-FUNK> tumbleweed: I've been making debian packages since 2003, so I would think that my review of other people's packaging would be enough. :) of course, second opinions are always welcome.
#ubuntu-motu 2012-01-14
<EvilResistance> ScottK:  is there any way to make a debian sid base.tgz within Ubuntu, for building debian unstable source packages?
<EvilResistance> or anyone else :P
<ajmitch> EvilResistance: yes, I believe pbuilder-dist should be set up to do that without having to tweak things
<ajmitch> though building source packages shouldn't be a problem
<EvilResistance> ajmitch:  the issue is building the binaries and then testing them
<EvilResistance> trying to get something into debian :P
<ajmitch> right, 'pbuilder-dist sid create'
<EvilResistance> ajmitch:  is there a way to run the built binaries within a sid chroot?  the debian mentor peoples want me to test the binaries before uploading the "repaired" source package
<ajmitch> yes, you can do it, though I usually prefer a VM for testing
 * EvilResistance had two rejected uploads of the package, but is allowed to resubmit only when he's repaired it as much as he can
<EvilResistance> you tell me how to make a sid VM that doesnt explode and i'll use that
<ajmitch> you can risk bind-mounting home, I think the PbuilderHowto wiki page has info on that
<ajmitch> 'explode' how?
<EvilResistance> ajmitch:  by "explode" i mean it results in numerous errors ranging from stdin/stdout to FATAL: Cannot stat <blah> stuff
<EvilResistance> going from stable -> unstable by modifying the apt sources list stuffs
<ajmitch> sounds fun
<EvilResistance> yeah that's what i said
<EvilResistance> in #debian-mentors @ OFTC xD
<ajmitch> yeah I saw
 * ajmitch is sitting in an airport so can't really help you through setting it up :)
<EvilResistance> OW!
<EvilResistance> damn, these compressed air cans get COLD
<EvilResistance> very quickly :/
<jincreator> Hi. Is it possible to request remove package and sync together?
<tumbleweed> why do you need to remove & sync?
<jincreator> tumbleweed: Beacuse the ppackage I want to request sync has higher version than package in Debian.
<tumbleweed> jincreator: removing it won't help
<tumbleweed> people may already have it installed, so they won't upgrade unless the version is higher
<jincreator> tumbleweed: Hmm...You are right.
<tumbleweed> which packge is this?
<jincreator> tumbleweed: ttf-unfonts-core, ttf-unfonts-extra
<tumbleweed> both have been removed from debian
<jincreator> tumbleweed: Actually changed to fonts-unfonts-core, fonts-unfonts-extra.
<tumbleweed> I see
<jincreator> tumbleweed: and there's also ttf-unfonts-core, ttf-unfonts-extra, but just metapackage.
<tumbleweed> the version for ttf-unfonts in Ubuntu is currently 1.0.3.is.1.0.1-0ubuntu1, so I suggest just following that scheme
<jincreator> tumbleweed: Well, but version fot ttf-unfonts in Debian is 1.0.2-080608-5 - higher version.
<jincreator> tumbleweed: Actually I heard merging package is one way to solve this question. But seems ttf-unfonts is not in merges.ubuntu.com. Or am I do something wrong?
<jincreator> (I have never merge package before)
<tumbleweed> jincreator: 1.0.2 < 1.0.3
<jincreator> tumbleweed: I mean 1.0.3 is actually 1.0.1-0ubuntu1
<tumbleweed> we need to do 1.0.3.is.1.0.2-080608-5ubuntu1 (or something like that)
<jincreator> tumbleweed: So, how can I merge package if it's source is not in merges.ubuntu.com?
<tumbleweed> by hand
<tumbleweed> you take every change we made, and apply it to the new version
<tumbleweed> (that's how I tend to merge, anyway, when it's not trivial)
<jincreator> tumbleweed: Hmm...after I did it, report to launchpad is enough? Seems I also need to add comment at m-o-m summary page.
<tumbleweed> yes
<jincreator> tumbleweed: I'll try. Thanks!
<KNRO> so I'm wondering, if a user can go ahead and add a PPA to their sources, how come 'one-click' install is not available in Ubuntu? i.e. ability to add repo and packages from one go?
<tumbleweed> KNRO: You can see some of the concerns to that here: https://wiki.ubuntu.com/ThirdPartyRepositoryApplicationProcess
<KNRO> tumbleweed: "last edited 2009-06-16" so it looks like nothing happened much about it. OpenSUSE has a one-click install method that worked pretty well I recall.
<tumbleweed> that's not the point. The point is that one-click install is dangerous
<geofft> I hear there's lots of Windows malware available via 'one-click' installs.
<jincreator> ls
<jincreator> oops...
<KNRO> Tumbleweed: You can ask user for permission. At any rate, the user can manually add the PPA and install the 'dangerous' software
<tumbleweed> KNRO: considering the size of the ubuntu repositories, and broken situations users are already getting into with 3rd party repositories, is that necessary?
<jtaylor> isn't there a firefox plugin that kind of does that?
<jtaylor> adds ppa's on click of a link
<KNRO> Tumbleweed: It makes software release for 3rd party folks easier. Instead of telling users how to add PPA to software center, I just say click here to download the latest version
<jtaylor> KNRO: opera has something like that
<jtaylor> they offer a deb which can be "one click" installed
<jtaylor> the deb then adds a ppa
<tumbleweed> so does google chrome
<jtaylor> so you get autoupdates
<tumbleweed> but it's ugly!
<tumbleweed> chrome even has a cron job that re-adds the ppa if you disable it :/
<tumbleweed> KNRO: how about packaging your app in Debian / Ubuntu?
<jtaylor> lol
<tumbleweed> err s/ppa/repository/
<KNRO> really, so I might look into how Opera does it :P
<KNRO> see, they have to resort to "hacks" to get that done
<tumbleweed> KNRO: we really don't encourage our users to find software on the web, but rather find it in the software centre
<KNRO> Tumbleweed: yeah, I will ask for my packages to be added to Universe soon.
<tumbleweed> KNRO: going via Debian is preferred
<KNRO> tumbleweed: Does Debian has something akin to the Universe repo?
<jtaylor> KNRO: debian has main for all free stuff
<jtaylor> which is ~ ubuntu main + universe
<KNRO> jtaylor: Ok thanks!
<jtaylor> anyone else getting hangs with apt-cacher-ng in precise?
<jtaylor> localhost works, but remotes work for a short while and then lock up
<ISK> Hello!
<EvilResistance> ScottK:  how can I run a Debian linitian check on a package, short of grabbing a debian VM and running lintian there?
<EvilResistance> i need to find out whether or not this is still occuring: W: maintainer-script-lacks-debhelper-token debian/postrm
<EvilResistance> (and if so, how to fix it)
<jtaylor> which ubuntu version hasn'T got that check?
<jtaylor> I don't think thats new
<Laney> --profile debian should work anyway
<Laney> i think
<ScottK> Yes.  It does.
<jtaylor> ubuntu does not check that?
<Laney> I can't believe that it doesn't
<jtaylor> me neither, I'm pretty sure I saw it in the past
<Laney> anyway you can just look at postrm and see if the token is there
<EvilResistance> is the token just #DEBHELPER#?  that's what the lintian docs over at Debian say, but i'm not sure
<Laney> yes, do lintian-info -t maintainer-script-lacks-debhelper-token
<EvilResistance> ah.  well i think i fixed that lintian error now... :)
<alkisg> On my-package.postinst, I want to display a notice to the users that I regenerated a certificate that had expired, and they need to copy it to all their computer lab clients, otherwise the program won't work.
<alkisg> What would be an appropriate way to do that? A debconf note?
<jtaylor> Debian.news probably
<jtaylor> NEWS.Debian
<alkisg> Ah, thanks, I couldn't find it in google :)
<jtaylor> though that won't be displayed by default
<alkisg> Hmm that won't do then
<alkisg> I only have a few users, and it's only going to be for that one upgrade, so I know they'll appreciate the notice, it won't annoy them
<Q-FUNK> hi
<Q-FUNK> would anybody be interested in reviewing a suite of 6 packages that are ready to submit to Precise's NEW queue?
<EvilResistance> um... werent you here yesterday?
<EvilResistance> and didnt they say it'd be easier to get new packages into Ubuntu by first submitting them to Debian?
<Q-FUNK> EvilResistance: yes. and?
<Q-FUNK> EvilResistance: actually, it's not easier.
<EvilResistance> says you
<Q-FUNK> says 10 years of experience at this.
 * EvilResistance has a package sitting in the Debian acceptance queue that are likely going to be accepted in the next 2 days
<EvilResistance> according to the debian sponsors i've spoken to :P
<Q-FUNK> I uploaded my first package at Debian in 2003 and have been a user longer.
<EvilResistance> i've been an end user since two years ago.  i started packaging things 9 months ago.  i've become pretty decent at it.
<EvilResistance> just because you've been doing this longer doesnt mean you know that its easier to submit direct to Ubuntu than to Debian
<jtaylor> it certainly shouldn'T be easier, but its better
<Q-FUNK> EvilResistance: I'll say this exactly once:  I came here asking for constructive feedback on the packaging. unless you're gonna chip in on this, please stop.
<EvilResistance> fine, watch the MOTUs tell you similar stuff
<EvilResistance> alright, that's it, no more packaging for me for the next week or so
<EvilResistance> i've about had it with the evil asinine methods Debian has for packages
<jtaylor> ?
<EvilResistance> jtaylor:  i've got issues with how Debian wants code structured for packaging
<EvilResistance> esp. Python apps
<EvilResistance> if they have a specific structure of an upstream program for packaging, they need to fscking PUBLISH their desired structure
<jtaylor> whats your problem with the policy?
<EvilResistance> give TEMPLATES
<EvilResistance> not leave people in the dust and give ambiguous unhelpful shitstatements
 * EvilResistance is done, walks off for a while
<jtaylor> there are many thousand templates in the archive
#ubuntu-motu 2012-01-15
<IDWMaster> I'm currently waiting for a package to build, and would like to know how I can contribute the package to Ubuntu. I've heard I should ask here. What is the next step after the package  has finished building in the PPA?
<IDWMaster> I'm currently waiting for a package to build, and would like to know how I can contribute the package to Ubuntu. I've heard I should ask here. What is the next step after the package  has finished building in the PPA?
<sagaci> what is it
<jtaylor> is something wrong with this control: http://paste.ubuntu.com/805332/
<jtaylor> because wrap-and-sort screws it up
<jtaylor> precise version
<jtaylor> ah found the issue
<jtaylor> there is a space in the line before python-zmq-db
<jtaylor> doesn't bother the archive though
<tumbleweed> that's a bug in python-debian, then
<jtaylor> is it a bug in -debian? according to policy 5.1 its a syntax error
<jtaylor> so its should be a bug in the control parser of dpkg
<jtaylor> hm no its only a should
<jtaylor> filed a bug in debian
#ubuntu-motu 2013-01-07
<micahg> ScottK: BTW, I'm looking at unbound ATM, I think I have it fixed
<ScottK> micahg: Great.  I have looking at it somewhere on a list.
<micahg> ScottK: unbound is fixed, you can take it off your list :)
<geser> TheLordOfTime: letting php5 (main) build a universe package isn't the problem, the problem is are the build-dependencies which must be also in main
<iulian> Laney: Morning. I'm afraid I don't have too much time on my hands right now (thesis to finish and stuff) but I'm quite certain that others will help with the transition. I shall try and do as many uploads as possible.
<iulian> Sorry for the late response.
<iulian> So I reckon the sooner we start the better, unless you've got other plans.
<Laney> I discovered that I have to package one or two new libraries for agda
<Laney> should do that first, then we can look at starting transitions
<ajmitch> Laney: more haskell stuff to break?
<Laney> ^Wfix
<Adri2000> ScottK: hi, sorry for the nominative ping but my global ~ubuntu-sru pings have been unsuccessful so far. could you have a look at bug #1048634 ?
<ubottu> bug 1048634 in ejabberd (Ubuntu Precise) "Login issue with Pidgin using SRV records" [Medium,In progress] https://launchpad.net/bugs/1048634
<TheLordOfTime> geser, as i understoood from the last question i asked on the matter, "is it because the deps are not in main"
<jtaylor> ScottK: do you know why sip crashes if you first import pyside and then pyqt?
<jtaylor> with this problem http://paste.ubuntu.com/1507752/
<jtaylor> reproduceable with ipython-qtconsole and with pyqt4 and incomplete pyside
#ubuntu-motu 2013-01-08
<ScottK> jtaylor: No.
<Logan_> micahg: Hey, can I PM?
<micahg> Logan_: sure
<jtaylor> yey another criticial cve for asterisk ._.
#ubuntu-motu 2013-01-09
<ral> With debian in freeze, what is the best way to get an updated package (new upstream version) into ubuntu? Upload to experimental and request a pull?
<Adri2000> ral: yes, that works
<ral> Adri2000: Ok, thanks.
<didrocks> nhandler: TheMuso: hey! it seems that I expired from the ubuntu sponsors team, can you please add me back? :)
<sao> Hey all. I am currently trying to get a package done for Diodon a clipboard manager for the official Ubuntu repository. See here https://bugs.launchpad.net/ubuntu/+bug/808464 for details. Is there anyone being interested to possibly sponsor this package?
<ubottu> Ubuntu bug 808464 in Ubuntu "[needs-packaging] diodon -- Clipboard manager for GNOME and Unity" [Wishlist,In progress]
<alo21> hi everybody... I have a package to patch, which hasn't a patch system. This patch should go to debian/upstream. Which patch system do I use?
<micahg> alo21: none
<micahg> is it not source format 3.0 (quilt)?
<alo21> micahg, 1.0
<alo21> micahg, how can I create a patch without a patch system?
<micahg> debdiff?
<alo21> micahg, this is the bug which I am fixing. As you can see in the last comment, I have to create a patch: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1095521
<ubottu> Ubuntu bug 1095521 in util-linux (Ubuntu) "Manpage for mount list different options in same paragraph (keybits, nofail, iversion)" [Medium,In progress]
<micahg> alo21: umm, he's wrong :), you did it correctly
<micahg> as a general rule, we don't add a patch system on top of Debian, and previous "upstream" changes didn't do that, so I don't see why you should start
<alo21> micahg, well... you could expose your idea (if you want) posting a comment in the bug report. In this way everybody can clear its own mind, and do what should be done in this case.
<micahg> alo21: can you please be a little more verbose in your changelog as to what you're fixing?
<micahg> normally with a patch, you'd have dep-3 headers to help with that, with inline patching, you just have the changelog, so it's good to be verbose enough so that the next person who merges from Debian understands what was done and why so it isn't dropped
<alo21> micahg, oh.. OK. I thought that is enough put LP bug-code. Do you think is better if I edit the patch a while?
<micahg> alo21: umm...well, it's easier if everything is in the changelog, the bug reference is so that the bug is closed on upload, the changelog is so that people working on the package can see what's changed
<alo21> micahg, do you think this entry is OK: Nofail and iversion are options itself, not continuation of 'keybits' (LP: #1095521)  ?
<ubottu> Launchpad bug 1095521 in util-linux (Ubuntu) "Manpage for mount list different options in same paragraph (keybits, nofail, iversion)" [Medium,In progress] https://launchpad.net/bugs/1095521
<micahg> alo21: I'd reference the file changed as well
<alo21> micahg, Nofail and iversion are options itself, not continuation of 'keybits'  in mount/mount.8 (LP: #1095521)  ?
<ubottu> Launchpad bug 1095521 in util-linux (Ubuntu) "Manpage for mount list different options in same paragraph (keybits, nofail, iversion)" [Medium,In progress] https://launchpad.net/bugs/1095521
<alo21> micahg, even if I think is too long
<alo21> it is 101.. I try to cut something and reduce the entry in max 80 characters
<micahg> alo21: use multiple lines :)
<alo21> whit '/'?
<alo21> with*
<micahg> alo21: hrm?  no, just go down to a new line and indent properly
<alo21> micahg, I am applying the debdiff to know if it works well... But it takes a lot of time. Is it normal?
<lfaraone> Is there a term for the "If you don't fix X then I'm switching to Gentoo" rhethoric that is common in bug reports?
<broder> brinkmanship
<lfaraone> I mean, my mental response is "let me know how that works out for you."
 * ajmitch would be more than happy to see such people try something else
<micahg> lfaraone: yeah, people have said much worse
<micahg> lfaraone: is it something worth fixing?
#ubuntu-motu 2013-01-10
<xnox> lfaraone: my mental response is "do _not_ let me know how that works out for you" i hear enough whining as it is =))))
<ajmitch> xnox: you don't like being blackmailed? :)
<micahg> hyperair: can I assume when you mention looking into Diodon, that's to push to Debian?
<hyperair> micahg: no, i meant for Ubuntu.
<micahg> hyperair: would you mind pushing to Debian instead?
<hyperair> micahg: i wouldn't mind, but are the build-deps satisfied?
<hyperair> micahg: afaik that's the main issue, isn't it?
<hyperair> diodon is primarily an indicator these days
<micahg> ah, right, lacking unity
<hyperair> micahg: i'll try looking into it. with a few patches i think it can make do with just the application indicator, which should work in Debian, i think.
<hyperair> i recall enabling indicator support for alarm-clock-applet on Debian, and immediately got bug reports complaining about left click behaviour not working.
<micahg> hyperair: ok, I thought it might be pushable as is, in this case, it makes sense to go into Ubuntu first and into Debian as time permits I think (but if it's really easy, why not :))
<hyperair> micahg: well the part that depends on unity is the diodon lens.
<hyperair> it might be possible to just exclude that
<micahg> ah, if it was a configure option, that would be nice :)
<hyperair> mmhm.
<hyperair> but diodon's python if i'm not mistaken, so maybe it's a setup.py thign.
<hyperair> no, it's native.
<hyperair> okay, configure then. that'll be considerably easier to handle :-)
<vibhav> micahg: Again, sorry for replying late. Yes feel free to take it :)
<micahg> vibhav: thanks
<vibhav> No problems, Im busy with exams these days
<alo21> micahg, hi
<alo21> hi everybody.
<alo21> micahg, What should I answer to this comment: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1095521/comments/4
<ubottu> Ubuntu bug 1095521 in util-linux (Ubuntu) "Manpage for mount list different options in same paragraph (keybits, nofail, iversion)" [Medium,In progress]
<alo21> hi
<alo21> I am fixing bug LP: #1095521
<ubottu> Launchpad bug 1095521 in util-linux (Ubuntu) "Manpage for mount list different options in same paragraph (keybits, nofail, iversion)" [Medium,In progress] https://launchpad.net/bugs/1095521
<alo21> and the same bug was reported in debian, which has a patch. What should I do? Wait for a coming merge, or pick the patch in debian and attach it in LP?
<micahg> alo21: if it's important to have for this release and a Debian upload isn't coming soon, we can upload the fix to Ubuntu (you take the Debian patch and add a changelog entry)
<micahg> otherwise, wait for a Debian update and the last person to touch it should merge it (or you can ask them if you can merge it)
<blkperl> Hi everyone, first time MOTU contributer, my branch has been sitting in the sponser queue for a while now, can someone take a look and give me some feedback? :)
<p0s> blkperl: in general, on all channels on irc, asking whether you can ask does not make sense, nobody will answer that. just specify your full question right away and wait some time
<jtaylor> the branch link would be helpful
<blkperl> link is here https://code.launchpad.net/~blkperl/ubuntu/raring/collectd/merge-from-debian
<blkperl> p0s: I was asking for feedback, not asking if I could ask a question but next time I'll leave out the background info and skip to the question
<p0s> blkperl: yes you were asking for feedback but not providing the full information to give you the feedback
<Laney> it's fine
<p0s> blkperl: as jtaylor pointed out, the branch link would be helpful
<Laney> no need to rag on him
 * blkperl assumed you would search for blkperl in the sponser queue....
<p0s> Laney, blkperl: just trying to give general advice on getting questions answered on irc, no insult :)
<jtaylor> I'm lazy, clicking a link is easier than searching for my bookmark :/
 * jtaylor needs dash search for bookmarks (in opera)
<alo21> micahg, hhmmm.... as the last comment says in the bug report in LP, I sent the patch upstream. How should I set the bug?
<micahg> alo21: triaged
<alo21> micahg, and assignee it to nobody. right?
<micahg> alo21: yeah
<alo21> thanks
<micahg> alo21: you might want to keep an eye on it if you want the change in raring
<alo21> micahg, hhmmm. OK
<alo21> micahg, but I think I have to test the patch. The problem is that the package has format 1.0
<micahg> alo21: so, it should be an inline patch anyways, just apply it and make a new source package
<alo21> micahg, this is the patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;filename=0001-util-linux-ffix-697881.patch;att=1;bug=697881
#ubuntu-motu 2013-01-11
<micahg> LoganCloud: Bug #1098392 , you TIL
<ubottu> bug 1098392 in yum (Ubuntu) "Sync 3.4.3 from Debian" [Undecided,New] https://launchpad.net/bugs/1098392
<Aeyoun> Hi. Regarding updating a upstream package. I have successfully followed[1] for version 1.0. Now I want to update to 1.1. But there seems to be a step missing regarding using bzr on[2]. Is there another document that explains it all? [1] http://developer.ubuntu.com/packaging/singlehtml/index.html#document-ubuntu-packaging-guide/packaging-new-software [2] https://wiki.ubuntu.com/PackagingGuide/Complete#Creating_and_Using_a_debian.2BAC8-wa
<Aeyoun> tch_File
<Aeyoun> I end up with one packagename/ that is the bzr repo, and one packagename-1.1/ which is not a repo.
#ubuntu-motu 2013-01-12
<alo21> 581Ã¹
<alo21> how can I propose an upgrade of program for Raring?
<mitya57> alo21: just file a bug
<sladen> alo21: a new upstream version?  Is it in Debian?
<alo21> sladen, upstream, and the code is entirely hosted on LP
<tumbleweed> alo21: what is it?
<alo21> tumbleweed, https://launchpad.net/subdownloader
<tumbleweed> alo21: subdownloader is in Debian, so it's preferable to get it updated there
<alo21> tumbleweed, I think so... but it take a lot of time
<tumbleweed> it doesn't have to
<sladen> alo21: here's a previous new upstream version bug for subdownloader in Debian:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687126
<ubottu> Debian bug 687126 in subdownloader "subdownloader: New version" [Wishlist,Open]
<alo21> sladen, yea
<tumbleweed> presumably the NMU he prepared is http://mentors.debian.net/package/subdownloader
<alo21> sladen, tumbleweed I will talk with maintainer.
<tumbleweed> NMUing new upstream versions isn't something we do lightly in Debian
<alo21> anyway I thought there is a faster way to upgrade package directly in ubuntu
<tumbleweed> but I am in PAPT, and would be happy to do that as a team upload, if it's sane
<tumbleweed> alo21: there is, but we don't use it without good reason
<tumbleweed> (it only cuts out 12 hours or so, and leaves one with a mess that has to be cleaned up later)
<alo21> tumbleweed, hhmmm as you can see in LP there is version 2.0.18. If you would/can port it in Debian you do me a huge pleasure
<alo21> tumbleweed, could you?
<tumbleweed> alo21: how about you prepare it, and I'll have a look?
<alo21> tumbleweed, OK.
<alo21> tumbleweed, prepare for debian right?
<tumbleweed> yes
<alo21> tumbleweed, unstable?
<alo21> or testing?
<mitya57> not testing!
<tumbleweed> uploads in Debian always go to unstable (or experimental)
<tumbleweed> in this case, the package isn't even in testing
<tumbleweed> so, unstable it is
<mitya57> ah, it has an rc bug that will be fixed with the new upstream version (debian bug 606993)
<ubottu> Debian bug 606993 in subdownloader "subdownloader: always fail to download selected subs" [Grave,Open] http://bugs.debian.org/606993
<tumbleweed> actually, that doesn't appear to be fixed in the new upstream version
<tumbleweed> but the package on mentors includes a patch for it
<mitya57> the milestone in bug 306589 is set to 2.0.15, and the latest is 2.0.18
<ubottu> bug 306589 in subdownloader (Ubuntu) "Error when clicking 'Download' (ascii codec can't encode)" [Undecided,Confirmed] https://launchpad.net/bugs/306589
<tumbleweed> oh, you're right
<alo21> tumbleweed, is there some bug (in debian) which request an upgrade to 2.0.18??
<tumbleweed> alo21: you can find all the debian bugs here: bugs.debian.org/src:subdownloader
<tumbleweed> packages.qa.debian.org/subdownloader is a handy place to find most things about a package in Debian
<alo21> tumbleweed, for example this bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687126) is about version 2.0.14-1. Have I set this as fix, even if I will upgrade to 2.0.18?
 * mitya57 doesn't think it's worth filing a new "update to new upstream version" bug when one is already open
<ubottu> Debian bug 687126 in subdownloader "subdownloader: New version" [Wishlist,Open]
<tumbleweed> alo21: yes. mitya57: agreed
<alo21> tumbleweed, Have to put LP bug too?
<alo21> bugs*
<tumbleweed> if you do they'll be automatically closed when it syncs to Ubuntu, so yes, it's a good idea
<alo21> tumbleweed, is a problem if changelog's entries are not very human-understandable ?
<alo21> tumbleweed, like    search (KeyError: 'MovieImdbRating')
<tumbleweed> changelogs are for humans
<tumbleweed> so, yes
<alo21> tumbleweed, done! what files yo need?
<alo21> you*
<alo21> do you*
<tumbleweed> alo21: how about a diff from the old debian/ directory to the new one?
<alo21> tumbleweed, the file will be very heavy
<tumbleweed> it shouldn't be
<alo21> more than 15 bugs has been fixed
<tumbleweed> presumabyl mostly upstream
<tumbleweed> (clean the build trees first, obviously)
<alo21> where?
<tumbleweed> pastebin.debian.net?
<alo21> tumbleweed, sorry, but I really did not understand
<tumbleweed> alo21: the output of debdiff subdownloader_2.0.14-1.dsc subdownloader_2.0.18-1.dsc | filterdiff -i '*/debian/*'
<alo21> tumbleweed, isn't OK if I do debdiff file1.dsc file2.dsc > difference.debdiff?
<tumbleweed> well, that'll have lots of stuff that I don't want to see, but sure, I don't mind
<alo21> tumbleweed, oh... the command you wrote before is in debian packaging guide?
<tumbleweed> probably not
<alo21> tumbleweed, may be I am fool, but can I create a diff on Ubuntu machine?
<tumbleweed> yes
<alo21> tumbleweed, really sorry if I annoying you, but what this command ( subdownloader_2.0.14-1.dsc subdownloader_2.0.18-1.dsc | filterdiff -i '*/debian/*') does?
<tumbleweed> I assume you already know what debdiff does?
<alo21> yes
<tumbleweed> filterdiff filters a diff (in this case, removing everything except the debian directory)
<alo21> tumbleweed, so... what you are really interested is debian folder only, because you will grab the source directly from LP. Right?
<tumbleweed> yes
<tumbleweed> if you look at what we have in PAPT SVN, you'll see it's only the debian directory http://anonscm.debian.org/viewvc/python-apps/packages/subdownloader/trunk/
<alo21> now I really understood. Thanks for your time and explanation
<tumbleweed> np (sorry, I try not to explain things too quickly - one learns more finding out for yourself)
<alo21> tumbleweed, could you give me the entire command, please?
<tumbleweed> I did earlier:
<tumbleweed> debdiff  subdownloader_2.0.14-1.dsc  subdownloader_2.0.18-1.dsc | filterdiff -i  '*/debian/*'
<alo21> tumbleweed, sorry, I missed a character... here is the output (http://pastebin.ubuntu.com/1524136/)
<alo21> I hope is OK
<tumbleweed> I see what you mean about lots of bugs
<mitya57> alo21: did you read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639003#10 ?
<ubottu> Debian bug 639003 in subdownloader "should depend on python-qt4" [Important,Open]
<alo21> mitya57, without this python-qt4 the program never start
<mitya57> alo21: doesn't it have a command-line interface?
<alo21> mitya57, yes it has
<mitya57> so, it will start :)
<mitya57> you can also read the suggestion in the next command
<mitya57> *comment
<alo21> mitya57, I read it, in fact there is the same bug in LP, I will try to fix the bug later. But not now
<alo21> mitya57, but you right...
<alo21> may be I have to put back python-qt as recommends
<alo21> mitya57, sorry... I leave it as depends... and I try to make double binary package as soon as possible.
<mitya57> alo21: thanks
<alo21> mitya57, I explain why... if I put python-qt as recommend, most of the people would start the gui without knowing that subdownloader will never work without python-qt package, and they think is a bug
<mitya57> "most of the people" will have python-qt4 installed as it's in recommends
<alo21> mitya57, if python-qt4 is as recommend, the package will never installed automatically
<mitya57> alo21: all tools I know (u-s-c, apt(itude), synaptic) install recommended packages by default
<alo21> mitya57, hhhmmm... if is as you said.... why someone fill that big? it is weird
<tumbleweed> alo21: you shouldn't need debian/dirs. debian/subdownloader-cli.install is totally unused. you shouldn't need subdownloader.postinst (which is currentnly pretty weird)
<tumbleweed> (and yes, this package is currently not the prettiest package)
<alo21> tumbleweed, I didn't set up the package (debian folder). I just fixed some bugs. Anyway I would like that you (if you want) make a re-stylish
<alo21> tumbleweed, or you could get in touch with Marco Rodriguez
<alo21> the debian maintainer
<alo21> and talk about it
<tumbleweed> alo21: I'm not suggesting you make it prettier, I'm just talking about changes you made
<alo21> tumbleweed, OK. subdownloader-cli can be deleted. But I didn't make any changes in .postinst and debian/dirs
<alo21> or I didn't create them
<tumbleweed> alo21: your patch says you did
<alo21> tumbleweed, the debdiff?
<tumbleweed> yeah
<alo21> tumbleweed, I am not the only developer.. may be someone else did it. Let me check something..
<alo21> tumbleweed, in fact, for example .postinstall file has been chnages by Ivan Garcia
<tumbleweed> alo21: how did you get it then? it's not in the tarball provided by the upstream
<alo21> tumbleweed, are you talking about: https://launchpad.net/subdownloader/trunk/2.0.18  ?
<tumbleweed> alo21: https://launchpad.net/subdownloader/trunk/2.0.18/+download/subdownloader_2.0.18.orig.tar.gz
<tumbleweed> anyway, we almost never take debian packaging from the upstream. we ignore their packaging and do our own
 * tumbleweed goes out for a bit
<alo21> this is because I took the source form the trunk, not from the link above, and may be the files are a little bit different
#ubuntu-motu 2013-01-13
<micahg> bdrung: about Bug #1099003, does vlc dlopen libopus?
<ubottu> bug 1099003 in vlc (Ubuntu) "VLC 2.0.5 won't work with Opus. Please include libopus0 from n-muench PPA" [Undecided,Won't fix] https://launchpad.net/bugs/1099003
<micahg> bdrung: if so, we can backport opus from quantal to precise
<micahg> bdrung: make that can, as I see there's a build-dep in quantal
<micahg> bdrung: alternatively, we can backport opus+vlc from quantal to precise once the can't build depend on backports in backports bug is fixed
<wendar> recap: gnumeric is a trivial manual merge, but depends on goffice 0.10.0
<wendar> goffice requires a sync, since the Ubuntu patches are no longer relevant
<wendar> but, it's a significant version change so requires a transition
<wendar> anyone got pointers for docs on library transitions?
<wendar> I'll ask cjwatson when the time zones roll around again if no other answers pop up
<micahg> wendar: preferably through merges/syncs from Debian if they're available
<micahg> if that's needed
<wendar> gnumeric is a merge from Debian, goffice will be a sync
<jtaylor> wendar: first setup a transition tracker http://people.canonical.com/~ubuntu-archive/transitions/
<micahg> jtaylor: it's a handful of packages
<micahg> or 2 handfuls
<wendar> jtaylor: is that populated manually or automatically?
<jtaylor> automatic
<jtaylor> you just have to provide the rules
<wendar> goffice isn't in there, but then goffice is blocked on a manual merge
<micahg> it's actually 5 sources
<wendar> so, if goffice is sync'd, will it then appear in the transition tracker?
<micahg> not worth a tracker
<jtaylor> no the tracker has to be setup manually
<wendar> ah, automatically generated, for manually specified package names?
<jtaylor> you provide the afftected, good and bad lines you see in the existing ones
<jtaylor> but it may not be worth it if its only handful
<wendar> is it fairly similar to the Debian transition "ben" format? http://wiki.debian.org/Teams/ReleaseTeam/Transitions
<micahg> indeed
<wendar> ok, exactly 5 packages
<wendar> micahg: is it reasonable to put in the Sync request for goffice, and include the list of reverse depends and reverse build depends?
<wendar> with the note that it may require a transition
<wendar> or would you lean more toward an email to ubuntu-motu (which is where I see some transition conversation happening)
<jtaylor> first do all rdeps still build?
<jtaylor> if yes (and they also work) the actual transition can be simple
<jtaylor> must get to bed now, n8
<micahg> wendar: if everything works, then file the appropriate bugs with notes that they should go together
<wendar> micah: I'm doing a test build on all of them
<cjwatson> wendar: yeah, for five I'd JFDI.  Let me know when I should merge gnumeric
<jtaylor> I probably asked that already but forgot,  when doing an sru that build depends on another sru do I have to add versioned depends?
<jtaylor> e.g. jcc (>= 2.11-3ubuntu0.1)
<Rhonda> hmmmmm, why don't I have the ssh key from my laptop on jubany.c.c â¦
<wendar> cjwatson: a sync'd version of the latest goffice from Debian builds fine, but I get build failures in gnumeric and gnome-chemistry-utils which depend on it
<wendar> those are the only two reverse depends on goffice that have ubuntu changes, everything else is already sync'd from Debian
<wendar> the build failures aren't directly related to goffice, though
<wendar> which means, it could be other gtk packages in Ubuntu that are different versions than Debian's
<wendar> gnumeric fails with a missing identifier in GTK-Doc
<wendar> gnome-chemistry fails with a missing symbol from libxslt at link time (so, not even gtk related)
<bdrung> micahg: backporting opus+vlc sound good. what needs to be done once quantal EOL?
<bdrung> backport from raring to precise?
<micahg> bdrung: that or just upload the precise version with enable opus + enable ssl
<bdrung> micahg: looking at the precise->quantal diff, it's better to just enable opus and ssl instead of backporting the quantal version
<micahg> bdrung: I was going to backport quantal + reinstate the postinst
<bdrung> micahg: and revert the fonts-freefont-ttf rename, please
<bdrung> otherwise you can't install it (or you backport the freefont package)
<micahg> bdrung: we just need the reverse dependencies tested with the built versions, I can throw them in my PPA
<micahg> bdrung: ah, yes
<bdrung> backporting the font would be probably better
<micahg> it has a few reverse dependencies as well, but I don't mind if they're tested
<bdrung> micahg: once we have one version of vlc in backport, keeping it updated shouldn't be that big issue (because security updates will go to precise and quantal)
<micahg> right
<micahg> ah, we actually don't need the backport on backport version
<micahg> both are new packages in backports
<wendar> cjwatson: is there a better way to test a partial archive rebuild for a library transition?
<wendar> cjwatson: I'm beginning to suspect the build failures may have more to do with creating a test build environent from a mixture of apt-get installs of raring packages and local custom dpkg installs of the new versions of the packages
<wendar> cjwatson: so, it's getting the dependencies confused on building packages that depend on other packages I've already built
<jtaylor> when doing an sru that build depends on another sru do I have to add versioned depends?  e.g. jcc (>= 2.11-3ubuntu0.1)
<micahg> jtaylor: if the version is required for functionality, yes
<jtaylor> its only the build
<jtaylor> runtime doesn't matter
<micahg> yes, I mean if it's required to make the build work properly, it should be versioned
<jtaylor> k
<cjwatson> wendar: Does the new goffice render the old (other packages) uninstallable?
<cjwatson> wendar: If so, the simplest way is to put it into raring-proposed (where everything's staged anyway) and then it'll automatically stay there until we fix everything else up - and it'll be easier to test-build them once the new goffice is in raring-proposed
<cjwatson> wendar: if the new goffice changes library package names or similar, that's good enough for this purpose
<wendar> cjwatson: I'm getting FTBFS on gnumeric and gnome-chemistry-utils when I rebuild locally on the new goffice
<wendar> cjwatson: so, yes going ahead and syncing the new goffice into raring-proposed would work
<wendar> cjwatson: I can watch and fix any errors until all the dependencies are straight
<wendar> cjwatson: (the library package names are different for the new goffice, all 0.10 instead of 0.8)
<cjwatson> wendar: done on your behalf, then
<cjwatson> I'll have a poke at gnumeric tomorrow
<wendar> cjwatson: thanks!
<wendar> I did the merge for gnumeric
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/ should tell you what's still blocking it (in a bit)
<cjwatson> point me to a source package and I'll start from that, then
<cjwatson> though the Ubuntu changes weren't complicated
<wendar> cjwatson: https://bugs.launchpad.net/ubuntu/+source/gnumeric/+bug/1099027
<ubottu> Ubuntu bug 1099027 in gnumeric (Ubuntu) "Please merge gnumeric 1.12.0-1 (universe) from Debian unstable" [Wishlist,New]
<cjwatson> ok, ta
<wendar> aye, the changes were light
 * cjwatson not a major fan of attempting to sponsor UDD merges anyway
<cjwatson> fine for other things, but there are a few too many directions to compare for merges
<cjwatson> so glad you just gave a debdiff
<cjwatson> anyway, -> tv, will look tomorrow
<wendar> enjoy :)
#ubuntu-motu 2014-01-06
<Laney> Logan_: please forward your gst-plugins-ugly1.0 changes
<Logan_> Will do.
<Logan_> In the morning. :P
<Laney> and 0.10 (or xnox)
<TJ-> Is anyone able to merge a patch? bug #1266461
<ubottu> bug 1266461 in isomaster (Ubuntu) "El Torito boot image corrupted by truncation" [High,Confirmed] https://launchpad.net/bugs/1266461
<jtaylor> can someone on trusty quickly check if accerciser starts?
<Noskcaj> jtaylor, I can't help you with that right now, but it's probably fixed in the latest upstream release, which is in the pkg-gnome svn
<jtaylor> its also broken in saucy
#ubuntu-motu 2014-01-07
<dholbach> good morning
<Unit193> Howdy.
<Noskcaj> dholbach, Has there been any progress on my MOTU application? I've not a had a reply in days. Is there some voting process?
<dholbach> Noskcaj, maybe everybody's just waiting for the next DMB meeting to happen?
<dholbach> https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
<dholbach> anyone of these guys should know more: https://launchpad.net/~developer-membership-board/+members
<Noskcaj> dholbach, ok. I've applied by email, since i doubt i can attend a meeting until later february
<dholbach> ok... did you point that out in the email?
<Noskcaj> lan3y, I think you where the one person who replied to my email.
<Noskcaj> dholbach, yeah
<dholbach> ok... in that case maybe just ping one of the guys and ask
<dholbach> it might just have been the Christmas/New Years break that delayed the application process
<Guest1882> not very helpful that he doesn't stay online
<TheLordOfTime> cjwatson: ping, for whenever, can you merge nginx 1.4.4-4 into Trusty?  1.4.4-3 fixed a nginx-naxsi issue, and 1.4.4-4 fixes a bug introduced by the fix for CVE-2013-0337 involving logrotate failing.
<ubottu> The default configuration of nginx, possibly 1.3.13 and earlier, uses world-readable permissions for the (1) access.log and (2) error.log files, which allows local users to obtain sensitive information by reading the files. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0337)
<TheLordOfTime> and sorry for the CVE spam :/
<TheLordOfTime> (it's already fixed)
<TheLordOfTime> unless there's a freeze date i missed and i'm in the wrong requesting it, if I am, please let me know (anyone)
#ubuntu-motu 2014-01-08
<cjwatson> TheLordOfTime: uploaded
<TheLordOfTime> cjwatson: thanks!
<dholbach> good morning
<Noskcaj> Laney, I only just saw your reply. Sorry for going offline, but my parents don't like the PC on after 8
 * Logan_ waves to dholbach.
<dholbach> hi logan_
<Noskcaj> hey Logan_, dholbach.
<Noskcaj> Any chance you could sponsor more stuff for me?
<Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/libxfce4ui/4.11/+merge/200196 being the main thing
<dholbach> hiya Noskcaj
 * Noskcaj needs to do something other than nag random sponsors
<Logan_> I'll take a look, Jackson.
<dholbach> thanks logan_
<dholbach> I'll do a bit more sponsoring later on
<Logan_> No problem.
<Noskcaj> thanks Logan_
<dholbach> need to rush off for a bit now
<Logan_> Believe me, I live for doing this stuff at 3:30 AM. :P
<Noskcaj> bye dholbach
<Noskcaj> lol
<Noskcaj> And fyi, http://people.canonical.com/~ubuntu-archive/NBS doesn't go to anywhere, might need taking out of the topic
<dholbach> Logan_, haha!
<Noskcaj> Logan_, Why are you awake at 3:30AM?
<Logan_> Noskcaj: Wonderful news. Bazaar crashed trying to merge your branch.
<Noskcaj> LOL
<Logan_> The wonders of UDD.
<Noskcaj> It's easier than MoM, but yeah
<Logan_> I'll give it another try.
<Logan_> Nope, crashed again.
<Logan_> Do you want me to just do the merge myself?
<Noskcaj> Logan_, I guess so, i blocks ~10 other xubuntu merges
<dholbach> it's unorthodox, but you could try to just get Noskcaj's branch and build the source package from it and see if that works
<Noskcaj> *it
<Logan_> Ah, I'll try that.
<Noskcaj> Logan_, It's probably because i only learned that UDD had a debian experimental branch after i made the merge
<Logan_> Oh, so you didn't do a bzr merge debianlp:experimental/libxfce4ui ?
<Logan_> That probably explains the crash. Let me try building your branch directly, as Daniel suggested.
<Noskcaj> Thanks. I probably need to fix libgweather some time tomorrow, since it will have the same issue
<Logan_> Noskcaj: Looks good. Uploading.
<Logan_> Unable to find libxfce4ui_4.11.0.orig.tar.bz2 in upload or distribution.
<Logan_> Er.
<Logan_> Let's try that again.
<Noskcaj> thanks
<Logan_> I forgot to include the tarball when building.
<Noskcaj> :)
<Logan_> This time with more gusto.
<Logan_> Okay, accepted.
* cjwatson changed the topic of #ubuntu-motu to: Saucy released! | 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.html | http://qa.ubuntuwire.com/bugs/rcbugs
<michagogo|cloud> !info litecoin
<ubottu> Package litecoin does not exist in saucy
<michagogo|cloud> !info litecoin trusty
<ubottu> Package litecoin does not exist in trusty
<michagogo|cloud> o_O
<michagogo|cloud> packages.ubuntu.com disagrees
<michagogo|cloud> !info src:litecoin trusty
<ubottu> Package srclitecoin does not exist in trusty
<michagogo|cloud> !info litecoind trusty
<ubottu> litecoind (source: litecoin): peer-to-peer network based digital currency - daemon. In component universe, is optional. Version 0.8.6.1-1 (trusty), package size 636 kB, installed size 2517 kB
<michagogo|cloud> ah
<michagogo|cloud> This should be removed from Trusty, and blacklisted for import from Debian, as Bitcoin was. (https://lists.ubuntu.com/archives/ubuntu-release/2013-December/002681.html)
<michagogo|cloud> (I also emailed suggesting this, but it doesn't seem there was any response...)
<cjwatson> please file a bug and subscribe ubuntu-archive
<cjwatson> other methods stand a good chance of getting lost
<michagogo|cloud> cjwatson: "Ubuntu Package Archive Administrators (ubuntu-archive)"?
<cjwatson> yes
<michagogo|cloud> done
<michagogo|cloud> cjwatson: https://bugs.launchpad.net/ubuntu/+source/litecoin/+bug/1267088
<ubottu> Ubuntu bug 1267088 in litecoin (Ubuntu) "litecoin should be removed from the archive (and blacklisted)" [Undecided,New]
<cjwatson> we tend to process those in batch mode, so it may take a while, but we always at least make a point of clearing out the list before release
<michagogo|cloud> cjwatson: Doesn't it need to be done by some time in February?
<cjwatson> why?
<cjwatson> feature freeze has no effect on removing stuff
<michagogo|cloud> Ah, okay
<jtaylor> hm which package are the python gi gtk bindings?
<jtaylor> you to to love 40 minute test suites that run 6 times :(
#ubuntu-motu 2014-01-09
<TheLordOfTime> I have a question.  In Ubuntu, is a package allowed to create /root/.somefolder/ during installation in the root user's "home" directory?
<TheLordOfTime> (this also applies to any standard user's home directories)
<TheLordOfTime> or does it violate policies
<RAOF> The application doesn't create those directories on first run?
<RAOF> (No, is the answer, btw)
<TheLordOfTime> RAOF: supposedly, bitcoind in precise creates /root/.bitcoind/ on install
<TheLordOfTime> but i haven't tested that to confirm
<TheLordOfTime> (initially reported/seen in the #bitcoin general discussion channel)
<RAOF> I'd guess that it runs the daemon on install, right?
<RAOF> Which would then create the directories...
<TheLordOfTime> it shouldn't, there's a billion security exploit risks in bitcoind on precise when its run as root
<RAOF> Although it sounds like bitcoind should probably run as a non-root user.
<RAOF> Right :)
<TheLordOfTime> the question was, though, is a package allowed, on installation, to create a directory in /root/
<TheLordOfTime> at all
<TheLordOfTime> (since the daemon wasn't even running yet)
<TheLordOfTime> (since the daemon wasn't even running yet according to the user that saw this)
<TheLordOfTime> RAOF: my question is a general policy one
<TheLordOfTime> not specific to this package
<TheLordOfTime> (if it were within my power, I'd wipe bitcoind from the repos and versionbump them all up to latest stable in all versions of Ubuntu, but meh)
<TheLordOfTime> s/wipe bitcoind/wipe the current bitcoind/
 * RAOF is pretty sure the policy answer is âNoâ, but I've not hunted the precise section down.
<RAOF> TheLordOfTime: They're wrong, too; bitcoind in Precise (and, indeed, Saucy) does not create /root/.bitcoind on install
<TheLordOfTime> RAOF: hmm.  does it autorun the daemon?
<RAOF> No
<TheLordOfTime> RAOF: having said this i still want to know the packaging policy on this
<TheLordOfTime> RAOF: then i'll have to educate people in how things work and tell them that they have failed epicly
<TheLordOfTime> either way, though, i still want to know the policy about this: is a package, during installation, allowed to mess with any user's "home" direcotyr.
<TheLordOfTime> s/direcotyr/directory/
 * TheLordOfTime shrugs
<RAOF> TheLordOfTime: As I said, I'm pretty sure the answer is ânoâ
<RAOF> Among other things, it's moderately difficult to actually do.
<Logan_> xnox: Mind if I disable -Werror on sphinxsearch to fix the FTBFS on rebuild?
<Logan_> (And the current FTBFS on ppc64el?)
<Logan_> Hi Jackson.
<Noskcaj> hey Logan_
<Logan_> Noskcaj: I'm sure you have something for me to do.
<Noskcaj> Logan_, Sponsorship queue in general, but there's a few high priority ones, let me check
<Noskcaj> ;)
<michagogo|cloud> TheLordOfTime: actually, Ubuntu has stopped including Bitcoin
<michagogo|cloud> Unfortunately, that change is only in effect starting with Trusty
<Logan_> Noskcaj: I plan on going to sleep at a reasonable-ish time tonight, so make it quick.
<Logan_> Although it appears that I have already failed at that, considering it's almost 1 AM.
<Noskcaj> Logan_, https://code.launchpad.net/~noskcaj/ubuntu/trusty/gauche/ppc64el/+merge/200266
<Noskcaj> It should fix a heap of your PPC64el issues
<Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/menu-cache/ppc64el/+merge/200244 also unblocks a heap
<Unit193> Logan_: Psh, 1am _is_ reasonable. ;)
<michagogo|cloud> Though I'm told that it could be effectively removed through the SRU process, by creating an "update" that simply makes the software unusable -- if anyone wants to do that, it'd be great
<Logan_> Noskcaj: Looking at gauche.
<Noskcaj> ubuntu-dev time =/= normal person time
<Noskcaj> ty
<Logan_> Believe me, I'm far from a normal person.
<michagogo|cloud> (I don't know how that would be done, both from the standpoint of Ubuntu policy/procedure and from the standpoint of the actual update itself and how it would work)
<Logan_> Noskcaj: Did you do a test build of gauche?
<Noskcaj> Logan_, On amd64, yes
<Noskcaj> built fine
<Logan_> Trusty?
<Noskcaj> yeah. pbuilder-dist
<Logan_> No, you didn't.
<Logan_> Because you would've noticed that the autoreconf failed with 16 missing header warnings.
<Noskcaj> I did, i'll try and build it again
<Logan_> Tsk tsk.
<Logan_> In any case, there's a simple fix if you don't know how to do it.
<TheLordOfTime> michagogo|cloud: oh good, may I ask the reasons for them not including bitcoin anymore? :)
<TheLordOfTime> michagogo|cloud: (that does not, however answer my question about general packaging policies)
<TheLordOfTime> i could go poke debian about that, but meh
<Noskcaj> Logan_, Just give me a minute to branch it
<michagogo|cloud> TheLordOfTime: read the ML archives
<TheLordOfTime> michagogo|cloud: ehh, i'm lazy, besides it's 01:12 and i'm tired, i'll add that to my todo list
<TheLordOfTime> ... which ML archive though
<Logan_> Noskcaj: Actually, my quick-and-dirty fix doesn't appear to have worked. So let me know if you come up with something.
<Noskcaj> Logan_, My internet is being more broken than normal. Any chance you could fix and upload?
<Noskcaj> I'll look into it tomorrow
<Logan_> Still playing with it, though.
<michagogo|cloud> TheLordOfTime: ubuntu-release
<michagogo|cloud> And actually, maybe also ubuntu-motu
<Logan_> Noskcaj: Do you have router problems or something?
<Noskcaj> Logan_, Internet below ADSL speed, plus 4 brothers
<Logan_> Noskcaj: I'm sorry to hear that you have brothers
<Noskcaj> :)
<Noskcaj> Should i delete the menu-cache branch
<Logan_> wgrant: Is it possible for MultiDistroTools on UbuntuWire to compare Trusty to Sid instead of to Jessie?
<wgrant> Logan_: The next update will use sid
<Logan_> Sweet. When will that come out?
<Logan_> Or are you referring to 14.10? :P
<wgrant> It's updated hourly.
<Logan_> Ah.
<Logan_> Thanks!
<dholbach> good morning
<xnox> LoganCloud: Logan_: well I did try to make sphinxsearch actually pass all of it's autoreconf errors =/
<Noskcaj> Laney, You around?
<Logan_> Noskcaj: End up figuring out that FTBFS?
<Noskcaj> Logan_, gauche? No, i was just getting around to it now,
<Logan_> Okay. Let me know.
<Noskcaj> Would the autoheader issue just need another b-dep or do i need to make some patches?
<Logan_> I'm not sure. I tried adding AC_CONFIG_MACRO_DIRS([m4]) to configure.ac, but it didn't appear to work.
#ubuntu-motu 2014-01-10
<Noskcaj> bdrung, slangasek, stgraber: Since you're the only dmb members online, would you mind checking the status of my MOTU application? It's been a week since i sent it and i've got more testimonials since.
<slangasek> Noskcaj: not a member of the dmb
<Noskcaj> sure? https://launchpad.net/~developer-membership-board/+mugshots
<slangasek> Noskcaj: yes, quite sure that I am none of those people :)
<Noskcaj> slangasek, Last time i click on the link you were there. Something in launchpad broke for me
<slangasek> hah
<Noskcaj> I'm going to guess it's because of the tech board
<slangasek> I'm going to guess it's because of solar flares ;)
<Noskcaj> :)
<dholbach> good morning
<MentalPower|Work> Hello again MOTU, I'm trying to create a two packages, a base nutcraker (that I already have) and a nutcracker-dbg with a few compile time debugging options (and debugging symbols) turned on. I've already found how to not strip the debugging symbols, but I have not found another package that uses different configure flags for different packages
<Noskcaj> MentalPower|Work, Normally -dbg packages are made only as addons, with dh_strip --dbg-package= and maybe some extra files/links
<MentalPower|Work> hmm... is there a way to have two compile chains without needing two sources?
<Rhonda> Why would you want two compile chains?   Like Noskcaj mentioned, compile it once with debug symbols turned on, and use dh_strip --dbg-pkg
<Rhonda> The regular package will then be without the debug symbols which get extracted to the mentioned package.
<Rhonda> That's the way most packages do it.  Just look at the source package of a random -dbg package.
<MentalPower|Work> Rhonda: I need to enable some compile-time debugging options
<MentalPower|Work> this specific software doesn't do hardly any debugging output unless its compiled in
<jtaylor> MentalPower|Work: a library or application?
<jtaylor> for application just compile a second time, rename the binary (and its libraries if it has some) and install them in a dbg package
<jtaylor> see e.g. python-dbg (conceptionally, don't look at the packaging ;) )
<MentalPower|Work> application
<MentalPower|Work> hmm... let me look at python
<jtaylor> or fftw3
<jtaylor> it builds multiple times with different configurations and sticks the results in different packages
<jtaylor> packaging should be easier to understand than python, though its also not great
<jtaylor> don't know of better examples
<MentalPower|Work> jtaylor: you're right, python's packaging is all over the place. fftw's is a bit better, but I can't find where its doing the two compiles
<jtaylor> MentalPower|Work: in build-arch:
<jtaylor> multiple configure make install DESTDIR
<jtaylor> the destdir is the important part
<jtaylor> moving into packages is then using the --sourcedir argument of dh_install
<jtaylor> in binary-arch:
<jtaylor> the rest is just cludge because not all variants work on all arches
<jtaylor> you hopefully won't need that
<sontek> When you have two packages with same name but different versions, how do you know which one will be selected by apt-get
<sontek> I just built a new package for precise that is updated from the ubuntu included version
<sontek> This is what I see when I do show: http://paste2.org/xnCU2dJD
<jtaylor> the one which has a higher version according to dpkg --compare-versions
<jtaylor> but apt.preferences are taken into acount for automatic upgrades
<jtaylor> sontek: ^
<sontek> jtaylor: ok, that sounds fine then
<sontek> Now I have one problem, there is one director in the .tar.gz that isn't being included right now
<sontek> What defines what files get shipped?
<sontek> I see the .install files
<jtaylor> install files and "manual" copies in debian/rules
<jtaylor> also .links .manpages etc
#ubuntu-motu 2014-01-11
<sontek> This is part of the source itself
<sontek> https://launchpad.net/~surveymonkey/+archive/surveymonkey/+packages
<sontek> Thats the package I built, libmemcached
<sontek> in the .tar.gz there is a libmemcache-1.0 folder not being included
<sontek> What is the .install file for?
<jtaylor> the normal packaging is use upstream buildsystem to install into DESTDIR=debian/tmp
<jtaylor> dh_install then installs from there into debian/package-name/ via the info in the .install files
<jtaylor> those folders are then turned into packages
<sontek> This is the folders in the package folder: http://paste2.org/LZ7yUvgA
<sontek> Its installing libmemcached/  but not libmemcached-1.0/
<sontek> and same, libhashkit/ but not libhashkit-1.0/
<jtaylor> whats the install file?
<sontek> http://paste2.org/DX9VL0Ws
<sontek> so does each .install file represent a folder in the package?
<sontek> so if I created a libmemcached-1.0.install, it'd autodetect?
<jtaylor> no it are text files
<sontek> Yeah, but inside they just have destination folders
<jtaylor> they can
<jtaylor> relative to debian/<package-name>
<jtaylor> but its optional
<sontek> I don't understand then.  What is required to get the libmemcached-1.0 and libhashkit-1.0 directories shipped into /usr/include/ with libmemcached/ and libhashkit/
<jtaylor> they have to be installed by the buildsystem into debian/tmp
<jtaylor> then you just list the path in the install file
<sontek> I don't have a debian/tmp folder
<jtaylor> it is created during the build
<jtaylor> normally
<jtaylor> the package can override it to a different name
<jtaylor> or not have one if its a single binary package
<sontek> I did debuild -S
<jtaylor> debuild -S does not build a binary package
<jtaylor> only a source package
<jtaylor> that will not contain any build sources
<jtaylor> binary packages are build without the -S argument
<sontek> But when I put it on a PPA, I think they only want a source package
<sontek> and then their build server builds the binary packages
<jtaylor> yes
<jtaylor> but you should build locally first
<sontek> ok, so just run debuild?
<jtaylor> for testing
<jtaylor> yes
<sontek> http://paste2.org/Z9D9XHHd
<sontek> thats the error I get when running locally
<jtaylor> you need to install build dependencies
<sontek> I have build-essential
<jtaylor> the best way is running. sudo mk-build-deps -ir
<sontek> Looks like its working
<sontek> ok, when I did it locally a libmemcached-1.0 folder is there in debian/tmp/usr/include/libmemcached-1.0
<sontek> so why doesn't the source package that was built on the build servers have it?
<sontek> ls debian/tmp/usr/include/
<sontek> libhashkit  libhashkit-1.0  libmemcached  libmemcached-1.0  libmemcachedprotocol-0.0  libmemcachedutil-1.0
<sontek>  ls -d /usr/include/libmem* /usr/include/libhash*
<sontek> /usr/include/libhashkit  /usr/include/libmemcached
<sontek> you see, the installed package is missing all the header directories
<Logan_> wgrant: I'm afraid that the comparison to Sid isn't working properly in MDT... can you take a look?
<Logan_> For example, the first package in the list (among many others) is in Sid, but it's marked as not found.
<Logan_> Also, the "universe" page stopped working.
<wgrant> Logan_: Ah, I didn't have the new signing key installed.
<Logan_> wgrant: Thanks for fixing it! :)
<dupondje> somebody around for some sponsoring ?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/opensc/+bug/1252254
<ubottu> Ubuntu bug 1252254 in opensc (Ubuntu) "OpenSC fails to authendicate with firefox" [Undecided,Confirmed]
<dupondje> seems quite silent here :(
<dupondje> :)
#ubuntu-motu 2014-01-12
<jtaylor> I should stop putting two strongly related issues into the same bug ...
<jtaylor> people just read one and I need to file another bug after they fixed it :(
#ubuntu-motu 2015-01-05
<Logan_> Noskcaj: please merge in the new dhelp to fix the installation problem
<Noskcaj> Logan_, Will do
<Laney> anyone want to handle universe rebuilds for libical1 -> libical1a?
#ubuntu-motu 2015-01-06
<dholbach> good morning
<darpa_droid> hi everyone
<darpa_droid> Is anybody here?
<Noskcaj> DalekSec, always
<Noskcaj> oops, darpa_droid ^
#ubuntu-motu 2015-01-07
<dholbach> good morning
<Rhonda> Laney: Thanks for the utopic backport approval.  What about trusty? :)
<Rhonda> Especially in the light that it was the last LTS release.
<Laney> Rhonda: Forgot, here we go
<Rhonda> Thanks. :)
#ubuntu-motu 2015-01-08
<Unit193> Hello!  Could someone sync gcalcli from Debian experimental?
<Noskcaj> Unit193, Why do you ask here rather than running requestsync?
<Unit193> Because 1. IRC is so much better, and 2. It won't pick it up yet.
<Noskcaj> ok
<dholbach> good morning
#ubuntu-motu 2015-01-09
<jcfp> 4 packages are listed as 'failure in the chroot' at http://qa.ubuntuwire.com/ftbfs/ as a result of a broken script in sysvinit a couple of days ago
<jcfp> the sysvinit issue has been fixed meanwhile, so somebody please add these four for back into the build queue
#ubuntu-motu 2015-01-10
<ari-tczew> jcfp: thanks, now packages have been built fine
<jcfp> ty :)
#ubuntu-motu 2016-01-11
<dholbach> good morning
<Unit193> Hello.  Since Mica has been pretty busy, anyone got a chance to review and sponsor a package?  https://sigma.unit193.net/source/newsbeuter_2.9-0ubuntu1.dsc fixes a huge memory leak in the package by backporting a commit from upstream.  I've been testing this since Nov or Dec and it works fantastically, compared to how much the version in Xenian (an LTS) is leaking now.
<Unit193> Furthermore, upstream does intend to land .10 here fairly soon, but that'll be after FF so would be better to get this in now, then upload that bugfix release afterwards.
<Unit193> Logan: â? :)
<ngomes> are MOTU's payed ?
<ngomes> first , hello
<ngomes> i was wondering if its possible to join the ubuntu-motu team
<ngomes> no reply ... ?
<Unit193> There's a contributing doc in the topic, and no this is all volunteer efforts.
<ngomes> Unit193, how can i propose a package for the repository ?
<Unit193> https://wiki.ubuntu.com/MOTU/Contributing#Preparing_New_Packages
<Unit193> Of course you'll need an LP account and all that.
<ngomes> i'm using vmtouch , whitch i had to compile would be great if it was available in main repositories
<ngomes> ok gonna read it
<ngomes> i don't have account.
<Unit193> !info vmtouch xenial
<ubottu> Package vmtouch does not exist in xenial
#ubuntu-motu 2016-01-12
<Logan> Unit193: is the Debian maintainer working on an update?
<Unit193> Logan: Nope, it's RFA'd.
<Logan> maybe you should adopt it :)
<Unit193> Noooooooope.jpg!
<dholbach> good morning
<tsimonq2> o/ dholbach
<dholbach> hey tsimonq2
<lfaraone> what's the Importance for a FTBFS bug?
#ubuntu-motu 2016-01-13
<dholbach> good morning
<tsimonq2> o/ dholbach
<dholbach> hi tsimonq2
<Unit193> Logan: Have a chance to review it?
#ubuntu-motu 2016-01-14
<yofel> so, after having been ~kubuntu-dev for a few years and getting to know the distro pretty well, what would be the appropriate way to apply for ~motu permissions? Any particular prerequisites i should be respecting?
<mitya57> yofel, the usual way: https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
<yofel> mitya57: thanks
<mitya57> It would be really nice to have you in MOTUs!
#ubuntu-motu 2016-01-15
<Logan> lfaraone: high
<Logan> Unit193: not yet
<Unit193> Logan: OK, ended up filing 1534366.
#ubuntu-motu 2016-01-16
<Mechtilde> https://bugs.launchpad.net/ubuntu/+source/calendar-exchange-provider/+bug/1203433
<ubottu> Launchpad bug 1203433 in calendar-exchange-provider (Ubuntu) "Please remove and blacklist calendar-exchange-provider" [Wishlist,Fix released]
<Mechtilde> what can I also do, to  push on?
#ubuntu-motu 2017-01-09
<ehoover> wgrant: ping
#ubuntu-motu 2017-01-10
<Unit193> Rhonda: Is the soft freeze hindering your desire to get Irssi 1.0 in Debian?
<Rhonda> Unit193: Yes, no, solved. ;)
<Rhonda> I was asked to check the reverse dependencies, and given we have transition freeze got told that an exception could be made if the reverse depends would do with just a binNMU.
<Rhonda> There was some API change upstream though, so I uploaded the bugfix release 0.8.21 for now.
<Rhonda> I got an upstream patch though that just used some #define old_functioname new_functioname which allows to binNMU the plugins, I tested that already, but I want to give the package maintainers of the modules a chance to check that themself before pushing it.
<Rhonda> So: 1.0.0 is prepared but not pushed yet (neither to git, I might want to do that for now)
<Unit193> OK, cool.  Thanks for the full update!
<Rhonda> Unit193: Also, there is something that I changed: /version now gives the full package version, not just the upstream version.  This is useful to know if one still has to /upgrade, and also for reports to upstream to know which security patches might be included already, if it's distribution related updates.
<Unit193> Oooh, cool.
#ubuntu-motu 2017-01-11
<ehoover> wgrant: when you have a chance, i have a question about deploying our wine packages
#ubuntu-motu 2018-01-08
<Rhonda> Where is the old releases of ubuntu stored?
<Rhonda> Rhonda: old-releases.ubuntu.com, duh
 * sladen wants for the punchline
 * sladen waits for the punchline
 * Rhonda punches sladen, consensualwise?
<sladen> best joke I've heard this year
 * sladen looks at the date
<JackFrost> Well...I've made bad jokes.  Those count?
<Rhonda> sladen: It was just that I found the site name directly after I wrote it, myself â¦
<Rhonda> So to take out the urge of others responding when they don't see an answer yet I responded to myself.  Is that so unusual?
<sladen> Rhonda: you may also be interested in  http://releases.ubuntu.com/  which has releases that are newer than the old releases.
<sladen> Rhonda: ...except for the latest one, owing to intel-spi knowing better than locking out flash chips
<JackFrost> (Rhonda maintains packages.ubuntu.com. last i knew.)
<sladen> bahdum.  Finally we reach the punchline
<JackFrost> Also very important packages, like irssi! \o/
 * Rhonda hides.
#ubuntu-motu 2018-01-09
<handsome_feng> Hi, tsimonq2, 'debuild' or 'sbuild -d bionic-amd64' works fine on my end, but I have no idea why you get that error :/
<tsimonq2> handsome_feng: Hm, that's weird :/
<tsimonq2> handsome_feng: If you can give me your sbuild log I'll call it good and upload
<JackFrost> What are we looking at?  I can push it through bionic/amd64 to see what I get.
<tsimonq2> JackFrost: kylin-display-switch's Ubuntu ITP
<tsimonq2> (I say ITP as a figure of speech here)
<tsimonq2> JackFrost: https://github.com/ukui/debian-packages <- source is there
<tsimonq2> lgtm but since builders are bricked I want to confirm
<handsome_feng> LP: #1738366
<ubottu> Launchpad bug 1738366 in Ubuntu Kylin "[needs-packaging] kylin-display-switch" [High,In progress] https://launchpad.net/bugs/1738366
<handsome_feng> JackFrost, Thanks!
<JackFrost> Thanks, https://launchpad.net/~ubuntukylin-members/+archive/ubuntu/newpackages/+files/kylin-display-switch_1.0.1-0ubuntu2.dsc was what I wanted.
<tsimonq2> JackFrost: er
<tsimonq2> no
<tsimonq2> He didn't upload his most recent revision
<tsimonq2> There's newer commits in Git than what's in the PPA
<handsome_feng> I have upload to the ppa
<handsome_feng> tsimonq2 :)
<tsimonq2> ohh
<tsimonq2> Ok
<tsimonq2> :)
<JackFrost> One hour old, sooo...
<JackFrost> WFM, anyway.
<tsimonq2> Alright, I'll take your word on it, uploading.
<JackFrost> https://unit193.net/kylin-display-switch_1.0.1-0ubuntu2_amd64.build why take my word on it? ;)
<tsimonq2> handsome_feng: Ok, so you had a few other ones too?
<tsimonq2> handsome_feng: Could you please upload new versions of those to your PPA as well?
<tsimonq2> handsome_feng: (seeing as you did debhelper compat bumps)
<handsome_feng> Yes, I will do it as soon as possible :)
<tsimonq2> Cool :)
#ubuntu-motu 2018-01-10
<Pr0t3us> What's up with the launchpad? I've been waiting on a build all day
<dax> the build farm's disabled 'cause of meltdown and spectre and such
<dax> per /topic #launchpad and /topic #ubuntu-devel
<Pr0t3us> thank you
#ubuntu-motu 2018-01-14
<maciemo> ââââââââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). jkupumlo: persia mdeslaur chrisccoulson âââââââââââââââââââ
<maciemo> ââââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). clpqz: vincent_c Pici sgclark âââââââââââ
<maciemo> ââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). ivspmtx: doppo Nafallo ScottE ââââââââââââââââ
<maciemo> âââââââââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). wybsdx: Elimin8er ubuntulog bschaefer âââââââââââââââ
<maciemo> âââââââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). ammqekcuh: slangasek ssweeny chiluk âââââââââââââ
<maciemo> âââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). ytkbkfd: Acn0w acheronuk grumble âââââââââââââ
<maciemo> ââââââââââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). cdufyppke: persia wgrant ogra_ ââââââââââââ
<maciemo> âââââââââââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). pjmdhtm: bschaefer Elimin8er glebihan âââââââââââââ
<maciemo> ââââââââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). cdxvov: hggdh dragan-s Rhonda ââââââââââââââââââ
<maciemo> âââââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). qwpoagv: pipedream acheronuk ratliff ââââââââââââ
<maciemo> âââââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). mdkyfd: LordOfBikes ember ochosi ââââââââââââââââââ
<maciemo> âââââââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). yicokq: ubuntulog czchen acheronuk ââââââââââ
<maciemo> âââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). grogabfxv: sbeattie lionel dragan-s ââââââââââââ
<maciemo> âââââââââââââââ TRELANE IS OFFERING FREE FELACIO CLASSES IN #FREENODE (FEEL FREE TO MESSAGE HIM AS WELL). dlycgmcb: Laney M-lfaraone cjwatson ââââââââââââââââ
