[00:35] <RAOF> essial: Welcome!
[00:35] <essial> Hello again
[00:36] <essial> i've been using linux since the early 90's, and now I think I have enough experience to be a good contributor to Ubuntu, since it seems to be one of the best distros out there
[00:36] <RAOF> Have you seen...
[00:36] <RAOF> !contribute
[00:36] <ubotwo> To contribute and help out with Ubuntu, see http://www.ubuntu.com/community/participate
[00:37] <RAOF> ?
[00:37] <essial> i've been traversing through it
[00:37] <essial> been going in circles though :)
[00:37] <RAOF> Right :).  Do you have some idea of where you'd like to help?
[00:37] <essial> my main thing is, at work, and most of my experience is with windows, and also with non-dist (aka, os development itself)
[00:38] <essial> but i'm moderately familiar with linux, as it has been my only OS for a few years now, and I've done work with Gtk, LibSDL, and have been practicing writing makefiles both manually and with autotools
[00:38] <RAOF> Right.  So, if you're comfortable coding & debugging, taking some of the apport backtraces on Launchpad and figuring out patches would be awesome.
[00:38] <essial> I know just about every language (with the exception of perl)... and to answer your question, No specific area
[00:39] <essial> see, thats why I need help, I have 0 experience 'debugging' in linux, I do it all the time in windows
[00:39] <RAOF> Failing that, much of the actual writing of _code_ happens upstream.
[00:39] <RAOF> Aaaah, right.
[00:39] <essial> but
[00:39] <essial> I don't mind doing anything really, I just want to help contribute in the most effective way possible
[00:39] <essial> even if it is not specifically code
[00:40] <essial> since I will need someone to help, if only a little, to get me started, I figure it best not to waste their time putting me in with an overcrowded group
[00:40] <lmr_> RAOF: Are you a MOTU already? Sorry for interrupting the conversation
[00:40] <essial> no problem lmr_
[00:40] <RAOF> Hm.  So, I find that the easiest way to contribute is to (1) Use Ubuntu, (2) find something that doesn't work like you'd like it to, (3) fix it ;)
[00:40] <RAOF> lmr_: Yup.
[00:41] <essial> I work better with lists :) Ubuntu is a large collection of things
[00:41] <lmr_> RAOF: essial: I've been trying to find out some time to help, I'd love to start packaging software for ubuntu
[00:41] <fmarier> How does one request a sync (from Debian unstable) for a package which has Ubuntu modifications that need to remain there?
[00:41] <fmarier> requestsync asks for a reason to remove the Ubuntu modifications...
[00:42] <ScottK2> fmarier: If the differences need to remain, it's a merge, not a sync
[00:42] <RAOF> fmarier: One doesn't.  One instead merges the Ubuntu changes into the new debian revision.
[00:42] <essial> RAOF: see things like that throw me off right now, so I need to be eased into the linux way of things :)
[00:42] <RAOF> essial: You can pick a package or group of packages that you're interested in and check out the bugs in Launchpad.
[00:42] <essial> so I guess step one is to create a user in launchpad, brb
[00:42] <RAOF> Or, you can find a specific upstream project that you're interested in, and join up.
[00:42] <ScottK2> fmarier: Prepare a debdiff from the new Debian revision to the needed Ubuntu revision attach that to a bug and subscribe ubuntu-universe-sponsors
[00:43] <fmarier> ScottK2: ok, I'll do that. thanks
[00:43] <lmr_> RAOF: I was thinking, since I work mainly with open source testing and I already contribute with an upstream test project, maybe there's a Ubuntu quality assurance/test team where my skills can be better used
[00:43] <RAOF> lmr_: Of course, at the moment what really needs to be done is to fix packages already in Ubuntu.
[00:44] <essial> perhaps help make rhythymbox not suck so much, as it seems to be what ubuntu thinks is the replacement for the superior xmms
[00:44] <lmr_> RAOF: Sure, that's what I meant, taking maintainership of software that's already packaged (orphaned maybe) would be great
[00:44] <essial> even though once it drops a stream, you have to restart it
[00:45] <RAOF> lmr_: I believe there is such a group, but I don't know for sure.  You could also help the iso testing team test the releases (alpha X, etc)
[00:45] <essial> and has no support for easy codecs, or whatever its called
[00:45] <RAOF> essial: If you're interested in coding, that'd probably be a nice patch to ease your way in :)
[00:46] <RAOF> Or were you describing xmms?  It's been some time since I've had to install any codecs :)
[00:46] <essial> the hard part is finding someone over there to help pull me in, well first things first, gotta find the project source page :)
[00:46] <essial> brb
[00:46] <lmr_> RAOF: Yeah, we do distro testing (the underlying system, kernel, filesystems, network) and have quite a bit of work on test automation
[00:47] <lmr_> RAOF: Which packages you take care as a MOTU? What other groups you're involved with?
[00:47] <RAOF> lmr_: I *know* that people do that for Ubuntu.  If you're capable of helping in that, which would be awesome, maybe you should hit the ubuntu-devel mailinglist.
[00:48] <lmr_> RAOF: Right, I see
[00:48] <RAOF> lmr_: We don't really have maintainers as such in Ubuntu.  I tend to fix up stuff that's broken for me.  I've also been lumbered with the Miro package, kinda by default.
[00:48] <mathiaz> lmr_: have you checked out the ServerTestingTeam ?
[00:49] <mathiaz> lmr_: since you've got some experience with automated testing, we'd love to know wheter the latest development version of ubuntu runs on different hardware
[00:49] <lmr_> mathiaz: No, I didn't. I suppose this is the page on the ubuntu wiki
[00:49] <mathiaz> lmr_: as RAOF mentionned, there is the iso testing team
[00:50] <mathiaz> lmr_: https://wiki.ubuntu.com/ServerTestingTeam
[00:50] <essial> gah
[00:50] <essial> rhythmbox is inside the gnomeSVN
[00:50] <essial> that'd explain why its still 0.11 :)
[00:50] <RAOF> Yes, but don't worry.  You can use bzr to work with it :)
[00:51] <essial> and hasn't had an update since december 21, 2007
[00:51] <RAOF> Really?  Wow.
[00:51] <essial> http://www.gnome.org/projects/rhythmbox/news.html
[00:51] <mathiaz> lmr_: you should also get in touch with the Ubuntu QA team - https://wiki.ubuntu.com/QATeam
[00:52] <RAOF> essial: Oh, right.  Hasn't seen a _release_ since the end of last year.  I suppose that is quite a while ago.
[00:52] <RAOF> If you're interested in C# and mono and such, banshee-trunk should be getting a preview release, and is a different media player thing, perhaps a bit more like iTunes.
[00:53] <lmr_> mathiaz: I've looked at the page. Do you have any idea where this server hardware comes from?
[00:53] <lmr_> mathiaz: Unfortunately the hardware I can't provide
[00:53] <essial> so is a seemingly desolate project a good place to start then?
[00:53] <lmr_> mathiaz: :D
[00:53] <essial> you talking to me RAOF about banshee
[00:53] <lmr_> mathiaz: In my case, all the hardware I use (power machines) comes from my employer
[00:53] <mathiaz> lmr_: this is hardware that people have access to
[00:54] <mathiaz> lmr_: most of them are through their employer I guess
[00:54] <lmr_> mathiaz: Hmmm, I see
[00:54] <mathiaz> lmr_: they can probably have access to them for a couple of hours to do some testing
[00:54] <RAOF> essial: I don't think rhythmbox is desolate in any way.  And, yes, I was talking to you about banshee.
[00:55] <essial> honestly they look very similar
[00:55] <mathiaz> lmr_: if you're interested in testing, we run iso tests before we release
[00:55] <essial> though functionality wise, banshee seems to be much further
[00:55] <mathiaz> lmr_: this is part of the iso testing team.
[00:55] <essial> will ubuntu even include that as a normal player you think?
[00:55] <essial> sorry for the questions but i'm starting with no knowledge of whats going on :)
[00:55] <RAOF> essial: Part of the thing is that rhythmbox is fairly stable.  It's in no way unmaintained, though; there've been plenty of recent commits :)
[00:56] <lmr_> mathiaz: Right, I'm checking where I would fit better
[00:56] <RAOF> ( See: http://bazaar.launchpad.net/~vcs-imports/rhythmbox/main/changes for such things )
[00:56] <mathiaz> lmr_: well - if you want to leverage your testing experience, the QA team is probably eager to hear from you
[00:57] <mathiaz> lmr_: lars is working on some automated testing of desktop application IIRC
[00:58] <lmr_> mathiaz: Sure, I'll be glad to help.
[00:58] <lmr_> mathiaz: We don't do much GUI testing, we do more kernel layer/command line user space utilities
[00:58] <essial> ok here's a good general question. Lets say I want to help develop banshee, so i go to the banshee page, click "developers"
[00:59] <essial> i see where to go to grab the source with svn
[00:59] <mathiaz> lmr_: that works also
[00:59] <mathiaz> lmr_: the server team would be a good place to start then
[00:59] <mathiaz> lmr_: https://wiki.ubuntu.com/ServerTeam
[00:59] <essial> do i then just click on "all current banshee bugs" and work on them?
[00:59] <essial> and what If I want to add new things, where would I post that?
[01:00] <RAOF> essial: Aaah, right.  Sorry, it's been a while since I needed to learn this sort of culture :)
[01:01] <lmr_> mathiaz: Thank you very much for your patience man ;) I'll get in touch with those guys
[01:01] <RAOF> essial: So, things that I would do: I'd subscribe to the banshee mailing list, possibly reading a bit of the archives too.
[01:01] <mathiaz> lmr_: great - I'm one of those guys - so you should hang out in #ubuntu-server
[01:01] <lmr_> mathiaz: Oh really? :) Nice
[01:01] <essial> yeah i'm subscribing to their list in a moment
[01:02] <essial> i just gotta get used to svn again... starteam made me lazy :)
[01:02] <RAOF> essial: You probably don't need to get used to svn if you don't want to.  bzr-svn should work nicely :)
[01:02] <RAOF> Of course, that requires you to learn the bzr VCS :)
[01:03] <bddebian> Heya gang
[01:03] <lmr_> essial: svn is pretty easy to get started with, don't worry
[01:03] <RAOF> essial: Then, I'd checkout the list of open bugs, yeah.  Probably starting with a gnome-love (one with a heart next to it) bug would be good.
[01:03] <essial> yeah i've read up on gnome-love
[01:03] <bddebian> Bye the time bzr finishes downloading you could learn svn ;-P
[01:03] <essial> should i use rapidsvn, or just svn
[01:03] <lmr_> essial: If you want, I can send you a quick reference that I put on my desk
[01:04] <RAOF> lmr_: Yeah.  It's _using_ svn to do non-trivial things that's hard :P
[01:04] <RAOF> bddebian: Hush!
[01:04] <bddebian> :-)
[01:04] <RAOF> bddebian: bzr is love!
[01:04] <lmr_> RAOF: I got your point, but the good thing is that we don't have to do non-trivial things frequently
[01:05] <RAOF> essial: There's also a banshee IRC channel.  Popping up in there might be a good idea, too.
[01:05] <essial> wee console scrolly
[01:05] <essial> popping
[01:05] <mok0> Hmm. Could someone explain how to interpret the "MoM" page? What are the colors? What is "Outstanding" vs. "Updated" merges?
[01:05] <essial> done grabbing svn
[01:05] <essial> er banshee
[01:06]  * RAOF has basically given up on any VCS that he can't make local commits in.
[01:08] <essial> now to figure out how to install it
[01:08] <essial> er compile it
[01:09] <RAOF> Yup.  Since we have a banshee package, pulling all the build-dependencies is (mostly) easy: you can run "sudo apt-get build-dep banshee" to install all the packages (our) banshee (package) needs to build.
[01:09] <StevenK> RAOF: Which leaves git, bzr and svn?
[01:09] <mathiaz> mok0: the colors are related to the last time a merge has been done
[01:10] <essial> its like i need to install autotools and run autogen
[01:10] <mathiaz> mok0: Outstanding means that the package hasn't been merge during this release cycle.
[01:10] <RAOF> StevenK: Which leaves git, bzr, mercurial.
[01:10] <mok0> mathiaz: ah, ok, because they are behind, too
[01:10] <mathiaz> mok0: Updated means that the package has already been merge at least once during this release cycle
[01:10] <StevenK> RAOF: I thought svn could do --local for commits
[01:10] <RAOF> Oh, maybe it can.
[01:11] <mathiaz> mok0: we try to merge each package at least once during the release cycle
[01:11] <essial> RAOF: were you talking to me about banshee?
[01:11] <RAOF> essial: Yes :)
[01:11] <essial> i don't want to much up my package tree too bad
[01:11] <essial> what is build-dep for
[01:11]  * mok0 thinks the key to the colors should be listed on MoM's web page
[01:11] <mok0> mathiaz: thanks
[01:11] <RAOF> StevenK: If you can, then "svn help commit" doesn't know about it.
[01:12] <StevenK> RAOF: I might not be remembering correctly
[01:12] <essial> i see the "configure build-dependencies for source packages" but does that mean downloading all .dev's?
[01:13] <essial> nice aparently i need 114 new packages :)
[01:14] <mok0> essial: you need to create a pbuilder
[01:14] <essial> meaning?
[01:14] <RAOF> mok0: Not for local development.
[01:14] <mok0> RAOF: if he want's to avoid installing 114 packages on his own system
[01:15] <essial> i don't mind as long as it doesn't bomb my dist
[01:15] <RAOF> essial: pbuilder is a tool which creates a clean build environment to build Ubuntu packages in.  If you're doing upstream development, it's probably more hassle than its worth.
[01:15] <essial> i have a very fast pc and connection
[01:15] <essial> i just don't want to reinstall ubuntu to update my packages :)
[01:15] <RAOF> The only thing that -dev packages use is disc space, which is cheap.
[01:16] <essial> i have over 1tb so
[01:16] <essial> i'll live
[01:17] <essial> aparently its done
[01:17] <essial> nice it took mono 4 seconds to crash on me :)
[01:19] <RAOF> Always fun.
[01:21] <essial> of course not a damn thing compiles :)
[01:21] <essial> i have more luck with C than C#, and thats scary *sighs*
[01:22] <essial> could have something to do with the error: Files in variable ASSEMBLY_CSFILES contains variables which cannot be parsed without path to the configure.in being set. ignoring such files
[01:24] <RAOF> Pastebinning the full output of autogen is likely to be helpful.
[01:24] <RAOF> !pastebin | essial
[01:24] <ubotwo> essial: pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the channel topic)
[01:25] <essial> thats most likely the problem, i didn't run autogen, just loaded the project
[01:28] <RAOF> essial: Ah, right.  The autotools foo is more likely to be buildable at any one time than the monodevelop project. :)
[01:29] <essial> and I hit my usual hurdle with trying to help.. version problems where it requires a version i cannot get without source
[01:29] <essial> ndesk-dbus must be >= 0.5, i have 0.4.2
[01:29] <essial> so tell me code gurus, how do I resolve without breaking my package tree
[01:29] <essial> :)
[01:31] <RAOF> Aaah.  ndesk-dbus 0.6.0 is in Hardy.  You are presumably using Gutsy.
[01:31] <essial> yup
[01:31] <ScottK2> essial: Work in a chroot.
[01:31] <essial> so what do I need to do in order to compile
[01:31] <mok0> essial: you need to create a pbuilder ;-)
[01:31] <RAOF> ScottK2: That's an excellent idea.
[01:32] <essial> so i gotta clone an entire system to compile a project?
[01:32] <mok0> essial: it takes about 3 minutes
[01:32] <essial> allright, well i'm assuming i will just create a folder and chroot into it
[01:32] <mok0> !pbuilder
[01:32] <ubotwo> pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
[01:33] <essial> reading, thanks!
[01:33] <azeem> essial: you've been "using linux since the early 90's", but never compiled a project?
[01:33] <mok0> mono is evil
[01:33] <RAOF> essial: Such is the way with developmnet code - particularly long-term development branches such as banshee-trunk.
[01:33] <essial> azeem: sure have
[01:33] <mok0> mono is evil and should be avoided
[01:34] <ScottK2> mok0: If you think that, just wait until you see moonlight
[01:34] <essial> ./configure --prefix = /usr/bin && make && make install works like a charm 99% of the time
[01:34] <mok0> moonlight is also evil
[01:34] <RAOF> mok0: Mono seems to be the thing most likely to allow me to, in some glorious future, not need to care that there's a C library for what I want but not a $LANGUAGE_OF_CHOICE library.
[01:34] <mok0> Imaging when M$ pulls the carpet and we have 1000 mission critical applications....
[01:35] <mok0> Imagine
[01:35] <essial> anyway, i'm not frustrated, i'll read the wiki and follow it
[01:35] <RAOF> mok0: No one seems to have convincing evidonce that this carpet exists.
[01:35] <mok0> It does
[01:35] <mok0> They've told us
[01:36] <RAOF> They've said "linux infringes patents" (which I assume is what you're referring to).  This is undobtedly the case.
[01:36] <ScottK2> RAOF: At the very least they've announced they have carpets that they won't say what it affects.
[01:37] <RAOF> There's probably a second 'u' in "undoubtedly". :)
[01:37] <essial> oh goody here it goes
[01:37] <ScottK2> Believing that none of those carpets affect Mono is an exercise in optimism at best.
[01:37] <mok0> ScottK2: they are patiently waiting
[01:37] <ScottK2> Sure
[01:37] <ScottK2> That's my expectation too.
[01:38] <mok0> gnome used to be a very nice C based system.
[01:38] <RAOF> mok0: Incidentally, http://people.freedesktop.org/~racarr/ms.gif
[01:38] <RAOF> But C is a crap language to write UIs in.
[01:39] <slangasek> haskell FTW
[01:39] <RAOF> Yeah!
[01:39] <mok0> RAOF: :-D
[01:39] <RAOF> I'm not saying that C is inherently bad, just that it's good at things which are nearly pointless on the desktop.
[01:39] <essial> C is good at starting words for example
[01:39] <essial> very bad at ending them
[01:40] <azeem> coc
[01:40] <essial> exactly
[01:40] <mok0> RAOF: Anyway, Miguel himself seems to have come to the conclusion that it might not have been a very good idea to introduce mono in gnome...
[01:41] <RAOF> As far as I'm aware, the only mono-dependency in Gnome is tomboy?
[01:42] <mok0> There's a couple more, can't remember which
[01:42] <RAOF> fspot, beagle, banshee, off the top of my head.  None of which are actually a part of Gnome.
[01:42] <mok0> ok, yeah those are the ones.
[01:43] <mok0> Oh, it's used in serpentine, that I have been merging
[01:44] <RAOF> Oh, really?  Wow.
[01:44] <mok0> or rather, a plugin, which creates a .dll
[01:44] <RAOF> You can write serpentine plugins in CIL?  Wow.
[01:45] <essial> should i do the pbuilder create --debootstrapopts --variant=buildd
[01:45] <RAOF> essial: You don't really need the buildd variant.  But something like that, yes.
[01:46] <essial> i'm still not quite sure what pbuilder does yet so :)
[01:46] <mok0> essial: basically, it creates a tarball of a system
[01:47] <mok0> essial: when building, it will unpack the tar ball in a chroot, copy the source package to it, and download the build-depends
[01:48] <RAOF> essial: For you, the interesting part is that you'll have a minimal Hardy system in a tarball.
[01:48] <essial> is hardy the codename for the dev of ubuntu, or just the name of the next version
[01:49] <mok0> essial, the tar ball will be ~80Mb
[01:50] <StevenK> essial: Hardy is code name for the next version.
[01:50] <StevenK> essial: Unlike Debian, where sid is always in development.
[01:51] <essial> ok i created the pbuilder environment, and added the hardy sources to the list
[01:51] <essial> now its saying apt-get source bc (which i'm assuming should be apt-get source get banshee)
[01:51] <essial> it doesn't say anything about chroot
[01:52] <mok0> essial: are you  building your package?
[01:52] <essial> I'll have to compile it so I assume so
[01:53] <StevenK> essial: No get, 'apt-get source banshee'
[01:53] <mok0> essial: did you do "pbuilder --build <yourpackage.dsc> ?
[01:53] <essial> all i've done thus far is pbuilder create ....
[01:53] <essial> and added the entry to my deb-src list
[01:53] <mok0> essial: it doesn't do the chroot when it creates
[01:53] <essial> i did it in my normal environment
[01:54] <essial> so i'm assuming i need to chroot before making that mod
[01:54] <mok0> essial, pbuilder --login
[01:54] <RAOF> mok0: He's not actually building a package.  He's trying to do some upstream banshee development :)
[01:55] <mok0> Aha
[01:55] <essial> and learning everything on the way up
[01:55] <mok0> In other words, having fun :-)
[01:55] <essial> ok i sudo pbuilder --login, it extracted the tarball and i'm assuming now i'm sitting at the chroot i just built
[01:55] <RAOF> Yup.
[01:55] <essial> so NOW i add that line to the sources and apt-get the source
[01:55] <mok0> essial: you might want a --save-after-login switch on there too
[01:56] <essial> what does that switch mean
[01:56] <essial> keep any file changes i presume
[01:56] <mok0> essial: because the normal behaviour is to zap the chroot
[01:56] <mok0> essial: yes
[01:57] <essial> ok so I understand the basics of pbuilder, it lets you compile without fscking up your current system with beta packages
[01:57] <essial> correct?
[01:57] <mok0> yes
[01:57] <essial> see, i'm learning :)
[01:57] <mok0> cool, huh?
[01:57] <essial> yeah that makes sense
[01:57] <essial> can you move files in and out of the chroot
[01:57] <essial> (into the host environment)
[01:57] <mok0> essial: ... and install all the build-depends
[01:58] <mok0> (it does that automagically)
[01:58] <RAOF> essial: You can, yes.  You can mount /home in your pbuilder chroot.
[01:59] <RAOF> I forget quite how to do that, though.  There's some configuration as to what you actually want mounted inside the chroot.
[01:59] <essial> changing packages to hardy
[01:59] <mok0> essial: didn't you create the pbuilder from hardy packages?
[01:59] <essial> i guess not
[01:59] <essial> remember i've never heard of pbuilder until 15 minutes ago
[02:00] <essial> --variant=hardy ?
[02:01] <essial> ah
[02:01] <essial> --distribution=hardy
[02:01] <essial> or not
[02:02] <mok0> essial: yes, yes
[02:02]  * essial sighs.. not working
[02:02] <essial> sorry I know i'm being a pain
[02:02] <essial> sudo pbuilder create --debootstrapopts --distrobution=hardypbuilder remove
[02:03] <essial> er -remove
[02:04] <mok0> pbuilder --create --distribution=hardy
[02:04] <mok0> pbuilder --update --distribution=hardy --override-config
[02:06] <essial> ah the = was throwing it off
[02:06] <essial> next question, is it always only one pbuilder environment or do you ever want more than one normally
[02:07] <mok0> essial: you can have as many as you want, but you need to set up the .pbuilderrc file to handle it sensibly
[02:08] <protonchris> Which channel the best place to ask about the ubuntu-release team?
[02:09] <mok0> essial: there's also a script called pbuilder-dist that can help you with having several pbuilders
[02:09] <essial> ok well pbuilder is up and running, gotta find the name of the hyena package now
[02:10] <mok0> essiel, there's a bunch of useful stuff in ubuntu-dev-tools
[02:11] <mok0> Well, time to go to bed for me. See you later guys!
[02:12] <essial> aparently banshee isn't in the normal sources
[02:16] <essial> ok i'm getting the hang of it
[02:17] <RAOF> essial: Hm.  Banshee is in Universe.  I'm not sure if that's enabled in a default pbuilder setup.
[02:17] <essial> i'm testing building gedit since i know that will be simple to do
[02:17] <essial> then i'll add universe
[02:17] <RAOF> Right, that might be a good idea :)
[02:17] <essial> apt-get build-dep gedit worked :)
[02:18] <essial> and apt-get source gedit pulled the sources into home so
[02:19] <essial> heres my question RAOF: is the apt-get source getting the latest source dist, NOT the svn dist?
[02:19] <essial> i'm assuming so
[02:19] <essial> in other words should i only apt-get build-dep gedit, THEN just svn gedit
[02:21] <RAOF> Yes.
[02:21] <essial> well i compiled gedit, jsut can't run it for obvious reasons :)
[02:21] <RAOF> apt-get source gets the "source package" for the package in the repositories - the upstream tarball that is the code + some metadata about how to build it & such.
[02:22] <essial> last question: i just complied gedit in a pbuilder console
[02:22] <essial> how am I supposed to test it?
[02:22] <essial> just copy it over to a local dir?
[02:22] <essial> or is there some way to run a shell X in a window
[02:23] <RAOF> You should be able to get X in the pbuilder environment, but I'm not sure how.
[02:23]  * essial sighs
[02:23] <Hobbsee> copying .Xauthority in there, iirc
[02:24] <RAOF> See!  People who know more than me :)
[02:24] <essial> so should I just install a hardy live install then?
[02:24] <essial> because it doesn't even have X or gnome in the chroot
[02:24] <essial> i'd have to re-get all of those packages
[02:25] <essial> it'd be just as quit to re-install with hardy and have it just work :)
[02:25] <essial> *easy
[02:25] <RAOF> If Hobbsee is right, copying the .Xauthority file from your home directory should allow apps to run on your X server.
[02:27] <RAOF> Other options include running Hardy in a VM, or having a full hardy install.
[02:27] <superm1> or just xhost +, DISPLAY=:0 app
[02:28] <RAOF> Sorry, it seems that Banshee wasn't such a good starting point!
[02:40] <squentin> essial: you can also install the needed libraries in a folder and set some environment variables so it is found
[02:41] <squentin> I'm just not sure what env variables, at least PKG_CONFIG_PATH and LD_LIBRARY_PATH
[02:41] <crimsun> xauth is generally preferable to xhost.
[02:42] <crimsun> or, ssh -Y
[02:42] <emgent> heya crimsun :)
[02:42] <crimsun> hi emgent :)
[02:45] <superm1> but for the purposes of a pbuilder for someone new, it's simplicity
[03:10] <essial> hey wouldn't it be just as easy to install a full dist inside of vmware?
[03:12] <RAOF> It might be, yes.
[03:13] <RAOF> If you happen to already have vmware (or some other virtualisation jobby) set up.
[03:13] <essial> is there a hardy cd or should i just base install and enable hardy sources
[03:13] <ScottK2> You can do either
[03:14] <ScottK2> One advantage of the pbuilder approach is you always know you are starting with a clean chroot.  You can do that in a virtual environment, but you do need to rememberto do it.
[03:14] <essial> i can just save a copy of the built system
[03:14] <essial> but then x and everything runs out of the box
[03:15] <ScottK2> Yes.  You can
[03:15] <essial> cool well that will make things much nicer
[03:15] <essial> do you guys run hardy for your main system?
[03:16] <essial> and to answer your question RAOF: yes, I have vmware as I do os development from time to time
[03:17] <ScottK2> essial: I've got several machines.  The one that runs Hardy is just for development and testing.
[03:18] <essial> torrents are awsome :) its only pulling 500kb/sec but thats better than the 90 the server was doing
[03:19] <RAOF> I do use hardy as my main system.
[03:20] <RAOF> It means that I hit bugs more often, so I'm more motivated to fix them ;)
[03:20] <essial> perhaps i should do so too then
[03:20] <RAOF> It'll *certainly* force you to learn about apt ;)
[03:20] <essial> that would allow me to easily develop native right?
[03:20] <essial> i know how to use apt-get and such
[03:21] <essial> i'm not afraid of the console, believe me
[03:21] <essial> i just have to learn the new stuff.. i use to use emerge and friends
[03:21] <RAOF> Running hardy is an exercise in being certain that the packages apt wants to remove won't seriously annoy you.
[03:21] <essial> it was always funny getting the base system running, then calling "emerge gnome" and watching it compile like 350 packages
[03:22] <essial> what do you mean RAOF
[03:22] <emgent> Fujitsu, ping
[03:23] <RAOF> essial: Well, packages don't necessarily build in the right order, so new packages appear with unmet dependencies, which apt will then want to uninstall on dist-upgrade, or suchlike.
[03:23] <essial> so can't I just go to package manager and just update individual packages?
[03:24] <essial> with "mark all upgrades"
[03:25] <emgent> Fujitsu, why you dont use patch system in bug #191488 ?
[03:25] <ubotwo> Launchpad bug 191488 in mplayer "[mplayer] [DSA-1496-1] several buffer overflows" [High,In progress] https://launchpad.net/bugs/191488
[03:25] <RAOF> It's just a bit more hit-and miss.
[03:25] <emgent> can i work on this bug for add patches with patch system?
[03:25] <RAOF> essial: With sufficient caution and a fair knowledge of the internals Hardy will only be unusable a couple of days in the dev cycle, give or take.
[03:26] <Fujitsu> emgent: Only Dapper has a patch system. Feisty and Gutsy are maintained in bzr.
[03:26] <essial> 760kb/sec..
[03:27] <essial> RAOF: when the new ubuntu version is completed, do old versions upgrade easily, or must you download and install the new iso
[03:27] <emgent> uhm ok Fujitsu
[03:27] <RAOF> essial: Upgrades are supported.  See, for example...
[03:27] <RAOF> !upgrade > essial
[03:28] <Fujitsu> emgent: Do not upload a new debdiff for feisty or gutsy unless you also have a bzr branch with those changes.
[03:29] <emgent> Fujitsu, sure np
[03:29] <essial> they really should make contributing to linux a lot less painful :)
[03:30] <essial> i guess thats one weakness to a package-tree style system
[03:30] <RAOF> essial: I'm not sure that it's actually painful, it's just a different culture.
[03:30] <essial> well I guess i need to buy some gloves and grow my chin hair out more
[03:30] <essial> :)
[03:30]  * RAOF suggests white kid gloves.
[03:30] <essial> i'll figure it out, i really do want to contribute
[03:31] <essial> 80% on the cd
[03:31] <essial> i'm just going to nuke my install, its no big deal
[03:31]  * essial has three hard drives, one for windows, one for data, and one for linux
[03:32] <essial> I must say though, I am impressed with how far wine is progressing
[03:32] <essial> I poped in the orange box cd, ran the setup, installed steam and the games, downloaded the updates, and everything ran with 0 problems
[04:27] <LaserJock> is there any good tool for tracking memory leaks?
[04:27] <nixternal> valgrind
[04:29] <RAOF> As long as it doesn't SIGILL on AMD64 :)
[04:29] <essial> hey
[04:29] <LaserJock> hmm, I'm not sure how to find what app to run valgrind on
[04:29] <essial> I'm on the beta now, it looks awsome, but now i get "Error: aclocal version 1.9 or better is required to configure banshee" :(
[04:30] <LaserJock> my laptop's just using too much memory
[04:30] <LaserJock> but I can't pinpoint an app that's doing it
[04:31] <RAOF> essial: You probably need to install automake?
[04:32] <RAOF> LaserJock: Can't top/htop/gnome-system-monitor help there?
[04:32] <LaserJock> they don't seem to
[04:32] <LaserJock> it seems like the sum of the apps mem usage doesn't agree with the total used
[04:32] <RAOF> Death by a thousand cuts?
[04:32] <LaserJock> perhaps
[04:33] <LaserJock> I go from 250MB usage at startup to 500MB after a day or two
[04:33] <LaserJock> with no apps open
[04:34] <essial> i thought linux was designed to use all of your ram always
[04:34] <essial> no sense freeing ram unless you need to
[04:34] <LaserJock> well, that is true
[04:34] <essial> thats why apps start up faster after the first time through
[04:34] <LaserJock> but if it's holding on to ram it shouldn't I'd like it to not
[04:35] <essial> and I know caching is the vast majority of my ram
[04:35] <essial> my 2gb of ram fills up to 99% within a day or two
[04:35] <essial> but 1.4gb of it is cache
[04:35] <LaserJock> oh, I'm not talking about cached memory
[04:35] <essial> well the system monitor should show memory usage
[04:35] <LaserJock> I'm talking about used memory
[04:36] <RAOF> There aren't some processes from other users being missed?
[04:36] <essial> YAY banshee compiles
[04:36] <LaserJock> no other users
[04:36] <essial> woo
[04:36] <LaserJock> and I'm looking at all processes
[04:37] <LaserJock> I don't know, it's probably not a big deal, it's just annoying that I don't know where it's going
[04:37] <essial> OMG
[04:37] <essial> holy hell they made some changes to the system monitor
[04:38] <RAOF> Drivers could concievably leak memory not accounted for anywhere?
[04:40] <essial> grr DapCore of course refuses to compile
[04:40] <essial> everyting else works though :)
[04:41] <LaserJock> ok, so if I add up all the processes >=1MB usage I get 312MB and I've got 512MB used
[04:41] <RAOF> You probably can't squirrel away 200MB in tiny processes...
[04:41] <LaserJock> and that's with about 1/2 since last reboot
[04:42] <RAOF> 1/2?  Half a day?  Half a week?
[04:42] <LaserJock> day
[04:42] <LaserJock> sorry
[04:44] <RAOF> Hm.  Well, my amd64 hardy web/mythtv/pulse/irssi server has been up for 26 days now, and it's at 600MB usage, which seems not unreasonable.
[04:45] <essial> well good news is i could compile banshee
[04:45] <essial> the bad news is MonoDevelop refuses to compile it
[04:46] <RAOF> That's not uncommon.
[04:46] <superm1> RAOF, you haven't been seeing any memory leaks in mythbackend have you ?
[04:46] <superm1> anything excessive at least...
[04:46] <superm1> there was a report of UPnP having fun
[04:47] <RAOF> I haven't.  Or, at least, the leaks have been below 10Mb/day or so :)
[04:47] <superm1> na, this was like 1200 in a day
[04:47] <RAOF> Then again, my mythbackend doesn't see a huge load.
[04:48] <superm1> yeah neither did his
[04:48] <superm1> it was just UPnP deciding to leak and leak and leak
[04:49] <RAOF> Thinking of which, any joy making my laptop's Totem an awesome upnp mythtv frontend? :)
[04:50] <superm1> yeah its all there except for the UPnP code to find your backend nicely
[04:50] <superm1> i've got the package in debian
[04:50] <superm1> but i couldnt get the patch to build on totem
[04:50] <RAOF> Wicked.
[04:50] <superm1> or totem to build at all for that matter
[04:50] <RAOF> Less wicked.
[04:50] <superm1> so at this point if u put the stuff in gconf-editor, it works
[04:50] <superm1> but the auto detect stuff isn't there yet
[04:50] <RAOF> Again incidentally, Gloss looks cool.  I'll help you package it for Intrepid if you like :)
[04:51] <RAOF> Right.  Which requires me to dig up all that config stuff.
[04:51] <superm1> well if it's ready for intrepid
[04:51] <superm1> but yeah, help appreciated either way
[04:51] <superm1> sometime during interpid time i'm going to revamp all the packaging for myth-*
[04:51] <superm1> it's turned into a cobbled complicated mess
[04:51] <superm1> so it needs some cdbs loving
[05:17] <ethana2> ..is firefox3 beta4 on it's way to repos?
[06:47] <dholbach> good morning
[06:48] <siretart> torkel: can you give me a list of files you had to remove?
[06:48]  * dholbach hugs siretart
[06:49]  * siretart hugs dholbach back! :)
[06:49] <dholbach> siretart: how are you doing?
[06:50] <siretart> dholbach: I'm about to leave for the office
[06:50] <dholbach> siretart: have a great day then! :)
[06:53] <siretart> cu in about an hour! :)
[06:56] <torkel> siretart: resolv.conf* and mtab* (not sure if you have to remove the last one if you add -n to romountopt)
[06:57] <torkel> siretart: the live kernel is a -11 though. I have no idea if they have changed anything in aufs in -12.
[07:55] <siretart> torkel: ah, thanks. will try that
[07:56] <siretart> dholbach: well, we're more or less finished with the move, but we need to finish the old flat
[08:03]  * dholbach hugs siretart
[08:03] <dholbach> siretart: all the best with that!
[08:04] <siretart> I really expect I'll can invest more time into intrepid. The last 6 month haven't been funny for me workwise
[08:04] <siretart> I'll tell you when I see you next time
[08:06]  * dholbach hugs siretart :))
[08:07] <siretart> :)
[09:59] <DaveMorris> who can I poke to get my patch for bug #195433 which I uploaded on 25/2
[09:59] <ubotwo> Launchpad bug 195433 in opensg "libopensg-core-dev is missing dependices which are called on in the pkg-config file" [Undecided,Confirmed] https://launchpad.net/bugs/195433
[10:02] <rexbron> jcastro: Hey Jorge, have you had any responces to my request yet?
[10:03] <YokoZar> dholbach: I have a sponsored upload with my name attached to it now, would reapplying to MOTU now be a good idea?
[10:21] <dholbach> YokoZar: your /+packages page still has only four entries - who did the sponsoring? - did you use  http://wiki.ubuntu.com/SponsorshipProcess ?
[10:30] <\sh> siretart: what must I do to enable qt-faststart tool in ffmpeg package?
[10:32] <\sh> dholbach: /me sponsored the last wine upload
[10:52] <YokoZar> dholbach: \sh did
[10:54] <\sh> YokoZar: I think what dholbach meant is that your list of packages is still not enough...maybe you should start working on dholbachs "really-fix-it" bug list ;)
[10:55] <YokoZar> No what he means is that my launchpad page still doesn't show Gutsy/Hardy Wine packages
[10:55] <YokoZar> Also I closed a couple of bugs from that list ;)
[10:55] <dholbach> yeah that's really weird
[10:55] <dholbach> if you did an upload it should show up in that list
[10:56] <YokoZar> Maybe it's because he added one of his own changes to mine in the same push
[10:56] <\sh> regarding -changes scotts name is on it
[10:56] <dholbach> maybe best to ask in #launchpad if anything goes wrong there
[10:56] <\sh> YokoZar: no...it parses changelog and there is your name
[10:57] <\sh> YokoZar: I never touched your debian/changelog tag line..and debuild -S -sa -k<my gpg key> doesn't change it magically
[10:57] <YokoZar> hmm
[10:57] <\sh> YokoZar: regarding my +packages list last wine is 0.9.56
[10:59] <Mez> \sh, you're the wine expert here right#?
[10:59] <dholbach> Mez: YokoZar is
[10:59] <\sh> Mez: yokozar is
[10:59] <\sh> YokoZar: I found the mistake
[10:59] <Mez> YokoZar / \sh - is it possible to have something installed system wide for wine (not using ~/.wine)
[10:59] <\sh> YokoZar: please add your ubuntu.com address to LP
[11:00] <YokoZar> Mez: Not yet.  To do that Wine would need to support registries in multiple places
[11:00] <YokoZar> \sh: Oh I might have an old key up there that didn't have the ubuntu address yeah
[11:00] <\sh> YokoZar: that's why it's not showing up
[11:00] <\sh> lunch
[11:01] <Mez> YokoZar, :( I want to set something up so that I can see if I can get a wine install of winrar ...
[11:01] <achadwick> \sh: sort of. Wine mostly doesn't care if a file is a symlink if it doesn't have to write to it
[11:01] <Mez> (they provide a package, but it'd be nice if you could apt-get it)
[11:02] <YokoZar> Mez: If the app has no registry entries (ie, a "portable" app), this is much easier
[11:02] <Mez> YokoZar, how can I tell if it has registry entries?
[11:03] <YokoZar> dholbach: looks like a dupe launchpad account was made: https://edge.launchpad.net/~scottritchie-ubuntu/+packages  (I'm merging it in now)
[11:03] <YokoZar> Mez: One way to try is to install it into one .wine, rename .wine, copy the folder over manually, then see if it runs
[11:04] <YokoZar> copy over manually into a new (clean) .wine that is
[11:04] <achadwick> So you can make a WINEROOT (like ~/.wine) for each user with cp -rs, then enumerate what your win32 binary needs to write to, and replace those symlinks with real files
[11:06] <Mez> YokoZar, what do I copy over - the drive_c?
[11:07] <YokoZar> Mez: No, just the application you're testing.  Maybe drive_c/program files/winrar or something
[11:08] <Mez> YokoZar, it was wiped anyways
[11:08] <Mez> It does seem to have registrey files, but doesnt seem to need them (except for registering)
[11:10] <YokoZar> Mez: another possible hack is modifying wine's system.reg file with what you need (all this is used for is the default registry at wineprefixcreate time, ie when making .wine for the first time)
[11:10] <YokoZar> dholbach: https://edge.launchpad.net/~scottritchie/+packages  is good now :)
[11:13] <Mez> YokoZar, I just tried running it without registry stuff, and it created that registry stuff.
[11:14] <Mez> YokoZar, what about installing it to a random directory, and then having it run from there?
[11:14] <Mez> (as it creates what it needs, and will just create new stuff when a new user runs it)
[11:14] <YokoZar> Nice, it's ideal when apps remake the registry stuff they need.  That way you could run them from wherever.
[11:15] <YokoZar> So, yes, it could be packaged fairly straightforwardly then (unless it needs to write to it's own folder)
[11:15] <Mez> YokoZar, it'd probs need some hacking with the script...
[11:15] <YokoZar> Well yeah
[11:15] <Mez> seeing as it wants to put everything in ~/.winrar
[11:16] <YokoZar> Really?
[11:17] <Mez> YokoZar, yup
[11:17] <Mez> (It's derived from the picasa scripts)
[11:18] <Mez> export WINEPREFIX=$HOME/.winrar
[11:18] <YokoZar> Picassa uses its own internal Wine, not the system one
[11:18] <Mez> lol - well that makes things nice and easy
[11:18] <YokoZar> So it's running it's own separate wineserver and registry and everything
[11:19] <Mez> ah, fuck... I didnt notice that
[11:19] <Mez> yeah it is
[11:19] <Mez> :(
[11:22] <Mez> YokoZar, which I presume means it'd be a pita to get them to accept?
[11:22] <Mez> (though, to be fair, it could mean that I can use a single registry for it
[11:22] <YokoZar> Mez: eh?  what do you mean accept here?
[11:22] <Mez> YokoZar, I dont know - my brain isnt working
[11:23] <YokoZar> A proper Ubuntu package for any Windows application would use the system Wine, I think.  At least one we supply.  Google ships their own internal one, inefficient as it is, since users so frequently change their system Wine.
[11:24] <Mez> YokoZar, yeah, but i'm unsure as to whether this'd work with the system wine
[11:25] <YokoZar> You could just try the procedure I gave above with a downloaded winrar installer and see if that breaks anything
[11:25] <YokoZar> (namely, if the app can reinstall its registry entries when they're missing or if it relies on the installer to do that)
[11:26] <YokoZar> Also if the app can run from a read-only directory
[11:26] <Mez> It has a sort of "in the middle" application that runs/installs winrar
[11:26] <Mez> It's kind of strange
[11:37] <YokoZar> Is there any place to get statistics on how often particular packages are downloaded / how many users total there are?
[11:37] <YokoZar> Other than the "stars of popularity" in gnome-app-install I can't really find anything concrete
[11:38] <\sh> YokoZar: if then on popcon.ubuntu.com
[11:38] <\sh> YokoZar: but no real numbers...
[11:40] <YokoZar> intresting, 165k wine users
[11:40] <\sh> YokoZar: it's inaccurate...all people who are not enabled popcon are not matched
[11:40] <\sh> s/are/have/
[11:41] <YokoZar> True.  Popcon is a default checkbox at install time, right?
[11:41] <Laney> It's disabled by default
[11:41] <Laney> And hidden under "Advanced" on the last page of the installer, AFAIK
[11:41] <YokoZar> Ahh, that changes things a bit.
[11:41] <\sh> YokoZar: but the impact of the broken wine on a devel release...was enough for me to tell, that people declare wine as important....
[11:42] <\sh> (mostly to play CS on linux ;))
[11:42] <YokoZar> Haha yeah when Wine was segfaulting on Hardy Alpha 5 we got like 10 duplicate bug reports and 60 people posting in the launchpad thread.  That's a hint right there ;)
[11:43] <\sh> YokoZar: when I'm tired of wine, I'll file an MainInclusionReport for Wine, so that our colleagues can deal with it *harharhar*
[11:43] <YokoZar> \sh: It's been brought up every year (with the expectation that Wine 1.0 would be out within a year) for the past 4 years now.
[11:45] <YokoZar> Truthfully though Wine going into Main would be something that would need to happen if we ever wanted to start supporting a package like Mez's winrar
[11:48] <\sh> YokoZar: well, I was thinking more about e.g. "Picasa" from Google..which has imho more users then Mez's winrar :)
[11:49] <YokoZar> \sh: True.  We could easily put Picassa into the partner repo, for instance.
[11:49] <slicer> dholbach: About bug 194836, the "logical" to me seems to have the mumble-server-web package conflict with a earlier version of mumble-server, however the debian policy says a Conflicts should "almost never" have an earlier than version clause. Is this one of the rare cases, or should it simply Replaces: it?
[11:49] <ubotwo> Launchpad bug 194836 in mumble "Update to 1.1.3 (bugfixes)" [Undecided,Confirmed] https://launchpad.net/bugs/194836
[11:49] <\sh> YokoZar: correct :)
[11:50] <YokoZar> Or any app like it.  Hell, no reason any old application couldn't be packaged this way (provided it worked in Wine).  That was one of the original goals of Lindows click and run, actually - to share revenue selling Windows software.  Wine just didn't work too well back then.
[11:51] <YokoZar> For MOTU purposes, we could package free apps without good linux equivalents (say, eMule)
[11:51] <\sh> YokoZar: if it compiles from source, sure :)
[11:52] <YokoZar> \sh: True.  Getting Visual Studio programs to compile on Linux has been a fantasy of mine for a while.
[11:52] <\sh> btw...any reason why we don't have APC (php optimizer/cache) in our archives, but only xcache?
[11:53] <YokoZar> There was some interest in it by one of the scons developers.  I should get back in touch with him.  Basically the idea was to run a visual studio project through some magic python script and then end up with an scons project that we could build in linux with winelib
[11:53] <\sh> YokoZar: what about the propietary MSVC compiler crap?
[11:58] <YokoZar> \sh: Some of that is portable.  The weird patented exception handling, for instance, can be handled with some macros to translate it into GCC stuff.  The windows API header files, on the other hand, are handled by Winelib's reimplementation.
[12:01] <\sh> YokoZar: well, the latter is not a problem actually..but the former will be a big piece of work to do
[12:03]  * \sh brb
[12:07] <dholbach> slicer: I'd use the replaces
[12:08]  * dholbach is out for a dogwalk now
[12:08] <dholbach> see you later
[12:09] <mok0> It's something they do for geeks now. Give them a dog so they get into the open once in a while :-P
[12:09] <Hobbsee> open?  what's that?
[12:09] <mok0> hehe
[12:10]  * Hobbsee wonders if that has something to do with the big blue room
[12:10] <mok0> Whatever it is, dholbach is heading there...
[12:10] <Hobbsee> scary.  will he come back?
[12:12] <mok0> Hobbsee: ask on the #future channel
[12:12] <Iulian> Hey
[12:22] <YokoZar> \sh_away: regarding macros, there are already some in wine's exception.h file
[12:24] <emgent> heya people
[12:59] <shibata> Can I list multiverse package in Suggestion/Recommend fields of main/universe package?
[13:00] <persia> shibata: As "Suggests:", yes.  As "Recommends:", no.
[13:00] <shibata> persia: thx
[13:01] <\sh> re
[13:22] <slytherin> has anyone tried installing elisa on hardy? Because I am getting broken depends
[13:25] <persia> slytherin: My apt-cache agrees with your experience, and expects elisa to be unable to be installed due to a lack of plugins.  Perhaps there was a FTBFS for elisa plugins, or a missing sync, or perhaps the dependencies are incorrect.
[13:27] <slytherin> persia: qa.ubuntuwire.com is stil not up right?
[13:28] <persia> slytherin: Doesn't resolve for me.  https://launchpad.net/ubuntu/hardy/+builds or http://members.ping.de/~mb/buildstatus_hardy/ may help you in the meantime
[13:29] <slytherin> persia: this looks more like missing sync because I can not find any source package for all those plugins
[13:30] <persia> slytherin: Quite possible.  Getting a new package freeze exception for this sort of broken behaviour is usually not too difficult, although it may be worth investigating when the dependency was added.
[13:30] <persia> bddebian: Hey (and no, still no attal patch).
[13:30] <slytherin> persia: yes checking same.
[13:31] <bddebian> Heya gang
[13:31] <bddebian> Hi persia
[13:31] <bddebian> persia: NP.  I'm actually trying to build from cvs now but having even worse problems :-(
[13:32] <persia> bddebian: You do like to make it difficult for yourself :)  Thank you.
[13:32] <bddebian> persia: :-)
[13:32] <bddebian> persia: What did you ever decide with CTSim?
[13:33] <persia> bddebian: To patch it to not build the GUI, but that's on my patch list, and I lost last week, and am still catching up on communications, and haven't done anything yet this week.
[13:34] <bddebian> Heh.  Not sick I hope?
[13:34] <persia> bddebian: Not anymore :)
[13:34] <bddebian> Oh :-(
[13:35] <mok0> Huh? Why doesn't emacs have a python-mode in hardy? Do I need to install a special package?
[13:36] <mok0> python-mode...
[13:36] <mok0> :-/
[13:37] <slytherin> persia: Looks like lool has just added all the plugin packages about 2 hours ago. Damn, no work left for me to be done. :-(
[13:37] <mok0> nope, doesnt
[13:37] <mok0> work
[13:50] <jussi01> could someone give me a quick rundown on the proceedure to add an icon to a package? (or point me somewhere?)
[13:51] <slytherin> jussi01: First check if upstream has added any icon recently. if now design one of your own. :-)
[13:52] <jussi01> slytherin: yeah, we have the icon, Im more wondering on the proceedure of adding it to the package
[13:52] <slytherin> jussi01: which package?
[13:52] <jussi01> genpo
[13:52] <jussi01> !info genpo
[13:52] <ubotwo> Package genpo does not exist in gutsy
[13:52] <jussi01> !info genpo hardy
[13:54] <jussi01> slytherin: its one of our packages included in ubuntu studio, just my skills are a litle rusty
[13:56] <slytherin> jussi01: I believe you will have to get source of the package in hardy. then add a change log entry, add icon file. you may need to change .desktop or .desktop.in file. I can not give instructions this way. You have to try it yourself.
[13:57] <jussi01> slytherin: ok, great
[13:57] <\sh> ScottK: ping...would you like to review bug #200996 pls? :)
[13:57] <ubotwo> Launchpad bug 200996 in ffmpeg "[FFMPEG] missing qt-faststart" [Undecided,New] https://launchpad.net/bugs/200996
[13:58] <\sh> ScottK: siretart is ok with this change and I filed it to debian, too :)
[13:59] <\sh> grmpf...wrong window..ffmpeg is main ;) so -devel is better
[14:00]  * Hobbsee adds a few more bugs to the "done" pile
[14:00] <Hobbsee> jdong: can you check 193784 please?  i've sent it to you guys
[14:01] <slytherin> \sh: synaptic still shows me ffmpeg in universe.
[14:02] <\sh> slytherin: Rejected:
[14:02] <\sh> Signer is not permitted to upload to the component 'main' of file 'ffmpeg_0.cvs20070307-5ubuntu7.dsc'
[14:02] <Iulian> jussi01: Also be sure that you add dh_desktop to debian/rules and dh_install debian/<pkg>.desktop /usr/share/applications. The icon needs to be 32x32 or 48x48
[14:02] <Iulian> jussi01: You may also have to install the icon to /usr/share/pixmaps
[14:03] <\sh> slytherin: the ffmpeg bin package is in universe...but we are talking about "source pkg" ;)
[14:03] <slytherin> \sh: :-D
[14:04] <Iulian> jussi01: That would be something like dh_install debian/<pkg_name>.xpm usr/share/pixmaps in debian/rules
[14:04] <jussi01> Iulian: thanks. is it possible to use an svg?
[14:04] <jdong> bug 193784
[14:04] <ubotwo> Launchpad bug 193784 in gutsy-backports "Amarok Size Mismatch (gutsy-backports)" [Undecided,Confirmed] https://launchpad.net/bugs/193784
[14:05] <Iulian> jussi01: I've never used an svg. I don't know.
[14:05] <jdong> Hobbsee: that seems like an archive issue, I don't think I can do anything about it
[14:05] <jdong> other than forward it to pitti
[14:05]  * jdong looks one channel left
[14:05] <Hobbsee> jdong: yeah, true
[14:07] <slytherin> jussi01: sure it is possible to use svg and it is recommended since they are scalable without loss in quality. Check /usr/share/icons/hicolor/scalable/
[14:08] <slytherin> jussi01: rather /usr/share/icons/hicolor/scalable/apps/
[14:12] <Hobbsee> dholbach: iv'e done 6.  can i stop now?  :)
[14:13] <emgent> jdstrand, ping
[14:13] <dholbach> Hobbsee: no... keep working on them! :-)
[14:13] <dholbach> http://daniel.holba.ch/really-fix-it :)
[14:13] <emgent> jdstrand, when you have time please commit debdiff in bug #200987 on -security, Thanks
[14:13] <ubotwo> Launchpad bug 200987 in lighttpd "CVE-2008-1270 when mod_userdir is loaded but not configured, the server's whole disk becomes remotely readable" [Medium,In progress] https://launchpad.net/bugs/200987
[14:21] <jdstrand> emgent: sure-- thanks!
[14:21] <emgent> jdstrand, thanks to you
[14:21] <emgent> oh jdstrand
[14:21] <emgent> see also https://edge.launchpad.net/~emgent/+assignedbugs?search=Search&field.status=In+Progress
[14:22] <jdstrand> emgent: right, I looked at it yesterday
[14:22] <emgent> ok thanks :)
[14:36] <jussi01> can someone suggest a sample package which has good menu and .desktop files? (for reference)
[15:10] <RainCT> heya
[15:11] <Laney> Is there any problem with KDE and gksu?
[15:13] <Laney> alternatively, is there anything else that KDE uses?
[15:17] <mruiz> hi all
[15:17] <persia> Laney: There are kdesu and su-to-root, but you may need to adjust dependencies to use those.  I don't remember a general solution ever being agreed upon by all.
[15:20] <sistpoty|work> hi folks
[15:20] <RainCT> hey sistpoty|work
[15:20] <sistpoty|work> hi RainCT
[15:21] <Laney> persia: So do you think it's OK for a package to just use gksu then?
[15:22] <persia> Laney: Depends on the package.  If it's a KDE package, better to use kdesu, but lots of non-DE specific packages use either su-to-root or gksu, and many KDE users have one or both of those installed.
[15:23] <persia> If the "binary" is a wrapper script of any sort, arranging for elevated permissions in the wrapper script allows one to check what is available on the local system, providing some flexibility.
[15:23] <hellboy195> persia: ah I see you :) do you remember fail2ban. About the SRU to dapper !?
[15:24] <Laney> persia: Yeah, actually it's ettercap-gtk, so I guess there wouldn't be a problem with gksu in that case.
[15:24] <persia> Laney: No, not for ettercap-gtk :)
[15:25] <Laney> Excellent
[15:25] <persia> hellboy195: Yes.  I thought Dapper support ended in June 2011, so we didn't need it because it next was a problem in February 2012, but I'm unsure if the patch allows one to read old log files, in which case many Dapper users might want it to recover their two-week old logs.
[15:25] <Laney> DktrKranz2: Can you review the patch again in that case? ;) re: the recommends: gksu - it already does!
[15:26] <hellboy195> persia: yeah. that's the problem. Do you think it's a big problem for people to delete the old log files? Or we have to ask the patch submitter if it's working also with the old log files
[15:27] <DktrKranz2> Laney: great! Now I'm unable to do it (Windows has some troubles with apt-get...), I'll check when I'll back home. Thanks :)
[15:28] <persia> hellboy195: Better to test locally: the bug submitter already deleted the old log files.  I'm not in favour of a solution that requires deletion of user data, but I suspect most users have already found some workaround at this point.
[15:28] <persia> DktrKranz2: Even with cygwin?  While it may be hard to test, or compile, or anything, at least apt-get ought work.
[15:29] <hellboy195> persia: so is it still worth it?
[15:29] <hellboy195> DktrKranz2: streamtuner?
[15:30] <DktrKranz2> persia: since it requires X to work, and no time to setup cygwin at work, I prefer to test it on a real Hardy ;)
[15:30] <persia> hellboy195: That's a hard question.  You might want to direct it to the motu-sru team, who are more qualified to have an opinion.  Doing nothing often feels safer, but there may be users who want to check the old data.
[15:30] <persia> DktrKranz2: cygwin isn't any good for testing anyway, only for manual package inspection :)
[15:31] <hellboy195> persia: I will ask the sru folks. thanks :)
[15:31] <DktrKranz2> I've got etch on our servers, but it's not a good idea doing some sponsoring there
[15:31] <persia> heh.  No :)
[15:31] <DktrKranz2> hellboy195: which bug? The famous one?
[15:32] <hellboy195> DktrKranz2: where I subscribed Hobbsee to help us. You unassigned it from you
[15:34] <DktrKranz2> hellboy195: yes, I'm still subscribed, though
[15:34] <hellboy195> DktrKranz2: I'm afraid that it will take some time if we can close the bug ^^
[15:35] <DktrKranz2> basically I'm just unsure why it was removed. If someone has a clear idea, it's good.
[15:35] <DktrKranz2> that's why i resubscribed u-u-s
[15:36] <hellboy195> DktrKranz2: and I subscribed Hobbsee, you know ^^
[15:36] <hellboy195> LucidFox: around?
[15:36] <LucidFox> yes
[15:37] <hellboy195> LucidFox: so. beagle merge is open since nearly 3 weeks. you and slomo are subscribed. WHAT's going on?
[15:37] <LucidFox> I just forgot about it :(
[15:37] <hellboy195> xD
[15:37] <hellboy195> LucidFox: ok ^^ and why (did you) is slomo subscribed?
[15:38] <DktrKranz2> hellboy195: daniel subscribed him
[15:38] <hellboy195> DktrKranz2: is beagle such "high" priority?
[15:39] <DktrKranz2> hellboy195: what about that SRU-related bug persia and you were discussing earlier?
[15:39] <DktrKranz2> hellboy195: being replaced by tracker, it's high-prio no more
[15:39] <hellboy195> DktrKranz2: yes but why then 3 motu's looked at it ^^
[15:40] <hellboy195> DktrKranz2: bug #197348 . Dapper users have problems with their old log files
[15:40] <ubotwo> Launchpad bug 197348 in fail2ban "Please sync fail2ban 0.8.1-5 from Debian(Unstable)" [Low,Fix released] https://launchpad.net/bugs/197348
[15:43] <jussi01> hmmm, can anyone give me a pointer on the following error when i try to build a package with pbuilder?
[15:43] <jussi01> make: *** [clean] Error 127
[15:43] <jussi01> dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2
[15:45] <persia> jussi01: typically means that it couldn't run the clean rule.  A frequent cause is an inability to unpatch the sources.  Are your patches reversible?  Are the patched files further modified by the build?
[15:46] <jussi01> persia: please ignore me... (i guess it helps to have debhelper installed?) :)
[15:46] <persia> jussi01: Well, yes, not having build-dependencies installed can also cause that problem :)
[15:48] <hellboy195> persia: how are my chances to get nexuiz 2.4 into hardy? have you some information about that?
[15:49] <persia> hellboy195: I've no information about that at all, although I suspect that given the close integration in the Games team between Debian and Ubuntu, you'd have difficulty getting a freeze exception unless it was already available in Debian.
[15:50] <DktrKranz2> hellboy195: correct one is bug #197348, and next "Feb 29th" will be on 2012 (out of Dapper support cycle). If I'm wright, only Hardy (and newer) will be supported on 2012, so there's no need to prepare a SRU (unless my misunderstandings).
[15:50] <persia> If you really want it, first find a Games team member around, and get them to verify it is all updated and good in Debian.  After that, check with motu-release.
[15:50] <ubotwo> Launchpad bug 197348 in fail2ban "Please sync fail2ban 0.8.1-5 from Debian(Unstable)" [Low,Fix released] https://launchpad.net/bugs/197348
[15:50] <hellboy195> persia: hmm debian folks are slow. not in sid yet :(
[15:50] <persia> DktrKranz2: The problem is that the current Dapper fail2ban crashes when reading logfiles from 29th February 2008.
[15:50] <QbixAway> Can somebody tell me how bug contact works? I'm listed as bug contact for dosbox, but I can't change imporantance in launchpad.
[15:50] <QbixAway> (for a bug)
[15:51] <persia> hellboy195: Not slow, just very many packages and only so many active members of the Games team.
[15:51] <DktrKranz2> persia: ah... this changes everything, then.
[15:51] <persia> QbixAway: You'd likely get a better answer in #ubuntu-bugs.
[15:52] <QbixAway> persia. ah thanks. didn't know it existed
[15:52] <hellboy195> persia: true. what do you think. How long can I wait until it's clear that it's "too late"
[15:52] <persia> DktrKranz2: Of course, most users have already cleared the broken log entry to get it working again, so the question is how many users would be affected vs. the risk of a stable update.
[15:52] <persia> hellboy195: Wednesday night.
[15:52] <hellboy195> persia: so. tomorrow in 1 week?
[15:53] <persia> hellboy195: Check the release schedule.  I'm tired, so it may be a week, rather than tomorrow (I'm not sure).
[15:53] <persia> After BetaFreeze, new upstreams are almost never allowed, except in very special cases.
[15:54] <hellboy195> persia: then tomorrow. k thx. and I'll talk to motu sru about fail2ban
[15:55] <sistpoty|work> hellboy195: 2.4 is already in the games svn, so I guess either there are problems with it, or Fuddl is waiting for it to get sponsored to debian
[15:55]  * persia notes that a member of motu-sru has been discussing fail2ban :)
[15:55] <persia> sistpoty|work: Do you know the current status?  I've still heaps of backlog mail.
[15:55] <hellboy195> sistpoty|work: buh 2 days are very few ...
[15:55] <hellboy195> persia: uhh. status?
[15:55] <sistpoty|work> persia: of nexuiz? no, not really
[15:56] <persia> Seems not to be a testing block.  Maybe just a final check to be sure SVN is 3.7.3 compliant, and needing another weekend of testing :)
[15:57] <persia> (err, that first "testing" referred to lenny)
[15:58] <sistpoty|work> oh, and there was just another commit to nexuiz ;)
[15:58] <hellboy195> sistpoty|work: I suppose we haven't got enough people to package it on our own?
[15:58] <sistpoty|work> hellboy195: it's already maintained by us?
[15:59] <hellboy195> sistpoty|work: Isn't it always synced from debian?
[15:59] <DktrKranz2> persia: u-u-s is quite populated actually, I'd like to define a strategy to clean it before next deadlines. Do you think we can discuss it on next meeting=
[15:59] <sistpoty|work> hellboy195: it's maintained by the debian/ubuntu games team, so yes, it's always synced
[15:59] <persia> hellboy195: It's maintained by "Debian Games Team", which has almost as many Ubuntu people as Debian people.
[15:59] <DktrKranz2> s/=/\?/
[15:59] <persia> DktrKranz2: Sure (and yes, I'll send out that announcement).
[16:00] <hellboy195> sistpoty|work: nice to see a debian-ubuntu collaboration :)
[16:00] <DktrKranz2> persia: ok, then. I'll add the point to the agende.
[16:00] <sistpoty|work> sure :)
[16:01] <hellboy195> persia: what's the opinion of the motu-sru member about fail2ban?
[16:01] <persia> hellboy195: I'm not the person to ask :)  See https://launchpad.net/~motu-sru
[16:02] <hellboy195> persia: ahh I thought the person talked to you ^^
[16:02] <jdstrand> emgent: when preparing your lighttpd update, would you also want to fix CVE-2008-0983?
[16:02] <jdstrand> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466663
[16:02] <ubotwo> Debian bug 466663 in lighttpd "fdevent.c.171: aborted" [Important,Closed]
[16:02] <hellboy195> DktrKranz2: hey, you are in motu-sru ^^
[16:02] <DktrKranz2> :)
[16:02] <hellboy195> persia: btw. When it's the "stop" for merges? also wednesday?
[16:02] <emgent> jdstrand, just a moment i go to see this cve
[16:03] <hellboy195> DktrKranz2: can you please check the progress?
[16:03] <jdstrand> emgent: the debian bug I gave has a patch, but I haven't revied any of it.  just came across it
[16:03] <sistpoty|work> hellboy195: btw, as I wrote in the FFe for nexuiz, you'll need a FFe for the quake c compiler as well, so I guess it might be prudent to get that done first ;)
[16:03] <jdstrand> reviewed
[16:04] <persia> hellboy195: Merges can be accepted up until the archive closes, as long as they don't break the freeze rules.  Just be more selective about the merges as we get closer, and make sure the bugs being fixed are more important.
[16:04] <hellboy195> sistpoty|work: I read that. I think nexuiz is rather going to hardy-updates than to manage both FFe in the next 2 days
[16:04] <hellboy195> persia: I'll keep that in mind :)
[16:05] <sistpoty|work> hellboy195: I guess you mean hardy-backports?
[16:05] <persia> hellboy195: For the gutsy cycle, I found that after BetaFreeze, I often would merge backwards, incorporating only some of the Debian fixes into a new Ubuntu version.  After RCFreeze, most of my merges were of that type.
[16:05] <hellboy195> sistpoty|work: hmm. what's again the difference?
[16:06] <emgent> jdstrand, i saw it now
[16:06] <hellboy195> persia: :)
[16:06] <emgent> hardy too seems vulnerable..
[16:06]  * jdstrand nods
[16:06] <sistpoty|work> hellboy195: -updates: a program is quite buggy during release, so an update goes in there. -backports: people who want the latest crack running a stable version
[16:06] <emgent> now plaese commit this, this night i work with new CVE-2008-0983, if it's ok for you
[16:06] <hellboy195> sistpoty|work: ah. backports then. true :)
[16:07] <jdstrand> emgent: if you want to do it, I recommend updating 200987
[16:07] <jdstrand> emgent: add this CVE and update the debdiffs
[16:07] <jdstrand> emgent: that way we don't need to do two uploads
[16:07] <emgent> ok uhm
[16:07] <emgent> i work now for it
[16:07] <emgent> thanks jdstrand for notice
[16:08] <hellboy195> sistpoty|work: but it's a pitty that sid repo can't be used with ubuntu :P
[16:08] <jdstrand> emgent: if you don't plan on doing it, I'll get to your debdiffs soon
[16:08] <jdstrand> emgent: cool.  thank you! :)
[16:08] <emgent> jdstrand, np i working now to it :P
[16:27] <\sh> hmmm...can someone explain the role of the "revu coordinator"?
[16:28] <persia> \sh: https://lists.ubuntu.com/archives/ubuntu-motu/2008-February/003362.html
[16:29] <persia> In summary, watch REVU between archive-open and FeatureFreeze to make sure the process is going smoothly.
[16:29] <persia> (and yes, I got the date wrong in that email)
[16:30] <\sh> well....
[16:31] <\sh> -ENOTFORME ;)
[16:31] <\sh> my ubuntu time per week is already counted...:(
[16:32] <persia> heh
[16:32] <persia> It's a major timesink, but rather enjoyable.
[16:34] <\sh> persia: I think it will be a nice job :) but regarding my duties I have (company, family, ubuntu :)) it's really hard to stay on top with a duty as half-sysstud for revu..:( sponsoring takes time and security support takes time too...so :)
[16:35] <hellboy195> \sh: time to help me with a FTBFS (merge)?
[16:36] <emgent> jdstrand, in hardy it'snt vulnerable
[16:37] <persia> \sh: Entirely understood.  On the other hand, if you've an opinion about how it ought be done, stay after the MOTU meeting, and help set the right goals.
[16:37]  * jdstrand nods
[16:38] <\sh> hellboy195: fire away
[16:38] <\sh> persia: I will :)
[16:38] <\sh> and someone is using my email address for spamming
[16:38] <\sh> which is bad..really
[16:38] <emgent> jdstrand, gutsy too.
[16:38] <hellboy195> \sh: You are the last uploader so this may help you :)
[16:39] <\sh> hellboy195: this is no surprise ;)
[16:39] <hellboy195> \sh: ^^
[16:39] <\sh> hellboy195: what is it?
[16:39] <hellboy195> \sh: https://edge.launchpad.net/ubuntu/+source/cernlib
[16:40] <hellboy195> \sh: http://packages.debian.org/changelogs/pool/main/c/cernlib/current/changelog
[16:42] <\sh> hellboy195: and the new version FTBFS (the debian one)
[16:42] <hellboy195> \sh: http://pastebin.com/m3610fb1f
[16:44] <hellboy195> \sh: first problem. gfortran. I had to set the build dep to the older version (ubuntu hasn't got the new one) but it's still FTBFS
[16:45] <\sh> hellboy195: yes...because the version is build against new gfortran...(as it says in the changelog)
[16:45] <hellboy195> \sh: so this causes the FTBFS and we can't do something?
[16:45]  * persia comments that there was some significant fortran transition underway, and not all sources may be compatible to the old fortran before wandering off
[16:46] <\sh> hellboy195: it looks like...and this is nothing I want to fix for hardy now...the transition will hit us in ibex
[16:46] <hellboy195> \sh: k thx
[16:46] <\sh> hellboy195: when we don't have the new fortran, don't think about upgrading the package
[16:46] <hellboy195> \sh: there is acutally a FFe for a package where gfortran is included but it was set to invalid ...
[16:47] <hellboy195> persia: I'm wondering that you are still online ;)
[16:47] <\sh> hellboy195: well, I think it's not reasonable to introduce a new compiler at this time in hardy release
[16:48] <sistpoty|work> actually, I set it back to new, as it looks like we have parts of the gfortran transition already done...
[16:48] <hellboy195> \sh: true :)
[16:48] <hellboy195> sistpoty|work: parts? dangerous
[16:48] <\sh> sistpoty|work: hmmm?
[16:49] <sistpoty|work> oh, doko: do you know the state of the gfortran transition in universe and should we go for it that late in the cycle?
[16:49] <sistpoty|work> bug #199190
[16:49] <ubotwo> Launchpad bug 199190 in libitpp "[FFe] [Sync request] libitpp 4.0.3-1 from debian unstable" [Undecided,New] https://launchpad.net/bugs/199190
[16:52] <\sh> sistpoty|work: can you compile a list of packages which are in need of the transition?
[16:53] <\sh> sistpoty|work: when we started the transition already (I never heard of it) I think it will be a stopper for Hardy when we don't finish it..I agree here with scotts comment on this bug
[16:53] <sistpoty|work> \sh: should already be there in the wiki link (see bug report)
[16:54] <emgent> jdstrand, this issue was fixed some month ago in all ubuntu version
[16:54] <jdstrand> emgent: really?
[16:54] <sistpoty|work> \sh: not too sure, hence I asked doko about it. If there are deep gfortran problems, it might also be an option to undo the transitioned packages
[16:54] <emgent> jdstrand, yuo can upload my debdiff
[16:54] <emgent> jdstrand, yep
[16:55] <emgent> 90_maxfds_crash_fix.dpatch
[16:55] <emgent> jdstrand, i go to rename launchpad bug :P
[16:55] <jdstrand> ok, cool
[16:57] <emgent> jdstrand, i have to go, see you later :)
[16:57] <doko> sistpoty|work: I don't care too much about it; you can try, at least it should build with gfortran, maybe you have problems on the port architectures
[16:58] <\sh> ok..time to go home for now :)
[16:58] <\sh> cu later
[17:02] <jdstrand> emgent: ok bye! thanks for looking into that
[17:16] <jussi01> hmmm, I have export DEBFULLNAME='Jussi Schultink' and the DEBEMAIL one in my .bashrc, just wondering what the variable is to add the comment that goes in the middle of the changelog entry is? - in my case (jussi01)
[17:17] <sistpoty|work> ScottK, Hobbsee, TheMuso: what are your feelings towards getting the gfortran transition done and waiving a general FFe for it? (bug #199190)
[17:17] <ubotwo> Launchpad bug 199190 in libitpp "[FFe] [Sync request] libitpp 4.0.3-1 from debian unstable" [Undecided,New] https://launchpad.net/bugs/199190
[17:19] <stdin> jussi01: comment? you mean so it has " -- Jussi Schultink (jussi01) <your-email> (date)" ?
[17:20] <ScottK2> sistpoty|work: Better to try and finish since it's started than give up and leave it half done.
[17:20] <ScottK2> \sh_away: What testing of your ffmpeg change have you done?
[17:23] <jussi01> stdin: correct
[17:24] <stdin> jussi01: can't you just set DEBFULLNAME="Jussi Schultink (jussi01)", I'm pretty sure it will look at the email address for what key to use for signing
[17:25] <jussi01> stdin: no, it needs to be exactly correct for signing. Ill try that though :)
[17:25] <ScottK2> stdin: Actually it won't.  It looks at the comment too.  He'd need to use -k to sign, but with that it should work fine
[17:25] <ScottK2> jussi01: Just feed it your keyid with -k and then it'll work with the expanded comment
[17:25] <stdin> I think the way others do it is by putting the comment in the key when creating it
[17:26] <jussi01> stdin: yeah, the comment is in the key, i just want it to come when I use things like: dch -i
[17:27] <stdin> I've never bothered using the comment part, so I can't really say
[17:29] <jussi01> hmmm, seems to have worked just expanding the realname feild, Id be curious to know if there is a correct feild for it though
[17:29] <jussi01> and I cant spell field :P
[17:29] <jdstrand> Fujitsu: fyi-- merged your ubuntu-cve-tracker updates
[17:29] <jdstrand> Fujitsu: thanks!
[17:29] <RainCT> jussi01: the comment should be in DEBFULLNAME
[17:30] <RainCT> or at least that's how I've always done it
[17:30] <sistpoty|work> blueyed: for etckeeper, did you already contact the debian maintainer with your patch for bzr support?
[17:30] <jussi01> RainCT: ok then :)
[17:33] <blueyed> sistpoty|work: it's not my patch, but I'll see what submittodebian can do about it (it's not reported on bts yet)
[17:34] <sistpoty|work> blueyed: thanks
[17:36]  * sistpoty|work heads home now
[17:36] <sistpoty|work> cya
[17:40] <hellboy195> RainCT: you remember libnxml?
[17:41] <RainCT> hellboy195: yes
[17:41] <hellboy195> RainCT: 2 days ago a new upstream version arrived in sid ^^
[17:42] <RainCT> lol
[17:43] <hellboy195> RainCT: funny :) btw. noticed that only the i386 and lpia builds of ldtp were sucessful?
[17:46] <RainCT> ldtp?
[17:46] <RainCT> ah yes
[17:47] <RainCT> hellboy195: I see.. dependency problems
[17:47] <hellboy195> RainCT: our fault or because something else?
[19:06] <tsmithe> slomo, you here? would you be prepared to sponsor a (pretty much no-change) upload of my mscore package to debian
[19:07] <tsmithe> ?
[19:07] <tsmithe> [since fluid-soundfont is now in]
[19:10] <erle-> when do you stop taking packages of debian unstable for ubuntu hardy?
[19:10] <hellboy195> erle-: we never stop? but the big wave stopped since we are now in FF and on wednesday Beta freeze starts
[19:10] <hellboy195> DktrKranz: buona sera :)
[19:11] <DktrKranz> :)
[19:11] <hellboy195> ^^
[19:11] <erle-> but i think you will not get gcc 4.3 to the repos
[19:11] <hellboy195> erle-: no we won't
[19:12] <protonchris> Anybody willing to take a look at bug 190744 and potentially sponsor an upload?
[19:12] <ubotwo> Launchpad bug 190744 in libgdamm3.0 "Request: Upgrade libgdamm3.0 to upstream version 2.9.81" [Undecided,Confirmed] https://launchpad.net/bugs/190744
[19:15] <jdstrand> emgent: uploaded lighttpd for #200987
[19:15] <jdstrand> bug #200987
[19:15] <emgent> jdstrand, thanks :P
[19:15] <ubotwo> Launchpad bug 200987 in lighttpd "CVE-2008-1270 when mod_userdir is loaded but not configured, the server's whole disk becomes remotely readable" [Medium,Fix committed] https://launchpad.net/bugs/200987
[19:15] <emgent> when you have time see other in progress ehehe :P
[19:15] <jdstrand> emgent: re bug #195949
[19:15] <ubotwo> Launchpad bug 195949 in vlc "VLC Arbitrary memory overwrite in the MP4 demuxer" [Medium,In progress] https://launchpad.net/bugs/195949
[19:16] <jdstrand> emgent: is there an edgy debdiff available?
[19:16] <emgent> uhm not now
[19:16] <jdstrand> if not, I'll review what's there and upload
[19:16] <emgent> i will work on this, just a moment
[19:16] <jdstrand> emgent: ok, np
[19:19] <tsmithe> is it worth filing a sync request for fluid-soundfont, which whilst being new in debian today with a couple of changes (timidity config files supplies), is a very large package?
[19:20] <Mez> tsmithe, wouldnt it be auto-synced?
[19:20] <tsmithe> it will be next cycle, yeah, so that's why i'm thinking it ain't worth the bother
[19:20] <Mez> or are the ubuntu changesok to wipe/
[19:20] <Mez> depends on what the changes are
[19:21] <tsmithe> wiping is fine :)
[19:21] <tsmithe> (there are no ubuntu changes; the ubuntu upload was first)
[19:35] <emgent> jdstrand, building test..
[19:35] <emgent> sorry for idle..
[19:36] <jdstrand> hey, thanks for doing it! :)
[19:36] <emgent> np :P
[19:41] <blueyed> emgent: bug status "committed" is not right: it has not been uploaded already, has it?
[19:41] <emgent> blueyed, about what ?
[19:42] <blueyed> emgent: 200987
[19:42] <emgent> bug #200987
[19:42] <ubotwo> Launchpad bug 200987 in lighttpd "CVE-2008-1270 when mod_userdir is loaded but not configured, the server's whole disk becomes remotely readable" [Medium,Fix committed] https://launchpad.net/bugs/200987
[19:42] <emgent> blueyed, for hardy committed by \sh
[19:42] <emgent> status it's ture.
[19:43] <emgent> jdstrand, change in fix committed because he send it to -security
[19:43] <emgent> blueyed, don't warry, be happy :P
[19:44] <jdstrand> emgent: what are you erferring to?
[19:44] <emgent> jdstrand, bug #200987 status.
[19:44] <ubotwo> Launchpad bug 200987 in lighttpd "CVE-2008-1270 when mod_userdir is loaded but not configured, the server's whole disk becomes remotely readable" [Medium,Fix committed] https://launchpad.net/bugs/200987
[19:45] <blueyed> emgent: ok, I'm happy.. but I'm still not sure if it's right.. but it does not matter really, unless it would get forgotten.. ;)
[19:45]  * jdstrand wonders emgent is talking about a change that jdstrand made as if jdstrand didn't know about it...
[19:45] <jdstrand> wonders why
[19:46] <emgent> blueyed, in bug 200987 jdstrand was change status to fix committed
[19:46] <ubotwo> Launchpad bug 200987 in lighttpd "CVE-2008-1270 when mod_userdir is loaded but not configured, the server's whole disk becomes remotely readable" [Medium,Fix committed] https://launchpad.net/bugs/200987
[19:46] <emgent> blueyed, see https://bugs.edge.launchpad.net/ubuntu/+source/lighttpd/+bug/200987/+activity
[19:46] <ubotwo> Launchpad bug 200987 in lighttpd "CVE-2008-1270 when mod_userdir is loaded but not configured, the server's whole disk becomes remotely readable" [Medium,Fix committed]
[19:46] <emgent> ubotwo, silent! :P
[19:47] <blueyed> jdstrand: so I guess you have uploaded them, right? Sorry for the confusion..
[19:47]  * jdstrand finally understands the context
[19:47] <jdstrand> blueyed: yep
[19:47] <emgent> heeheh :)
[19:47] <jdstrand> blueyed: they are building on dak
[19:48] <blueyed> Great, thank you both.. :)
[19:48]  * blueyed has just checked his lighty conf..
[19:53] <emgent> jdstrand, done, debdiff attached
[19:53] <jharr> So I have ircd-hybrid installed, I did some source mods to it (#define config variable), and rebuilt it. Now, 'aptitude dist-upgrade' wants to upgrade my package to its package (of the same version).
[19:53] <jdstrand> emgent: ok thanks
[19:53] <emgent> jdstrand, builted fine in my box
[19:53] <emgent> np
[19:53] <jharr> What's the propper way to get that to stop.
[19:53] <emgent> now i have to go, sorry :P
[19:54] <emgent> see you later
[19:55] <emgent> thanks for all jdstrand
[19:55] <emgent> bye
[19:56] <jdstrand> have a good rest of the day!
[19:56] <jdstrand> emgent: ^^
[20:05] <Fujitsu> jdstrand: Thanks. I'll hopefully be a little more active security-wise from now on.
[20:06] <jdstrand> Fujitsu: thanks for what you've been doing :)
[20:09] <ScottK2> Fujitsu: I hear there's a new python-scipy release tomorrow....
[20:09] <tritium> ScottK2: really?
[20:10] <Fujitsu> ScottK2: I was half-way through typing the dput command to make it installable again.
[20:10] <tritium> scipy is what got me interested in python in the first place (along with matplotlib)
[20:28] <ScottK2> Fujitsu: I don't know that I would stop uploading something that's ready because who knows
[20:29] <ScottK2> Fujitsu and tritium: It was mentioned in a Debian bug.  Let me see if I can find it
[20:29] <tritium> ScottK2: only if it's convenient for you
[20:31] <ScottK2> I'm glad I looked.  It was numpy anyway.
[20:32] <tritium> Ah.
[20:32] <ScottK2> Fujitsu and tritium: New numpy release mentioned in Debian Bug #470293
[20:32] <ubotwo> Debian bug 470293 in python-numpy "python-numpy: bug in numpy.histogram" [Important,Open] http://bugs.debian.org/470293
[20:32] <tritium> Thanks, ScottK2
[20:33] <Fujitsu> ScottK2: Thanks, will look at it.
[21:05] <neskiem> is anyone free to take a look at a package on revu?
[21:06] <tsmithe> which, and does it have a feature freeze exception? (i don't have time to review anything, however, nor am i a motu)
[21:09] <neskiem> ttf-lg-aboriginal it's a new package so i guess it wouldn't
[21:10] <ScottK2> tsmithe: If he asked me for an FFe, I'd ask him if it's been reviewed/advocated.
[21:10] <ScottK2> neskiem: We are close to release, so not taking new packages unless it's particularly urgent.
[21:11] <ScottK2> neskiem: There are fonts teams in Debian I think that might sponsor your package there.  If they do it'll get in the next Ubuntu automatically.
[21:11] <neskiem> ScottK2: thanks for the information i've been in contact with the font people in Debian
[21:12] <ScottK2> I'd concentrate on that then.
[21:12] <ScottK2> Come see us mid-may if you haven't gotten into Debian by then.
[21:12] <neskiem> ScottK2: thanks. later.
[21:13] <KasimirGabert> I am trying to upload a new package to REVU, but nothing is showing up
[21:14] <KasimirGabert> would somebody be able to help me?
[21:14] <KasimirGabert> would somebody be able to help me?
[21:33] <RainCT> is someone with an amd64 around?
[21:33] <KasimirGabert> yes
[21:34] <KasimirGabert> however, just a regular user
[21:34] <KasimirGabert> :)
[21:34] <RainCT> KasimirGabert: can you try that and tell me what it says please?    python -c "import os; print os.uname()[4]"
[21:34] <KasimirGabert> x86_64
[21:35] <RainCT> KasimirGabert: and   python -c "import platform; print platform.machine()"   =
[21:36] <KasimirGabert> the same
[21:36] <RainCT> ok, thanks
[21:36] <KasimirGabert> np
[21:37] <blueyed> Any plans to add "grab-merge.sh" to ubuntu-dev-tools, so that it can get fixed?
[21:37] <jdong> RainCT: platform.machine() is cross-platform
[21:38] <RainCT> jdong: do you know how I can get just i386/amd64/powerpc/etc?
[21:39] <jdong> RainCT: what was wrong with platform.machine()?
[21:39] <jdong> that returns x86_64 right?
[21:39]  * RainCT is trying to drop all dependencies on external stuff on pbuilder-dist (new python version), and dpkg-architecture is the only one remaining
[21:39] <RainCT> jdong: yes
[21:39] <hellboy195> RainCT: because of ldtp?
[21:39] <jdong> well then just replace x86_64 with amd64
[21:40] <jdong> RainCT: uname probably is bettter
[21:40] <RainCT> jdong: is amd64 always (and only) = x86_64?
[21:40] <jdong> RainCT: yes
[21:40] <KasimirGabert> would somebody be able to help me with uploading to REVU? it does not seem to work
[21:40] <jdong> RainCT: there's apparently an entire article dedicated to the trademarking/nomenclature but they are interchangeable terms
[21:41] <RainCT> oh
[21:41] <jdong> RainCT: uname -m is probably a better idea too
[21:41] <RainCT> jdong: and for i386?
[21:41] <KasimirGabert> uname -m returns x86_64 as well
[21:41] <jdong> RainCT: you'll get i386, i586, or i686
[21:41] <RainCT> allright then, thanks!
[21:41] <jdong> sure :)
[21:41] <ScottK2> blueyed: We can't add it until after MoM and DaD are merged as currently there are two grab-merge.sh
[22:03] <RainCT> jdong: is os.uname[4] the host architecture?
[22:03] <RainCT> (like dpkg-architecture which has host architecture and build architecture)
[22:06]  * RainCT really hopes so as using this the script is 4 times faster than with dpkg-architecture
[22:09] <jdong> RainCT: yeah this would be host architecture
[22:09] <RainCT> jdong: great. thanks
[22:10] <jdong> RainCT: dpkg-architecture uses gcc -dumpmachine
[22:10] <jdong> /usr/bin/dpkg-architecture  0.07s user 0.01s system 97% cpu 0.082 total
[22:10] <jdong> and you're sure that is going to be a speedup?
[22:12] <RainCT> jdong: I get "real 0m0.344s, user 0m0.156s, sys 0m0.028s" here
[22:13] <jdong> hmm
[22:13] <RainCT> and for pbuilder-dist right now "real 0m0.243s, user 0m0.040s, sys 0m0.028s"
[22:14] <RainCT> * real 0m0.130s
[22:14] <RainCT> 240 ms when the .pyc is outdated
[22:15] <RainCT> (will get a bit slower as there's still some stuff missing, but in any case it'll be a lot faster than before :))
[22:25] <awen_> A freeze exception for a new package... is it correctly understood, that I should have it reviewed in REVU before having a chance?
[22:33] <RainCT> awen_: no, first get the Freeze Exception
[22:35] <awen_> RainCT: so subscribe "motu-release" to the bug-report with the files attached (or a link to the package in motu)?
[22:37] <RainCT> awen_: yes (with link to the package in REVU). remember that the bug description has to contain a rationale about why you think it's important to get it in now
[22:38] <ScottK2> RainCT: Actually he's right
[22:38] <ScottK2> awen_ needs a reviewed package for an FFe.
[22:39] <RainCT> oh
[22:40] <RainCT> that a bit ironic then.. I though most MOTU's only review new packages if they have a FFe
[22:40] <RainCT> or did I understand that wrong?
[22:40] <ScottK2> It can be kind of tough at this point.
[22:40] <awen_> ScottK2: thanks for clearing that up... it's really not written that clearly anywhere (that I could find)
[22:41] <Adri2000> blueyed: get grab-merge.sh fixed? how is it broken?
[22:41] <ScottK2> awen_: It's pretty unlikely to get accepted at this stage unless there's a real crisis
[22:43] <awen_> ScottK2: okay... couldn't really be called a crisis; it's a small package providing a lot of extra import/export formats for inkscape
[22:43] <RainCT> ScottK2: btw, this doesn't need a FFe, or? http://paste.ubuntu.com/5597/plain/
[22:44] <ScottK2> RainCT: Am I going to regret it if I say no?
[22:44] <RainCT> ScottK2: heh I hope not :)
[22:45] <awen_> bug 200730 / http://revu.tauware.de/details.py?package=uniconvertor ... if a motu is around, that has some spare time; should be pretty straight forward
[22:45] <ubotwo> Launchpad bug 200730 in ubuntu "[needs-packaging] UniConvertor: universal vector graphics translator (needed by Inkscape for Corel Draw formats support)" [Wishlist,Confirmed] https://launchpad.net/bugs/200730
[22:45] <ScottK2> awen_: I'd suggest that should wait for the next cycle.
[22:45] <ScottK2> OTOH, if you can find two motu willing to advocate, then I'd give it a look
[22:45] <ScottK2> RainCT: As long as you're tracking bug reports and will make sure it's fixed up before release, I'll say no.
[22:46] <RainCT> awen_: changelog has no bug number
[22:46] <awen_> ScottK2: suspected that my chances wasn't that good...
[22:46] <RainCT> add (LP: #xxxx) at the end of the "initial release" line
[22:46] <RainCT> awen_: why is architecture any if it's a python package?
[22:47] <RainCT> ah it has c stuff
[22:47] <awen_> RainCT: too slow with my answer :)
[22:48] <awen_> RainCT: thanks for reminding me about the LP bug number
[22:48] <RainCT> awen_: differentiate in debian/copyright about which files are under the GPL and which under LGPL
[22:49] <blueyed> Adri2000: grab-merge.sh fails quite miserable when there's nothing to merge. well, only cosmetical, but still.
[22:49] <RainCT> awen_: and I'm not sure if it applies (only had a fast look), but the package doesn't follow the python policy
[22:49] <ScottK2> Wiping the merge dir clean is suboptimal too I think
[22:50] <awen_> RainCT: it doesn't say in the package which are LGPL and which are GPL... what then?
[22:50] <RainCT> awen_: oh. and files have no header with the copyright info?
[22:52] <awen_> RainCT: they have individual copyright notices... but they don't state LGPL/GPL
[22:52] <RainCT> :/
[22:53] <awen_> RainCT: now i see... seems to be hidden in some extra readme files deep in the source tree
[22:54] <awen_> RainCT: i'll have a look at the copyright then
[22:55] <awen_> RainCT: what in particular did strike you regarding the python policy?
[22:56] <RainCT> awen_: that the package isn't using pycentral/pysupport to byte-compile
[22:57] <awen_> RainCT: it has it's own internal build-script (written in python) which the rules-file uses... this should be a sane approach?
[22:58] <RainCT> awen_: what does the script do? create .pyc files (if so were are those installed)?
[22:59] <awen_> RainCT: exactly... they are installed in a sub-directory, and the rules-file then uses dh_install to install those files
[23:01] <RainCT> awen_: I don't think the policy is happy with this, pyc's should rather be handled by pysupport or pycentral
[23:04] <awen_> RainCT: you might be right, I'll change that then... any preference between python-support/pycentral?
[23:04]  * RainCT doesn't mind
[23:04] <awen_> RainCT: and there is no general ubuntu-preference?
[23:05] <RainCT> not that I know about
[23:05] <RainCT> ScottK2 might know better though
[23:08] <james_w> awen_: pycentral was written by someone involved in ubuntu development, but there are a huge number of packages using each, so it doesn't really matter.
[23:08] <awen_> james_w: thanks... I'll flip a coin then :)
[23:09] <james_w> awen_: as good a method as any in my opinion.
[23:10] <awen_> RainCT: thanks for the feedback... sorted the copyright issues out also
[23:10] <RainCT> awen_: great! you're welcome :)
[23:20] <mok0> Funny, I am also working with a python package at the moment. However, the build doesn't create .pyc files. I thought py-central was supposed to do that
[23:22] <soren> mok0: At install time. Not build time.
[23:23] <mok0> It's not being done
[23:24] <soren> mok0: Sure?
[23:25] <mok0> soren: yep
[23:25] <mok0> There's nothing in the installer script doing it
[23:26] <soren> No call to pycentral?
[23:26] <soren> Er..
[23:26] <soren> "installer script2?
[23:26] <mok0> soren: maintainer script, sorry
[23:26] <mok0> postinst
[23:26] <soren> No call to pycentral in postinst?
[23:26] <mok0> soren: using cdbs
[23:27] <soren> mok0: Doesn't matter.
[23:27] <soren> In the resulting postinst, is there no call to pycentral?
[23:27] <mok0> soren: using: DEB_PYTHON_SYSTEM=pycentral
[23:28] <soren> mok0: When cdbs and debhelper is done fiddling with your postinst, does it contain a call to pycentral?
[23:29] <mok0> soren: you mean when building the package?
[23:29] <mok0> postinst has a section added by py_central
[23:30] <soren> Good.
[23:30] <essial> afternoon/morning everyone
[23:30] <soren> And what's the problem, exactly?
[23:30] <soren> The lack of .pyc files in the .deb?
[23:30] <mok0> soren: after installation no .pyc files anywhere
[23:30] <mok0> soren: and no .pyc files in .deb
[23:30] <soren> mok0: Can I see the package?
[23:31] <soren> There's not supposed to be any .pyc in the .deb.
[23:31] <mok0> soren: hang on, I'll put it somewhere
[23:31] <soren> They're generated during postinst by pycentral.
[23:31] <essial> one of you wouldn't happen to know what "Files in variable 'ASSEMBLY_CSFILES' contain variables which cannot be parsed without path to the configure.in being set" in MONO is caused by would you?
[23:33] <mok0> soren: http://www.bioxray.au.dk/~mok/udist_0.5-0ubuntu1.dsc
[23:35] <soren> mok0: Er... That looks suspicously as a python-support package..
[23:35] <mok0> soren: what do you mean?
[23:35] <anon32> I see a lot of packages in need of maintenance and I was wondering if I being a MOTU packager requires me to know how to write code?
[23:35] <soren> mok0: The resulting .deb contains python-support paths..
[23:36] <soren> mok0: DEB_PYTHON_SYSTEM=pysupport
[23:36] <protonchris> Anybody willing to take a look at bug 190744 and potentially sponsor an upload?
[23:36] <mok0> soren: hm. I tried both python-support and python-central
[23:36] <ubotwo> Launchpad bug 190744 in libgdamm3.0 "Request: Upgrade libgdamm3.0 to upstream version 2.9.81" [Undecided,Confirmed] https://launchpad.net/bugs/190744
[23:36] <soren> mok0: Are you sure about that url? :)
[23:36] <ScottK2> anon32: It helps, but it's not required
[23:36] <soren> mok0: That one seems to work.
[23:36] <soren> mok0: What's the problem with it?
[23:37] <soren> mok0: I see .pyc files in the expected places just fine.
[23:37] <mok0> soren: weird. what's your system?
[23:37] <anon32> ScottK2, I see. And how do I join? heh...
[23:37] <soren> mok0: Where are you looking for the .pyc files?
[23:37] <soren> mok0: I'm runing up-to-date hardy (like a real man)
[23:38] <mok0> soren: ok, me too
[23:38] <soren> :)
[23:38] <mok0> soren: I was looking in pysupport
[23:39] <mok0> soren: I guess the bottom line is I don't really understand how the installation works
[23:39] <soren> mok0: I'm looking fir the exact path you're looking at..
[23:39] <soren> mok0: Ok. Here's how it works for python-support:
[23:39] <mok0> soren: sorry, this is where I look: /usr/share/pyshared/udist/
[23:39] <soren> THat's not going to work.
[23:40] <soren> For python-support here's the magic:
[23:40] <james_w> anon32: https://wiki.ubuntu.com/MOTU/GettingStarted is a good place to start from.
[23:40] <mok0> soren: I looked where dpkg -L udist told me
[23:40] <soren> mok0: Your .py files are installed into /usr/share/python-support/$module/
[23:41] <soren> mok0: The postinst calls update-python-modules $module
[23:41] <mok0> I might be out of sync with the latest version of the package
[23:41] <soren> mok0: update-python-modules looks as which versions of python you have installed, compiles the .py files for that, and shoves them into /var/lib/python-support/python$pyversion/$module
[23:42] <soren> mok0: ...along with symlinks to the .py files.
[23:42] <mok0> soren: so, it works for you?
[23:42] <soren> mok0: Yes.
[23:42] <mok0> hmm.
[23:42] <soren> mok0: The one you sent me a link to is a python-support using package.
[23:42] <soren> ...which works.
[23:43] <mok0> soren: ok, let me check again
[23:43] <soren> Hang on, it's easier if I pastebin it..
[23:44] <soren> http://paste.ubuntu-nl.org/59301/
[23:47] <mok0> soren: ok, in my local version I was using pycentral
[23:47] <soren> mok0: I prefer pycentral, so let's get that working :)
[23:47] <mok0> soren: I will change back to pysupport
[23:47] <soren> mok0: Let's see it.
[23:47] <mok0> soren: ok, hang on
[23:48] <mok0> soren: done. Same url
[23:51] <soren> mok0: That works fine, too?
[23:52] <awen_> when using pycentral the debian rules shouldn't compile .pyc-files right?
[23:52] <soren> awen_: Right.
[23:52] <mok0> soren: where are the .pyc files?
[23:52] <soren> (same with python-support)
[23:52] <soren> mok0: /usr/lib/python2.5/site-packages/udist/
[23:53] <soren> mok0: Actually, /usr/lib/python*/site-packages/udist/
[23:53] <mok0> soren: right
[23:53] <mok0> soren: I was execting them to be in /usr/share/pyshared/udist
[23:54] <mok0> soren: well, everything is dandy, then
[23:54] <soren> mok0: Seems to be :)
[23:54] <mok0> soren: 1000 tak!
[23:54] <mok0> :)
[23:54] <soren> mok0: I like helping you. All I need to tell you is that it's already working. :)
[23:54] <mok0> soren: does udist work? :-)
[23:54] <soren> Dunno. What is it?
[23:55] <soren> Oh, you should name it python-udist, by the way.
[23:55] <soren> Just the binary package.
[23:55] <mok0> soren: a small application that writes stuff about the distro
[23:55] <mok0> soren: a la uname
[23:56] <soren> Oh, I see.
[23:57] <mok0> soren: works on redhat family of distros too
[23:57] <soren> mok0: Yep, seems to be working.
[23:57] <mok0> soren: cool
[23:58] <soren> udist.distro.Distro().__str__() says Ubuntu a lot, so I'm guessing it's doing the right thing :)
[23:58] <mok0> soren: heh
[23:58] <awen_> soren: and then the package should of course be "arch: any"?
[23:58] <soren> all
[23:59] <soren> arch: all
[23:59] <awen_> of course all ... typo in the question, hehe
[23:59] <soren> arch: all means that the same binary is usable on all architectures. arch: any means that a binary can be built for any archicture.