[01:25] <ebroder> Anyone willing to sponsor an upload? bug #339449
[04:53] <imbrandon> jcastro: happy bday ( its midnight mytime, not sure about yours )
[04:53] <imbrandon> :)
[05:23] <tgm4883> in debian/copyright, I have the standard gpl v2 blurb, but I have some files that are strictly v2, can I freely remove the part that says  "or (at your option) any later version. "
[05:23] <tgm4883> the standard blurb i'm talking about is similar to http://bazaar.launchpad.net/~mythbuntu/mythexport/intrepid/annotate/head%3A/debian//copyright
[05:24] <persia> tgm4883, If you have sources with two different licenses (and GPLv2 is different than GPLv2+), then it's best practice to identify them, and have two paragraphs.
[05:25] <persia> If all your source is the same, just use the same text as in the source files.
[05:25] <tgm4883> persia, right, and I am separating them.  I just need to know if I can just remove that part for the files that are strictly v2, or if there is a different blurb I should be using
[05:25] <persia> You should *always* use the blurb in the source files.
[05:25] <persia> Don't use "standard" blurbs, except when upstream did.
[05:27] <ripps> I'm trying to write a script that puts the operations dch, debuild, and dput into single command. How can I pull the latest version from debian/changelog, without a bunch of other stuff?
[05:27] <persia> Note that when dealing with licenses with addresses, and you *know* the address is no longer current, updating that is fine, but otherwise, stick with upstream.
[05:28] <persia> ripps, I don't think you want to do it that way, but dpkg-parsechangelog is probably what you want.
[05:28] <tgm4883> persia, ok, in the files, the only thing they say is "# Released under the terms of the GNU GPL v2"
[05:28] <tgm4883> which I was under the impression that I had to add the short license to debian/copyright
[05:29] <persia> OK.  You've found an exceptional case.
[05:29] <tgm4883> well I am exceptional ;)
[05:29] <persia> I recommend bugging upstream, because they are *supposed* to put in the blurb.  Bugging by way of a patch attached to an enhancement request is best practice.
[05:30] <tgm4883> ok, and the short term?
[05:30] <persia> That said, yes, drop the "or (at your option) any later version." text.
[05:30] <tgm4883> ok
[05:30] <ripps> What's the easiest way of managing multiple packages with multiple backports?
[05:30] <persia> I can't promise the archive-admins won't complain, but it's the closest you'll get to being right for now.
[05:30] <tgm4883> heh, well, they are complaining with how it is right now ;)
[05:31] <tgm4883> thats what i'm trying to fix
[05:31] <persia> The source files are *not* properly licensed, in my opinion.  I recommend checking with the archive admin to make sure you're meeting their requirements before pushing it again.
[05:32] <tgm4883> ok, will do
[05:32] <tgm4883> thanks persia
[05:33] <persia> tgm4883, Also, it's worth remembering that regardless of the contents of debian/copyright, the orig.tar.gz must be suitable for redistribution on it's own.
[06:45] <iulian> Does anyone know why I'm getting: 'Could not find compatible GRE between version 1.9.0.1 and 1.9.0.*.' when I run firefox?
[06:47] <iulian> Doh
[06:47]  * iulian hasn't finished upgrading.
[06:50] <dholbach> good morning
[06:55]  * wgrant notes that we are ~ half way through the obvious part of the universe Python 2.6 transition.
[07:15] <iulian> G'morning dholbach!
[07:15] <dholbach> hiya iulian
[07:17] <iulian> How is it going?
[07:18] <dholbach> very good - how are you doing?
[07:18] <ebroder> I know I can't make the alpha release, but can someone upload bug #339449 so it's in the queue?
[07:20] <iulian> dholbach: I'm doing my calculus homework right now and looking at my irssi window. :-)
[07:21] <dholbach> good luck with that :)
[07:22] <ebroder> Dude - IM + homework !!= productivity
[07:22] <iulian> Hehe
[07:22] <ebroder> Seriously - it just doesn't work. Context switches are expensive
[07:58] <dholbach> fabrice_sp__: looks like im-sdk is still FTBFSing (it built fine for me in pbuilder though :-/)
[07:58] <dholbach> I'll be back in a bit, just letting you know
[08:34] <willwill> hi! any one willing to review my package here? http://revu.ubuntuwire.com/details.py?package=mbpurple
[08:57] <Toadstool> good morning everybody
[10:10] <eMerzh> If a motu has some time to review my package at http://revu.ubuntuwire.com/details.py?package=sqliteman ...
[10:41] <c_korn> hello, I want to open a bug about moving scilab to univesre because it is now free. is there a wiki or something about how to request?
[10:43] <slytherin> c_korn: have you solved the FTBFS problem?
[10:43] <c_korn> slytherin: yes, it is already in jaunty. but in multiverse
[10:44] <dholbach> c_korn: just file a bug report, explaining what changed and that you want to move it to universe and subscribe ubuntu-universe-sponsors - somebody will review, ACK and subscribe ubuntu-archive later
[10:45] <slytherin> c_korn: I asked you if you solved the FTBFS problem.
[10:46] <c_korn> slytherin: it only failed to build because there were empty translation files in the package. I removed them in clean target.
[10:47] <dholbach> seems like it FTBFS in a couple of other places still: https://launchpad.net/ubuntu/jaunty/+source/scilab/5.1-0ubuntu2
[10:48] <c_korn> oh, that you mean :P I filed a bug in the scilab bug tracker. sylvestre wants to look at it.
[10:48] <c_korn> at least powerpc and ia64 should build then
[10:48] <c_korn> the other archs fail for some other reasons
[10:48] <c_korn> missing dependencies
[10:49] <dholbach> ah ok
[10:49] <directhex>   openjdk-6-jdk: Depends: openjdk-6-jre (>= 6b14-1.4.1-0ubuntu2) but it is not going to be installed
[10:49] <directhex> java shonk
[10:49] <directhex> on SOME arches anyway
[10:50] <directhex> checking to see if we can link a JNI application... no
[10:50] <directhex> configure: error: could not link file that includes jni.h
[10:50] <directhex> on others
[10:50] <directhex> generally, java suckitude's to blame one way or another
[10:52] <c_korn> is this sufficient? https://bugs.launchpad.net/baltix/+bug/340413
[10:53] <slytherin> c_korn: why did you file it in baltix?
[10:53] <c_korn> slytherin: was a mistake
[10:53] <c_korn> https://bugs.launchpad.net/scilab/+bug/340413
[10:54] <c_korn> should I mark the baltix one as invalid?
[10:55] <c_korn> should I list all packages that have to be moved?
[10:58] <geser> c_korn: have you checked if all build-dependencies and runtime-dependencies for all binary packages are in main/universe?
[10:59] <geser> and the bug should be better against the scilab package in ubuntu and not the scilab project
[11:08] <pochu>    * Change pastebinit's default behavior to reading from stdin (Thanks fta)
[11:08]  * pochu hugs stgraber :-)
[11:08]  * pochu hugs fta too ;)
[11:11] <c_korn> geser: https://bugs.launchpad.net/scilab/+bug/340413/comments/1 I checked all dependencies
[11:11] <c_korn> they are fine
[11:17] <stgraber> pochu: works ?
[11:18] <stgraber> pochu: that should be a "no new feature but everything's fixed" release, a bit last minute for Jaunty but we couldn't keep the one we had in so ...
[11:19] <pochu> stgraber: didn't update yet... shouldn't it?
[11:19] <pochu> stgraber: you're a good upstream for that! :)
[11:24] <stgraber> even the translations seem to work (except one string as it's been added yesterday and isn't translated on LP yet)
[11:41] <Laney> jcfp: I need your python 2.5 wizardry. How did you manage to get rid of the << 2.6 dep on sab? I've a similar problem with another package...
[11:42] <jcfp> Laney: it had to do with trying to provide a public module without supporting the default python version
[11:43] <jcfp> which apparently isn't allowed unless the package name is something like pythonX.Y-modulename
[11:43] <Laney> guh
[11:44] <jcfp> In case of sab, solution was to make the module private
[11:45] <Laney> might work, thanks
[12:04] <torkel> siretart: thanks!
[12:16] <sistpoty|work> hi folks
[12:29] <ScottK> Hi sistpoty|work.
[12:29] <sistpoty|work> hi ScottK
[13:00] <cristi> savvas: hy!
[13:00] <cristi> savvas: so what should i do in order to help out with the python packages update to 2.6 (i think)
[13:08] <geser> cristi: you mean the python 2.6 transition?
[13:08] <cristi> geser: yes
[13:09] <geser> cristi: have you read the mail on ubuntu-devel what needs to be changed in the packaging of a package?
[13:09] <cristi> geser: i am just getting started, i am still reading articles on the wiki. however i was told that it's not that hard to contribute to the python 2.6 transition
[13:10] <cristi> geser: so the answer is no
[13:10] <geser> cristi: it's really easy
[13:10] <geser> (in most cases)
[13:10] <cristi> what is really easy lol
[13:11] <cristi> the python transcription i guess, ok can you help me out so i can start doing something
[13:11] <geser> cristi: https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027528.html
[13:12] <geser> the next step is then picking a package which needs a transition
[13:13] <geser> btw: have you already a jaunty pbuilder?
[13:14] <cristi> geser: yes, i got it last night and took a look at introductive stuff
[13:14] <geser> good as it makes the test building easier
[13:20] <Laney> ffmpeg did a release?! :O
[13:21] <directhex> what what?
[13:21] <directhex> ffmpeg, the "change everything every week" app?
[13:21] <Laney> http://svn.ffmpeg.org/ffmpeg/branches/0.5/RELEASE?revision=17805
[13:21] <Laney> crazy
[13:28] <StevenK> And the world didn't end!?
[13:29] <StevenK> The release name is all kinds of ironic
[13:33] <slytherin> what kind of policy is this "we have made a release but we only accept bugs against svn trunk"?
[13:33] <directhex> slytherin, it's more liberal than their usual policy of "trunk or gtfo"
[13:34]  * slytherin will be back in 10-15 minutes.
[13:35] <theholyduck> directhex, i like the trunk or gtfo
[13:35] <theholyduck> it works therefor its good
[14:00] <bddebian> Heya gang
[14:00] <geser> Hi bddebian
[14:00] <bddebian> Hi geser
[14:05] <__iron> hi
[14:13] <__iron> isnt a new pidgin-version avaible in 8.10 ?
[14:14] <geser> __iron: afaik it's being worked on
[14:15] <__iron> k thx geser
[14:21] <sven777> would any motu kindly review my package?  Thanks in advance!  http://revu.ubuntuwire.com/p/lmalinux
[14:25] <quadrispro> hi guys
[14:30] <siretart> Laney: and guess what, that release is already in debian unstable since *last week*
[14:33] <cristi> uhm i had the hardy version of pbuilder (or at least i think), and i run     sudo pbuilder update --distribution interpid --override-config. however, after trying to build a package i am getting this (error i think?) http://pastebin.com/m30804dd7
[14:33] <cristi> can anyone tell me what should i do? this is my first package
[14:34] <directhex> cristi, not enough output to be helpful
[14:34] <slytherin> cristi: can you paste complete error? The part you pasted is not much usefull
[14:34] <cristi> yes, one moment
[14:34] <cristi> i see now that the problem is a bit deeper
[14:35] <cristi> http://pastebin.com/m13e8dfee
[14:36] <hyperair> cristi: sudo
[14:37] <hyperair> no wait, there's more
[14:37] <cristi> no no, i think i overpasted
[14:37] <cristi> i used sudo
[14:37] <cristi> 2nd time
[14:37] <slytherin> cristi: have you enabled universe section in your config? because libstatgrab-dev is in universe
[14:38] <cristi> blah i guess not, can you tell me how to do that, or give me a link..?
[14:39] <hyperair> --components
[14:39] <slytherin> cristi: are you using a ~/.pbuilderrc? If not, it is better to copy /etc/pbuilderrc to ~/.pbuilderrc and modify that file.
[14:40] <hyperair> cristi: sudo pbuilder update --override-config --components "main universe"
[14:41] <cristi> hyperair: i am getting hardy release packages :-s
[14:41] <hyperair> oh
[14:41] <hyperair> --distribution intrepid then
[14:42] <cristi> i guess i should give an output
[14:43]  * hyperair nods
[14:44] <cristi> http://pastebin.com/m53074083
[14:44] <hyperair> intrepid not interpid
[14:45] <cristi> lol omg
[14:45] <hyperair> lol
[14:45] <directhex> i didn't want to say anything... :/
[14:46] <hyperair> lol
[14:46] <cristi> >_<
[14:47] <cristi> what the hell   -> Someone else has lock over /var/cache/pbuilder/base.tgz.tmp, waiting
[14:47] <slytherin> cristi: this is the reason I asked you to use separate pbuilderrc
[14:48] <cristi> slytherin: i did separate
[14:48] <cristi> copied to ~/
[14:48] <cristi> ok, so now what should i do
[14:49] <slytherin> cristi: did you name the file .pbuilderrc?
[14:49] <cristi> yes
[14:49] <cristi> however, it's all i did
[14:49] <cristi> just copied it
[14:49] <slytherin> cristi: did you change the distribution and components in that file?
[14:50] <cristi> no
[14:50] <slytherin> after that you need to do pbuilder --update --override-config
[14:51] <cristi> #COMPONENTS="main restricted universe multiverse" // i should just uncomment the line ?
[14:54] <slytherin> cristi: it depends on what all components you want. If you want all of them then uncomment it.
[14:54] <cristi> i am still getting   -> Someone else has lock over /var/cache/pbuilder/base.tgz.tmp, waiting
[14:56] <cristi> slytherin: so, now what should i do?
[14:57] <hyperair> slytherin: does it matter, if you're on a single-user system?
[14:57] <hyperair> cristi: break the lock. don't ask me where it is though
[14:59] <c_korn> hello, is this move request sufficient? or do I miss something? https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/340413
[15:00] <slytherin> hyperair: does what matter?
[15:00] <cristi> hyperair: this is not really working
[15:01] <cristi> i don't know what is causing the lock.
[15:02] <hyperair> slytherin: having a separate .pbuilderrc. personally i have a bunch of scripts which maintain different pbuilder base.tgz, each of different releases. i've never touched a pbuilderrc before
[15:02] <hyperair> cristi: maybe another pbuilder is running?
[15:02] <hyperair> or maybe the previous run of pbuilder didn't close cleanly
[15:02] <cristi> hyperair: i have only one terminal session open
[15:02] <hyperair> hm
[15:03] <cristi> hyperair: i can start over reinstalling pbuilder i guess ?
[15:03] <hyperair> no.
[15:03] <hyperair> no need.
[15:03] <cristi> ok
[15:03] <hyperair> i mean it won't do anything
[15:03] <hyperair> hmmm
[15:03] <hyperair> just delete /var/cache/pbuilder
[15:03] <slytherin> hyperair: I have punch of pbuilderrc each corresponding to a different pbuilder chroot. :-)
[15:04] <hyperair> slytherin: command line options ftw =p
[15:04] <slytherin> cristi: don't delete /var/cache/pbuilder. It will also delete your base.tgz.
[15:04] <hyperair> slytherin: that's the point. it can be regenerated
[15:04] <cristi> slytherin: ok, i didn't delete it
[15:05] <cristi> slytherin: was really close to though xD
[15:05] <hyperair> i don't know, when things get messy like this, sometimes it would be faster to just start over, don't you think?
[15:05] <slytherin> cristi: delete that .tmp file instead.
[15:06] <slytherin> hyperair: provided you have fast internet connection.
[15:06] <cristi> ok
[15:06] <cristi> now?
[15:06] <hyperair> slytherin: debootstrap takes at most 15 minutes on my desktop, and that's with 512kbps
[15:06] <slytherin> hyperair: 512 is fast.
[15:06] <hyperair> slytherin: you sure?
[15:06] <hyperair> it maxes out at 50 kB/s
[15:07] <slytherin> hyperair: yes. In the places I live, you either get fast speed or unlimited data transfer. Not both.
[15:07] <hyperair> slytherin: ouch.
[15:07] <hyperair> slytherin: i've got 512kbps, unlimited data transfer
[15:08] <hyperair> slytherin: which part of the world are you from anyway
[15:08] <slytherin> hyperair: India
[15:08] <hyperair> i see.
[15:08] <hyperair> your ISP sucks =(
[15:09] <hyperair> and i thought malaysian ISPs were bad
[15:09] <cristi> slytherin: uh i deleted the .tmp file, now i just run again sudo pbuilder --update --override-config ?
[15:09] <hyperair> cristi: yeah
[15:10] <cristi> slytherin: ok, finally done
[15:11] <cristi> slytherin: thank's a lot! :D
[15:11] <slytherin> cristi: welcome
[15:58] <ara> anyone willing to answer a migration to python 2.6 question?? any takers? :)
[15:59] <RainCT> ara: just ask, and if someone knows the answer he'll tell you :)
[15:59] <RainCT> although I guess you already know this
[15:59] <ara> :D
[16:00] <ara> well, the thing is that if in jaunty now you do 'apt-get source ldtp' and try to build it, it will fail
[16:00] <ara> the problem is that it does not use distutils
[16:00] <ScottK> What's the error?
[16:00] <ara> so I don't know how to fix it
[16:01] <ara> dh_install -i --sourcedir=debian/tmp
[16:01] <ara> dh_install: python-ldtp missing files (usr/lib/python2.5/site-packages/*.py), aborting
[16:01] <ara> it does not find it, because it places them under /tmp instead
[16:01] <ara> (debian/tmp)
[16:03] <pochu> ara: what are the contents of your .install file?
[16:04] <ara> usr/lib/python2.5/site-packages/*.py
[16:04] <ara> usr/lib/python2.5/site-packages/ldtplib/*.py
[16:04] <jpds> You'll have to change it to python2.6/dist-packages*.
[16:05] <ScottK> ara: Change it to usr/lib/python*/*-packages/*.py
[16:05] <ara> I already tried that
[16:05] <pochu> you guys are fast
[16:05] <ara> I already tried that :)
[16:05] <ScottK> ara: Tried which?
[16:05] <anakron> hi all
[16:05] <ara> I changed it to usr/lib/python*/dist-packages/*.py
[16:05] <ara> it didn't work
[16:05] <pochu> ara: can you do `ls debian/tmp/usr/lib/` when the build fails?
[16:05] <anakron> hi rainct, persia, thekorn. pedro_
[16:06] <ScottK> ara: That's not what I suggested.
[16:06] <anakron> and Laney
[16:06] <anakron> :)
[16:06] <ara> ScottK, yes I am going to try it now
[16:06] <pochu> anakron: you're on a waving spree!
[16:06] <anakron> :-)
[16:06] <ScottK> Also if the issue is related to overall path, like /tmp/debian versus /tmp, that's unrelated to the new Python.
[16:07] <ara> ScottK: i tried your suggestion and it didn't work either
[16:07] <ScottK> OK.  What error then?
[16:08] <ara> ScottK: smae
[16:08] <ara> ScottK: same
[16:09] <ScottK> ara: Can you pastbin the actual build failure message and your debian/rules?
[16:09] <ara> ScottK, pochu: these are the contents of debian/tmp after the failure: http://paste.ubuntu.com/129373/
[16:10] <ara> ScottK: it is the current package, without changes: if you do "apt-get source ldtp" you will have it all
[16:10] <ScottK> OK
[16:11] <pochu> ara: it's installing things in /ldtplib rather than /usr/lib/python*/*packages :)
[16:11] <ara> pochu: not really
[16:12] <ara> pochu: it used to install things under /usr/lib/python*/*packages/ldtplib and /usr/lib/python*/*packages, and now it has lost that structure
[16:12] <ara> pochu: again, I didn't change anything on the packaging
[16:12] <ara> pochu: so I thought it might be something related to the python migratoin
[16:13] <pochu> ara: sure. I mean, right now it tried to install things in / ;)
[16:13] <pochu> or at least that's what your pastebin shows
[16:14]  * ScottK is going to try building it and see.
[16:14] <ara> pochu: but I already saw that :)
[16:15] <ara> pochu: thanks anyway, I will keep trying
[16:31] <savvas> geser: thanks for sponsoring it! :) and sorry for the typo ("LP" instead of "LP:")
[16:36] <savvas> hm.. that's nice, debian bugs are now successfully tracked through launchpad :)
[16:45] <ScottK> ara: Change python-ldtp.install to *.py
[16:46] <ScottK> It at least builds.
[16:46] <ScottK> You'd have to see if the binary has all the right files in it.
[16:49] <ara> ScottK: it is an upstream bug. i am talking with upstream now, thanks!
[16:50] <ScottK> ara: Excellent.
[17:00] <savvas> Is there a command that outputs "i386" or "amd64" depending on the architecture?
[17:02] <savvas> arch isn't available unfortunately
[17:04] <RainCT> savvas: uname, but it returns other values than just i386/amd64
[17:04] <savvas> uname -m ? I'll see what I can do with it, thanks :)
[17:04] <RainCT> and I'm not sure if it shows the architecture you are running one or that one for the kernel.. :P
[17:04] <savvas> oh :p
[17:05] <savvas> cristi: you asked to help for python transition?
[17:05] <cristi> savvas: yes, but geser helped me a lot
[17:05] <RainCT> savvas: I'm using it in pbuilder-dist, os.uname()[4].replace('x86_64', 'amd64').replace('i586', 'i386').replace('i686', 'i386')
[17:06] <RainCT> for bash,  uname -m | <sed/awk..>  should do the same
[17:06] <pochu> dpkg-architecture -qDEB_HOST_ARCH
[17:06] <savvas> cristi: ah ok:) Since you also mentioned you're a beginner, I would suggest to start looking for bugs with "bitesize" tags: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[17:07] <savvas> pochu: now that's more like it :P thanks! :)
[17:07] <RainCT> pochu: uhmm nice
[17:07] <savvas> pochu: does it return i386 for i686 kernels as well?
[17:08] <maxb> Also, dpkg --print-architecture
[17:08] <cristi> savvas: they seem a bit difficult, i don't know. I tried to repair the xsensors package but i couldn't figure it out >_<. uhm and most bugs are taken for the ubuntu version
[17:08] <pochu> savvas: no idea, see dpkg-architecture(1) :)
[17:08] <savvas> hm, cool
[17:09] <maxb> dpkg --print-architecture definitely returns the string you expect to find in .deb file names.
[17:09] <pochu> savvas: and no, because I have a 686 kernel and it return 386 :)
[17:09] <maxb> Which is probably the same as DEB_HOST_ARCH
[17:09] <pochu> s/386/i386/
[17:10] <RainCT> does someone know how often popcon.ubuntu.com is updated (the data, not the website :))?
[17:10] <cristi> savvas: can i have your opinion apout a pbuild build error?
[17:12] <savvas> cristi: sure, but don't forget that I'm a beginner as well, not a motu :)
[17:13] <cristi> savvas: lol i thought you were a motu. however you surely know more about packaging than me so http://pastebin.com/m376c52b9
[17:13] <savvas> pochu, maxb: just what I needed, awesome!! thanks :)
[17:14] <savvas> cristi: I think --install-layout is for python 2.6
[17:14] <savvas> error: option --install-layout not recognized
[17:14] <cristi> savvas: is there really a problem with debian/rules ?
[17:14] <cristi> savvas: oh
[17:15] <savvas> cristi: try to substitute "for py in python2.4 python2.5" with "for py in python2.6 python2.5"
[17:16] <maxb> I think jaunty's python2.5 might well accept --install-layout as a no-op
[17:16] <savvas> cristi: is your pbuilder for jaunty release?
[17:16] <cristi> savvas: yes
[17:17] <cristi> savvas: i don't know where to substitute that
[17:17] <cristi> savvas: ﻿ "for py in python2.4 python2.5" with "for py in python2.6 python2.5"
[17:17] <savvas> cristi: cool then :) - it's in the file debian/rules :)
[17:17] <cristi> savvas: >_<
[17:18] <savvas> cristi: found it?
[17:18] <cristi> savvas: one moment
[17:18] <savvas> maxb: right, I forgot :P
[17:18] <cristi> savvas: i can't find that phrase
[17:20] <cristi> i have a --install-layout=deb , it's what i added to rules
[17:20] <savvas> brb
[17:22] <savvas> cristi: can you paste the debian/rules file on pastebin?
[17:22] <cristi> savvas: sure
[17:22] <cristi> savvas: http://pastebin.com/m19039cb8
[17:23] <savvas> cristi: can you paste debian/control as well? :)
[17:24] <savvas> cristi: and debian/pyversions as well, I forgot :)
[17:24] <cristi> savvas: http://pastebin.com/m630c5e16
[17:25] <cristi> savvas: no pyversions
[17:25] <cristi> savvas: only pycompat
[17:25] <savvas> ah true
[17:25] <savvas> ok
[17:26] <savvas> so the log says "for py in python2.4 python2.5"
[17:26] <savvas> in debian/rules you have something similar: for py in $(PYVERS)
[17:26] <ScottK> savvas: That's the expansion of what's in rules
[17:26] <savvas> PYVERS is a variable in that file
[17:27] <cristi> savvas: ok, so what should i do?
[17:27] <savvas> cristi: if you look at the top of the rules file it says: PYVERS:=$(shell pyversions -r)
[17:27] <savvas> also in the log it says: #
[17:27] <savvas> pyversions: missing XS-Python-Version in control file, fall back to debian/pyversions
[17:27] <savvas> pyversions: missing debian/pyversions file, fall back to supported versions
[17:27] <savvas> #
[17:28] <ScottK> Which should work OK even if it's not preferred.
[17:28] <cristi> savvas: ah so i should change PYVERS to what?
[17:28] <savvas> ScottK: so XS-Python-Version isn't necessary at all?
[17:28] <cristi> note that i don't have intrepid, but 8.04
[17:29] <savvas> cristi: if pbuilder is jaunty, it's fine :)
[17:29] <ScottK> It's supposed to be there, but the fallback should work.
[17:29] <cristi> savvas: it is
[17:29] <cristi> ScottK: so why doesn't it?
[17:29] <ScottK> Good questions.
[17:29] <savvas> ok cristi in debian/control under "Standards-Version: 3.7.2" try putting in a new line: XS-Python-Version: all
[17:30] <cristi> savvas: aha, ok
[17:31] <savvas> cristi: by the way, when did you last update pbuilder?
[17:31] <cristi> should i add these changes when running dch -i?
[17:31] <ScottK> cristi and savvas: From the build log you're building against Intrepid, not Jaunty
[17:31] <cristi> savvas: i installed it today
[17:31] <ScottK> That's the problem.
[17:32] <cristi> ScottK: uhm, so i should have a Jaunty pbuilder?
[17:32] <savvas> ah, I missed that :P
[17:32] <ScottK> Look at the version of python2.5 that's installed and then rmadison python2.5
[17:32] <cristi> ScottK: i have no idea how to do that
[17:33] <ScottK> savvas: Would you please help cristi get her pbuilder to be Jaunty.
[17:33] <cristi> ScottK: his! xD omg
[17:33] <savvas> cristi: to remove the pbuilder you already have try this: sudo rm /var/cache/pbuilder/base.tgz
[17:33] <cristi> savvas: can't i just upgrade?
[17:34] <tillux> heya there. I'm looking for a way to build a pxe-bootable image with xserver, gtk etc... I don't know where to start so I thought it'd be best to ask the masters of the universe ;)
[17:34] <savvas> cristi: it's easier to start clean :)
[17:34] <ScottK> cristi: You can, but you'll end up with a slightly different configuration and it will take as long if not longer.
[17:35] <savvas> sudo pbuilder --create --debootstrapopts --distribution jaunty --components "main restricted universe multiverse"
[17:35] <ScottK> cristi: Every day isn't like this.  The first day is the hardest.
[17:35] <cristi> savvas ScottK: ok, so i'll start over deleting
[17:35] <cristi> ScottK: hope so
[17:35] <savvas> cristi: this is the command to create a new pbuilder ^
[17:35] <cristi> savvas: done
[17:36] <ScottK> savvas: You might also consider recommending pbuilder-dist for new people.  It's generally simpler.
[17:36] <cristi> savvas: oh w8 ok
[17:36] <savvas> ScottK: never heard about it :) I'll try it :P
[17:36] <ScottK> savvas: It's in ubuntu-dev-tools
[17:36] <ScottK> The equivalent is pbuilder-dist jaunty create
[17:37] <cristi> savvas: damn, i get an error
[17:37] <ScottK> Or you can symlink pbuilder-jaunty to it and do pbuilder-jaunty create.
[17:37] <savvas> cristi: what does it say?
[17:37] <cristi> savvas: http://pastebin.com/m54799feb
[17:39] <savvas> cristi: let's try with pbuilder-dist, install this: sudo apt-get install ubuntu-dev-tools
[17:39] <cristi> savvas: i have them
[17:39] <savvas> great! execute: sudo pbuilder-dist jaunty create
[17:40] <cristi> still not
[17:40] <cristi> savvas: http://pastebin.com/m2e854888
[17:41] <savvas> give me a sec
[17:42] <fta> pochu, you're welcome (pastebinit stdin)
[17:42]  * fta hugs pochu back
[17:43] <savvas> cristi try: sudo pbuilder-dist jaunty create --mirror "http://archive.ubuntu.com"
[17:44] <cristi> savvas: it;s basically the same error
[17:44] <savvas> argh
[17:44] <savvas> give me a sec
[17:44] <cristi> savvas: [: 195: /home/cristi/pbuilder/jaunty-amd64_result: unexpected operator
[17:44] <cristi> savvas: this is extra
[17:45] <savvas> cristi: how about this: sudo pbuilder --create --debootstrapopts --distribution jaunty --components "main restricted universe multiverse" --mirror "http://archive.ubuntu.com"
[17:45] <cristi> savvas: same.
[17:46] <ScottK> cristi: Do you have hardy-backports enabled?
[17:46] <cristi> ScottK: i don't know what are those
[17:47] <ScottK> I think they are generally called unsupported updates or something similar
[17:47] <ScottK> savvas: cristi needs the deboostrap out of hardy-backports for this to work.
[17:48] <cristi> ScottK the instalation worked today
[17:48] <savvas> cristi: sudo wget http://paste.ubuntu.com/129431/plain/ -O /usr/share/debootstrap/scripts/jaunty
[17:49] <savvas> cristi: and then: sudo pbuilder-dist jaunty create
[17:49] <savvas> if this doesn't work, we'll try ScottK 's suggestion :)
[17:49] <cristi> savvas: nice, it does (i think)
[17:50] <savvas> nevertheless, it's good to update debootstrap from backports repositories if you'll use pbuilder: http://fr.archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_1.0.10ubuntu1~hardy1_all.deb
[17:50] <mrooney> would anyone have time to get to bug 333639? It is an update request and I think everything is ready to go!
[17:52] <cristi> i am installing that too
[17:53] <savvas> cristi: it basically needed the script for the jaunty release, debootstrap didn't "know" about jaunty since it was released after hardy :)
[17:54] <stefanlsd> How can i use a different build place for pbuilder-dist. ive tried export BUILDPLACE and --buildplace. It defaults here - /tmp/buildd/
[17:54] <cristi> savvas: hah, cute
[17:54] <RainCT> stefanlsd: PBUILDFOLDER
[17:54] <savvas> cristi: once it's done, try rebuilding, without any changes (without adding XS-Python-Version), if ScottK is right, it should work :)
[17:54] <RainCT> ah, build place
[17:54] <RainCT> I don't know then :(
[17:55] <stefanlsd> RainCT: nodnod.  my /tmp is on lvm and its too small for this package... guess i could symlink it
[17:56] <savvas> stefanlsd: --buildplace should work
[17:56] <savvas> any errors?
[17:57] <cristi> savvas: i guess that it is common to create the tarball first, and it's not something that should have been created previously ?:-s
[17:59] <savvas> cristi: If I understood you correctly, every time you do a change in the debian source package you have to execute "dch -i" (add a changelog) and "debuild -S -sd" if the package is already in ubuntu (if the package is new or a new upstream release, use "debuild -S -sa")
[17:59] <savvas> cristi: you can skip "dch -i" if you already have changed the changelog :)
[18:00] <cristi> savvas: i got that so far
[18:01] <savvas> usually you get the debian source package along with the tarball with this command: apt-get source packagename
[18:01] <cristi> savvas: nonono, uhm i was refering to the pbuilder tarball
[18:01] <stefanlsd> savvas: this is using pbuilder-dist. does that make a difference?
[18:02] <savvas> stefanlsd: try with pbuilder (might be an error in the pbuilder-dist script?)
[18:03] <stefanlsd> savvas: will do. my pbuilder always used to work. not sure when in jaunty it stopped working. seems like it doesnt read my vars in ~/.pbuilderrc
[18:04] <savvas> cristi: I don't understand :\ you feed pbuilder with *.dsc files created using debuild :)
[18:04] <cristi> savvas: creating base tarball [/var/cache/pbuilder/base.tgz]
[18:04] <cristi> savvas: this is what i was talking about
[18:04] <savvas> ah :P
[18:05] <savvas> it's created automatically if it's not already there
[18:05] <savvas> I mean..
[18:05] <savvas> we use --create to create it
[18:05] <cristi> error: option --install-layout not recognized
[18:06] <cristi> savvas: unbeliveable
[18:06] <savvas> cristi: paste the whole log
[18:07] <cristi> savvas: http://pastebin.com/m6f64d9ba
[18:07] <savvas> Get:1 http://archive.ubuntu.com intrepid/main gettext-base 0.17-3ubuntu2 [83.9kB]
[18:07] <savvas> it still uses intrepid, weird
[18:08] <savvas> let me check that debootstrap script I gave you :P
[18:08] <cristi> savvas: :))
[18:09] <savvas> cristi: try installing debootstrap from backports, the link I gave you earlier
[18:09] <cristi> savvas: uhm the problem might be with pbuilderrc?
[18:10] <cristi> savvas: i had it copied to ~/
[18:10] <cristi> ~/.pbuiderrc could be the problem? i have DISTRIBUTION=intrepid there
[18:10] <savvas> er.. probably
[18:10] <savvas> remove that file
[18:11] <savvas> install debootstrap backports and try again: sudo rm /var/cache/pbuilder/base.tgz; sudo pbuilder-dist jaunty create
[18:12] <savvas> third time's the charm :P
[18:13] <cristi> savvas: :)) what should i get from the link you gave me?
[18:14] <savvas> cristi: wget http://fr.archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_1.0.10ubuntu1~hardy1_all.deb; sudo dpkg -i debootstrap_1.0.10ubuntu1~hardy1_all.deb; sudo apt-get -f install
[18:14] <cristi> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[18:16] <cristi> savvas: i don;t think that's ok
[18:16] <cristi> savvas: eh, we'll see
[18:17] <savvas> cristi: did it complain about dependencies?
[18:18] <cristi> savvas: damn i didn't see an error
[18:19] <savvas> cristi: apt-cache policy debootstrap
[18:19] <savvas> it should show you which version is installed
[18:19] <savvas> debootstrap 1.0.10ubuntu1~hardy1 is the backport version
[18:20] <cristi> savvas:   Installed: 1.0.10ubuntu1~hardy1
[18:20] <savvas> cristi: and try again: sudo apt-get -f install
[18:20] <cristi> savvas: so it's ok?
[18:20] <savvas> if it doesn't complain, then it's alright :)
[18:20] <cristi> ok then rerunning pbuilder
[18:21] <savvas> great, good luck :D
[18:21] <cristi> savvas: i'll need it i guess ~_~
[18:22] <savvas> cristi: check the logs while downloading
[18:22] <savvas> Distribution is jaunty.
[18:22] <savvas> it should say jaunty, not intrepid
[18:23] <cristi> savvas: it's jaunty
[18:25] <savvas> then it should be ok now :)
[18:27] <cristi> savvas: E: failed to find /var/cache/pbuilder/base.tgz, have you done <pbuilder create> to create your base tarball yet?
[18:27] <cristi> savvas: sudo pbuilder create?
[18:28] <savvas> cristi: you used pbuilder-dist ?
[18:28] <cristi> savvas: hm? no
[18:28] <savvas> try: sudo pbuilder-dist jaunty build yourfile.dsc
[18:28] <cristi> shift: 72: can't shift that many
[18:29] <cristi> savvas:  -> creating base tarball [/home/cristi/pbuilder/jaunty-amd64-base.tgz]
[18:29]  * savvas scratches his head
[18:29] <cristi> savvas: this is part of the pbuilder create
[18:29] <cristi> savvas: jaunty pbuilder create
[18:29] <savvas> cristi: try: sudo pbuilder-dist jaunty build yourfile.dsc
[18:30] <cristi> savvas: seems to be working, let's see results
[18:30] <savvas> ah, so pbuilder-dist installs the base files locally! :P
[18:31] <cristi> savvas: /:) i don't understand
[18:31] <savvas> 19:11:41 < savvas> install debootstrap backports and try again: sudo rm /var/cache/pbuilder/base.tgz; sudo  pbuilder-dist jaunty create
[18:31] <savvas> if you used this command, you used pbuilder-dist to make the new .tgz pbuilder file
[18:32] <savvas> unless you set it to be created at /home/cristi/pbuilder/ :)
[18:33] <cristi> savvas: let me get you a bit of output because i don't really know if it is ok
[18:34] <cristi> savvas: http://pastebin.com/m452ccc06
[18:36] <savvas> looks good, you got both 2.5 and 2.6 directories as far as I can see
[18:38] <cristi> savvas: now, how do i do the debdiff :D? what do i put there? i can see in the example 2 .dsc, which?
[18:38] <savvas> cristi: while in the directory of the package folder (e.g. "somepackage-1.0.1/") type: debdiff
[18:39] <cristi> debdiff: fatal error at line 248: Can't read file: debian/changelog
[18:40] <savvas> cristi: ls -l
[18:40] <cristi> savvas: hm i think i got it wrong
[18:40] <savvas> do you see a folder like somepackage-1.0.1/ ?
[18:40] <cristi> yes
[18:40] <savvas> then cd somepackage-1.0.1/
[18:40] <savvas> :)
[18:40] <savvas> and then: debdiff
[18:41] <savvas> it should output a patch, that you can save: debdiff > ../mypatch.debdiff
[18:42] <savvas> ( to access it, cd .. and cat mypatch.debdiff )
[18:42] <cristi> savvas: http://pastebin.com/m30d60c35
[18:42] <savvas> cristi: sudo apt-get install devscripts
[18:43] <cristi> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[18:43] <savvas> ah
[18:43] <savvas> sudo apt-get install patchutils
[18:43] <savvas> :)
[18:44] <savvas> now try again: debdiff > ../mypatch.debdiff
[18:44] <savvas> cd ..
[18:44] <savvas> cat mypatch.debdiff
[18:45] <cristi> should mypatch.debdiff have a specific name?
[18:45] <savvas> well, no, but I like to use packagename_version.debdiff
[18:46] <cristi> savvas: ok, so it's done
[18:46] <savvas> yep
[18:46] <savvas> what did you add in the changelog?
[18:46] <savvas> ah wait
[18:46] <savvas> +  * Python 2.6 transition: added --install-layout=deb to debian/rules
[18:46] <savvas> +  * Modify Maintainer value to match the DebianMaintainerField
[18:46] <savvas> +    specification.
[18:47] <savvas> cristi: did you find a bug open about this?
[18:47] <cristi> savvas: in the changelog?
[18:47] <savvas> cristi: hold a sec
[18:48] <savvas> cristi: https://bugs.launchpad.net/ubuntu/+source/pystatgrab
[18:48] <cristi> savvas: ?
[18:49] <savvas> since there are no bugs open for it, click "report a bug"
[18:49] <savvas> cristi: it's good to open a bug report about it, so you can close it afterwards :)
[18:49] <cristi> savvas: wait. what bug?
[18:50] <cristi> savvas: how did you reach a conclusion that there is a bug?
[18:50] <savvas> http://paste.ubuntu.com/129462/
[18:50] <savvas> if you would have jaunty, you would see this error
[18:51] <savvas> you could report the bug with a subject as "fails to install in jaunty"
[18:51] <cristi> savvas: you took this out of one of my pastes ?
[18:51] <cristi> savvas: aha
[18:51] <savvas> or the error: "Depends: python (< 2.6) but 2.6.1-0ubuntu3 is to be installed
[18:52] <cristi> savvas: shouldn't i upload the package first?
[18:52] <savvas> cristi: upload it where? :)
[18:52] <cristi> submit for sponsoring ?
[18:52] <cristi> i don't really know what to do next
[18:53] <savvas> cristi: ok step by step
[18:53] <cristi> savvas: ok, so what's next ?:D
[18:53] <savvas> file the bug first, with the subject "fails to install in jaunty" and the error message in the description
[18:54] <savvas> then you check if your package is main or universe, it matters because you then know who to subscribe
[18:54] <savvas> check here: http://packages.ubuntu.com/python-statgrab
[18:54] <savvas> it says "[universe]"
[18:54] <cristi> savvas: should i give an advanced report?
[18:55] <cristi> savvas: if so, what tags should i put?
[18:56] <savvas> cristi: nothing :) but if you want to, I think these are correct: bitesize packaging
[18:56] <savvas> https://wiki.ubuntu.com/Bugs/Tags
[18:57] <cristi> savvas: ok i submited
[18:57] <savvas> ok so we know it's in universe, as I explained above
[18:58] <cristi> savvas: https://bugs.launchpad.net/ubuntu/+source/pystatgrab/+bug/340681
[18:58] <savvas> you have to subscribe the sponsors for universe
[18:58] <savvas> click "subscribe someone else"
[18:58] <cristi> savvas: who?
[18:59] <savvas> actually wait
[18:59] <savvas> cristi: a couple of things to change in your debian/changelog
[19:00] <savvas> 1) Remove this: "* Modify Maintainer value to match the DebianMaintainerField specification."
[19:00] <cristi> savvas: ok, done?
[19:00] <savvas> in ubuntu it's not required to mention that you changed it to Ubuntu MOTU Developers :)
[19:00] <cristi> savvas: do i now rebuild and debdiff?
[19:00] <savvas> and 2) include this: * LP: #340681
[19:01] <cristi> what is that
[19:01] <savvas> that's a code the launchpad janitor detects when someone uploads the source - it uses it to close the bugs :)
[19:01] <cristi> savvas: so i rebuild and debdiff?
[19:01] <savvas> you can use (LP: #nnnn) or in any way you like, as long as it says "LP: #1234"
[19:01] <savvas> yes
[19:02] <savvas> then attach that patch to the bug page
[19:02] <savvas> "Add a comment/attachment
[19:02] <savvas> by clicking ^
[19:02] <ScottK> (LP: #nnnn) is the preferred formulation.
[19:02] <cristi> savvas: ah, how do i recreate the .diff?
[19:03] <savvas> debdiff > ../mypatch.debdiff
[19:03] <savvas> cristi: also note what ScottK mentioned :)
[19:03] <cristi> savvas: ok
[19:04] <savvas> (just don't forger that ":" as I have :P)
[19:04] <savvas> *forget
[19:04] <cristi> savvas: now, starting from scratch, after editing the changelog what was i supposed to do again?
[19:04] <cristi> savvas: i put   * LP: #340681
[19:04] <cristi> savvas: so it's with the ":"
[19:05] <savvas> well you can change it again if you want to :)
[19:05] <savvas> * Python 2.6 transition: added --install-layout=deb to debian/rules (LP: #340681)
[19:05] <cristi> savvas: debuild -S -us -uc ?
[19:05] <savvas> (without "* LP: #340681")
[19:06] <cristi> i'm confused now
[19:06] <cristi> savvas:   * Python 2.6 transition: added --install-layout=deb to debian/rules
[19:06] <cristi>   * LP: #340681
[19:06] <savvas> ok open the editor and open debian/changelog
[19:06] <cristi> savvas: is this ok?
[19:06] <savvas> Remove * LP: #340681
[19:06] <savvas> And use: * Python 2.6 transition: added --install-layout=deb to debian/rules (LP: #340681)
[19:06] <cristi> savvas: and that's it?
[19:06] <savvas> then save and do as you said: debuild -S -us -uc
[19:07] <savvas> I hope so :)
[19:08] <savvas> cristi: by the way, note the errors that debuild mentions, especially the ones from lintian checking
[19:09] <savvas> if the package comes from debian, just note them, don't do anything to follow or fix them
[19:10] <savvas> the less changes ubuntu has from debian, the easier is to follow debian again during debian sync stage (synchronisation of packages) :)
[19:10] <cristi> savvas: ok
[19:10] <cristi> savvas: i finished debdiff
[19:10] <cristi> savvas: now what ?
[19:10] <savvas> 20:02:20 < savvas> "Add a comment/attachment
[19:11] <savvas> and attach that file
[19:11] <savvas> *that debdiff
[19:11] <cristi> savvas: so i should attach the debdiff to the bug report?
[19:12] <savvas> exactly
[19:12] <savvas> and check that "this attachment is a patch" check mark
[19:12] <ScottK> Ping me when it's there and I'll review it.
[19:13] <savvas> will do :)
[19:13] <cristi> savvas: uhm you told me the is a patch thingy too late.. i already uploaded the .debdiff
[19:14] <savvas> cristi: no problemo
[19:14] <cristi> savvas: i can edit that?
[19:14] <savvas> cristi: see the patch on the right menu?
[19:14] <savvas> there's an "edit" below it
[19:14] <cristi> savvas: :D
[19:14] <savvas> you can thank the launchpad developers for that ;)
[19:15] <cristi> savvas: mkay
[19:15] <cristi> savvas: and now, what goes next?
[19:15] <savvas> cristi: ok so now you have your bug, your LP: #nnn in the changelog, and the patch uploaded. you're ready to subscribe the universe sponsors
[19:16] <savvas> subscribe some else and add: ubuntu-universe-sponsors
[19:16] <cristi> savvas: i am not understanding what you want me to do
[19:17] <savvas> click "Subscribe someone else"
[19:17] <savvas> Person: ubuntu-universe-sponsors
[19:17] <savvas> click Add
[19:18] <cristi> savvas: and that's it?
[19:19] <savvas> cristi: and that's it :)
[19:19] <cristi> savvas: savvas and the package?
[19:19] <savvas> cristi: if you find another bug with this problem, you of course subscribe yourself to the bug report
[19:20] <savvas> cristi: you attach debdiffs for patches, OR diff.gz for new upstream releases
[19:20] <cristi> savvas: no, uhm, i mean the package, don't i upload any packages or whatever?
[19:20] <savvas> I don't know, I don't generally do that :)
[19:21] <savvas> sponsors usually check the packages on their own
[19:21] <cristi> savvas: so i only look for errors and report them? or what?
[19:22] <savvas> cristi: I would look for bitesize stuff
[19:22] <savvas> usually they already contain easy stuff that needs to be done
[19:22] <savvas> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[19:22] <cristi> savvas: i don't understand what exactly is going on
[19:22] <cristi> so far
[19:23] <cristi> i got that package, edited what should have been edited, debuild, debdiff
[19:23] <cristi> and uploaded the debdiff because there was an error?
[19:24] <savvas> it's a python transition
[19:24] <savvas> let me explain
[19:24] <ScottK> cristi: I'm reviewing your debdiff and if it's good, I'll upload a package with those changes.
[19:24] <savvas> ubuntu developers decided to use python 2.6 as the standard python version for ubuntu jaunty
[19:25] <ScottK> cristi: There is an extra changelog.dch.save file in your diff.  I'll remove it, but watch out for that in the future.
[19:25] <cristi> ScottK: oooh so a motu looks at the debdiff and makes the changes, and uploads the package?
[19:25] <savvas> cristi: exactly :)
[19:25] <ScottK> Yes.
[19:25] <savvas> sponsors = motu
[19:25] <savvas> for universe :P
[19:25] <cristi> savvas: i see, that really makes sence
[19:26] <savvas> so everything's ok now? :)
[19:26] <cristi> savvas: however, where do i upload the debdiff if i don't get any bugs when building?
[19:27] <savvas> cristi: there are always bugs! you mean you don't see them because you don't use jaunty :)
[19:27] <cristi> savvas: so there is no chance not to be a bug
[19:27] <savvas> then, as I said use a detailed subject such as "cannot install in jaunty (python transition required)"
[19:28] <savvas> cristi: if there's no bug, why would you change it?
[19:28] <ScottK> cristi: One other point is line lengths no longer than 79 characters in debian/changelog.  I also fixed that.
[19:28] <cristi> nice
[19:29] <savvas> cristi: note that sponsors don't usually fix the patches :P
[19:29] <cristi> ScottK: ok, thank you
[19:30] <cristi> savvas: so, i should have respected the line lenght and removed the changelog.dch.save
[19:30] <savvas> cristi: yep!
[19:30] <cristi> alright!
[19:31] <savvas> hm..
[19:31] <cristi> so, i'm done!
[19:31] <savvas> ScottK: which line was it?
[19:31] <savvas> cristi: yes :)
[19:32] <savvas> welcome to the packaging side of the world!! :D
[19:32] <ScottK> savvas: The only line in debian/changelog that was added.
[19:32] <savvas> oh, "* Python 2.6 transition: added --install-layout=deb to debian/rules (LP: #340681)
[19:32] <cristi> savvas:  :D thank you
[19:32] <savvas> good to know :P
[19:33] <savvas> cristi: another note, you start a new line under the first character of the previous one
[19:33] <cristi> ScottK: how am i supposed to spot that fast?
[19:33] <savvas> * Python da da da
[19:33] <ScottK> cristi: Uploaded.  Thank you for your contribution to Ubuntu.
[19:33] <savvas>   new line
[19:33] <cristi> ScottK Thank you! :D yay!
[19:34] <savvas> cristi: perhaps the line lentgth was mentioned in the lintian errors :)
[19:34] <ScottK> cristi: I use either vim which tells me what column I'm in or Kate which I have set to have a vertical line at 80 characters.
[19:34] <savvas> *length
[19:34] <cristi> savvas: thank you a lot for the help and lost time :D
[19:34] <ScottK> savvas: It's not.
[19:34] <ScottK> savvas: Thank you for helping out.
[19:34] <savvas> ScottK: ah ok :P anytime! :)
[19:34] <savvas> cristi: anytime as well :)
[19:34] <ScottK> cristi: Generally it takes some longer time to get sponsored, but I took you out of turn since it was your first one.
[19:35] <cristi> ScottK: i see, thank you again then :)
[19:35] <cristi> ﻿last question for today, how do i spot more of these python transition packages?
[19:36] <ScottK> cristi: https://launchpad.net/ubuntu/jaunty/+source/pystatgrab/0.4-1.1ubuntu1
[19:37] <cristi> ScottK thanks
[19:37] <savvas> cristi: you have to use the development release for that :)
[19:37] <savvas> grep-aptavail -F Depends "python (<< 2.6)" -sPackage
[19:38] <cristi> savvas: development release for what?
[19:38] <savvas> 20:36:00 < cristi> ﻿last question for today, how do i spot more of these python transition packages?
[19:38] <savvas> you can use: grep-aptavail -F Depends "python (<< 2.6)" -sPackage
[19:38] <savvas> development release = jaunty for now :)
[19:39] <cristi> savvas: ok, so the packages listed are the ones that need editing for the transition
[19:49] <savvas> cristi: you always check the launchpad for bugs and the source logs
[19:49] <savvas> example, for binary package python-statgrab, the source package is: pystatgrab
[19:49] <cristi> savvas: yes.. i thought of that, you probably get all the packages with that grep command
[19:49] <savvas> you go to: https://launchpad.net/ubuntu/+source/sourcepackagename
[19:50] <savvas> that means: https://launchpad.net/ubuntu/+source/pystatgrab
[19:50] <savvas> you see if there's anything about python transition mentioned
[19:50] <savvas> cristi: here's a list from jaunty: http://paste.ubuntu.com/129491/
[19:51] <maxb> You could also use -sSource instead of -sPackage for the grep-aptavail
[19:51] <cristi> savvas: https://launchpad.net/ubuntu/+source/python-renpy returned nothing
[19:52] <savvas> http://paste.ubuntu.com/129493/
[19:52] <maxb> best then to feed it through sort -u, since some sources will build multiple python binary packages
[19:52] <savvas> ok, as maxb said :P
[19:52] <cristi> savvas: so that means that i can edit the package?
[19:52] <cristi> aha..
[19:52] <maxb> cristi: The binary package python-renpy is built by the source package renpy
[19:52] <savvas> cristi: binary package names != source package names (not always :) )
[19:53] <maxb> Also, 1 source package builds 1 *or more* binary packages
[19:53] <savvas> cristi: here's the list with maxb 's suggestion: http://paste.ubuntu.com/129494/
[19:54] <cristi> maxb: ah ok, thanks, so -sSource
[19:55] <savvas> grep-aptavail -F Depends "python (<< 2.6)" -sSource | sort -u
[19:55] <cristi> and if i get a page not found, i can edit the package, else it has already been done?
[19:55] <maxb> uhm, no, not at all
[19:55] <maxb> If you get a page not found, you've constructed a broken URL
[19:55] <maxb> So there's no package by that name for you to edit
[19:56] <cristi> maxb: so how do i know which package to edit ?
[19:56] <maxb> uh, because you just picked one from the list?
[19:57] <savvas> here's a final list with links: http://paste.ubuntu.com/129497/ :P
[19:57]  * savvas loves the Linkification add-on for firefox :)
[19:58] <cristi> xD
[19:59] <savvas> maxb: do you know a devscript that changes the control Maintainer field to ubuntu motu "automagically"? :)
[19:59] <maxb> update-maintainer?
[20:00] <savvas> let me check
[20:01] <savvas> cool! thanks :)
[20:01] <hyperair> hmm i never knew there was such a thing
[20:01] <hyperair> quite useful
[20:01] <fabrice_sp_> Hi. If I'm getting this error: objcopy:debian/iiimf-server/usr/lib/stA2gQhj: cannot create debug link section `debian/iiimf-server/usr/lib/debug//usr/lib/libiiimutils.so.0.0.0': Invalid operation. Where should I open a bug report?
[20:02] <savvas> maxb: it checks if it main or motu appropriately?
[20:02]  * maxb gently nudges savvas at the manpage
[20:02] <savvas> :P ok got the message haha
[20:02] <hyperair> lol
[20:04] <savvas> it does, nice :)
[20:13] <eMerzh> I'm looking for a MOTU review on my package (http://revu.ubuntuwire.com/details.py?package=sqliteman ) thansk :)
[20:41] <LiraNuna> Hello, I want to be able to cross compile 32bit on 64bit environment. I got gcc/g++ -m32 working, but I still can't cross compile when it comes to extra libraries
[20:42] <LiraNuna> for example, libpng, I have it as 64bit library but not as 32bit
[20:43] <LiraNuna> any idea what package I need to install to achieve cross compile environment?
[20:44] <Amaranth> LiraNuna: so you just need a 32-bit libpng to link to?
[20:44] <LiraNuna> not 'just' libpng, I'm using libpng as an eample
[20:44] <LiraNuna> example*
[20:44] <Amaranth> ia32-libs
[20:45] <LiraNuna> I got this installed.
[20:45] <LiraNuna> $ apt-cache policy ia32-libs ia32-libs:  Installed: 2.2ubuntu18
[20:45] <Amaranth> LiraNuna: well that has /usr/lib32/libpng.so
[20:46] <LiraNuna> hmm, that's correct - but GCC cannot find it
[20:47]  * Amaranth checks wine to see what it does
[20:47] <LiraNuna> ... wine ?
[20:47] <Nafallo> red please
[20:47] <Amaranth> wine on ubuntu amd64 is a 32-bit app
[20:47] <Nafallo> oh. oops.
[20:47] <LiraNuna> Amaranth, ah, I see
[20:47] <Amaranth> LiraNuna: so it is one example of building a 32-bit app on a 64-bit system
[20:48] <LiraNuna> I use gcc/g++ -m32
[20:48] <LiraNuna> and I use g++-multilib package
[20:48] <Amaranth> looks like you need --libdir
[20:48] <Amaranth> assuming the app is using autotools
[20:49] <LiraNuna> no, custom makefiles
[20:49] <LiraNuna> http://rafb.net/p/cjmTEG43.html
[20:50] <Amaranth> the problem is you can't use -lpng12
[20:50] <Amaranth> you have to give it the library path explicitly
[20:50] <LiraNuna> bleh, -L/usr/lib32/ ?
[20:51] <Amaranth> that might work, i dunno
[20:51] <LiraNuna> isn't that hardcoding ...
[20:52] <LiraNuna> oh, I am using pkg-config
[20:52] <LiraNuna> `pkg-config --cflags --libs $(PACKAGES)`
[20:52] <Amaranth> yeah, can't do that
[20:52] <LiraNuna> anyway to tell it 'use 32bit version' ?
[20:52] <Amaranth> you'll have to hard code
[20:53] <Amaranth> there is no pkg-config file for the 32-bit versions
[20:53] <LiraNuna> I lose portability this way...
[20:53] <LiraNuna> damn :(
[20:53] <LiraNuna> thanks for your help and your time
[20:54] <Amaranth> LiraNuna: if you were using autotools it would be possible to do it dynamically like wine
[20:54] <LiraNuna> autotools is heavy and bulky, I'd rather not use it
[20:54] <Amaranth> although to be honest building wine on 64-bit seems to be a big magic, I've never managed to build it locally
[20:55] <Amaranth> s/big/bit/
[20:56] <cristi> can anyone provide a link with what to do for the python 2.6 transition?
[20:57] <ScottK> cristi: I can tell you how I've been finding packages than need work ....
[20:58] <ScottK> You can do pbuilder login to login to your Jaunty chroot.
[20:58] <ScottK> That will give you a shell in a Jaunty environment.
[20:58] <ScottK> Then do apt-cache rdepends python2.5
[20:58] <ScottK> That will give you a list of packages that still have a direct depends on 2.5 (some are OK and some are not)
[20:58] <cristi> ScottK i see
[20:59] <ScottK> Then try and install them in your chroot.  The ones that refuse to install with the depends on python << 2.6 error need work.
[20:59] <cristi> ScottK i was referring to what to do once you get the package, what to do to the package
[20:59] <ScottK> I'm sure there are far more efficient ways to do it, but that works for me.
[21:00] <ScottK> First look in the debian directory for any hard coded references to site-packages.
[21:00] <ScottK> If you find those, that guarantees the package needs modfication.
[21:00] <ScottK> If not, try a test build and see if it rebuilds without change.
[21:00] <ScottK> If it doesn't then you know you have stuff to fix.
[21:01] <ScottK> If it does, examine the results of the build and see if it installs files in /usr/local or any odd places.
[21:01] <ScottK> There are many ways to do this.  I use debc.
[21:02] <ScottK> From your pystatgrab build you should be able to do debc pystatgrab_0.4-1.1ubuntu1_i386.changes|less in the dir with the results from your build.
[21:03] <ScottK> If that looks sane it may just need a rebuild.
[21:03] <cristi> ScottK ok, thanks
[21:04] <ScottK> That's the general process I follow.
[21:10] <cristi> ScottK thanks again for the help today
[21:11] <cristi> good night all
[22:10] <savvas> bug 340783 for python transition :)
[22:10] <savvas> and this time the LP: #nnn is correct :P
[22:11] <lfaraone> Hi, it seems like I might have broken the public portion of my GPG key. This must have happened a while ago, because none of the keyservers I've checked have a valid copy. Is there any way to find the public portion of my key, possibly from an archive or something?
[22:12] <savvas> lfaraone: name?
[22:13] <savvas> I'll try and check :)
[22:19] <drewmeigs> hi, everyone.
[22:20] <savvas> lfaraone: Luke Faraone (Prior keys lost) <luke.faraone at gmail dot com> ?
[22:21] <savvas> there seems to be an old one revoked: 1024 bit DSA key 32799A20, created: 2007-04-22 (revoked)
[22:22] <drewmeigs> i know this question is probably asked many times each day, but i was wondering if anyone had some advice on joining you guys aside from what is in the wiki? i would really like to join your group.
[22:23] <ScottK> drewmeigs: My advice is just dive in, get to work, and ask questions as you have them.
[22:24] <lfaraone> savvas: oops, yes, it's 0AC-something
[22:24] <lfaraone> savvas: sorry, I was away
[22:24] <lfaraone> savvas: http://pgp.cs.uu.nl/stats/0AC70206.html
[22:24] <drewmeigs> thank you ScottK. is it difficult to get a mentor or guide?
[22:24] <lfaraone> drewmeigs: well, what do you know already?
[22:24] <savvas> lfaraone: try: gpg --keyserver keyserver.ubuntu.com --search-keys "faraone"
[22:25] <lfaraone> drewmeigs: (about programming/packaging etc)
[22:25] <ScottK> drewmeigs: There is a formal mentorship program that has a wait, but if you're a bit of a self starter you don't need one.
[22:25] <ScottK> There is almost always someone here willing to help.
[22:25] <lfaraone> ScottK:   1024 bit DSA key 0AC70206, created: 2008-01-24
[22:25] <lfaraone> savvas: * 	  1024 bit DSA key 0AC70206, created: 2008-01-24
[22:26] <drewmeigs> i have read through the wiki and have some theoretical knowledge. im not saying i am ready to be a member today or anything. i mean, i dont need someone to hold my hand, but i would like someone who could really be a mentor to me. that would be nice. sort of a designated resource and guide.
[22:26] <ScottK> lfaraone: Why are you pointing me at that?
[22:26] <savvas> lfaraone: gpg --keyserver keyserver.ubuntu.com --recv-keys 32799A20
[22:27] <savvas> lfaraone: it worked for me :) I think I got the revoked key
[22:27] <lfaraone> savvas: yeah, that's my old key.
[22:27] <savvas> ScottK: error :)
[22:27] <ScottK> Fair enough.
[22:27] <lfaraone> savvas: which I revoked because I had the other one, which is now broken.
[22:28] <lfaraone> drewmeigs: feel free to ask us any questions you have.
[22:28] <ScottK> drewmeigs: If you look on the wiki there is stuff about the mentorship program.
[22:28] <lfaraone> drewmeigs: do you know how to get started with MOTU?
[22:28] <joaopinto> drewmeigs, https://wiki.ubuntu.com/MOTU/Mentoring
[22:28] <savvas> lfaraone: so wait, you want to use your revoked key?
[22:29] <lfaraone> savvas: No, I mean 0AC70206's public key is broken on the keyserver; try to use it.
[22:29]  * lfaraone will be right back, dinner.
[22:30] <drewmeigs> i have read the wiki and all. would someone mind telling me a good way to get started? im not sure i was entirely clear on that.
[22:35] <savvas> lfaraone: revoked key: http://paste.ubuntu.com/129555/ and key 0AC70206: http://paste.ubuntu.com/129554/
[22:41] <drewmeigs> well thanks for your help, guys. i appreciate it. i'll go back and read the documentation some more.
[22:43] <lfaraone> savvas: yes, when I import 0AC70206 (my non-revoked pubkey) onto a clean system and run "gpg --encrypt 0AC7026", I get gpg: 0AC70206: skipped: unusable public key
[22:44] <ScottK> drewmeigs: We're in the middle of trying to update packages for Python 2.6.  If you look at the logs for earlier today where savvas and I were talking with crissi you can get a good tutorial on getting started with something useful.  See irclogs.ubuntu.com.
[22:47] <savvas> ScottK: you were some seconds late :)
[22:48] <ScottK> Oh.
[22:48] <ScottK> Oh well.
[22:48] <savvas> and I didn't notice him unfortunately
[22:49] <savvas> I've sent him a query message
[22:50] <ScottK> OK.  Good.
[22:54] <savvas> lfaraone: no idea, sorry - the only thing I could recommend it to try and change the expiry date on the new key - maybe that would make it work :)
[22:55] <savvas> *recommend is
[22:55] <lfaraone> ScottK: ... oh?
[22:55] <savvas> fix that tab key :)
[22:55] <lfaraone> savvas: is that seriously the problem?
[22:55] <lfaraone> savvas: that too. :P
[22:55] <lfaraone> ScottK: (sorry)
[22:55] <savvas> I've no idea, just a hunch :P
[22:56] <lfaraone> savvas: expires 2010-01-01 according to seahorse
[22:57] <lfaraone> savvas: although there's an el-gamal subkey that expired 3 months ago...
[22:59] <savvas> lfaraone: I meant bump the expiration, until 2010-06-01 or 2011-01-01, this could possibly allow you to reissue the key
[23:02] <lfaraone> savvas: ah.
[23:05] <savvas> lfaraone: any luck? :)
[23:11] <lfaraone> savvas: none yet.
[23:12] <lfaraone> savvas: hm, it seems to work fine.
[23:12] <lfaraone> savvas: can you try importing it from subkeys.pgp.net and encrypting something?
[23:14] <savvas> lfaraone: I don't know how to use other people's keys other than mine :\
[23:14] <lfaraone> savvas: gpg --recv-keys 0AC70206; echo blah | gpg -a -e -s -r 0AC70206
[23:15] <maxb> lfaraone: So, you can sign, but you can't encrypt?
[23:16] <savvas> lfaraone: that one seems to work :)
[23:17] <savvas> http://paste.ubuntu.com/129564/plain/
[23:18] <savvas> mine is key 94185BB9 :P
[23:18] <lfaraone> maxb: people couldn't encrypt to me because my el-gamal key was expired and GPG didn't tell me :)
[23:19]  * pochu lols at bug 337396
[23:19] <lfaraone> In other news, I'm currently using an ElGamal encryption key and a DSA signing key. Isn't DSA insecure?
[23:20] <pochu> http://www.youtube.com/watch?v=CX3F_uVDANA
[23:22] <maxb> I think that's still the combination that gnupg suggests for generating new keys, so why do you think so?
[23:23] <savvas> lfaraone: isn't the bits number that matters? :)
[23:23] <lfaraone> maxb: I thought I saw someone say somethign to that effect. Wasn't backed up by anything, however.
[23:23] <lfaraone> savvas: quite.
[23:24] <maxb> It's conceivable that DSA is weak for encryption but not for signing... but I'm not a crypto expert :-)
[23:24] <lfaraone> maxb: ah.
[23:24] <maxb> Generally I trust the GnuPG guys to be recommending something sane
[23:25] <lfaraone> maxb: obviously it's just easier to do rubber-hose cryptanalysis or guess my passphrase :)
[23:26] <maxb> meh, I'd like to see people guess my passphrase
[23:26] <maxb> It's >30 characters
[23:26] <lfaraone> maxb: lord.
[23:26] <lfaraone> maxb: I prolly should regen my keys anyway, my passphrase is much less than that.
[23:26] <lfaraone> maxb: (between 8 and 12)
[23:27] <maxb> 'tis amazing how quickly you can type a decently long passphrase once your fingers are used to it, if you choose one which flows over the keyboard
[23:27] <lfaraone> maxb: is it a sentance?
[23:28] <maxb> no, it's an obscure bit of trivia drawn from an obscure sci-fi book
[23:29] <lfaraone> maxb: which book? :P
[23:29] <maxb> sufficiently obscure that I feel comfortable announcing that to the world :-)
[23:29] <maxb> Hah!
[23:29] <lfaraone> maxb: ah, so not something like "Foundation"
[23:29] <lfaraone> maxb: keep in mind this is archived for all eternity :)
[23:30] <maxb> The important things being that (a) it's pronouncable, and (b) it's no words you'll ever find in a dictionary
[23:31] <savvas> so now it works? :P
[23:32] <lfaraone> maxb: savvas yeah.
[23:32] <lfaraone> maxb: plugh!
[23:33] <lfaraone> maxb: so something like eezeefooyotuviaseewalahmuCietu or kauxiHevahdahvohSietahcenaiDor?
[23:34] <maxb> I think I recognize pwgen at work here :-)
[23:36] <lfaraone> maxb: hehe.
[23:36] <lfaraone> maxb: I'd assume that pwgen passwords are *not* secure?
[23:36] <maxb> Well, they're a whole lot more secure than anything that can be dictionary-attacked
[23:37] <savvas> great :)
[23:39] <maxb> Obviously they're not quite as secure as 8 fully random chars, but you've got to draw the line somewhere
[23:39] <savvas> is it safer than "I'm a real bada**, I just love me!" :p
[23:40] <maxb> "It depends"
[23:40] <maxb> :-)