[00:00] <phil_ps> okay
[00:00] <phil_ps> I want to test gui stuff
[00:00] <phil_ps> I am using a VM (host is windows guest is intrepid)
[00:00] <phil_ps> so should I upgrade my guest to jaunty?
[00:01] <RainCT> phil_ps: Ah. Yes, or just make a clean Jaunty installation in a new VM
[00:02] <blueyed> I'm getting a build failure with the virtualbox-ose merge, but I don't know what may be wrong. build log: http://launchpadlibrarian.net/23237526/build.log (bug 328161).
[00:05] <RainCT> blueyed: int RTASSERTVAR [0]
[00:05] <RainCT> blueyed: ISO C++ forbids zero-size array 'RTASSERTVAR'
[00:05] <RainCT> well.. the error says it all :P
[00:06] <phil_ps> RainCT: Is making a new VM inside my guest os REALLY slow?
[00:07] <phil_ps> I want to work in linux and I use alot of computers (on campus)
[00:07] <RainCT> phil_ps: why don't you just create a second one inside the host os?
[00:07] <RainCT> and.. I don't know, never tried that
[00:07] <phil_ps> so I have to reinstall virtualbox each time and there is no way to import guests
[00:07] <phil_ps> you have to recreate them each time
[00:08] <phil_ps> so I have to make a new one, close virtual box, fiddle with the xml configs and then reopen each time
[00:08] <phil_ps> maybe I should add import/export support to virtualbox then
[00:08] <RainCT> blueyed: seems like that's an error which was previously only showed with pedantic but was then moved to fail by default (can be disabled with a 'permissive' flag)
[00:09] <RainCT> phil_ps: I guess you can just copy the hard disk file
[00:09] <blueyed> RainCT: well.. I'm not used to C++ though, I've read it of course.. where would I add the flag?
[00:09] <blueyed> RainCT: that's the code: http://pastebin.com/m46b98c67
[00:09] <phil_ps> RainCT: I do that, but whenever I make a checkpoint I loose things
[00:10] <phil_ps> RainCT: because they don't update the hard disk file
[00:10] <RainCT> pochu: seems like it's still installing into local/
[00:10] <RainCT> find debian/python-wxgtk2.6/usr/lib/python2.6 -name '*.py?' -exec rm '{}' ';'            find: `debian/python-wxgtk2.6/usr/lib/python2.6': No such file or directory             make: *** [install-gtk-pylib2.6] Error 1
[00:11] <blueyed> RainCT: your setup.py line?
[00:11] <RainCT> blueyed: the flag is called "fpermissive", I guess you have to add it to some variable in debian/rules
[00:12] <RainCT> blueyed: http://paste.ubuntu.com/124495/ line 432
[00:12] <RainCT> python$* ./setup.py build --install-layout=deb \
[00:13] <RainCT> errr
[00:13] <RainCT> that should be in the  "setup.py install" line, right? :$
[00:13] <blueyed> yes :)
[00:15] <phil_ps> RainCT: okay, I am done complaining. where can I get a .iso for jaunty...
[00:15] <RainCT> phil_ps: http://cdimage.ubuntu.com/releases/jaunty/alpha-5/
[00:15] <AdamDH> phil_ps: http://cdimage.ubuntu.com/releases/jaunty/alpha-5/
[00:15] <AdamDH> doh RainCT got there first
[00:16] <RainCT> :)
[00:16] <AdamDH> just put Jaunty on my MacBook Pro
[00:17] <AdamDH> RainCT in that cross compilers libc Makefile there was a dirty sed hack that changed where libc was been installed to, took me a while to find it! that was causing some of my issues
[00:17] <AdamDH> so prefix or destdir would not have worked passed from rules
[00:48] <RainCT> and it's still failing to build.. argh
[01:05] <directhex> hm.
[01:05] <directhex> ogra/NCommander?
[01:38] <phil_ps> installed jaunty on a virtualbox VM
[01:38] <phil_ps> mounting share folder is not working
[01:39] <phil_ps> sudo mount -t vboxsf share /mnt/share
[01:39] <phil_ps> /sbin/mount.vboxsf: mounting failed with the error: Protocol error
[01:39] <phil_ps> is this a #ubuntu+1 discussion?
[01:46] <directhex> :|
[01:47] <Laney> :O
[01:48] <directhex> Laney, ready for a screamer?
[01:48] <directhex> Laney, been fighting for a few nights to get an arm install of ubuntu going in qemu, but keep running out of RAM
[01:48] <directhex> Laney, as if qemu's "-m" flag is being ignored
[01:49] <directhex> config-2.6.28-versatile -> CONFIG_CMDLINE="root=1f03 mem=32M"
[01:50]  * theholyduck lol'z
[01:50] <theholyduck> phil_ps, try pulling a restart :P
[01:50] <theholyduck> i seem to remember ubuntu pulling some shit like that in virtualbox the one time i tried it
[01:51] <theholyduck> mount it as a machine share not transisten share aswell
[01:51] <Laney> directhex: There an "Ubuntu virtualisation team" ;)
[01:52] <Laney> there's
[01:52] <directhex> Laney, and they need stabbing inna face! :o :o :o
[01:52] <directhex> or maybe it's just ogra
[01:53] <directhex> generating locales, fr'example, appears to not take 12 mins per locale, as long as one has more than 5 meg of free ram
[02:26] <directhex> blarg, jaunty's not very installable just at the moment on ARM
[02:27] <directhex> certainly the MID or Netbook tasks aren't working
[02:27] <directhex> python rubbish
[02:27] <StevenK> doko did warn people
[02:29] <directhex> xubuntu-desktop seems functional though
[02:32] <directhex> nope, it lied
[03:38] <jdong_> nothin like a quest for paranoia leading to checkin how SELinux in Lenny.
[03:39] <ryanakca> Could someone point me to a watch file for an app hosted on google code? I can't seem to get rid of the ``.tgz'' from the version number.
[03:40] <vorian> ryanakca: chm2pdf
[03:40] <ryanakca> vorian: thanks
[03:40] <vorian> no problemo
[03:43]  * jdong_ questions if mutt is REALLY needed in the base system task...
[04:28]  * Hobbsee waves, as she sponsors a patch
[04:40] <iulian> Morning
[05:55] <sejdong> whoo selinux works
[05:55]  * sejdong considers switching his server to Debian
[06:09] <jldugger> ive got a question about  bug #335832
[06:10] <jldugger> how does it come to pass that a package can be built for an depricated platform?
[06:11] <jldugger> i guess i missed an email threda
[06:11] <jldugger> thread
[06:14] <ScottK> When it was last compiled when it wasn't deprecated.
[06:16] <jldugger> so do I just need have it uploaded with a version bump and have doko look at it if it fails?
[06:17] <ScottK> No.  It's in Universe so it's mostly up to the community to fix.
[06:17] <ScottK> I'm test building it now.
[06:17] <rgreening> good evening ScottK
[06:17] <ScottK> Some packages need changes too.
[06:17] <ScottK> Heya rgreening.
[06:17] <ScottK> rgreening: Up for some Python transition fun?
[06:17] <rgreening> so I finally finished the motu app
[06:17] <rgreening> what sort of fun :)
[06:18] <rgreening> 2.6?
[06:18] <ScottK> yes
[06:18] <rgreening> and deprecated stuff
[06:18] <ScottK> I saw, but I haven't had a chance to scribble on it yet.
[06:18] <rgreening> bzr has lots
[06:18] <rgreening> well, Im pumped now. kdebindings built first try. I was amazed I didnt have to dance and use voodoo
[06:19] <rgreening> so sure, I can help with some python stuff
[06:19] <rgreening> fire away
[06:19] <ScottK> rgreening: pypoker-eval has some 'fun' mix of source changes needed for the Python 2.6 transition and some kind of autofoo/libtool confusion that's more than I'm up for at the moment.
[06:19] <rgreening> you used the 'auto' word.. oh no's
[06:20] <ScottK> Enjoy.
[06:20] <rgreening> I'll get source and have a peek
[06:27] <ScottK> jldugger: Uploaded.  I'll warn you that it's bugged though.  It only supports the highest Python version, so it'll now work in 2.6, but not 2.5.
[06:27] <ScottK> That's a pre-existing problem as the previous package only supported 2.5 and not 2.4.
[06:28] <ScottK> Debian control claims it'll support all Python versions, so the build system's bugged.
[06:31] <jldugger> ScottK, the package build system or Canonicals?
[06:32] <ScottK> The package.
[06:32] <ScottK> It's late and I'm tired, so I just got it to installable again.
[06:32] <jldugger> that's fine by me
[06:32] <jldugger> im just curious how this all works
[06:33] <ScottK> Well it currently only provides cwiid.so built for one Python version.  It should provide it for all.
[06:33]  * ScottK heads off for bed.
[06:33] <jldugger> it seems that intrepid binaries depend on 2.5
[06:34] <jldugger> so you'd need versioned package names (and builds)
[06:35] <jldugger> well thanks for looking at it.
[08:03] <savvas> is there a list of packages for the python transition?
[08:26] <wgrant> savvas: I see 300 binaries with 'python (<< 2.6)' in their Depends, which is an incomplete list. grep-dctrl is useful here.
[08:26] <wgrant> I don't know of a real list, I'm afraid.
[08:26] <wgrant> It would certainly be useful.
[08:27] <savvas> thanks wgrant, I'll try and filter them using the pythoneers ppa
[08:43] <Q-FUNK> howdy!  could anyone help with bug #335741 ?
[08:46] <a|wen> Q-FUNK: try to change the build-depends and see if it works with python 2.6 ... if not, we need to patch it to work or in some cases see if a new upstream version supporting 2.6 is there
[08:46] <Q-FUNK> it doesn't
[08:47] <Q-FUNK> ./configure (or however this package checks for python) needs tlo be updated to not be specific about versions to check
[08:47] <Q-FUNK> right now, it seems to explicitely assume that 2.5 is the one to look for if it cannot find 2.4
[08:48] <Q-FUNK> ah, uscan indeed reports a newer minor version
[08:49] <a|wen> try to check what the upstream changelog says of that one
[08:50] <Q-FUNK> doesn't mention anything about python versions
[08:51] <Q-FUNK> trying a build anyway, just in case upstream is sloppy about changelogs
[08:54] <a|wen> Q-FUNK: the configure is failing due to Boost::Python not being avaible ... we have been through a boost transition, so might actually be something in that regard that is the problem
[08:54] <rgreening> ScottK: bug 336151 - problem fixed as requested.
[08:55] <Q-FUNK> a|wen: noticing exactly what is pulled by pbuilder, it even looks like libboost-dev is not among the build-depends.  could that be it?
[08:57] <a|wen> Q-FUNK: i'm actually not sure, what the python-bindings part of boost is called
[08:57] <a|wen> but could be that or something similar
[08:58] <Q-FUNK> ok, so we went from libboost 1.35 to 1.37, correct?
[08:59] <a|wen> from 1.34 to 1.35
[08:59] <a|wen> but 1.37 is in the archives as well
[08:59] <Q-FUNK> this package already checks for 1.35
[09:00] <Q-FUNK> and depends on 1.35 too
[09:01] <Q-FUNK> could it be that libbost 1.35 itself hasn't been rebuilt against python 2.6?
[09:01] <a|wen> Q-FUNK: it depends on libboost-python1.35-dev ?
[09:02] <Q-FUNK> the new upstream builds as-is, if we remove the single patch in debian/patches
[09:02] <Q-FUNK> yup, it depends on 1.35
[09:03] <a|wen> Q-FUNK: the rebuild of libboost-python1.35-dev against python 2.6 is less than two days old
[09:03] <Q-FUNK> ah, so it has already been rebuilt?
[09:03] <a|wen> Q-FUNK: jup ... but might not have hit your archive yet
[09:04] <a|wen> Q-FUNK: which version does pbuilder (or what you use) pull in of libboost-python1.35-dev?
[09:05] <a|wen> Q-FUNK: it should be 1.35.0-8ubuntu5 ... if it is 1.35.0-8ubuntu4 it doesn't work
[09:11] <Q-FUNK> 1.35.0-8ubuntu5
[09:13] <Q-FUNK> so that's not becuase we don't have the latest libboost
[09:16] <a|wen> Q-FUNK: okay ... i'm not sure exactly what the configure does; if it only checks for libboost for certain python versions; so yeah, you might want to take a look in it
[09:17] <Q-FUNK> we're already patching the m4 stuff in the current package.  I wouldn't be surprised if we actualy break things
[09:18] <a|wen> he, not impossible
[10:38] <directhex> hm. is there an ETA on python-pysqlite2 and python-launchpad-integration being installable?
[10:41] <savvas> is anyone working on it?
[10:42] <geser> I'm looking at the moment at it (but no promises that I will be successful) and I'd need a main sponsor for it
[10:42] <savvas> hm.. that was a nice patch
[10:43] <directhex> other than that, i more or less have an ARM system installed in qemu
[10:44] <StevenK> If both python-pysqlite2 and python-launchpad-integration are in main, then doko ought to have fixed them ...
[10:45] <geser> StevenK: py-lp-i was already touched my doko, but it still depends on python < 2.6
[10:45] <geser> and p-pysqlite2 is in universe
[10:45] <StevenK> geser: I can fix py-lp-i directly, if you wish
[10:45] <savvas> I also need someone to review the patch for keysafe: https://bugs.launchpad.net/ubuntu/+source/keysafe/+bug/336011
[10:46] <geser> StevenK: sure, so I don't need to for a sponsor
[10:46] <pochu> geser: why aren't you core-dev yet? :)
[10:47] <savvas> usr/lib/python*/site-packages/compizconfig.so
[10:47] <geser> pochu: good question :)
[10:47] <savvas> oops
[10:48] <lesterc> Hi - does anyone knows how does the vesamenu on the netboot tarball works?
[10:49] <StevenK> doko didn't push his changes for py-lp-i into bzr. Bad.
[10:49] <sebner> geser for core-dev \o/
[10:51] <StevenK> geser: The Depends for py-lp-i look fine to me ... >= 2.5, << 2.7
[10:52] <directhex> it  varies per-arch
[10:52] <directhex> python  (<< 2.7) [i386]
[10:52] <directhex> python  (<< 2.6) [amd64]
[10:52] <directhex> and arm is <<2.6
[10:52] <StevenK> Hmmm
[10:52] <directhex> http://packages.ubuntu.com/jaunty/python-launchpad-integration
[10:53] <StevenK> Okay, so I'm betting it was uploaded too early
[10:54] <directhex> before the default python was updated on all arches?
[10:54] <StevenK> But it's arch all ....
[10:54]  * StevenK digs
[10:55] <StevenK> Helpfully, I run on amd64 here
[10:56] <directhex> arch all with per-arch depends? beautiful
[10:56] <directhex> hm, no, looks arch-any to me
[10:57] <directhex> Architecture: any
[10:57] <directhex> hm, gotta go
[10:58] <StevenK> No, python-all-dev
[11:02] <geser> StevenK: looks like it was a bad build order, I've just rebuild it on amd64 in my pbuilder and the depends are fine now
[11:02] <StevenK> geser: I'll confirm and then upload a no-change rebuild.
[11:07] <wattazoum> hello all
[11:08] <geser> Hi wattazoum, just answered on your mail to ubuntu-motu
[11:08] <wattazoum> I saw that :-)
[11:08] <wattazoum> very nice and fast :-)
[11:08] <wattazoum> thank you
[11:09]  * RainCT too heh
[11:10] <wattazoum> Is it possible to make a .deb package Depend on a certain package (and install it) if a third packages is intalled?
[11:10] <geser> savvas: re keysafe: you missed some python2.4 references in {keysafe,ksed}.in
[11:11] <wattazoum> basically, if a UI (like GTK)is installed , depends on python-gtk , but if it's QT , depends on python-qt4
[11:14] <geser> wattazoum: it won't work e.g. on multi-user system where both gnome and kde are installed (and used) or if a gnome user prefers a qt program and has both gtk and qt libs installed
[11:15] <wattazoum> geser, Indeed :-/ ,
[11:16] <savvas> thanks geser, I'll check it out :)
[11:19] <savvas> geser: btw, the debian maintainer was changing files directly - should I do the same? without quilt/dpatch?
[11:21] <geser> savvas: yes, as using quilt would introduces a mix of changes some as patches and some directly applied
[11:22] <geser> savvas: and please forward your changes also to the debian maintainer (if not already done)
[11:22] <savvas> ok :)
[11:23] <savvas> geser: actually, the maintainer has a new version in mentors.debian.net: http://mentors.debian.net/debian/pool/main/k/keysafe/
[11:26] <savvas> oh you mean about the quilt build-dep removal
[11:26] <savvas> alrighty
[11:27] <geser> savvas: if your changes are already in the next debian packages then of course you don't need to forward them anymore
[11:27] <geser> savvas: I think more about the changes to unversion the python interpreter
[11:28]  * savvas checks
[11:29] <savvas> they're removed, yay! :)
[11:30] <geser> savvas: the idea is to get any change which is not ubuntu-specific to get also included in the debian package so we can sync it in future again
[11:31] <savvas> I see
[11:41] <a|wen> hi geser! ... i'm trying to find some recent sponsors for my motu application; you took at least a few from the arts batch, if you feel adding a short comment: https://wiki.kubuntu.org/AndreasWenning/DeveloperApplicationTemplate
[11:42] <geser> wattazoum: fyi: [ubuntu/jaunty] python-sqlite 1.0.1-7ubuntu1 (Accepted)
[11:42] <wattazoum> wonderful !!!
[11:42] <wattazoum> thanks
[11:48] <AnAnt> Hello, I'm preparing a package to install a PPA key
[11:48] <AnAnt> what should I mention in debian/copyright  under Upstream authors ?
[11:50] <Hobbsee> AnAnt: if you've written it...you?
[11:50] <AnAnt> Hobbsee: written what ? it's only the PPA keyring
[11:51] <Hobbsee> if you've written what normally classes as "upstream"
[11:51]  * Hobbsee is uncertain why you're trying to package something to install a PPA key, but whatever
[11:52] <savvas> AnAnt: I would say that logically there's no upstream for that, perhaps you should remove upstream authors. ( I'm not a MOTU :) )
[11:52] <AnAnt> sounds reasonable
[11:53] <geser> AnAnt: see the copyright file for ubuntu-keyring: http://changelogs.ubuntu.com/changelogs/pool/main/u/ubuntu-keyring/ubuntu-keyring_2008.03.04/ubuntu-keyring.copyright
[11:54] <geser> as an example
[11:54] <AnAnt> thanks
[12:00] <james_w> geser: hey, you say you are working on the python transition today? Anything I can do to help?
[12:01] <savvas> geser: how does this look like? http://launchpadlibrarian.net/23250898/keysafe_0.3.5-2ubuntu1.debdiff
[12:01] <geser> james_w: I'm going through the unmet deps list and see what I can fix
[12:01] <james_w> geser: ah, cool
[12:02] <james_w> geser: do you think it is worthwhile trying to come up with a list of candidate packages to fix?
[12:02] <james_w> i.e. parse Packages files to find likely candidates for a rebuild?
[12:02] <savvas> hm.. what does "reverted:" mean in a patch/debdiff header?
[12:02] <james_w> I'm pretty sure it should be possible, I just haven't quite worked out the criteria yet
[12:03] <geser> james_w: that would be a good idea
[12:03] <james_w> the first target would be "Architecture != all" packages
[12:04] <james_w> with a python dependency?
[12:04] <geser> a criterion could be: check the Contents file for packages building python modules and check if they have transitioned yet (have a python 2.6 module)
[12:05] <geser> in case the dependency on python < 2.6 doesn't catch them
[12:05] <geser> and those are already listed in the unmet deps output
[12:08] <geser> savvas: looks good. Although using "/usr/bin/python" is preferred to "/usr/bin/env python" (think of a different python version installed in /usr/local/bin without the needed modules for that version)
[12:08] <geser> savvas: I'll fix it while building the updated package
[12:08] <RainCT> james_w: ScottK had a line to get all packages which depend on "<< 2.7"
[12:10] <RainCT> * 2.6
[12:10] <geser> james_w: it would be also good to check packages which directly depend on python2.5 (or even python2.4)
[12:19] <RainCT> >> 17:08 < ScottK> I did finally figure out grep-available -F Depends "python (<< 2.6)"|grep Package for the packages that explicitly need rebuilt.
[12:21] <savvas> geser: ok noted, thanks :)
[12:25] <geser> savvas: [ubuntu/jaunty] keysafe 0.3.5-2ubuntu1 (Accepted)
[12:25] <savvas> woohoo!
[12:28] <savvas> RainCT: really minor, but for better sync with debian, in compizconfig-python we could use this line instead of the two in debian/install: usr/lib/python*/*-packages/compizconfig.so
[12:31] <RainCT> savvas: ah, right. I'm still waiting for Sean to answer to my ping from yesterday, though :P
[12:31] <savvas> ok :)
[13:16] <geser> james_w: fyi: you can skip python-omniorb as I've already an updated package just waiting on omniorb4 getting build
[13:16] <james_w> geser: cool, thanks for the heads up
[13:18] <geser> james_w: if you need something more demanding than a simple change, try setools (I've gave it a quick look at put it to the end of the queue)
[13:18] <geser> :)
[13:19] <james_w> heh
[13:32] <geser> james_w: I'm just looking over your changes to yapgvb (I wanted to look at it again after I was done with the easy ones): will the install-ext-% target do the right thing for python2.5?
[13:33] <james_w> geser: no, it won't, but it is XS-Python-Version: current
[13:33] <geser> yes, I just noticed it myself
[13:55] <ScottK> RainCT: I did later figure out that only works for packages that are or have been installed.
[13:56] <RainCT> ScottK: oh, too bad
[13:57] <ScottK> So I did my first cut by apt-cache rdepends python2.4 and installing all those packages in a chroot.
[13:59] <ScottK> From that list I know of python-codespeak-lib, python-migrate, and python-pypoker-eval are left undone.
[14:00] <ScottK> rgreening was looking at python-pypoker-eval when I went to bed last night.  Dunno if he got it sorted.
[14:00] <directhex> yay @ lp-integration
[14:00] <directhex> i can continue my arm tinkering
[14:02] <ScottK> In fact, Bug #336151 is waiting for uus.
[14:02] <Laney> core > arm
[14:03] <directhex> Laney, true
[14:03] <ScottK> RainCT: Would you have time to sponsor that one?  I'm on my way out the door.
[14:04] <RainCT> ScottK: Sure
[14:04] <ScottK> RainCT: Thanks.
[14:08] <mok0> Laney: you really thing I should patch requestsync??
[14:08] <mok0> :-P
[14:08] <Laney> mok0: It's your idea!
[14:08] <mok0> heh
[14:09]  * RainCT is OK with it
[14:12]  * Laney does it
[14:15] <RainCT> .. with Ubuntu :)
[14:15] <Laney> ffs
[14:16] <Laney> how do I remove a commit?
[14:16] <Nafallo> uncommit
[14:16] <Laney> ...who'd have thought? :O
[14:16]  * RainCT uploads wxwidgets2.6 and hopes it won't FTBFS again
[14:16] <RainCT> ffs?
[14:17] <jpds> RainCT: wtf ffs
[14:17] <RainCT> jpds: Gee...  I don't know what ffs means...
[14:18] <savvas> free for some :p
[14:19] <savvas> http://en.wiktionary.org/wiki/FFS ;)
[14:19] <RainCT> hehe
[14:20] <RainCT> An expression of anger or frustration.
[14:20] <sebner> !ohmy | Laney :P
[14:20] <Laney> :((((((((
[14:33] <directhex> python-hildondesktop needs a rebuild too afaik
[14:36] <StevenK> directhex: Leave that one, I'll deal with it tomorrow
[14:36] <directhex> okay, cheers
[14:36] <directhex> just alerting you
[14:36]  * StevenK adds it to his todo
[14:38] <Laney> anyone got a sync to make?
[14:38] <jpds> Laney: Main or universe?
[14:38] <Laney> doesn't matter
[14:38] <Laney> just want to test this change
[14:38] <jpds> I usually use gnupg as a control for main.
[14:39] <geser> Laney: use staging for testing?
[14:39] <Laney> geser: Yeah, that requires digging around elsewhere in u-d-t :(
[14:40] <jpds> Laney: No really, just manage-credentials with the staging flag.
[14:40] <jpds> .. I think.
[14:40] <Laney> can I have multiple sets of credentials at once?
[14:40] <Laney> or will it overwrite my old ones?
[14:41] <jpds> Backup your old ones, just in case.
[15:02] <Laney> well, that doesn't work!
[15:03] <jpds> Whoops.
[15:03] <Laney> I think it doesn't look to see what service the credentials are for
[15:04] <RainCT> YEAH!
[15:04] <jpds> You did use the --lp flag right?
[15:04] <RainCT> wxwidgets2.6 built!!
[15:04] <Laney> yes
[15:04] <Laney> gives a 401 unauthorized error
[15:05] <jpds> Hmm.
[15:06] <anakron> Hi all
[15:06] <anakron> :)
[15:06] <jpds> Laney: Traceback?
[15:06] <jpds> anakron: Hola.
[15:06] <anakron> HI RainCT, Laney
[15:07] <anakron> hola
[15:07] <Laney> ey up
[15:07] <anakron> :O
[15:07] <RainCT> Hi anakron :)
[15:07] <Laney> jpds: http://pastebin.ubuntu.com/124792/
[15:08] <jpds> Laney: Which access level did you give the token?
[15:08] <Laney> all
[15:08] <thekorn> Laney, did you use manage-credentials to create the credentials, if so, don't forget to set --level
[15:09] <Laney> thekorn: oh, I don't remember doing this before
[15:09] <Laney> (and the usage doesn't mention it)
[15:09] <Laney> let me try again
[15:10] <Laney> thekorn: no change
[15:11] <Laney> thekorn: Is there no way for the tool to tell what access it was given?
[15:11] <thekorn> Laney, staging or edge?
[15:11] <Laney> thekorn: staging
[15:11] <Laney> Here's the line I used: "manage-credentials create -c ubuntu-dev-tools --service staging -l 4"
[15:12] <thekorn> Laney, no, unfortunatly the API and launchpadlib does not give such information (yet)
[15:12] <thekorn> there is an open bugreport about it
[15:12] <Laney> Wouldn't it be more sensible for the application to request the access level it needs?
[15:12] <Laney> and LP to say "ubuntu-dev-tools wants to read and write non-public data. Is that OK?"
[15:14] <Laney> jpds: Is the problem that get_launchpad takes a service parameter?
[15:23] <jpds> Laney: Actually, that might be the thing you'd want to change to STAGING for testing.
[15:24] <Laney> it'd be better if it could determine it from the credentials file though
[15:31] <RainCT> Started:   1 hour ago        /me wonders why his PC compiles faster than the buildd's
[15:31] <RainCT> ah nvm, it's built, I just can't read :P
[15:37] <anakron> Hi laney
[15:38] <Laney> hi ho
[15:38] <anakron> hey, look it, https://bugs.launchpad.net/ubuntu/+bug/335940 , I think that this could be helpful to many people
[15:39] <anakron> it's useful if i "solved" it?
[15:40] <RainCT> oh, nvidia-settings is FLOSS?
[15:40] <anakron> mm
[15:40] <RainCT> that was a retoric question, I've just seen it's in "main".. nice :)
[15:41] <anakron> :) so it able to add a debdiff file to it?
[15:42] <anakron> it's so easy to solved, but this is not actually an app that MUST be run with root priv
[15:43] <anakron> so
[15:43] <RainCT> anakron: I can't see the bug (LP is slooooow) but if it is about adding gksudo, please don't
[15:44] <anakron> i think that only this option must requieres root priv
[15:44] <Laney> the proper way is to use policykit to get root, right?
[15:44] <RainCT> right
[15:44] <Laney> for that one op
[15:44] <RainCT> yep
[15:45] <RainCT> anakron: please forward the bug upstream and ask them to use policykit
[15:45]  * anakron learning, writting..:)
[15:45] <jpds> RainCT: lies.
[15:45] <anakron> ok
[15:45] <RainCT> jpds: eh?
[15:46] <RainCT> if that's an answer to LP being slow, I had to refresh 3 times because it always timed out -.-
[15:54] <cody-somerville> RainCT, is there a dbus interface to editing xserver configuration?
[15:54] <cody-somerville> If not, policykey can't magically work
[15:56] <RainCT> cody-somerville: Dunno, both dbus and policykit are topics into which I still have to digg in. But in any case, it shouldn't be too difficult to create it, or?
[15:57] <cody-somerville> Take a look at this bug: https://bugs.edge.launchpad.net/ubuntu/+source/startupmanager/+bug/238499
[15:59] <bersace> Hi
[15:59] <bersace> When will the inclusion window be closed ?
[15:59] <RainCT> cody-somerville: so, can't they create a dbus interface for that?
[15:59] <RainCT> and, is there some human-readable dbus tutorial? last time I looked at dbus I didn't understand anything :P
[16:00] <cody-somerville> RainCT, I dunno. However, saying folks can't use gksudo or whatever doesn't sound right to me.
[16:00] <RainCT> cody-somerville: they can't use gksudo because that is only a minor feature of the application
[16:01] <cody-somerville> nvidia-settings?
[16:01] <RainCT> yes
[16:01] <cody-somerville> It never seemed to work for me unless I ran it as root.
[16:01]  * cody-somerville thinks we should bug superm1 about this.
[16:01] <RainCT> I use it everyday myself and it works fine..
[16:05] <james_w> if anyone with a bit of KDE/CMake knowledge want to take a look at bug 336295 that would be great
[16:10]  * JontheEchidna takes a peek
[16:15] <bddebian> Hey folks, how deep of freeze is Jaunty in now?
[16:15] <directhex> feature freeze
[16:15] <geser> Hi bddebian, we are already in FF
[16:15] <directhex> last time i checked
[16:16] <bddebian> Hmm, so I'm screwed for a new lordsawar upstream eh?
[16:16] <directhex> you could file a FFe request
[16:17] <sebner> bddebian: or is it bugfix only?
[16:17] <bddebian> Mostly bugfix but I'll ask him
[16:22] <directhex> hm, nobody got around to updating nvidia-glx-180 to a stable release on intrepid. so when my new pc is fixed, i need to upgrade to jaunty or wait... :/
[16:43] <RainCT> directhex: it is in intrepid-updates
[16:44] <directhex> RainCT, 180.11, a beta missing lots of hardware support, is
[16:44] <RainCT> ah
[16:44] <alex-weej> The following packages have unmet dependencies.
[16:44] <alex-weej>   python-tagpy: Depends: python (< 2.6) but 2.6.1-0ubuntu1 is to be installed
[16:44] <alex-weej> E: Broken packages
[16:44] <RainCT> directhex: then update it :)
[16:44] <alex-weej> i have python 2.5 on my jaunty system
[16:44] <alex-weej> why is it whingeing?
[16:45] <directhex> alex-weej, because "python" version 2.6 is not "python-2.5"
[16:45] <RainCT> alex-weej: because python is a package dependency on python2.6
[16:45] <geser> alex-weej: because of the python 2.6 transition
[16:45] <alex-weej> so how do we fix this?
[16:45] <geser> rebuild
[16:45] <alex-weej> python-tagpy?
[16:45] <geser> give my a minute
[16:45] <RainCT> yes
[16:45] <geser> yes
[16:46] <alex-weej> geser: you're going to do it?
[16:46] <geser> I can
[16:46] <alex-weej> thanks!
[16:46] <RainCT> directhex: does the stable release have performance improvements or something?
[16:46] <JontheEchidna> james_w: With your patch it got past cmake just fine
[16:46] <JontheEchidna> in pbuilder at least
[16:47] <directhex> RainCT, well, hardware support, lots of bug fixes in vdpau... opengl 3 support
[16:47] <JontheEchidna> james_w: this is at the start that it's supposed to fail at, correct?
[16:47] <RainCT> and does it  build on intrepid?
[16:48] <directhex> RainCT, i don't see why it wouldn't, but i'd be uneasy about touching that stuff without tseliot
[16:49] <tseliot> directhex: what's up?
[16:49] <directhex> tseliot, nvidia 180 in intrepid
[16:50] <tseliot> aah, the SRU
[16:50] <tseliot> actually I wanted to file a backport request about it
[16:50] <tseliot> but I haven't had the time yet
[16:51] <directhex> tseliot, $DEITY-willing i'll have my pc up & running within a week... but there's no driver in intrepid for the 216-core gtx260 yet :p
[16:52] <tseliot> directhex: would you like to file the backport request yourself? The driver in Jaunty should just work with Intrepid
[16:53] <directhex> tseliot, no extra mucking about needed? whatever happened to that huge ubuntu-restricted-modules source package with every little thing in it?
[16:53] <tseliot> directhex: well, there was a reason if I split nvidia from the l-r-m and moved to DKMS too ;)
[16:54] <tseliot> maintenance is a lot easier now
[17:04] <james_w> JontheEchidna: no, it fails later for me
[17:05] <geser> alex-weej: [ubuntu/jaunty] tagpy 0.94.5-2ubuntu1 (Accepted)
[17:05] <Rhonda> Hi. I would like to have someone to speak to with respect to the required security-related updates for wesnoth in releases other than jaunty (which was synced already).
[17:06] <james_w> hi Rhonda
[17:06] <james_w> Rhonda: is there a CVE for it?
[17:07] <Rhonda> I'm willing to prepare the patches but have absolutely no clue about the procedures on getting it to the right people to have it done.
[17:07] <Rhonda> james_w: Yes, it's in the changelog for 1:1.4.7-4 in jaunty.
[17:08] <Rhonda> CVE-2009-0367 (which also requires a change to one campaign to make it still work) and CVE-2009-0366
[17:09] <james_w> Rhonda: https://wiki.ubuntu.com/SecurityUpdateProcedures is documentation on the subject, but it's a mix of things that you have to do and things you don't need to care about, which is unfortunate
[17:09] <Rhonda> I did backport the required changes for Debian last week to also 1.4.4 and even 1.2, so I am quite confident that I can help with getting things done within Ubuntu - just I don't know the procedures, and I don't want to have these problems still open here.
[17:11] <Rhonda> james_w: If I have someone in the Ubuntu team to discuss with that does the Ubuntu part and I only do the source patch preparation that would be extremely convenient, I guess.
[17:11] <Rhonda> It's not that I totally object to dig into ubuntu pracises, it's just that I so rarely need them that it costs me quite some effort ... to forget it until the next time something would pop up again. :/
[17:11] <ploum> hello
[17:12] <ploum> I'm trying to make my debian package
[17:12] <ploum> so far all seems to be relatively fine but I have the following error :
[17:12] <ploum>  dpkg-genchanges: failure: cannot read files list file: No such file or directory
[17:12] <ploum> does it ring a bell for anyone ?
[17:13] <james_w> Rhonda: that's certainly possible
[17:14] <james_w> there's a mess of different versions in different releases though, which complicates things
[17:17] <Rhonda> james_w: 1.4.5 (intrepid) and 1.4 (hardy) aren't that big of a problem, not sure wether 1.2.6 (gutsy) is still needed, but yes, dapper version looks a bit messy to me.
[17:17] <alex-weej> geser: does tagpy include the python bindings?
[17:18] <geser> alex-weej: yes, that's the source package for it
[17:18] <james_w> Rhonda: it's more the version skew between pockets that concerns me
[17:18] <alex-weej> cool. cheers
[17:18] <geser> alex-weej: you just need to wait till it gets build and appears on your mirror
[17:18] <alex-weej> k will wait it out
[17:18] <Rhonda> james_w: Not sure what you mean with that. Pockets?
[17:20] <james_w> Rhonda: as well as the "release" pocket we have "-security", "-updates", "-proposed" and "-backports", so there can be multiple copies of the code to update for each release in essence
[17:20] <james_w> https://launchpad.net/ubuntu/+source/wesnoth shows all the versions in supported releases at the top
[17:21] <Rhonda> james_w: dapper + dapper-updates aswell as gutsy and gutsy-updates have the same versions.
[17:21] <Rhonda> I'm at http://packages.ubuntu.com/search?keywords=wesnoth-server  ;)
[17:21] <james_w> you don't need to worry about that too much, as we have various rules, and try and reduce the duplication at the same time, it will just take me longer to work out what to patch :-)
[17:22] <Rhonda> .. and about the backports version, I guess the easiest fix is taking the update for the backport, not?
[17:22] <Rhonda> I mean, that's also what I did in Debian for its backports versions.
[17:23] <james_w> yeah, we can ignore backports to start with
[17:23] <james_w> hardy is easy enough
[17:23] <james_w> https://edge.launchpad.net/ubuntu/hardy/+source/wesnoth/1:1.4-1
[17:23] <ScottK> Generally for backports we just do a new backport in Ubuntu too.
[17:23] <james_w> gutsy too
[17:23] <james_w> https://launchpad.net/ubuntu/gutsy/+source/wesnoth/1.2.6-1ubuntu2.4
[17:23] <james_w> if you can supply patches that will apply to those two versions then we can get them updated easily enough
[17:24] <Rhonda> Sure thing.
[17:24] <james_w> intrepid is harder because there is something in -proposed, I'll see what the rules are for that
[17:26] <james_w> it's bug 287158 for that, which is without confirmation for a month
[17:26] <Rhonda> james_w: Yeah, once again pochu didn't notify me about that one.  %-/
[17:27] <Rhonda> Hmm, wait, I've seen that bugreport. Ah, right, it's fixed in 1.4.6 (or 1.4.7) so it didn't bother me too much, frankly spoken.
[17:27] <pochu> Rhonda: which one?
[17:28] <pochu> Rhonda: aren't you subscribed to wesnoth in Ubuntu?
[17:28] <Rhonda> In the meantime I am. :)
[17:28] <pochu> Rhonda: and I'm using Debian in my desktop and don't have Ubuntu handy (other than VMs) so I'm afraid I may not be of much help anyway...
[17:29] <Rhonda> No worries, and sorry, didn't want to badmouth you with that.
[17:29] <Rhonda> I'm very happy that we finally managed to get together more properly. :)
[17:31] <james_w> Rhonda: I can't find documentation of the best way to proceed there, so the best thing may be to leave Intrepid until a security team member is around
[17:31] <james_w> as for dapper, it's 1.0.2-0ubuntu1.2, which it doesn't sound like you have backported to, is that version affected?
[17:32] <Rhonda> Depends. Did configure get called with --enable-python? If so it is for the python bug.
[17:32] <Rhonda> ... which is the more severe.
[17:37] <james_w> it's not clear
[17:38] <james_w> there's no explicit --enable-python or --disable-python as far as I can see
[17:38] <james_w> and no build log any longer it appears
[17:39] <Rhonda> 1.3.1 was the first version that had python enabled by default.
[17:39] <Rhonda> So if there is no explicit --enable-python it can be assumed that it isn't.
[17:40] <james_w> the only thing is that the changelog mentions adding "python-dev to Build-Depends so that the python API is available", is that related?
[17:40] <Rhonda> hmmm
[17:40] <Rhonda> I'll take a closer look - after cooking. :)
[17:41] <Rhonda> Thanks so far, I'll keep you updated. You can expect first patches propably tomorrow (CET here)
[17:42] <james_w> Rhonda: I've got to disappear soon I'm afraid. Basically if you file a bug against wesnoth, explain the issue, including CVE numbers, and then subscribe the "ubuntu-universe-sponsors" team, and attach any patches you have, then we can work from there
[17:42] <Rhonda> james_w: Will try that - and have a nice evening too (I guess it's evening for you, too)
[17:43] <james_w> it is, thank you, enjoy your cooking
[17:43] <geser> a good idea would be to also subscribe motu-swat and ubuntu-security
[18:43] <Laibsch> Hi
[18:43] <Laibsch> Can somebody please push bug 335891 ?
[18:43] <Laibsch> It's about as little work for fixing any bug you'll ever find
[18:43] <Laibsch> debdiff included
[19:18] <cristi> hy! i am just getting started, still reading some of the documentation. However i don't understand something. It says that i should make a ssh key in order to upload to launchpad. Where exactly am i supposed to upload the key?
[19:19] <cristi> i mean what is the remote host's adress
[19:19] <directhex> cristi, https://launchpad.net/~yourlpname/+editpgpkeys
[19:22] <superm1> cody-somerville, about what?
[19:22] <cody-somerville> superm1, about running nvidia-settings as root
[19:22] <cristi> directhex: bless you
[19:22] <superm1> cody-somerville, i think its better to get it policykit ified
[19:22] <superm1> although someone from the ubuntu side would likely have to write the patch and submit it to them.  i dont think they're generally too keen on feature requests
[19:24] <superm1> looking at scollback looks like thats what someone already suggested
[19:24] <superm1> it's the right solution.
[19:24] <RainCT> OT, does someone know where to get an ipk package for irssi?
[19:24] <superm1> likely need to switch nvidia settings to use xkit first though
[19:24] <superm1> once it's using xkit, then it's a matter of moving that code into a backend for dbus to operate with
[19:25] <cristi> directhex: and how do i connect? i tried ssh myaccnmb@launchpad.net and i got refused on standard port
[19:26] <fabrice_sp> RainCT, about bug #330392.
[19:26]  * RainCT looks
[19:27] <RainCT> fabrice_sp: yes?
[19:27] <fabrice_sp> did you do something with it?
[19:27] <superm1> anakron, so if you want a little project, i'd say go ahead and write a patch to convert to using xkit, otherwise it'll probably just live in nvidia's bucket for a bit
[19:27] <RainCT> Nope
[19:28] <fabrice_sp> ok. as we are post FF, I need to fill a FFe
[19:50] <Rhonda> hmmm, what would be the proper version string, distribution and urgency for the wesnoth fix for hardy? (1:1.4-1ubuntu1) hardy-security; urgency=high?
[19:51] <directhex> ubuntu ignores urgency
[19:51] <a|wen> Rhonda: what is the current version in hardy?
[19:51] <Rhonda> 1:1.4-1
[19:52] <a|wen> Rhonda: i would go with 1:1.4-1ubuntu0.1
[19:52] <Rhonda> directhex: Well, then it still can help as a hint to the users, not?
[19:52] <Rhonda> Thanks.
[19:53] <a|wen> Rhonda: we usually avoid it
[19:55] <a|wen> Rhonda: https://wiki.ubuntu.com/SecurityUpdateProcedures ... look at the template for the changelog
[19:55] <ScottK> It doesn't hurt, but it make no actual different.
[19:56] <savvas> anyone taking care of aptoncd ?
[19:56] <savvas> for the python transition I mean
[19:57] <savvas> hm.. good candidate for me :P
[20:10] <RainCT> damn.. why are there no mips .ikp packages for screen and irssi.. :P
[20:11] <RainCT> *ipk
[20:11]  * directhex throws slugs at RainCT 
[20:12]  * RainCT moves directhex a few places upwards in his blacklist :)
[20:13] <savvas> I think aptoncd just needs a rebuild - testing currently
[20:13]  * RainCT has a shot at pykaraoke
[20:17] <savvas> aptoncd builds fine - just needs a rebuild: http://launchpadlibrarian.net/23268539/buildlog_ubuntu-jaunty-i386.aptoncd_0.1.98-0ubuntu4~ppajaunty1_FULLYBUILT.txt.gz
[20:17] <savvas>  Depends: python-central (>= 0.6.11), python2.6, libgnomevfs2-0, genisoimage | mkisofs, apt-utils, synaptic (>= 0.57.7), python-gnome2, python-apt, python-glade2, python-dbus, lsb-release, gksu, python-gtk2, gnome-icon-theme
[20:19] <jcfp> Is there any special procedure or team to notify for all those python 2.6 related bugs?
[20:19] <RainCT> why is there python2.6 and not "python (>= 2.6)"?
[20:19] <RainCT> (imho that's actually a good thing, just asking)
[20:19] <savvas> no idea, I didn't touch the source :)
[20:20] <RainCT> jcfp: Afaik no. Only this info message: http://paste.debian.net/29528
[20:20] <RainCT> (from doko)
[20:21] <savvas> RainCT: Depends: ${python:Depends} and XB-Python-Version: ${python:Versions}  - it uses setup.py to build
[20:22] <savvas> hm..
[20:22] <savvas> python$* setup.py build
[20:22] <savvas> nice :P
[20:22] <RainCT> ScottK: I have pykaraoke ready
[20:22] <RainCT> also ScottK2
[20:22] <ScottK> OK.
[20:22] <ScottK> So do I.
[20:23] <ScottK> RainCT: Yours is more than a no-change rebuild?
[20:24] <RainCT> ScottK: Yes, no-change will place stuff into /usr/local
[20:24] <RainCT> so it needs the --install-layout=deb
[20:25] <ScottK> Yes.  That's what I have too.
[20:25] <savvas> ScottK: is there a bug report that could track requests for a simple rebuild?
[20:25] <ScottK> savvas: Not generally no.  In this case there was one.
[20:26] <savvas> ah oko
[20:26] <RainCT> So who uploads? :P
[20:26] <savvas> *ok :)
[20:26] <ScottK> RainCT: I guess go ahead and upload yours, but next time please assign yourself the bug so we don't duplicate work.
[20:28] <RainCT> ScottK: OK, it's up. I tried, but the page didn't open (two timeouts until I got it a minute ago).. :(. I mentioned that I was working on it here, though
[20:28] <savvas> anyone working on envyng-core ?
[20:28] <ScottK> savvas: I'd leave that for tseliot.
[20:29] <ScottK> OK.
[20:29] <savvas> cool
[20:33] <savvas> I think it just needs a simple rebuild as well, haven't tested it
[20:33] <RainCT> (in case someone else is also suffering Launchpad's slowness and is a beta tester, switching to production makes it much faster)
[20:33] <savvas> RainCT: here's fast :)
[20:33] <RainCT> savvas: are you on edge?
[20:33] <savvas> yep
[20:33] <RainCT> weird
[20:34] <savvas> which link is weird?
[20:34] <savvas> er.. slow? :P
[20:34] <RainCT> all sorts of bug reports
[20:34] <savvas> this one? https://bugs.edge.launchpad.net/ubuntu/+source/envyng-core/+bug/292173
[20:35] <savvas> it seems fine here
[20:35] <RainCT> I've disabled edge for now
[20:36] <savvas> anyone working on hplip ?
[20:36] <savvas> ah doko took care of it
[20:45] <Rhonda> james_w: When you see this in your away log, #336396 contains the patch for gutsy, am working on hardy patch now.
[20:49] <Laibsch> ScottK: Thank you for taking a quick stab at pykaraoke.  Can I maybe get you interested in the other python 2.6 related problem I documented in bug 331461?
[20:55] <tseliot> savvas: yes, that's a bug which I think I fixed sometime ago but I can't find my code. I'll have a look at it (it affects only users who have 2 nvidia cards)
[21:05] <Rhonda> james_w: ... and #336406 for gutsy. :)
[21:06] <Rhonda> hmm, was the other way round actually, #336396 was for hardy, not gutsy.
[21:11] <geser> Rhonda: just for you information: you can mark a bug affecting several releases, no need to open a bug for every Ubuntu release
[21:13] <Rhonda> geser: There is different patches needed for the different releases.
[21:14] <savvas> tseliot: hi, what bug? I just saw that python needs to be transitioned to python 2.6 and envyng-core is one of them :)
[21:14] <Rhonda> But yes, feel free to merge them if that works for you and won't end in a mess if it's fixed for one release but not for the other. I just don't want to get it forgotten because of some workflow problem.
[21:14] <tseliot> savvas: https://bugs.edge.launchpad.net/ubuntu/+source/envyng-core/+bug/292173
[21:15] <tseliot> savvas: ok if you were referring to the transition to python 2.6 and you want to do it yourself you're welcome ;)
[21:19] <geser> Rhonda: you can attach several patches to a bug :) as long as the patch description tells which one is which there is no problem
[21:19] <savvas> tseliot: I'm not a motu unfortunately, but I've looked at the code, I think it just needs a rebuild - I can try it in PPA if you want to :)
[21:19] <geser> Rhonda: I leave it up to james_w how he wants this handled
[21:20] <tseliot> savvas: it's just a matter of modifying the debian/rules. I think I can do it, thanks.
[21:21] <savvas> alrighty!
[21:23] <Rhonda> geser: I'm not confident with ubuntu handling of stuff, at all. I just want to have the issue solved and try to offer my best. Sorry to not have studied the practices before, but I guess that's still alright.
[21:24] <ripps> I've created a dshowserver (coreavc-for-linux) package in my PPA, but the code won't compile on amd64, the wiki says to compile the programs with a STATIC parameter and it will work on 64 bit arch's. How do I get the installation script to change it's procedure when the arch is 64 bit.
[21:25] <ripps> ^ to clarify: how to install precompiled binaries in PPA.
[21:25] <geser> Rhonda: no problem, it's still alright the way you do it, I just wanted to help you to ease it a bit
[21:34] <bekks> hi
[21:35] <ripps> How do I setup my PPA package to compile on one architecture and use precompiled on another?
[21:35] <geser> not at all
[21:36] <geser> it must be build from source on every architecture
[21:37] <bekks> geser: juliux told me to contact you if dholbach isnt around - may i query you?
[21:38] <ripps> geser: my package doesn't build on amd64, it must be compiled with STATIC on a i386 to work on 64 bit.
[21:38] <geser> bekks: sure
[21:38] <geser> ripps: and how does upstream build the precompiled binaries?
[21:39] <ripps> geser: like that, they tell 64bit users to compile on i386 with static or use a precompile package they supply.
[21:40] <geser> ripps: ah, so the amd64 users us the i386 binaries?
[21:40] <ripps> geser: I guess so, but that makes it difficult to use with PPA.
[21:41] <ripps> http://code.google.com/p/coreavc-for-linux/wiki/DshowserverInstall
[21:41] <geser> ripps: then you need to build the i386 binaries on amd64 again (cross-compile)
[21:43] <ripps> geser: how do I do that?
[21:50] <geser> ripps: I'd avoid it at all and only offer an i386 deb
[21:51] <ripps> geser: That's currently what I'm doing, I just wanted to make easier for those just adding my PPA apt line to their sources.list.
[21:56] <savvas> some of the servers for gb.archive.ubuntu.com seem faulty - where do we report this?
[21:56] <jpds> savvas: To Datahop.
[21:57] <savvas> datahop at ubuntu.com ?
[21:58] <jpds> savvas: datahop.com - they run the gb.a.u.c servers.
[21:58] <savvas> oooh, ok thanks :)
[21:58] <ripps> How do I compile a single architecure-independent package to be used with all architectures?
[22:00] <lifeless> ripps: you don't
[22:00] <lifeless> ripps: sorrry, i read archiecture-dependent, my bad
[22:01] <ripps> lifeless: Oh, I thought it was possible. I keep seeing packages that have -all instead of -i386 or -amd64
[22:01] <lifeless> ripps: yes, it is possible, I just misread your question
[22:02] <lifeless> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
[22:03] <lifeless> summary - all -> one binary for all platforms, any -> one binary per platform works on all platforms
[22:04] <ripps> lifeless: will this work with PPA's?
[22:06] <lifeless> yes
[22:06] <lifeless> but building the package you were describing before as a binary-all package is a bad idea
[22:07] <lifeless> in case thats what you were thinking of doing
[22:07] <ripps> lifeless: why, if I build it as static, shouldn't work on both i386 and amd64?
[22:08] <lifeless> for starters, static packages need strong justification because of the security problems involved
[22:08] <geser> arch:all packages also install on sparc, powerpc, hppa, armel, lpia
[22:08] <lifeless> we have 32 bit libs available on amd64
[22:08] <geser> and only on lpia you might have success running the binaries
[22:08] <lifeless> secondly, as geser says, all is much more than i386 and amd64
[22:09] <ripps> should I create a seperate package that uses static and specificallly builds only on amd64.
[22:09] <ripps> no, that won't work...
[22:10] <lifeless> you should start by filing a bug with upstream :) - its bad not being able to rebuild the someware one is using, and as an amd64 user I'd need a really good reason to install something I can't rebuild
[22:10] <lifeless> you should be able to get the package to build on amd64 using -mi386 and other such configure flags, with appropriate dependencies
[22:11] <lifeless> though multiarch isn't finished, it will depend on what you need
[22:11] <ripps> Upstream is working on it, but work seems to be slow. They haven't made any updates in a long time.
[22:12] <ripps> "gcc -mi386" in the makefile?
[22:19] <ripps> If I don't have a amd64 machine, then I can't test the package with pbuilder, can I?
[22:22] <andersk> Is anyone available to look at the sync request in bug 289921?
[22:23] <DBO> hello MOTU's
[22:23] <DBO> is there a document someone to go about getting an FFE for GNOME Do
[22:24] <DBO> we have another release coming out in a day or two that fixes a lot of crashing bugs
[22:25] <pochu> !featurefreeze
[22:25] <Laney> did banshee release?
[22:25] <pochu> !ffe
[22:25] <geser> https://wiki.ubuntu.com/FreezeExceptionProcess
[22:25] <pochu> DBO: check out that link ^
[22:25] <DBO> thank you all
[22:31] <DBO> pochu, geser do any of you know anyone familiar with packaging mono apps?
[22:31] <geser> iirc directhex is familiar with mono packages
[22:32] <pochu> RAOF usually takes care of gnome-do I think, but he's not around right now
[22:32] <DBO> yeah he does
[22:32] <DBO> I am one of the developers of Do
[22:32] <Laney> Oh
[22:32] <DBO> we are looking to get 0.8.1 in ubuntu since 0.8.0 has some really nasty crashers in Docky
[22:32] <Laney> He asked me to do the packaging
[22:32] <Laney> it's no problem
[22:32] <DBO> but with RAOF gone right now
[22:33] <DBO> Laney, oh really? =)
[22:33] <Laney> oh yes
[22:33] <DBO> I am happy
[22:33] <Laney> got a changelog link/
[22:33] <DBO> we are gearing up
[22:33] <DBO> it will be within 24 hours
[22:33] <Laney> I thought it waited for Banshee?
[22:33] <DBO> so I was coming here to figure out how we went about getting this into jaunty, I didn't know RAOF already hooked it up
[22:34] <DBO> Laney, we can actually release before then since we develop against banshee svn
[22:34] <DBO> but you probably wont get a working build until banshee releases
[22:34] <Laney> ok
[22:35] <DBO> i thought they were releasing yesterday
[23:41] <bddebian> Do I need to request a sync and then an FFe or just an FFe for a new upstream release?
[23:41] <pochu> bddebian: FFe first, and if it's accepted you can sync it
[23:42] <pochu> bddebian: btw I went yesterday through libsoup2.2 rdependencies and got this: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libsoup2.2;users=pkg-gnome-maintainers@lists.alioth.debian.org
[23:42] <pochu> we may be able to remove it from the archive soon :)
[23:43] <bddebian> Sweet, I like RM:s :)
[23:47] <ScottK> bddebian: Speaking of which weren't you trying to port cstim to a later wxwidgets?
[23:48] <ScottK> err ctsim
[23:48] <bddebian> I tried
[23:48] <bddebian> Who do I need to subscribe to the FFe?
[23:48] <ScottK> motu-release.
[23:48] <ScottK> Unless it's in Main.
[23:50] <bddebian> OK, thx
[23:50] <bddebian> Actually ctsim is going to have worse problems when we drop Gtk1.2 :)
[23:52]  * bddebian is such an Ubuntu loser anymore