[00:12] <vizeke> anyone can help me?
[00:12] <micahg> vizeke: https://wiki.ubuntu.com/MOTU/Mentoring/Junior_Contributor
[00:13] <vizeke> lol... thank you again
[00:14] <micahg> vizeke: sorry, I'm not a MOTU, I just answer what I can
[00:14] <micahg> they're probably busy getting ready for the next round of packaging for Lucid
[00:15] <vizeke> yeah...
[04:32] <MTecknology> !search bzr-bookmark
[06:41] <wrapster> i get this error while apt-get update...
[06:41] <wrapster>  http://pastie.org/682862
[06:41] <wrapster> can anyone pls look into it..
[06:46] <wgrant> wrapster: That seems like a Nexenta support question -- certainly not an Ubuntu development question.
[06:46] <wrapster> wgrant: yeah i know.. but i though it has got something to do with apt-get and thats why i asked..
[06:46] <wrapster> sorry about that
[06:46] <wgrant> It's nothing to do with apt-get.
[06:50] <hypercube> I think I've got an Ubuntu development question...
[06:52] <hypercube> Um, well, I guess I'll just ask.  So I'm trying to get started with patching bugs.  Looking at the example at https://wiki.ubuntu.com/Bugs/HowToFix
[06:53] <hypercube> I'm on Karmic, and when I do apt-cache show xicc, I notice that the Maintainer field is already set to Ubuntu MOTU Developers
[06:53] <hypercube> But, when I apt-get source xicc...
[06:54] <wgrant> That's some magic performed by Launchpad when the package is built.
[06:54] <wgrant> The maintainer address is overridden, to avoid inappropriately attributing packages to their Debian maintainers.
[06:55] <hypercube> OK, so on that page they say when we make a patch we should update the Maintainer field
[06:55] <hypercube> but is that still necessary if launchpad does it for us?
[06:55] <wgrant> Launchpad will override the Maintainer field of the *binaries*.
[06:55] <wgrant> We need to manually override it for the sources that we modify.
[06:57] <hypercube> OK... I think I understand.  If there had been an ubuntu specific patch already, then the source i get through apt-get source would have the maintainer field already modified, and I wouldn't have to modify it, right?
[06:58] <wgrant> that's how it should be, yes.
[06:58] <wgrant> Occasionally somebody forgets to change it, however.
[06:58] <hypercube> ok, i guess it's good to check every time
[06:58] <hypercube> thanks!
[06:59] <wgrant> hypercube: There is an update-maintainer (I think that's it?) script to do it for you as required.
[07:04] <porthose> hypercube, check out ubuntu-dev-tools :)
[07:08] <hypercube> thanks, the wiki also mentioned update-maintainer.  just wanted to make sure i understood what's going on.
[07:27] <dholbach> good morning
[07:32] <porthose> dholbach, good morning :) Do you know if there will be a GPG key signing party at UDS?
[07:33] <dholbach> porthose: last time slangasek organised one
[07:33] <slangasek> aw man
[07:33] <slangasek> somebody else should do it this time :)
[07:39] <LucidFox> How do I make dch add new entries as lucid rather than karmic?
[07:43] <StevenK> LucidFox: -D lucid, from dch(1)
[07:45] <LucidFox> I mean automatically.
[07:45] <LucidFox> By default.
[07:46] <geser> LucidFox: edit dch and update the default for Ubuntu
[07:46] <dholbach> change it in devscripts? :)
[07:48] <LucidFox> Okay.
[08:11] <Unggnu> hi all
[08:12] <Unggnu> There is a package firefox-3.6 in the repository in Karmic. Is it planned to ship the 3.6 final after its release or is it just bogus?
[08:21] <micahg> Unggnu: there is no firefox-3.6 package in karmic
[08:23] <Unggnu> micahg, It has no package but if I enter "sudo apt-get install firefox" and press tab two times it is shown
[08:26] <micahg> Unggnu: do you have the ubuntu mozilla daily repo?
[08:38] <Unggnu> micahg, no
[08:40] <micahg> well, it won't install
[08:41] <Unggnu> micahg, I know, it has no packages associated but it is shown, even in an untouched VM of Karmic
[08:41] <Unggnu> that's why I am asking if there will be one :)
[08:41] <Unggnu> like in Jaunty with 3.5
[08:42] <micahg> well, it depends on what's decided about how firefox will be supported in stable releases
[08:42] <micahg> Unggnu: it most likely will not be through a firefox-3.6 package
[08:49] <Unggnu> micahg, ok, thx
[09:05] <LucidFox> Laney, the changelog for f-spot says "fakesync from Debian", but I don't see 0.6.1.4 in Debian. Is it from svn.debian.org?
[09:06] <directhex> ooh, a LucidFox
[09:07] <Laney> LucidFox: yeh
[09:07] <Laney> yeah, from git
[09:07] <Laney> unexpected transition stuff delayed it
[09:08] <LucidFox> directhex> Now I'll have to clarify to everyone that I had this username long before the naming of Ubuntu 10.04. :)
[09:08] <directhex> LucidFox, i wondered whether you were back with us to work on your namesake ;)
[09:10] <LucidFox> Back? I never left, it's just that my activity and interest fluctuate.
[09:10] <LucidFox> Right now I look at REVU and see packages untouched since the beginning of the year, and weep.
[09:11] <mok0> Karmic is getting a bad rap in El Reg: http://www.theregister.co.uk/2009/11/03/karmic_koala_frustration/
[09:12] <LucidFox> I'm tempted to just send all REVU packages for jaunty to the "needs work" bin.
[09:13] <LucidFox> Ah, the old kernel. A friend of mine had that problem.
[09:14] <mok0> More bad press: http://www.thelatestnews.in/another-failure-of-linux’s-karmic-koala/21261.html
[09:15] <LucidFox> "Linux's Karmic Koala"
[09:15] <mok0> Heh
[09:15] <mok0> Dunb
[09:16] <mok0> Well imho we need a revision of the semi-annual release dogma
[09:17] <LucidFox> I'm actually tempted to do a clean reinstall to hopefully get rid of small issues that have been bugging me in Karmic gradually updated from the unstable version since beta.
[09:17] <LucidFox> Like sound sometimes being off at start.
[09:17] <mok0> LucidFox: I've thought about doing the same thing
[09:26] <directhex> i've found karmic to be a pretty solid release. the bad press confuses
[09:32] <mok0> directhex: bad press is bad press
[09:35] <soren> Curiously, a friend of mine who's usually quite the problem magnet upgraded to Karmic and for the first time, everything works on his system. The upgrade was painfree and everything Just Works[tm].
[09:35] <directhex> i'm happy with karmic
[09:36] <mok0> Well, what can I say? Karmic is getting bad press. Perhaps it's unfair, but it's a fact
[09:36] <soren> I don't know.. It's getting kind of old. :)
[09:36] <directhex> I: Distribution is lucid.
[09:36] <directhex> I: Building the build environment
[09:38] <mok0> Linux used to be treated as "a hobbyist OS" by the press. Now they take us seriously, and we're being held to the same standards as MS and Apple, which is good
[09:39] <mok0> IMO the semi-annual releases worked well for a while when it came to defining Ubuntu, but that dogma needs to be revised now
[09:40] <micahg> the problem isn't the schedule, the problem is we can't get to all the bugs...we need more help
[09:40] <mok0> micahg:  we have the help we have
[09:40] <mok0> micahg: where are you going to get it from? Unless you start paying people?
[09:41] <micahg> no, people are out there that are willing to help, they just don't necessarily know they can
[09:41] <mok0> micahg: we need more time to get to the bugs :-)
[09:41] <micahg> mok0: more time = more bugs
[09:41] <mok0> huh?
[09:42] <micahg> there will be new/more bugs found with more time
[09:42] <mok0> micahg: ok, well better to find them and fix them before consumers do
[09:42] <micahg> unless you freeze the packages in which case, you end up shipping old versions of everything like debian
[09:43] <micahg> It's a problem with open source in general, not enough peoplepower
[09:43] <mok0> micahg: the bugs that are being complained about is not bugs in new versions of applications, it's how the OS interacts with hardware
[09:44] <micahg> but, if people realized that Ubuntu != M$ and people can actually help fix their own issues, we'd be very much ahead
[09:44] <mok0> micahg: if, if, if :-)
[09:45] <mok0> micahg: increasingly, Ubuntu is being held to the same standards as MS, with its 10's of thousands of highly paid developers... that's actually impressive
[09:45] <micahg> indeed
[09:46] <slytherin> Does anyone know if our buildd are ready for source format version 3?
[09:46] <micahg> Ubuntu kernel team has 30 members and 9k bugs of which 5k are new
[09:46] <mok0> They used to dismiss Linux as a toy OS
[09:46] <micahg> it's not surprising we can't keep up with the HW
[09:47] <mok0> slytherin: there was a message about that somewhere... in Debian
[09:47] <mok0> micahg: well, vendors are getting aware that they can avoid the MS tax
[09:47] <slytherin> mok0: I am talking about Ubuntu buildd.
[09:47] <mok0> slytherin: I know
[09:48] <mok0> slytherin: but someone wrote that it worked in Sid
[09:48] <mok0> slytherin: so it shouldn't be far off
[09:49] <slytherin> hmm
[09:49] <mok0> micahg: Re: getting more hands, perhaps making sure the ones we have stay on would be one important first step
[09:50] <mok0> micahg: as I see it, we are bleeding devs because ppl become frustrated and worn-out
[09:50] <mok0> The lack of communication from top to bottom is one important reason
[09:51] <mok0> There's all this rumor about archive re-organization and dissolving the MOTU team but nobody knows anything about it, and it's not discussed
[09:52] <micahg> mok0: yeah, that would be important
[09:53] <micahg> mok0: we already have the best community support and the best build infrastructure in the FOSS world AFAIK, it should only be a matter of time before more people start helping
[09:54] <hyperqbe> Hi all, I'm a wannabe developer, going through the docs right now.  I'm currently on karmic.  If I want to do bug fixes, I'm going to have to move to lucid, is that right?
[09:54] <mok0> micahg: Hmm
[09:54] <\sh> micahg, the best build infra has opensuse ;)
[09:55] <mok0> hyperqbe: no, you can work with any supported release
[09:55] <directhex> slytherin, no worky. i asked yesterday
[09:55]  * mok0 is looking forward to format 3
[09:55] <directhex> opensuse has some things we don't in its infrastructure. crucially, there's susestudio, and there's the opensuse build service's multi-distro support (ppa's are ubuntu-only)
[09:55] <hyperqbe> mok0: ok, so if i make a patch in karmic, but they're not gonna release it until lucid, they'll be able to apply my patch?
[09:55] <slytherin> directhex: So that means the packages in new format won't build right?
[09:56] <Laney> yes
[09:56] <Laney> bug 293106
[09:56] <slytherin> Wow, it is 'In progress'. :-)
[09:57] <directhex> Laney knew a bug number?
[09:57] <directhex> this is why he's an international man of mystery
[09:57] <mok0> hyperqbe: if the bug is important enough to pass the sru team (stable release updates) the fixed package moves to first *-proposed, then *-updates
[09:58] <mok0> !sru
[09:58] <hyperqbe> mok0: yeah, i'm just guessing that my first bug is not going to be that important. :)
[09:59] <mok0> hyperqbe: the main thing when doing an SRU is to patch the bug in the version already present in that release
[10:00] <mok0> hyperqbe: they are not so keen on package upgrades
[10:00] <mok0> hyperqbe: so often it's a matter of back-porting a fix
[10:01] <mok0> hyperqbe: those kinds of bugfixes get accepted without problems
[10:01] <mok0> hyperqbe: even if they're small :-)
[10:02] <slytherin> hyperqbe: Any bug with a working and tested patch is important. :-)
[10:08] <\sh> wasn't there a possibility to copy source packages from ubuntu archive to ppa
[10:08] <maxb> Kind of
[10:08] <mok0> \sh: what would be the point of that?
[10:08] <maxb> the relevant URL was blocked/hidden because it tended to OOPS because there are too many packages in the ubuntu archive
[10:09] <maxb> mok0: Easier than doing a sourceful backport if you know dependencies aren't an issue
[10:09] <mok0> ah, yes
[10:10] <maxb> Or for preserving the last version of something that was removed from karmic
[10:10] <maxb> which is why I copied sun-java5 into my PPA
[10:11] <\sh> maxb, how did you do it? somehow I don't see it on edge
[10:11] <maxb> The url is blocked
[10:11] <maxb> well, no, it's not, it's just not linked from anywhere
[10:12] <maxb> However the last time I told someone about it, a Launchpad developer told me off and asked me not to pass it around
[10:13] <maxb> You could do it via launchpadlib, I believe
[10:17] <hyperqbe> anyone want to help me review my first debdiff? It's a simple one to add a dependency.
[10:17] <dholbach> hyperqbe: post the link to it and somebody will have a look :)
[10:19] <\sh> maxb, anyways....launchpad has still some issues, not displaying lucid
[10:20] <maxb> I would be entirely unsurprised if Lucid wasn't turned on for PPAs yet
[10:20] <hyperqbe> ok, here's my debdiff... comments? http://eggiweg.org/scratch/mydebdiff
[10:21] <rowinggolfer> maxb, lucid is visible in my ppa.
[10:21] <rowinggolfer> I copied a package there
[10:21] <\sh> maxb, no it's not shown even for ubuntu on the overview pages of ubuntu packages
[10:21] <maxb> link pls
[10:21] <\sh> maxb, https://launchpad.net/ubuntu/+source/zend-framework
[10:22] <\sh> i see the latest release on the left, which is now the lucid version i just uploaded...but I don't see lucid itself on the overview
[10:24] <maxb> \sh: It's there... it's just in a ridiculous order.... look down!
[10:24] <\sh> micahg, you know that I'M trying to have zend-framework always latest for other releases the latest devel on lp:~zend-framework ;)
[10:25] <\sh> maxb, oh crap...I don't look for new releases at the bottom ;)
[10:25] <micahg> \sh: yes, that was when the builders weren't taking forever :)
[10:25] <slytherin> hyperqbe: What is the reason for adding this dependency? You should mentione that in changelog. The Ubuntu formato for auto closing the bugs is (LP: #xxxxxx).
[10:25] <micahg> \sh: can I ask you a Q about ZF?
[10:25] <\sh> micahg, sure :)
[10:25] <maxb> \sh: I'd regard it as a bug - how about you file it as such?
[10:26] <micahg> \sh: why don't we ship dojo in zf?
[10:26] <\sh> micahg, dojo is pita regarding packaging
[10:26] <micahg> at least until it's packaged
[10:26] <micahg> pita?
[10:26] <hyperqbe> slytherin: i mentioned the bug in the changelog using the convention i saw in the rest of the changelog.  I'll change it to say LP: # instead of closed: #
[10:26] <\sh> micahg, I have packages at hand...but the debian/copyright file is very large...and I don't have the time to get all the used license
[10:26] <\sh> s
[10:27] <maxb> hyperqbe: Closes: is Debian's convention, LP: is Ubuntus
[10:27] <micahg> ah
[10:27] <slytherin> hyperqbe: The convention you used is Debian's not Ubuntu's
[10:27] <micahg> \sh: can I help?
[10:27] <hyperqbe> got it, thanks!  anything else?
[10:28] <slytherin> hyperqbe: which ubuntu release are you targeting this for? karmic-updates or lucid?
[10:28] <\sh> micahg, well, sure...always :) dojo consists of more then some .js files...there is a .js compiler which needs to be packages as standalone...
[10:29] <hyperqbe> slytherin: hehe, well, i have no idea.  I just wanted to fix my first bug... don't really care if it goes into karmic or lucid.
[10:29] <micahg> ok, well, I'll ping you then when I'm ready to help package it, I filed an LP bug and linked to the debian bug for packaging dojo
[10:29] <micahg> \sh: ^^
[10:30] <\sh> micahg, I can send you my initial try version for the package...I think it's already in a good state...just update the dojo version
[10:30] <slytherin> hyperqbe: If you don't care then probably lucid. So you need to modify the changelog that way.
[10:31] <micahg> \sh: ok, sure
[10:32] <hyperqbe> slytherin: so i'm currently running karmic, which is why it showed up as for karmic.  is it recommended to upgrade to lucid to do this right, or can i just change the changelog to say lucid?
[10:32] <\sh> micahg, give me a sec and I push it into my lp:~shermann ppa ;)
[10:32] <micahg> do you have a bzr branch?
[10:32] <slytherin> hyperqbe: Just change the changelog. No one expects you to be running lucid at this point. :-)
[10:32] <micahg> \sh: no rush, I won't be able to do much with it till next month
[10:35] <\sh> micahg, if you want I can make you a team member of ~zend-framework :)
[10:36] <micahg> \sh: if you'd like...I'm happy to push the new versions for you
[10:36]  * micahg uses it at work
[10:36] <hyperqbe> slytherin: ok, i reuploaded the diff with those two changes... anything else, or should i just post it to the bug?
[10:36] <\sh> micahg, nice :) I would just like to copy the latest lucid package to the ppa...if this works out somehow...I'll have to ask on #launchpad
[10:36]  * micahg also discovered the get-orig-source in there
[10:37] <\sh> micahg, hehe..was annoyed of removing the externals manually
[10:38] <micahg> \sh: after you copy that, do you want me to push hardy-jaunty tomorrow?
[10:38] <micahg> or tomorrow night more specifically?
[10:38] <\sh> micahg, I hope it's possible to just copy from devel to the other release pockets...if not, we need to do that manually
[10:39] <\sh> micahg, you should now have ~zend-framework team rights :)
[10:40] <micahg> \sh: it seems that you can binary copy to another version
[10:40] <micahg> with the same version number though
[10:44] <micahg> \sh: I'm going to sleep, I'll check tomorrow night and upload the backported versions if they aren't there for 1.9.5
[10:45] <\sh> micahg, cool thx :) and good night :)
[10:46] <slytherin> Why is MoM down? Not all packages in Debian have switched to new source format. So those using old format should still be listed on MoM.
[10:50] <mok0> slytherin: probably MoM doesn't know about those packages
[10:50] <mok0> slytherin: there's likely to be a mix of source package formats from now on
[10:51] <slytherin> mok0: right, but I am assuming it should be easy to simply ignore the packages with new format and show packages that use old format.
[10:52] <mok0> slytherin: yeah
[10:58] <mok0> Whoa, over 900 comments in this /. thread http://linux.slashdot.org/story/09/11/03/2211231/Some-Early-Adopters-Stung-By-Ubuntus-Karmic-Koala
[10:58] <mok0> Many are hostile
[11:00] <directhex> ubuntu's not cool. slashdot's too-cool-for-school crowd run cool distros like arch
[11:00] <directhex> or is arch unfashionable now?
[11:01] <mok0> directhex: dunno
[11:01] <mok0> directhex: I guess you're only really cool if you build your own distro from scratch.
[11:07] <mok0> Very sober comment here: "Rants replacing Bug reports?" http://linux.slashdot.org/comments.pl?sid=1429898&cid=29971656
[11:12] <LucidFox> And now, time to wait for Debian sponsors to notice my RFS.
[11:17] <rowinggolfer> Newbie question. I push sources to launchpad, targeted at the intrepid release. They build without fail.
[11:17] <slytherin> LucidFox: for which package?
[11:18] <rowinggolfer> openmolar, in my ppa
[11:18] <rowinggolfer> if I build the packages locally,
[11:18] <directhex> man, what is it with free software and dentists?
[11:18] <rowinggolfer> on jaunty or intrepid, they fail to install due to "python-central"
[11:18] <rowinggolfer> directhex, lol.
[11:19] <slytherin> rowinggolfer: please do not split your questions on 3-4 lines unnecessarily.
[11:19] <rowinggolfer> slytherin, sorry.
[11:19] <directhex> rowinggolfer, python packaging practices tend to change around every now & again
[11:20] <LucidFox> slytherin> smplayer
[11:20] <rowinggolfer> directhex, to summarise my question - why do the same sources build working packages when the launchpad bots build them, but not when I do? Do I need to build them on an intrepid machine?
[11:20] <LucidFox> I uploaded 0.6.8-1 to m.d.n
[11:21] <slytherin> rowinggolfer: you need to build them in chroot
[11:21] <slytherin> either pbuilder or sbuild.
[11:22] <rowinggolfer> not dpkg-buildpackage ?
[11:22] <directhex> rowinggolfer, if the packasges are for intrepid, they'll likely only build in intrepid (e.g. in an intrepid chroot or VM)
[11:22] <rowinggolfer> directhex, ok. thanks.
[11:23] <slytherin> rowinggolfer: dpkg-buildpackage will build for your current system. It will not have correct dependencies for target system (intrepid).
[11:24] <LucidFox> Trying gnome-shell, it feels... heavy.
[11:24] <LucidFox> That is, there is noticeable lag in response time.
[11:24] <rowinggolfer> slythering, directhex - thanks. sorry for the long-winded question.
[11:35] <rowinggolfer> slytherin, directhex the package build fine in intrepid, and is installed and working. thanks.
[11:39] <slytherin> LucidFox: yes it is heavy. I reverted to good old two panel setyp. :-)
[11:41] <LucidFox> Some of the drag and drop is counterintuitive, too.
[11:43] <directhex> i'm on 1-panel-with-Do
[11:43] <directhex> not sure i trust things that rely on javascript
[11:44] <slytherin> and I don't like things that rely on hardware acceleration. That is why I don't have compiz enabled :-)
[12:18] <mok0> Yay I now have a lucid sbuilder :-D
[12:36] <ghostcube> hmm who is responsible for the ppc releases
[12:36] <ghostcube> :)
[12:36] <ghostcube> i have a bug
[12:40] <mok0> ghostcube: the ppc release is "unsupported"... which means "community supported"
[12:40] <mok0> ghostcube: report the bug on LP
[12:40] <ghostcube> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-r128/+bug/400864
[12:41] <ghostcube> its alreaqdy from another one
[12:41] <ghostcube> but no decisiions so far
[12:41] <ghostcube> i wanted to know if its maybe fixed
[12:41] <ghostcube> in 9.10
[12:41] <mok0> ghostcube: I see. One is enough :-)
[12:41] <ghostcube> :)
[12:42] <mok0> ghostcube: did it *ever* work?
[12:42] <ghostcube> i tried this first with 9.04 but the one there mentioned it did work flawlessly for him in 8.10
[12:42] <ghostcube> so i think yes
[12:43] <mok0> Oh, a regression :-(
[12:43] <ghostcube> i have this prob since 3 days i get an mac from an friend and wanted to install xubuntu and all works fine exept this r128 modul
[12:43] <ghostcube> i tried the fixes out in the wild but nothing helped
[12:44] <mok0> ghostcube: I can understand you're frustrated
[12:44] <ghostcube> nah not really frustrated i just promised him xubuntu is better than macosx9
[12:44] <ghostcube> and now iam not able to show him rofl
[12:44] <ghostcube> :D
[12:45] <ghostcube> so just interested in if it will be fixable
[12:45] <ghostcube> :)
[12:45] <ScottK> ghostcube: Generally TheMuso or NCommander are the two people best to discuss PPC issues with.
[12:45] <mok0> ghostcube: Hehe. Be careful what you promise. (I 'm also a Mac user)
[12:45] <ghostcube> hehe
[12:45] <ghostcube> ScottK: ok thx
[12:45] <mok0> ScottK: but this looks to be an X issue
[12:46] <ScottK> mok0: RIght, but if it's PPC specific, I'd start with them.
[12:46] <mok0> ScottK: yeah I guess
[12:47] <ghostcube> ok thx for the help guys i will talk to them then :)
[12:47] <mok0> ghostcube: good luck to you
[12:48] <ghostcube> thx :) i just started asking in ubuntu-powerpc
[12:48] <ghostcube> :)
[12:52] <slytherin> ghostcube: all the ati cards have same module these days.
[12:53] <slytherin> the driver name is ati.
[12:53] <ghostcube> slytherin: on pc yes
[12:53] <ghostcube> on ppc it loads r128
[12:53] <ghostcube> not ati
[12:53] <ghostcube> i tried no chance
[12:53] <slytherin> hmm surprising. But I can not confirm the bug as I have Radeon 9200
[12:54] <ghostcube> ok this is ati
[12:54] <ghostcube> for the rage ones there is an own modul
[12:54] <ghostcube> and this one is making truble somehow and if i disable fb it makes an xorg error for int10 modul
[12:54] <ghostcube> if i disable it it dosnt take care of disable int10 in xorg.conf
[12:54] <ghostcube> starts again
[12:55] <slytherin> ghostcube: have you tried using ati module instead of r128?
[12:55] <ghostcube> yep
[12:55] <ghostcube> ati loads then r128 loads
[12:55] <ghostcube> and ati gets kicked
[12:55] <ghostcube> i seen in xorg.0.log
[12:56] <ghostcube> i think some default settings may be wrong inside the modul
[12:56] <ghostcube> and it cant be changed somehow
[12:56] <ghostcube> i can update to 9.10 next days i think so
[12:56] <ghostcube> and look into 9.10
[12:56] <ghostcube> but this wont fix the jaunty problems for many ones
[12:56] <slytherin> ghostcube: check the file /etx/X11/xorg.conf.failsafe
[12:57] <ghostcube> must do if iam back at tis machine
[12:57] <ghostcube> at work now
[12:57] <ghostcube> but failsafe doesnt work too
[12:57] <ghostcube> i cant boot low grafics
[12:59] <slytherin> ghostcube: what I meant is check if failsafe configuration is forcing r128 module.
[13:00] <ghostcube> ahhh
[13:00] <ghostcube> ok i will do :)
[13:03] <ghostcube> thursday i will be back at the machine
[13:03] <ghostcube> i tell you then
[13:03] <ghostcube> so tomorrow
[13:04] <ghostcube> damn today is wednesday omg
[13:11] <slytherin> ghostcube: Whatever comments you have add them to the bug.
[13:11] <ghostcube> slytherin: i will do thx for the suggestions :)
[13:46] <ingenius1> Hi!
[13:49] <ingenius> I'm trying to port a debien package to 9.04, when I do "dpkg-buildpackage -rfakeroot" ... I have this error -> dh: --with quilt not supported or failed to load module Debian::Debhelper::Sequence::quilt
[13:50] <mok0> ingenius: it's probably in the new source package format
[13:51] <ingenius> aha ... and any way to change to old format ?? :)
[13:51] <mok0> ingenius: if you can unpack the source package, you can always rebuild it in the old format
[13:52] <mok0> ingenius: you may need to go back to basic unix tools, such as ar etc
[13:52] <mok0> ingenius: what's the package name?
[13:54] <ScottK> mok0: It's not the new source format it's needing a newer debhelper
[13:55] <mok0> ScottK: I see. I haven't played with the new format yet, but I'm curious
[13:55] <ScottK> The --with-quilt option was introduced after Jaunty.
[13:56] <mok0> ScottK: on dh ?
[13:56] <ScottK> mok0: Yes.
[13:56] <ScottK> I don't recall the version number.
[13:57] <mok0> ScottK: strange. That ought to require a bump in the compat number
[13:58] <ScottK> mok0: No, the package bug is to not have a versioned build-depend on a high enough debhelper version.
[13:58] <mok0> ScottK: yeah ok, that only cements my impression that debian/compat should be abolished
[13:59] <mok0> ScottK: it's useless if versioned depends are used instead
[13:59] <sebner> ScottK: quilt 0.46-7, dh 7.0.50
[14:00]  * mok0 goes looking for a package in format (3.0 quilt)
[14:00] <wgrant> mok0: quilt itself in sid.
[14:00] <mok0> wgrant: ah :-) thx
[14:01] <ingenius> mok0: this one -> http://mentors.debian.net/debian/pool/main/l/libsockets/
[14:02] <mok0> Heh it applies all patches when you dget it
[14:02] <ingenius> mok0: sorry but this is my first package ...
[14:02] <mok0> ingenius: np
[14:02] <mok0> ingenius: but that's not a new style source packagE??
[14:04] <mok0> ingenius: the .dsc file says: Format 1.0
[14:05] <ingenius> mok0: yes but in rules file say -> dh ${@} --with quilt
[14:05] <mok0> ingenius: ah yes... /me is being stupid
[14:05] <ingenius> sorry but my experience is making packages for gentoo  not for debian ...
[14:05] <mok0> ingenius: can't you just get rid of the --with-quilt stuff?
[14:06] <mok0> ingenius: perhaps I'm not too ingenious right now :-)
[14:06] <ingenius> hahahha
[14:07] <ingenius> Yes i can erase this --with-quild .. but i have another error ... in 9.10 idont have any problem but  i need it in 9.04 ...
[14:10] <mok0> ingenius: it has a lot of build dependencies
[14:10] <ingenius> mok0: yes ...
[14:10] <mok0> ingenius: try relaxing those
[14:11] <mok0> ingenius: it might just work
[14:21] <mok0> wgrant, is 3.0 (bzr) working?
[14:23] <JontheEchidna> What's the current policy on boost build-depends? Do we still want to specificly build-depend on the 1.38-dev packages?
[14:23] <Laney> ScottK: ^^^
[14:23] <wgrant> mok0: No. It's not supported by dpkg or dak, FAIK.
[14:23] <wgrant> mok0: But it's easy to support once dpkg does.
[14:23] <ScottK> JontheEchidna: For Karmic, yes
[14:23] <ScottK> For Lucid, TBD.
[14:23] <JontheEchidna> ok, I'll maintain the status quo then
[14:23] <mok0> JontheEchidna: The current boost is 1.40 so unless there are specific reasons to do so, I think we want to not use 1.38
[14:24] <JontheEchidna> ok, so I should bump it to 1.40 then
[14:24] <mok0> wgrant: I see
[14:24] <mok0> JontheEchidna: I think so, for lucid
[14:25] <ScottK> It'll be at least 1.40, so that's safe
[14:25] <JontheEchidna> ok, cool
[14:25] <Laney> what's wrong with using the unversioned one?
[14:25] <mok0> Laney: it's o.l.d.
[14:26] <Laney> easily fixed to not be isn't it?
[14:26] <mok0> Laney: boost is now versioned so they can live side-by-side
[14:26] <Laney> dunno how they are for backwards compatibility
[14:26] <ScottK> Laney: My view is that you don't want to change boost versions by accident.
[14:26] <mok0> Laney: That's exactly the reason. Boost evolves much faster than client apps
[14:27] <ScottK> Packages need to be rebuilt with the new version anyway, so best to explicitly say which.
[14:27] <ScottK> In Debian, with binary NMUs, they can point to the new version, rebuild everything, and then see what fails.
[14:27] <ScottK> In Ubuntu, we have to do sourceful uploads to rebuild anyway, so you may as well pick your boost version.
[14:29] <mok0> Biggest change in 1.40 is the build system I believe
[14:29] <Laney> thumbs up, makes sense to me now
[14:30] <mok0> The scrapped the awful jam build system:)
[14:30] <mok0> cmake is ... better
[14:31] <mok0> although it sucks too
[14:31] <mok0> :)
[14:32] <JontheEchidna> anything but autohell
[14:32] <JontheEchidna> and the progress indicators are quite nice too
[14:35] <mok0> JontheEchidna: I'm a HUGE fan of autotools actually :-)
[14:35] <JontheEchidna> heh
[14:37] <mok0> Of course KDE switched to cmake, the basterds
[14:38] <mok0> scons sucks even worse
[14:40] <mok0> There. I've said it. Let the flaming begin.
[14:42] <ScottK> \sh: Any reason you need to keep the Zend stuff in a PPA and we can't do official backports instead?
[14:42]  * kees agrees with mok0 :)  autotools > cmake > scon. even if autotools hurts
[14:43] <mok0> It can hurt sure. But it's made up of standard UNIX tools
[14:43]  * kees nods
[14:44] <kees> autotools hurts, cmake maims, scon kills. :P
[14:44] <\sh> ScottK, you can...I don't know the timeframe and what to do to request backports...if it's an automated task, go ahead pls :)
[14:44] <mok0> :-D
[14:45] <ScottK> New KDE releases with KDE3 and autofoo was hell.  With KDE4/cmake it's very easy in comparison.
[14:45] <mok0> ... so, can we upload Format: 3.0 (quilt) source packages now?
[14:45] <ScottK> mok0: No
[14:45] <ScottK> Well you can, but they'll get rejected.
[14:45] <mok0> Heh, just checked, it works fine in my jaunty sbuilder
[14:47] <ScottK> \sh: If it didn't take any packaging changes to backport it's just a matter of a bug filed against the relevant backports project, someone testing that it builds, installs, and runs, and a backporter (like me) giving it an ack.  Then an archive administrator has a magic script.
[14:47] <mok0> ScottK: that's because KDE insisted on having their own specialized versions of autotools, AFAIR
[14:47] <ScottK> Could be.
[14:47] <ScottK> I mostly notice the absence of pain.
[14:47] <mok0> :-)
[14:48] <\sh> ScottK, hehe..."runs" means backporter needs to have clue about zend-framework coding ;)
[14:48] <ScottK> \sh: If you tell me it runs, I'll believe you.
[14:50] <\sh> ScottK, k...for the next time :)
[15:02] <Laney> yay, gtk2hs built
[15:07] <bddebian> Heya gang
[15:09] <mok0> bddebian: it's been a while since gang was here :-P
[15:09] <bddebian> :)
[15:11] <iulian> Hey bddebian, mok0!
[15:11] <mok0> iulian: hi!
[15:15] <bddebian> Hi iulian
[15:28] <sebner> huhu bddebian iulian mok0
[15:29] <bddebian> Heya sebner
[15:30] <mok0> hiya sebner
[15:31] <geser> Hi bddebian, sebner, mok0, iulian
[15:32] <bddebian> Gah you guys are killing me this morning.. :)  Hi geser
[15:32] <Laney> hi bddebian!
[15:32] <mok0> Hi Laney, geser!
[15:32] <Laney> and the rest
[15:33] <Laney> ah mok0, a pleasure
[15:35] <bddebian> Heya Laney
[16:43] <mrayzenoss> So I've got a large application that needs some assistance in packaging: https://bugs.launchpad.net/debian/+bug/251404
[16:44] <mrayzenoss> we're looking for the best steps to make our build friendlier for packaging
[16:44] <mrayzenoss> We're getting to the latest Zope 2.12 and Python 2.6, but our build is currently a monolithic shell script that wraps Make
[16:45] <mrayzenoss> should we use autotools or a buildout?
[16:45] <Laney> using a normal build system will make life easier for packaging
[16:45] <Laney> autotools/distutils/...
[16:46] <mrayzenoss> that was our inclination, but a lot of Python stuff is done with buildout (especially Zope stuff)
[16:46] <Laney> if you know of any similar software then you can look at how that is packaged
[16:47] <mrayzenoss> yeah, we were looking for large Zope applications and came up a little short (LaunchPad?)
[16:47] <mrayzenoss> that is, LaunchPad runs on Zope
[16:48] <Laney> it's not packaged though
[16:48] <mrayzenoss> right
[16:53] <dcushman> Is there a "definitive" guide to creating Ubuntu focused apps? I'm starting a new project for a client who has happily targeted Ubuntu Karmic as the platform. App is python business focused. Haven't really chosen any implementation details. Looking for best practices to share with community. My google-fu is dredging up Hoary age documents.
[16:54] <dcushman> Gnome based desktop application.
[17:27] <XiXaQ> regarding ubuntu-restricted-extras. In Karmic, it doesn't recommend or require java. Still, the appcenter does say it will pull it in. Is this a package bug or is it meant to not pull in java?
[17:31] <jpds> XiXaQ: bug #359934
[17:33] <XiXaQ> thanks, jpds.
[17:59] <sebner> hihi geser, Sry I missed you :\
[18:02] <ScottK> mrayzenoss: From a Python perspective, distutils tends to work best with Debian style packaging.  Someone familiar with buildout and Debian packaging should be able to translate between the two relatvely easily, but AFAIK there's nothing automated.
[18:03] <ScottK> dcushman: You might look at the new Quickly project in Karmic.  In general for Python stuff if you use distutils for Python packaging, getting to a good Debian package is easy.
[18:09] <sebner> hihi geser, Sry I missed you :\
[18:12] <joaopinto> hello
[18:12] <joaopinto> what would be the best course of action to have libsdl upgraded on Lucid ?
[18:27] <ScottK> joaopinto: The best course is to get it upgraded in Debian and then sync/merge
[18:28] <joaopinto> ok
[18:29] <joaopinto> now I need to check how to achive it in Debian :P
[18:30] <joaopinto> we really need libsdl fixed
[18:46] <ScottK> joaopinto: Filing a bug in BTW with the needed diff for the debian dir for the new release is a good start.
[18:47] <joaopinto> ScottK, , I can't file a bug on Debian because I don't use it, alsot it might be related to PA, I have no idea how Debian stands with that
[18:48] <joaopinto> right now libsdl sound is unusable for random people
[18:48] <ScottK> Well if you can test build an update to their package in a chroot, that's problably good enough for a wishlist bug for a package upgrade.
[18:49] <joaopinto> I have checked the libsdl release notes and they did fixes related to ALSA and PA
[18:50] <joaopinto> ok, I will try it, this is really something important to fix for Lucid
[20:29] <serialorder> how often do you guys use a chroot environment? I have been wrestling with setting one up for a few days now but I am unclear how often it would be used?
[20:32] <av`> serialorder, a chroot build environment is used everytime you need to test whether a package builds fine or not
[20:32] <sebner> serialorder: depending on how often you contribute to ubuntu. If you are planning doing a lot syncs and merges you will need it a lot
[20:33] <serialorder> i know but that can be done with pbuilder
[20:33] <av`> serialorder, and it's pretty easy to setup :)
[20:33] <av`> serialorder, yes
[20:33] <av`> pbuilder creates for you a chroot environment if needed
[20:33] <av`> e.g if you use the --login flag
[20:35] <serialorder> but do you set up another chroot with schroot to login and use that for testing packages or do you just login and use the pbuilder environment ?
[20:35] <serialorder> I realise i could choose to do either but I am trying to get a sense for what other people like
[20:37] <av`> serialorder, I usually use a VM for direct tests and I build stuff with pbuilder or another build system hosted on my server
[20:37] <av`> never had to use schroot
[20:37] <av`> since tests that do not require X can be done into pbuilder with --login flag
[20:37] <av`> plus you can use X into a pbuilder too, but it's more complicated to set up
[20:40] <serialorder> av`, so for working with merges and syncs for lucid would you just use pbuilder?
[20:40] <serialorder> that is all i have done in the past but I wondered if there was a "better" way to do it
[20:41] <av`> serialorder, yes, and specific tests can be done using a VM or directly youy system if you've upgraded to lucid already
[20:41] <av`> * into your
[20:41] <serialorder> how do you set up a VM for lucid?
[20:42] <av`> install karmic and update distro in sources.list
[20:42] <av`> like alwais
[20:42] <joaopinto> serialorder, I prefer a schroot
[20:42] <av`> anyway I use another system to build stuff, which is like a simple buildd
[20:42] <joaopinto> serialorder, I have a script which does everythinf for you
[20:43] <av`> serialorder, it's name is debomatic
[20:43] <fabrice_sp_> I personally uses a schroot for dev purpose (merge, sync,, upgrades, bugfixing, testing, ..) and keep my main system cleam
[20:43] <fabrice_sp_> and sbuild for building
[20:43] <av`> fabrice_sp_, schroot allows you to use X?
[20:43] <joaopinto> it does
[20:43] <fabrice_sp_> yes
[20:43] <av`> cool, never tried
[20:43] <fabrice_sp_> only dbus failed with karmic
[20:44] <joaopinto> serialorder, check http://bazaar.launchpad.net/~debfactory-devs/debfactory/devel/annotate/head%3A/bin/schroot_build.py
[20:44] <fabrice_sp_> more lightweight than a full VM :-)
[20:45] <serialorder> joaopinto, this is the script you use?
[20:45] <joaopinto> yes
[20:45] <av`> serialorder, the buildd I use can be found at debomatic.debian.net
[20:45] <fabrice_sp_> arghh: http://patches.ubuntu.com/ is dead :-( This was the page I used to check sync request when modifications were done in Ubuntu :-(
[20:46] <av`> serialorder, http://debomatic.debian.net so you can click directly on it
[20:47] <av`> serialorder, apt-get source debomatic to know what's running behind it :)
[20:47] <fabrice_sp_> is there another way to check if a ubuntu modified package has been updated in Debian? (like the main page of MoM)
[20:47] <av`> fabrice_sp_, what about manually?
[20:47] <av`> fabrice_sp_, e.g PTS checks
[20:47] <av`> or I dunno if u-d-t has something for it
[20:48] <fabrice_sp_> yeah: I keep all the packages I uploaded, but it was easier to look after my name in MoM main page :-)
[20:48] <fabrice_sp_> (and quciker)
[20:48] <av`> yep, dunno how long till it gets open again
[20:50] <serialorder> thanks for the suggestions and advice guys
[20:52] <av`> serialorder, np, hope to see you around asking for some debdiff's review
[20:56] <serialorder> av`, i think i will be able to this time around, I was too busy for karmic but I merged like 12 packages for jaunty. I know that is not very many among this group but I was surprised by how many i managed to do =)
[21:00] <av`> :)
[21:04] <micahg> ping \sh re zend framework
[21:16] <cherva> anyone maintaining the nautilus package for 9.10 ?
[21:17] <ScottK> cherva: You probably want #ubuntu-desktop
[21:18] <cherva> ScottK: thanks
[21:30] <serialorder> joaopinto, if you are still there the script worked like a charm, once I added lucid the list of options. There was one issue, since I have my /home/user drive encrypted it would not show my files but i fixed that by explicitly binding it in /etc/schroot/mount-defaults
[21:31] <joaopinto> sebner, great :)
[21:31] <joaopinto> ops, serialorder :P
[21:32] <joaopinto> I didn't tested it with lucid yet, so that's good knews
[21:32] <joaopinto> erm, news
[21:34] <serialorder> is there something extra I need to do to run x apps? because I am getting this error: "Error: Can't open display: :0.0"
[21:36] <joaopinto> serialorder, xhost + on your host
[21:36] <joaopinto> to gran X access to the schroot apps
[21:37] <serialorder> joaopinto, thanks!
[21:37] <joaopinto> that was not required on Jaunty, something was changed on the X config
[22:09] <gaspa> geser: I may be wrong, but seems build_status.py doesn't work with py-launchpadlib shipped with karmic.
[22:13] <wgrant> That's right.
[22:13] <wgrant> There's an import change.
[22:13]  * wgrant finds it.
[22:14] <wgrant> gaspa: I've changed it to this:
[22:14] <wgrant> try:
[22:14] <wgrant>     from launchpadlib.resource import Entry
[22:14] <wgrant> except ImportError:
[22:14] <wgrant>     from lazr.restfulclient.resource import Entry
[22:15] <gaspa> wgrant: ah, thank you!
[22:16] <gaspa> wgrant: that-> http://qa.ubuntuwire.com/ftbfs/source/ is still with the old import
[22:17] <wgrant> gaspa: Right, that's running on Hardy. The one for the rebuild (which I've developed on karmic recently) has the new import.
[22:18] <gaspa> oh
[22:18] <gaspa> ok, never mind.
[22:19] <DktrKranz> wgrant, gaspa: with recent lazr.restfulclient there could be issues with unicode encodings
[22:20] <DktrKranz> I noticed that when packaging them in Debian
[22:20]  * gaspa reinstalls Hardy
[22:20] <gaspa> :P
[22:20]  * DktrKranz backports the whole stuff in Hardy
[22:22] <ajmitch> gaspa: be brave, go for lucid
[22:23] <gaspa> ajmitch: in these days I guess lucid have the same issues as karmic, at least :P
[22:23] <DktrKranz> naah, it's gonna be a LTS, I'd say lucid + 1 :)
[22:39]  * ajmitch doesn't want to think about how many problems there could be in supporting direct hardy->lucid upgrades
[22:51] <geser> ajmitch: just thing about the python upgrade
[23:04] <ajmitch> geser: hopefully that won't go too badly if squeeze is on python 2.6 by then as well
[23:07]  * ajmitch has lucid running inside vbox to keep updated & play with, plus a basic karmic install to clone & upgrade from
[23:07] <ajmitch> but most of the small problems in various universe packages will be hard to catch
[23:22] <Laney> hm
[23:22] <Laney> requestsync isn't finding a package from squeeze
[23:23] <Laney> try this: requestsync --lp gnome-do-docklets
[23:25] <Laney> did those messages get through?
[23:25] <directhex> Laney, works here, but assumes sid
[23:26] <Laney> directhex: works if I force unstable
[23:26] <jpds> Someone has to change ubuntutools/requestsync/lp.py
[23:27] <Laney> I assume it's due to this: https://launchpad.net/debian/+source/gnome-do-docklets/+publishinghistory
[23:27] <Laney> other package work well
[23:27] <directhex> Laney, weird... why's the data wrong?
[23:28] <Laney> dunno
[23:28] <Laney> to #launchpad!
[23:29] <directhex> but i am le tired!
[23:36] <jpds> directhex: Well, have a nap.