[00:15] <superm1> ScottK, looking at the debdiff between the two uploads, i highly doubt that is where the problem was introduced? http://launchpadlibrarian.net/22563445/libsdl1.2_1.2.13-4ubuntu1_1.2.13-4ubuntu2.diff.gz
[00:15] <superm1> i think that previous merge would be more likely to cause the problems
[00:19] <ScottK> superm1: OK.  Thanks for looking.  TheMuso uploaded that one, so maybe he'll look.
[00:20] <TheMuso> The OpenGL and sdl one? I really don't know what I should be looking for actually, everything looks sane to me when I glanced atht ehrules file the other day.
[00:29] <directhex> DktrKranz, braving the debian NM gauntlet, i see?
[00:31] <DktrKranz> directhex, yep
[00:31] <directhex> DktrKranz, who is your advocate?
[00:32] <DktrKranz> cedric
[00:34] <DktrKranz> and now, I'll get some sleep... boring day is just passed
[00:34] <directhex> the NM list is odd. ian murdock, the ian part of "debian", is stuck in NM since 2004?
[00:35] <DktrKranz> emeritous
[00:43] <ScottK> TheMuso: I'm not sure, but between the upload you sponsored and the one superm1 sponsored it seems to have gotten somewhat broken.
[00:49] <TheMuso> ScottK: Right. WIll have another look then.
[00:50] <ScottK> TheMuso: Thanks.
[00:56] <RAOF> Is the new DX notification daemon going to get significantly less crap at displaying notifications without actions associated, or is it time for me to start patching stuff?
[00:58] <directhex> RAOF, i fear how the new daemon will interact with banshee
[00:58] <RAOF> directhex: This is exactly the use-case I'm exploring now :)
[00:58] <Laney> It'll just mean the skip button will go away, right?
[00:59] <directhex> Laney, which will make me mad. grr, directhex smash!
[00:59] <RAOF> No.  It means that instead of a notification, a dialog pops up with "skip", "cancel", and "ok" buttons.
[00:59] <directhex> RAOF, no wai!
[00:59] <Laney> I'm assuming it gets patched
[00:59] <RAOF> This dialog isn't always on top, and hence is almost always not on top, due to focus-stealing prevention.
[00:59] <TheMuso> ScottK: Hrm interesting. It may be a Debian change that broke it. I'll have to dig up my merge diff to double check it to be sure that also wasn't the culpret.
[01:00] <Laney> ah, national anthem on the radio
[01:00]  * Laney hand on heart
[01:31] <TheMuso> SDL problem found, squashing a few bytesize SDL bugs while I'm at it.
[01:32] <directhex> yay TheMuso
[01:35] <RAOF> Alright motu-release!  The only thing between us and a working evolution-sharp package in Jaunty is a FFe ack.
[01:37] <ScottK> TheMuso: Great.  Glad to hear it.
[01:38] <ScottK> RAOF: What bug?
[01:38] <RAOF> https://bugs.edge.launchpad.net/ubuntu/+source/evolution-sharp/+bug/331858
[01:39] <RAOF> Should be a bit of a no-brainer, really.  evolution-sharp is totally broken at the moment.  I guess "working" after "not-working at all" is a bit of a featuer :)
[01:40] <ScottK> RAOF: Are you going to take responsibility for the rebuilds and how soon will they be done?
[01:41] <RAOF> I'll take responsibility for the rebuilds.
[01:41] <RAOF> They should be easy; I'll do them shortly after evolution-sharp clears NEW.
[01:43] <ScottK> OK.
[01:43] <ScottK> Ack from me then.  You need two.
[01:44] <RAOF> Yup.  Thanks.
[01:44] <RAOF> Any pet bugs you'd like fixed? :)
[01:46] <ScottK> I'd ask you to fix boost, but I've already got test builds started.
[01:49] <ScottK> RAOF: I guess if you'd go knock out a few from the sponsorship queue, I'd appreciate that.
[01:49] <RAOF> That's a good plan.  I've been meaning to do that for ages.
[01:54]  * ScottK notes that there are currently 890 Universe packages FBTFS in Jaunty if anyone is looking for something to do http://qa.ubuntuwire.com/ftbfs/#universe
[01:55] <RAOF> Um. We require 2 motu-sru acks before an SRU is approved, yes?
[01:56] <RAOF> The wiki page doesn't actually appear to contain this information.
[01:56] <ScottK> Dunno about SRU.
[01:57] <ScottK> My suggestion would be upload it an let them decide.
[01:57] <ScottK> By that's probably totally wrong.
[01:57]  * ajmitch wonders how many of those are FTBFS on the main release architectures
[01:58] <ScottK> ajmitch: Mostly not, but enough for people to keep busy.
[02:00]  * ajmitch sees a lot of spurious armel failures there
[02:00] <ScottK> Yep
[02:00] <ScottK> There's a lot on sparc and ia64 that just needs a retry too.
[02:00] <ajmitch> eg last-exit failed to build because udev couldn't be installed in the build chroot
[02:01] <ScottK> Still some on powerpc too altough I managed to clear up a lot of powerpc the list time the buildd's were quiet.
[02:02] <ajmitch> RAOF: you'll be disappointed to see that xserver-xorg-video-nouveau failed to build on HPPA :)
[02:02] <RAOF> ajmitch: I'm crushed.
[02:03] <ajmitch> can you even use nvidia cards with those?
[02:03] <RAOF> Probably not.
[02:06] <TheMuso> ScottK: Will probably take a ook at powerpc FTBFSs at some point.
[02:06] <TheMuso> look
[02:06] <TheMuso> And sparc should be fixed by tomorrow, got a ports kernel upload coming tonight hopefully, my time.
[02:07] <TheMuso> for glibc/qt4-x11 and anything else depending on endianness.
[02:07] <ScottK> TheMuso: I've been gradually working on sneaking in retries of stuff that died when the ports kernels were all broken.
[02:07] <TheMuso> ScottK: cool.
[02:07] <ScottK> I think on powerpc almost anything in Main has some real problem.
[02:07]  * RAOF hasn't been doing particularly well with the sponsors queue.  A bunch that weren't meant to be sponsored, and now vnc4 hasn't built since Hardy.
[02:07] <ScottK> That's great news about sparc.
[02:08] <ScottK> TheMuso: IA64 seems to be healthy too, just needs time to catch up.
[02:08] <TheMuso> ScottK: Yeah.
[02:09] <ScottK> About 36 hours ago I noticed the powerpc buildd's were idle so I went to find something to retry.  While I was doing that two uploads got done.  That retry still hasn't happened.
[02:12]  * ajmitch wonders what should be done about packages that have FTBFS since hardy
[02:14] <TheMuso> ScottK: lol
[02:14] <TheMuso> I think my weekends are the best time, most devs are asleep, and those of us in a similar timezone to myself are either doing something else, or aren't always donig uploads etc.
[02:14] <TheMuso> I remember last weekend I retried several packages on various arches in main, plan to do the same this weekend.
[02:15] <ScottK> I had similar luck myself.
[02:35]  * TheMuso shakes his head at libsdl. It doesn't even link directly to the X libs, it dlopens them. :S
[02:35] <TheMuso> At least thats how it gets built.
[02:36] <TheMuso> Although that does make sense in terms of non-X systems wanting to use it.
[02:40] <TheMuso> SDL would be better off having a plugin system, which probably already exists in the post 1.2 branch upstream anyway.
[05:28] <dholbach> good morning
[06:01] <fabrice_sp> Good morning
[06:13] <iulian> Morning dholbach, fabrice_sp.
[06:13] <fabrice_sp> morning iulian!
[06:14] <fabrice_sp> morning dholbach also
[06:14] <fabrice_sp> :-)
[06:14] <dholbach> hiya iulian, hi fabrice_sp
[06:15] <fabrice_sp> by the way, one question: now that we are in FF, a merge that hasn't been sponsored before, has to follow the FFe process? (it's for Bug #247591)
[06:17] <ScottK> yes it does
[06:17] <fabrice_sp> ok. Will do then. thanks
[06:51] <Laibsch> Is this a good place for questions about pbuilder-dist?  I tried #pbuilder but that does not seem to exist anywhere.
[06:56] <ScottK> Probably.
[07:16] <Laibsch> I want to backport a package X (for personal use), which relies on debhelper 7.   Although I re-compiled debhelper 7 first, it does not seem to find it.  How do I include previously built packages in those available to subsequent builds?
[07:16] <Laibsch> Same question goes the other way round, too, of course.  How to exclude so to make sure a package succeeds a build from scratch
[07:59] <tonyyarusso> What is the function of 'make clean' exactly?
[08:02] <Flannel> tonyyarusso: It removes all packages from /var/cache/apt/archives/
[08:02] <Flannel> oh, make clean!
[08:02] <Flannel> hah
[08:02]  * Flannel runs away.
[08:04] <tonyyarusso> Way to read Flannel :P
[08:04] <Flannel> quiet.
[08:04]  * jussi01 points and laughs at Flannel (yes... Im everywhere) :P
[08:05] <Flannel> jussi01: I'm everywhere-er!
[08:11] <dholbach> tonyyarusso: it removes files that are created automatically during the build process (like the compiled binaries, etc.)
[08:11] <tonyyarusso> dholbach: ah, ok
[08:11] <tonyyarusso> any of you guys have an AIM account and want to help me test something?
[08:11]  * tonyyarusso compiled without SSL, so that's the only protocol that works - whoops.
[08:14] <tonyyarusso> Also, how do you build a package with a configure script?  I'm used to using 'debuild -S -sa' and then 'sudo pbuilder build *.dsc', but debuild requires the ./configure to have run first.  However, it appears that script is run within debian/rules, so is all automatic if I can figure out the invocation properly.
[08:17] <liw> tonyyarusso, debian/rules must invoke the configure script in some way; if you use cdbs, one of the magic includes will do that for you; if you don't use cdbs, you need to write your own build target and call ./configure from there
[08:17] <tonyyarusso> liw: debian/rules does invoke the configure script.  I just am not getting to the point of letting debian/rules do it's thing.
[08:18] <tonyyarusso> oh, wait - I think it's because I was missing some helper scripts.  nvm
[08:23] <tonyyarusso> Do all Ubuntu changes go in debian/patches/, or do some touch the bulk of the source?  (how does that directory compare to the rest, and under what circumstances should changes go there)
[08:24] <geser> tonyyarusso: it depends if the package uses a patch system or not
[08:25] <tonyyarusso> geser: It does, CDBS with something.  (pidgin)
[08:25] <pmjdebruijn> tonyyarusso: then patches should go under debian/patches
[08:25] <tonyyarusso> simple-patchsys apparently
[08:25] <tonyyarusso> okie dokie
[08:26] <geser> so patches to the source should go there while you can change files in debian/ directly
[08:27] <dholbach> what-patch (in ubuntu-dev-tools) FTW!
[08:28] <tonyyarusso> just found that - cool beans
[09:27] <`6og> hi all. I want to rebuild the hardy kernel packages to see if the packages in -security will build without -updates. Any clues how i could do that?
[09:28] <soren> Try it in a PPA. You can configure it to only use -security.
[09:30] <`6og> soren, i'll investigate that, thanks.
[09:51] <tonyyarusso> What are some reasons a patch would fail to apply during 'pbuilder build'?
[09:52] <savvas> tonyyarusso: usually when the original file that you are patching changes
[09:53] <tonyyarusso> savvas: ah, possibly due to another patch for instance?
[09:53] <geser> or you try to patch a already patch file while the patch is against the unpatched version
[09:54] <geser> tonyyarusso: might also be due to changes upstream
[09:54] <savvas> true, like my problem yesterday with boost1.35 :P
[09:54] <tonyyarusso> geser: Can't be upstream - I haven't changed versions.
[09:54]  * tonyyarusso greps for patches touching the same file
[09:55] <tonyyarusso> well that's not it...
[09:56] <tonyyarusso> I wish the error was more descriptive - all it says is "Trying patch debian/patches/75_pounce-options-enhance.patch at level 1 ... 0 ... 2 ... failure."
[09:56] <savvas> tonyyarusso: source link?
[09:57] <tonyyarusso> savvas: to what, the patch?
[09:57] <tonyyarusso> http://paste.ubuntu.com/120522/
[09:57] <geser> tonyyarusso: try to manually apply the patch (with patch) so you see the exact messages
[09:57] <savvas> patch and the debian source if you have them :)
[09:57] <savvas> ah pidgin
[09:57] <tonyyarusso> yeah
[09:58] <tonyyarusso> oh, nvm - everyone ignore me...
[09:58] <savvas> tonyyarusso: hardy?
[09:58] <tonyyarusso> I left changes in the source tree from generating said patch, 'cause it's 4am and I'm an idiot.
[09:58] <tonyyarusso> savvas: for now yes
[09:59] <savvas> oh, so problem fixed :)
[10:00] <tonyyarusso> Let's try this again...
[10:04] <tonyyarusso> savvas: btw, what was relevate about asking if it was hardy?  (I ask so I know what I need to change to do this for jaunty as well)
[10:04] <tonyyarusso> *relevant
[10:05] <savvas> I just wanted to know which source package you are using :)
[10:05] <tonyyarusso> ah
[10:05] <savvas> I saw 2.4.1 in the patch
[10:05]  * tonyyarusso hopes not much has changed in this part of the package so I don't get any surpriseds
[10:07] <tonyyarusso> savvas: btw, if you know anything about pidgin, I figured out how to do what I want in GTK, but I have no idea how to do it in GNT for finch, since GNT doesn't seem to have a radio button feature, only checkboxes that aren't mutually exclusive.
[10:08] <savvas> nope, still learning packaging, sorry :P
[10:11] <savvas> geser: I'm trying to make all boost (1.34) packages move to boost1.35 - I should patch so that packages such as libboost-filesystem-dev in boost (1.34) is renamed as libboost-filesystem1.34-dev, right?
[10:12] <savvas> or if anyone else knows :)
[10:12] <incorrect> hopefully backporting bdb 4.7 will fix openldap replication issues
[10:24] <geser> savvas: I wouldn't rename them, better would be to get rid of boost 1.34 if possible, we have 1.35 and 1.37 in archive too
[10:25] <savvas> geser: so I should just work on boost1.35?
[10:27] <geser> what are you trying to accomplish? it's not really clear to me right now
[10:28] <savvas> geser: sorry, hold a sec
[10:28] <savvas> $ sudo apt-get install libboost-filesystem-dev
[10:28] <savvas> The following packages have unmet dependencies: libboost-filesystem-dev: Depends: libboost-dev (= 1.34.1-15ubuntu1)
[10:29] <geser> works here: jaunty on amd64
[10:31]  * savvas updates
[10:31] <savvas> oooh.. now I see
[10:32] <savvas> I already had libboost-filesystem1.37-dev hehe
[10:32] <savvas> aptitude makes it a bit more clear :)
[10:34] <savvas> thanks!
[10:43] <ahasenack> hi, does anybody have an example of a postinst script that detects whether it's the first installation of a package?
[10:43] <ahasenack> I have a package with a hourly cron job whose start time I want to randomize at install time
[10:43] <ahasenack> but I don't want to touch it in upgrades
[10:44] <ahasenack> I wouldn't want to use something as a macro (@RANDOM@) in the cron.d file and sed it in postinst because there is a window of time where the @RANDOM@ would be there, thus making the cron.d file invalid during that amount of time
[10:46] <soren> ahasenack: if $1 is "configure" and $2 is empty or undefined, then it's the first install.
[10:46] <savvas> ahasenack: you could check if the file  in cron.d exists
[10:46] <savvas> oh
[10:46]  * savvas notes :P
[10:47] <ahasenack> soren: thanks
[10:47] <soren> ahasenack: If $1 is "configure", $2 contains the version from whence you're upgrading.
[10:47] <savvas> soren: is dpkg --compare-versions used in that case?
[10:48] <Toadstool> ahasenack: if [ ! -e $file ]; then TMP=`mktemp` ; … ; mv $TMP cron_location fi also works
[10:48] <Toadstool> hi everybody
[10:48] <soren> savvas: You can use dpkg --compare-versions to compare $2 to a known version string to determine if you need to do certain things during this particular upgrade, yes.
[10:48] <ahasenack> Toadstool: thanks too
[10:48] <savvas> cool
[10:49] <geser> Toadstool: wouldn't that overwrite an admin decision to rm that cron.d file on  upgrades?
[10:49] <soren> savvas: If, for instance, a configuration file moved in version 1.2-4ubuntu2, you can do "if dpkg --compare-versions "$2" -lt 1.2-4ubuntu2; then mv <old path> <new path> ; fi" or something like that.
[10:51] <soren> savvas: What would belong in the preinst, though.
[10:51] <Toadstool> geser: hmm, well yes, good point
[10:51] <savvas> thanks soren :)
[10:53] <Toadstool> geser: that could be worked around using ucf, though...
[10:54] <soren> Toadstool: ucf is a completely different kettle of fish, though :)
[10:54] <Toadstool> agreed :)
[10:57] <ahasenack> hmm, can't use $RANDOM with /bin/shj
[10:57] <ahasenack> sh
[11:02] <soren> Right, it's a bash thing.
[11:04] <savvas> is there a special section for virtual packages / meta packages?
[11:07] <slytherin> savvas: metapackages? I believe ubuntu-restricted-extras uses it.
[11:09] <savvas> thanks
[11:19] <ScottK> DktrKranz: Are you around?
[11:39] <savvas> is there a standard policy for dummy packages? e.g. description one-line or the detailed one?
[11:43] <sistpoty|work> hi folks
[11:47] <slytherin> savvas: What do you mean by dummy packages? Transitional packages?
[11:47] <slytherin> NCommander: around? have question about a build failures on sparc.
[11:47] <savvas> slytherin: yes, transitional dummy packages
[11:48] <slytherin> savvas: I don't think the description of transitional packages are treated any different way.
[11:48] <savvas> ok thanks :)
[12:04] <incorrect> yay! libdb 4.7 backported to hardy
[12:09] <slytherin> wow, openjdk build on armel is sure blocking other builds. :-)
[12:10] <directhex> slytherin, yeah..... how much RAM do the buildds have?
[12:10] <slytherin> directhex: I am not sure this is RAM problem.
[12:11] <directhex> slytherin, well, it can't help... if it needs ram into the gigs, and has barely any ram, then all the swapping won't speed it up
[12:12] <slytherin> directhex: looks like the last successful build of openjdk also took two days, and that was on another server.
[12:13] <directhex> slytherin, does it work well on arm?
[12:14] <slytherin> directhex: no ides, I don't have an armel machine. You should ask NCommander if he has one.
[12:14]  * NCommander has a few ...
[12:15] <slytherin> NCommander: how many different ports do you have?
[12:15] <slytherin> I mean archs
[12:15] <directhex> i still can't see mention of NCommander without the electric six song "dance commander" running through my head
[12:15] <NCommander> slytherin, I got a MIPS, a few ARMs, PowerPC, x86, amd64, lpia
[12:15] <NCommander> my sh4 is MIA
[12:16] <slytherin> that is a long list. :-)
[12:16] <\sh> guys, what do we need to sync a package from debian, during FF? especially security stuff (uw-imap)
[12:16] <slytherin> \sh: if it is bug fix only then no FFE is needed.
[12:17] <\sh> slytherin: so just a sync request on LP
[12:17] <directhex> NCommander, you can give the moonlight plugin a shot on them now, if they run jaunty ;)
[12:22] <NCommander> Microsoft compiled their codecs for ARM?
[12:29] <directhex> NCommander, nay. built against ffmpeg
[12:29] <directhex> NCommander, but i've been told by upstream that if they CAN build them (ie.. have a working build environment) then they'll add any arch people ask for
[12:29] <NCommander> Upstream as in Microsoft?!
[12:29] <directhex> as in novell
[12:30] <NCommander> oh
[12:30] <directhex> the binaries are hosted on microsoft.com, but the builds are done by novell
[12:30] <NCommander> so Novell has MS's codec code O__o;
[12:30] <NCommander> wow ....
[12:30] <NCommander> I'm suprised that ever leaves Seattle
[12:34] <directhex> i doubt MS want the arseache of doing it themselves
[12:34] <directhex> they're just hosting the binaries & paying the mpeg-la fees
[12:44] <fransman> that got to be a remote sever at the Microsoft campus Novell is working on
[12:47] <directhex> fransman, well, no, hence the request for build servers (or tips for making qemu work)
[12:50] <slytherin> NCommander: do you think you can take a look at a build failure on sparc and provide some insight?
[12:51] <NCommander> slytherin, the kernel on sparc is extremely broken ATM
[12:51] <NCommander> We have a kernel upload pending to fix it, and then glibc needs to be retried, which should make most of the stranger build failures go away
[12:51] <slytherin> NCommander: hmm, that could be reason. I saw some error in one of the linux header files.
[12:51] <slytherin> So I will ignore the error for now and will do rebuilds later.
[12:54] <stefanlsd> dholbach: for the 5-a-day stuff, all we need to do now is join the team?
[12:54] <dholbach> yes
[12:54] <dholbach> and add yourself to https://wiki.ubuntu.com/Bugs/Events
[12:54] <dholbach> the stats are not quite ready yet but should be soon
[12:54] <dholbach> nothing will be lost :)
[12:55] <nhandler> What team has the ability to modify http://www.ubuntu.com/community pages? http://www.ubuntu.com/community/processes/techboard is out of date
[12:58] <stefanlsd> dholbach: does it rely on the  LP id's being on that page?
[12:58] <dholbach> stefanlsd: yep, just for the bug jams
[12:58] <stefanlsd> dholbach: aah ok. will do
[12:59] <dholbach> super
[12:59] <james_w> nhandler: bugs on ubuntu-website are the preferred way to report those sorts of issues I believe
[13:01] <nhandler> james_w: Ok, thanks a lot. I'll file the bug when I get back home later.
[13:18] <fransman> savvas: why do we need, what got to be his task, the contact person you can't riches for some week for flumotion?
[13:19] <Vest84> mok0: hi, do you have a free time to review my project again? I've fixed it: http://revu.ubuntuwire.com/details.py?package=gnome-quod
[13:20] <mok0> Vest84: I will take a look later, busy right now
[13:20] <Vest84> ok, thank you in forward
[13:21] <fransman> savvas: talking about bug 319204 btw
[13:22] <DktrKranz> ScottK: yes
[13:23] <ScottK> DktrKranz: I had sent you mail about the Ubuntu Release meeting today, but sistpoty|work said he'd cover it, so no worries.
[13:23] <directhex> DktrKranz, how does that changelog i posted to the md2 bug look?
[13:24] <DktrKranz> ScottK: cool. I can eventually attend too
[13:27] <DktrKranz> directhex: I plan to look at them at a whole tonight (so I can finally install MD2 \o/)
[13:29] <savvas> lool: any update on flumotion - debian? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473781
[13:30] <lool> savvas: So first, 0.4.x was supposed to be a stable series and 0.5.x a devel series leading to 0.6
[13:30] <lool> I believe 0.5.x would now be more easy to work with than 0.4 though
[13:31] <lool> savvas: Second, updating packages like flumotion is very time consuming if you try to get the Depends right; it's usually easy to get it working, but ensuring that you have the proper depends for any Python module that the code might use less so
[13:32] <lool> And apart of that, I had no time nor interest in working on flumotion while lenny was frozen, now would be more interesting though
[13:33] <savvas> fransman: ^ :)
[13:33] <savvas> lool: ok thanks, if you need help, I could try out and minimize the usage of packages in Depends
[13:35] <lool> I don't know; I can think of two time consuming ways to do things right; alternatively I don't care if someone picks up the package, removes my name from it, and does it empirically
[13:45] <_ruben> slightly offtopic, but does anyone has a decent Makefile syntax reference?
[13:48] <soren> _ruben: "info make"?
[13:50] <fransman> lool: have you seen [link] because they uses them self for pbuilder
[13:50] <fransman> https://code.fluendo.com/flumotion/trac/browser/flumotion/trunk/pkg
[13:51] <lool> They started it from my packages
[13:51] <fransman> https://code.fluendo.com/flumotion/trac/wiki/PbuilderUbuntu
[13:51] <fransman> ok i didn't know
[13:51] <_ruben> ah .. that brought me to "the gnu make manual" .. which seems to a very decent doc
[14:21] <DktrKranz> nhandler: I just sent a mail to MC to formally add you to motu-release team
[14:24] <kpirc> I am looking for a reviewer for my 'cadabra' package on REVU. Any takers?
[14:24] <directhex> woo for nhandler?
[14:24] <directhex> kpirc, which language is it in?
[14:24] <kpirc> directhex: C++
[14:24] <directhex> pass
[14:27] <stefanlsd> dholbach: is that tag anything special?  gbj-za-0902 , or gbj-johannesburg-0902?
[14:27] <dholbach> stefanlsd: should be all fine - just pick anything similar to the others on Bugs/Events
[14:28] <dholbach> stefanlsd: talk about it on  #ubuntu-bugs ?
[14:28] <stefanlsd> dholbach: kk
[14:28] <stefanlsd> oh right :)
[14:28] <dholbach> stefanlsd: that's where the bug and bug jam action is going on :)
[14:43] <bddebian> Heya gang
[14:49] <geser> Hi bddebian
[14:49] <bddebian> Heya geser
[14:55] <slytherin> persia: I wonder why netbeans has not yet cleared the queue
[15:20] <sistpoty|work> siretart: new faucc on spooky:~sistpoty/faumachine
[15:27] <siretart> sistpoty|work: what about faumachine? unchanged?
[15:27] <sistpoty|work> siretart: just adding the versioned build-dep there, give me a minute please ;)
[15:28] <siretart> ok. building faucc...
[15:32] <sistpoty|work> siretart: thanks... faumachine is now also on spooky
[15:36] <siretart> sistpoty|work: building...
[15:37] <sistpoty|work> siretart: thanks! (crossing thumbs that this indeed fixes it on i386)
[15:38] <MaduserTr> Is there a way to have a debian/watch where the version is not in the href?
[15:43] <siretart> sistpoty|work: well, it seems that at least as no longer exists with exit code 1 :-)
[15:43] <siretart> still building though...
[15:43] <savvas> transitional dummy packages have 'Architecture: all', right?
[15:43] <sistpoty|work> siretart: :) (and yes, it does take ages :/)
[15:45] <savvas> MaduserTr: no, not usually - in such cases, it's good to contact the administrator or the author to create uwatch-friendlier links :)
[15:46] <savvas> MaduserTr: can you show us the link and the debian/uwatch file you have?
[15:46] <MaduserTr> The link is http://josm.openstreetmap.de/tested
[15:47] <MaduserTr> and they changed because of trafik some days ago, (before it was a link)
[15:48] <savvas> MaduserTr: you could use get-orig-source in the debian/rules - but I have never tried it
[15:48] <MaduserTr> savvas: thanks i will search and try
[15:50] <savvas> MaduserTr: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball
[16:01] <orci> I remember reading somewhere that Shuttleworth made a comment that the desktop is not viable for ubuntu. Does this mean that Ubuntu will aim servers primarily in the near future?
[16:02]  * RainCT has just bought an ubuntu certified PC.. the sticker looks nice :)
[16:03]  * directhex certifies his laptop for ubuntu directhex edition
[16:03] <RainCT> 150€ box.. works like a charm :)
[16:05] <sistpoty|work> thanks siretart, just got the accepted mail :)
[16:07] <siretart> :)
[16:07] <__iron> hi RainCT
[16:07] <__iron> just time for pm
[16:07] <__iron> ?
[16:11] <RainCT> Hi __iron
[16:11] <RainCT> Sure
[16:14] <orci> sorry wrong channel?
[16:14] <__iron> orci: try #ubuntu
[16:16] <orci> __iron, unfortunately #ubuntu is useless most of the time. But thanks, I'll try another channel
[16:16] <__iron> motu is dev-channel
[16:16] <DktrKranz> dholbach: hi, mind adding nhandler to motu-release team? See also https://lists.ubuntu.com/archives/motu-council/2009-February/002029.html
[16:18] <dholbach> DktrKranz: I'm not on the MC
[16:19] <dholbach> soren: ^ can you help there?
[16:19] <soren> dholbach: hm?
[16:19] <soren> Oh.
[16:19] <soren> Er.. Sure.
[16:19] <DktrKranz> dholbach: oh... already dropped your role?
[16:20] <dholbach> the TB and CC are still discussing the MC election
[16:20] <soren> DktrKranz, dholbach, nhandler: Done.
[16:20] <dholbach> DktrKranz: so I can lay back and let soren do the work
[16:20] <soren> dholbach: We miss you! :)
[16:20] <dholbach> already?
[16:21] <soren> Since before you left, dude.
[16:21]  * DktrKranz hugs soren and hugs dholbach for past, awesome, MC work
[16:21]  * dholbach hugs y'all back :)
[16:21] <dholbach> The Ubuntu Community - where hugging comes first!
[16:22] <dholbach> :-D
[16:22] <DktrKranz> dholbach: do you miss mass-hugs, don't you? Be prepared for next UDS ;)
[16:22] <dholbach> :-)
[16:22] <dholbach> DktrKranz: it's much more fun if you don't prepare :)
[16:23] <DktrKranz> heh
[16:35] <savvas> what was that file that they list packages and architectures that are blocked from being built?
[16:35] <savvas> I remember seeing it somewhere online on debian.org
[16:38] <soren> savvas: http://buildd.debian.org/quinn-diff/Packages-arch-specific
[16:40] <maxb> soren, savvas: btw, Soyuz currently uses an out-of-date version
[16:41] <soren> maxb: How can you tell?
[16:41] <savvas> maxb: I got a heavy lag for some reason, did any reply to my question?
[16:41] <soren> 16:38:59 < soren> savvas: http://buildd.debian.org/quinn-diff/Packages-arch-specific
[16:41] <savvas> 17:35:23 < savvas> what was that file that they list packages and architectures that are blocked from being  built?
[16:41] <savvas> cool, thanks soren :)
[16:41] <soren> Sure.
[16:41] <maxb> soren: by asking the admins on #launchpad
[16:42] <maxb> bug 316579
[16:42] <soren> maxb: Just now?
[16:42] <maxb> back when I filed that bug
[16:42] <soren> maxb: That's useful info. Thanks.
[16:42] <maxb> fortunately it appears milestoned for a fix soon
[16:59] <savvas> hm.. %i8kutils: i386							      # Dell (i386) laptop utils
[17:03] <iulian> (removed the MOTU meeting part)
[17:04] <iulian> The next meeting was TBD so we don't want to have it in the topic if we didn't schedule one.
[17:11] <savvas> looks like i8kutils can be built on amd64 as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480938
[17:12] <stefanlsd> Karmic Koala
[17:12] <stefanlsd> hehe
[17:15] <savvas> Grumping Groundhog? :p
[17:16] <kpirc> I need a reviewer for my 'cadabra' package on revu. Any takers? (it's a computer algebra system)
[17:33] <phaidros> hi, can I tell prevu to use a different arch then the host system?
[17:35] <RainCT> yay, UDS in Barcelona :)
[17:47] <iulian> Karmic... sounds cool :)
[17:47] <phaidros> any hints on setting arch with prevu?
[17:48] <phaidros> I want to backport x86 packages on an amd64 host ..
[17:48] <phaidros> is that doable ?
[17:54] <loic-m> phaidros: should be ok as long as they don't use assembler code
[17:54] <loic-m> Don't know much about prevu though
[17:55] <maxb> prevu's mostly a simple frontend for pbuilder. If you're getting into that sort of advanced territory, you probably want to use pbuilder directly (or better still cowbuilder)
[17:59] <jdong> phaidros: you can use a linux32 chroot
[17:59] <RainCT> or pbuilder-dist/cowbuiler-dist :)
[17:59] <jdong> other than that, no, prevu doesn't have built-in support for i386 pbuilders on amd64.
[18:00] <slytherin> geser: just FYI ... libjboss-buildmagic-java really seems to have circular build dep.
[18:05] <phaidros> jdong: thanks.
[18:22]  * sistpoty|work heads home... cya
[18:57] <savvas> oops, I think I made a mistake with bug #190247 - we aren't supposed to touch the status once sponsors are subscribed, right?
[18:57] <savvas> I subscribed ubuntu-main-sponsors and then set it as "in progress"
[18:59] <slytherin> khashayar: there? I have question about celt.
[19:23] <goshawk> hi
[19:28] <RainCT> hi :)
[19:59] <weboide> Hi, what can I do (except hit my head with my keyboard) when there's already a package with the same source name in the repos as the package I'm working on?
[20:03] <slytherin> weboide: which package is that?
[20:04] <weboide> slytherin: I'm working on eina (a music player) and in debian experimental there is source package eina already.
[20:04] <weboide> slytherin: eina (debian) is a lib.
[20:05] <slytherin> weboide: you rename your package to something like eina-player
[20:05] <slytherin> weboide: meanwhile make sure upstream knows that they are using and already used project name
[20:05] <weboide> slytherin: that's what I thought but there would be issues with the directory name in the orig.tar.gz, would I have to rename that too?
[20:06] <weboide> slytherin: the best way is that upstream changes the name...
[20:06] <weboide> slytherin: right?
[20:06] <slytherin> weboide: yes
[20:07] <weboide> slytherin: but the thing is it seems that the debian eina appeared afterwards...
[20:07] <slytherin> weboide: have you checked first release dates for both projects?
[20:09] <weboide> slytherin: no, but I am now. Debian eina appears to be Enlightenment libraries.
[20:10] <a|wen-> savvas: AFAIK you should make sure it is set to confirmed, with no assignee when subscribing ubuntu-*-sponsors
[20:11] <savvas> a|wen-: ok, I'll set it back now
[20:29] <slytherin> slomo: gst-plugins-ugly-multiverse0.10 source is nothing but a copy of gst-plugins-ugly0.10 source, right?
[20:29] <weboide> slytherin: ha, I found eina (player) back in 2004!
[20:29] <slytherin> :-)
[20:41] <andersk> I have a debdiff for Intrepid's open-vm-tools that fixes bug 289921, bug 306835, and bug 302226.  Should I keep adding fixes to the one debdiff, or do I need to post separate debdiffs for each bug?
[20:42] <sistpoty> andersk: one debdiff is preferred
[20:43] <andersk> Great.  Thanks.
[20:47] <silas428> Is C essential to developing for Ubuntu, or can I use other languages?
[20:48] <mrooney> silas428: it is not at all! many desktop things are done in Python
[20:48] <mrooney> and if you are writing your own app, you can use pretty much anything
[20:48] <mrooney> C#, Vala
[20:48] <silas428> My programming skills aren't good enough to program my own apps
[20:48] <silas428> How about fixing bugs etc?
[20:48] <DaSkreech> Hello
[20:49] <mrooney> silas428: for fixing bugs, you will just be limited to fixing non-C bugs
[20:49] <silas428> mrooney: where can I find some python desktop things? I have done some reading on python
[20:49] <DaSkreech> Is there any chan for the Aluetian islands?
[20:49] <mrooney> silas428: however looking at bitesize C bugs might be on your level and could help you learn
[20:50] <silas428> Do the intro programming books help any for fixing bugs?
[20:50] <silas428> or learning to fix bugs
[20:50] <DaSkreech> I don't think there are any for the chukcha language
[20:51] <mrooney> silas428: I'd check out https://wiki.ubuntu.com/UbuntuDeveloperWeek
[20:51] <mrooney> for example the second Wed talk
[20:52] <mrooney> also https://wiki.ubuntu.com/UbuntuOpenWeek is likely to be helpful
[20:54] <silas428> thanks
[20:55] <DaSkreech> I've never even heard of chukcha before :-(
[21:47] <Vest84> guys, I've found in the internet the next lines: Clutter and Cluttermm packages are probably available from your Linux distribution. For instance, on Ubuntu Linux or Debian you can install the libcluttermm-0.9-dev package But there is no packages with this name in packages.ubuntu.com
[21:47] <Vest84> do you know they exist?
[21:50] <rexbron> tseliot: Is there a particular reason why the dontzap class is part of the cli gui?
[21:50] <rexbron> or cli interface rather
[21:56] <tseliot> rexbron: what's the problem?
[21:59] <tseliot> rexbron: the methods in that class are used to talk to kubuntu's control panel (which is written in C++)
[22:09] <rexbron> tseliot: Ubuntu Studio is looking at disabling the dontzap option by default and want to provide a gui method to enable it if users so desire. Since dontzap is written in python and so is ubuntstudio-controls, I was looking at calling the dontzap methods directly from there  rather than creating a subshell
[22:13] <tseliot> rexbron: you can copy that class then and depend on python-xkit.
[22:13] <tseliot> The implementation in Kubuntu calls it from the command line and it works well though
[22:14] <tseliot> the Python class is only a few lines
[22:17] <directhex> Vest84, not in the archive - even jaunty has only 0.8
[22:19] <Vest84> directhex: so, you mean the information is wrong?
[22:19] <directhex> Vest84, seems so.
[22:19] <Vest84> take a look please
[22:19] <Vest84> http://www.openismus.com/documents/cluttermm_tutorial/0.9/docs/tutorial/html/sec-installation.html
[22:20] <Vest84> directhex: what do you think ab. it?
[22:21] <rexbron> tseliot: I'm pushing a branch that has DontZap factored out as a module and has the dontzap script import it
[22:22] <RainCT> ScottK-desktop or some other Kubuntu guy: in Jaunty there is no system-config-printer-kde executable anymore. I guess this is normal and now it can only be launched from some control panel?
[22:23] <ScottK> RainCT: I don't recall.
[22:23]  * ScottK looks at JontheEchidna.
[22:23] <JontheEchidna> It's launchable from System Settings now
[22:24] <tseliot> rexbron: ok, I'll have a look at it ASAP (it's night here)
[22:24] <JontheEchidna> It's in the Advanced tab iirc
[22:24] <RainCT> Okay, thanks. Just to be sure that it isn't missing :)
[22:25] <rexbron> tseliot: I hope I'm not misunderstanding you but asap usually refers to very quickly and I think you are implying "when I can"
[22:25] <JontheEchidna> It might be better placed in the Computer Administration section instead of the System section in the advanced tab..
[22:25] <nemo> what the heck happened to libsdl-net1.2-dev in jaunty?
[22:25] <nemo> and libsdl-net1.2 for that matter
[22:27] <rexbron> tseliot: https://code.edge.launchpad.net/~rexbron/dontzap/trunk.dontzap_as_module
[22:27] <tseliot> rexbron: yes, it's more like "when I can". It's been a rather stressing period and I have to fix a nasty bug (which has the highest priority now)
[22:28] <rexbron> tseliot: is there anyone else who could look at that branch? bryce is listed as a contributer
[22:30] <tseliot> rexbron: he reviewed my code but he might be very busy too
[22:30] <rexbron> tseliot: I can ask :)
[22:30] <tseliot> ok
[22:31] <nemo> eek. you guys got rid of fpc too :(
[22:32] <tseliot> rexbron: on a second thought (now that I can see the diff) I think I can have a look at it tomorrow. It shouldn't take long
[22:33] <tseliot> well, tomorrow in Italy ;)
[22:34] <tseliot> (the time zone)
[22:35] <nemo> hm. restoring the Ibex packages seems to work fine. I wonder why they were removed
[22:35] <rexbron> tseliot: thanks!
[22:36] <tseliot> rexbron: np. Good night
[22:49] <nemo> frig. no a52dec-dev either
[22:52] <maxb> nemo: removal reasons should be given on https://launchpad.net/ubuntu/+source/<sourcepackagename>
[22:54] <maxb> sdl-net1.2 is still there in jaunty
[22:54] <maxb> fpc is still there in jaunty
[22:54] <maxb> a52dec is still there in jaunty
[22:55] <maxb> nemo: I call pilot error :-)
[22:55] <nemo> maxb: hmmmm
[22:55] <nemo> maxb: where are you finding these?
[22:55] <nemo> for i386
[22:55] <maxb> https://launchpad.net/ubuntu/+source/a52dec
[22:55] <maxb> https://launchpad.net/ubuntu/+source/fpc
[22:55] <maxb> https://launchpad.net/ubuntu/+source/sdl-net1.2
[22:55] <nemo> source packages are there, yes :)
[22:56] <maxb> Well... if the binaries have gone missing, that's worrying
[22:57] <nemo> maxb: if you drill down to i386, only binaries listed for all these are Intrepid
[22:57] <nemo> maxb: I've been slowly adding the intrepid ones by hand, one at a time.
[22:57] <nemo> which was working out ok, right up until I ran into fp-units-multimedia which wanted a52dec-dev
[22:57] <nemo> which I can't seem to find even an Intrepid package of, oddly.
[22:58] <nemo> maxb: certainly they aren't in the repository
[22:58] <nemo> which is pretty nutty for libsdl-net I have to say
[23:01] <maxb> so, um, I can see libsdl-net1.2 in jaunty i386 and amd64 Packages file
[23:01] <maxb> So what's the problem?
[23:01] <nemo> If I go to:
[23:01] <nemo> https://launchpad.net/ubuntu/jaunty/i386/libsdl-net1.2/1.2.7-2
[23:02] <nemo> the only downloadable file was for hardy RELEASE
[23:02] <nemo> is this ok?
[23:02] <maxb> yes
[23:02] <nemo> if so, I must be missing something more fundamental about package management in ubuntu
[23:02] <nemo> do I need to enable some hardy repo in order to install all this in Jaunty?
[23:02] <maxb> No
[23:02] <nemo> 'cause the default repo said that libsdl-net1.2 wasn't available
[23:03] <maxb> bad mirror?
[23:03] <nemo> no. said it was literally not available.
[23:03] <maxb> Well, it is available
[23:03] <nemo> masked or whatever. not familiar with the terminology precisely
[23:04] <nemo> anyway. so I installed off of the link above, the Hardy package
[23:04] <nemo> but. let me remove it, try reinstalling, and get the precise error
[23:04] <maxb> That's a kludgy way to do it
[23:04] <nemo> didn't say I knew this stuff...
[23:04] <nemo> Packkage libsdl-net1.2 is not available, but is referred to by another package.
[23:05] <nemo> This may mean that the package is missing, has been obsoleted, or is only available from another source
[23:05] <maxb> apt-get update
[23:05] <nemo> that seems an odd reason given I just updated to Jaunty minutes ago :)
[23:05]  * nemo does it anyway
[23:07] <nemo> and heck. why'd it uninstall 'em in the first place on update, unless they had been obsoleted
[23:07] <nemo> I had a functioning libsdl-net1.2-dev which I let it uninstall thinking I had to perhaps install libsdl-net1.3 or somesuch
[23:09] <nemo> maxb: *sigh* you were right :(
[23:09] <maxb> O:-)
[23:10] <nemo> now why didn't it do that *FOR* me :-p
[23:15] <directhex> dear firefox, of all the times to crash, when i click "confirm booking" is not one of them. no love, directhex
[23:15] <nemo> directhex: can I see the crash stack from about:crashes ?
[23:16] <nemo> want to see if flash or java might have been at fault.
[23:16] <nemo> 'course could be just some buggy plugin you have :)
[23:16] <nemo> er. extension.
[23:16] <directhex> The URL is not valid and cannot be loaded.
[23:19] <directhex> This booking has already been made. If you feel this is wrong please contact us at the phone number at the bottom of this page.
[23:19] <directhex> could be worse
[23:19] <mok0> karmic koala!
[23:20] <nemo> heh
[23:20] <nemo> hm. now why on earth is Qt sucking up 100% of my CPU in Jaunty
[23:20] <nemo> laptop is just churning away
[23:21]  * nemo checks to see what libqt packages changed
[23:21] <nemo> great. 4.5.0 :-/
[23:21] <nemo> guess I can forcibly revert to Ibex on those
[23:38] <genii> Hi, is launchpad currently down? Trying to participate in the BugJam but keep getting "try reloading"
[23:39] <JontheEchidna> nah, it's still up. It's just doing that more than often
[23:39] <mrooney> genii: #launchpad  would be the appropriate place to inquire, and it is a known issue :)
[23:40] <JontheEchidna> *more than usual
[23:40] <genii> mrooney: Great, thanks
[23:43] <nemo> looks like I'm running into http://www.qtsoftware.com/developer/task-tracker/index_html?method=entry&id=173328
[23:43] <nemo> I suppose I should file it as a Jaunty bug too, as a warning to others :)
[23:43] <nemo> hm. n/m. that can't be the right bug.
[23:44] <nemo> wrong reason
[23:44] <nemo> right place, wrong reason :)
[23:46] <nemo> oh well. enough whinging in here. I didn't actually have any *ubuntu* problems that an update couldn't fix. later y'all
[23:51] <mrooney> Any idea why my Intrepid package is saying "Error: Dependency is not satisfiable: python-central"
[23:56] <goshawk> for an ubuntu-security member: bug #292923 have been solved in jaunty with the next version 1.2.4 . This version is just a security fix, i think it could be backported to intrepid too..