[01:42] <stgraber> asac: FF3 rocks, I just have some weird font size on LP (on +builds especially), everything else seems to work
[06:40] <pitti> Good morning
[06:40] <StevenK> Morning pitti
[06:40] <LaserJock> morning pitti
[06:42] <warp10> hi pitti, good morning!
[06:42]  * pitti hugs the crowd
[06:59] <YokoZar> what is the reason the old, unsupported repositories are deleted?  If I have a hoary installation now I can't even dist-upgrade it to breezy then dapper
[07:00] <YokoZar> Or did they just get moved?
[07:01] <LaserJock> I think they were moved
[07:02] <YokoZar> LaserJock: know where are they moved to?
[07:05] <YokoZar> ahh, old-releases.ubuntu.com
[08:10] <soren> Over the last few days, I've gotten e-mails about failed builds of open-vm-tools on powerpc, ia64, and lpia. However, p-a-s says only to build them on i386 and amd64.. What gives?
[08:11] <thegodfather> soren: that you should have mention this to #launchpad where it belongs?
[08:11] <thegodfather> :)
[08:12] <soren> Smart arse.
[08:12] <soren> :)
[08:12] <thegodfather> ahha
[08:52] <soren> cjwatson_: I just stumbled upon a note saying that I should pester you about the debconf bug we worked out about a month ago.. It would probably be good to get it in in time for alpha 3. My note says the fix is in r2249, but I may have just noted that for SRU purposes.
[08:54] <pitti> mvo: if you upload a new apt soon, can you please build it against libdb-dev instead of libdb4.4-dev along the way?
[08:55] <mvo> pitti: sure, I fix this in bzr now
[08:55] <pitti> mvo: *hug*, thanks
[08:55]  * Fujitsu hopes for a new apt which fixes that libc6 issue.
[08:55]  * pitti blinks -- php5 build-depends against libdb4.4 and depends against libdb4.5??
[08:55] <Fujitsu> php5 and apache2 do evil things together, IIRC.
[08:58] <soren> pitti: Erm.... That's a bit unfortunate. I received a patch that ought to have fixed that, but apparantly it didn't.
[08:58] <pitti> soren: I'll clean it up
[08:58]  * soren hugs pitti
[08:59] <soren> pitti: Thanks!
[08:59] <pitti> soren: I just uploaded apr-utils to link against db4.6, and preparing subversion to do the same
[08:59] <pitti> (since they need to go in lockstep)
[08:59] <pitti> once these are built, we can build php5 against db4.6, too
[08:59] <soren> php5 /needs/ to follow suit as well.
[08:59] <pitti> soren: patch> anything complicated, or just the usual 'switch version numbers' build stuff?
[09:00] <pitti> soren: right, at it; but apr-utils needs to build first before we can upload svn and php
[09:00] <soren> pitti: The latter.
[09:00] <soren> pitti: Sure, sure.
[09:00] <pitti> right
[09:00] <soren> pitti: debian/patches/use-specific-libdb-version.patch
[09:00] <pitti> soren: that's applied in hardy
[09:00] <soren> pitti: Yes?
[09:00] <soren> pitti: ...and that's the one you probably want to remove.
[09:01] <soren> pitti: We're not talking hardy stuff here?
[09:01] <pitti> soren: I think I need to keep the patch and make it check for 4.6 (it only checks up to 4.5 upstream)
[09:01] <soren> pitti: Ah, yes. That sounds right.
[09:02] <mvo> Fujitsu: I'm working on a fix for this currently, would you like to help and test it once its ready?
[09:03] <Fujitsu> mvo: Sure, I've got a test environment in schroot here from when I was debugging it in the first place.
[09:03] <mvo> Fujitsu: cool! thanks
[09:04] <Fujitsu> I'm glad it turned out to be an apt bug and that I wasn't missing something simple.
[09:07] <persia> archive-admins: I've been reviewing Debian changes, and pushing sync bugs, and notice that the holiday backlog is becoming large.  Is this expected, or would it be helpful for me to process syncs rather than just pushing bugs?
[09:10] <pitti> persia: we'll get to it; what do you mean with 'process syncs'? using my script?
[09:10] <persia> pitti: precisely
[09:10] <pitti> persia: if there are urgent ones which block work, feel free to do so, but the bulk should be done with the soyuz tool IMHO
[09:10]  * Fujitsu wishes for a `sync' button.
[09:11] <persia> pitti: It's the opinion I sought.  Nothing urgent, I just saw the U-A queue was over 100 bugs, and didn't want to be causing lots of extra work.  Thanks.
[09:48] <pitti> carlos: btw, any idea when we can get hardy langpacks?
[09:48] <Fujitsu> Or universe langpacks?
[09:48]  * Fujitsu hides quickly.
[09:49] <pitti> persia: hm, since my box is currently building three huge packages in parallel and can't do much more, I'll do some syncs now :)
[09:50] <persia> pitti: Thanks.  There's a heap of apache (1) related removals in queue as well.
[09:50] <Fujitsu> Yay! Kill kill kill!
[09:51]  * persia thanks awen for aggressive research to hunt them down and explain why they must die (including updating those that could be rescued)
[09:51] <pitti> persia: yummy
[09:53] <StevenK> Yay! Die, apache 1!
[09:53] <Fujitsu> Apache 1 is long dead.
[09:53] <StevenK>           rescued)
[09:53] <StevenK> Ooops
[09:54] <mvo> Fujitsu: do you prefer a patch or a package to test my fix? (if package, what arch?)
[09:54] <Fujitsu> Nice job.
[09:54] <carlos> pitti: I don't know. Seems like the initial Hardy opening failed
[09:54] <StevenK> steven@liquified:~% HEAD http://wedontsleep.org/ | grep Server
[09:54] <StevenK> Server: Apache/2.2.6 (Ubuntu) mod_ssl/2.2.6 OpenSSL/0.9.8a
[09:54] <carlos> pitti: I'm not working in Translations this month, let me check with jtv...
[09:54] <StevenK> That was my pain to do last night ^
[09:54] <pitti> carlos: ah, I see
[09:54] <Fujitsu> mvo: It only takes a couple of minutes to build, but a binary is always nice, if you can do i386.
[10:01] <mvo> Fujitsu: please give http://paste.ubuntu.com/3244/plain/ a try, works on my test-case
[10:01] <Fujitsu> mvo: Looking;
[10:07] <carlos> pitti: jtv tells me that the copy from Gutsy is already done, he's going to do some extra testing today and start importing Hardy's files
[10:08] <carlos> pitti: it would take around a week to get everything imported (at least the basic parts)
[10:08] <pitti> hm, that sounds like the status we had one week after opening hardy
[10:08] <carlos> pitti: do you want a language pack export with the translations from Gutsy or wait until we catch up with all translated files from Gutsy?
[10:09] <carlos> pitti: yeah, although seems like he detected an error and he had to revert the opening
[10:09] <pitti> carlos: no, we only need a current hardy one
[10:09] <pitti> we already have the ones from gutsy
[10:09] <carlos> pitti: I mean to generate a Hardy one with gutsy data
[10:09] <pitti> carlos: right, I understand; however, we already have that
[10:10] <carlos> ok
[10:10] <carlos> so you prefer to wait until Hardy translations are mostly imported
[10:10] <Fujitsu> mvo: Works fine on the two broken setups I had here.
[10:12] <mvo> Fujitsu: nice! thanks for testing
[10:12] <Fujitsu> mvo: Thanks for fixing it.
[10:13] <Fujitsu> Do we know why this only appeared last week?
[10:15] <mvo> Fujitsu: not in detail, something in the dependencies must have changed to trigger it. but it seems like this is a old bug.
[10:15] <mvo> Fujitsu: it seems like it was pure chance that we did not hit it earlier
[10:16] <Fujitsu> Ah.
[10:20] <mvo> but its only triggered when essential=yes packages are involved and there are not that many of those
[10:20] <persia> pitti: Why do my sync bugs need an ack from a MOTU?
[10:20] <pitti> persia: they don't?
[10:21]  * persia hunts down the source of the confusin
[10:22] <pitti> persia: I subscribed ubuntu-universe-sponsors to three sync bugs from non-MOTUs
[10:22] <pitti> you might have gotten the bug mail
[10:23]  * TheMuso saw those.,
[10:23] <persia> pitti: Actually, I apparently forgot to include "ACK" when updating those decriptions.  Fixing now (after solidly thwacking self)
[10:27] <Tonio_> hello everyone and happy new year
[10:36] <pitti> hi Tonio_! and to you!
[10:37] <Tonio_> hey pitti :)
[11:44] <Hobbsee> wow, something's borken
[11:47] <Hobbsee> asac: erm, does thunderbird need to be built for the new libnss stuff?
[11:47] <asac> Hobbsee: hmm ... in a perfect world this wouldn't be needed
[11:48] <asac> i think i tested it
[11:48] <asac> what happens?
[11:48] <Hobbsee> asac: the 2 libnss versions have file conflicts.
[11:48] <Hobbsee> so by force overwriting with the firefox-3.0 version, i get a message in thunderbird about teh security components being disabled (there is more to that message, but that's the gist)
[11:48] <asac> if installed it works for me
[11:49] <asac> which version do you have installed?
[11:49] <Hobbsee> ahhh
[11:50] <asac> Hobbsee: 3.12.0~1.9b2+nobinonly-0ubuntu1 thats what i have
[11:50] <asac> libnss-0d + libnss-1d
[11:50] <Hobbsee> asac: sorry, it's Ubulette's version, from when i was using those firefox packages
[11:50] <Hobbsee> as beta 2 hadn't hit the repos yet
[11:50] <asac> ah right ... the versioning is borked in his archive
[11:50] <Hobbsee> well, even so
[11:50] <asac> just --reinstall with the official sources
[11:50] <Hobbsee> but downgrading to the one in the archive brings it back correctly
[11:51] <asac> yep
[11:51] <asac> ok thanks
[11:52] <Hobbsee> asac: sorry for the wrong poke :(
[11:52] <asac> welcome
[12:07] <StevenK> asac: Mind looking at the libtinymail 0.0.6 FTBFS? It built for me locally.
[12:13] <asac> StevenK: thought you didn't use xulrunner for now? (but gtkhtml) ?
[12:14] <asac> ripping out 99.9% of the gtkmozembed patch? you have an interdiff for that?
[12:15] <StevenK> I ripped out 99.9% because I thought it was applied upstream
[12:17] <StevenK> asac: http://wedontsleep.org/~steven/xul-005-006-inter.diff
[12:19] <StevenK> Although, that thought did occur while updating to 0.0.6
[12:20] <StevenK> asac: Never mind about it now, I'll dump that patch and fix it to use gtkhtml.
[12:21] <StevenK> asac: Thanks, I'm now remembering what happened in the dim dark recesses the last time I touched this thig.
[12:24] <pitti> Riddell: soprano> can you please use Xbuild1 versions for these 'fake' syncs?
[12:25] <asac> StevenK: all this XPCOM_GLUE code was needed ... otherwise it won't really work.
[12:25] <StevenK> libtool, I am going get you. And then I'm going to eat your liver.
[12:25] <Riddell> pitti: would that not be in danger of having broken syncs in future if it tried to sync but the .orig didn't match?
[12:25] <StevenK> libtool: link: cannot find the library `/usr/lib/libdirectfb.la' or unhandled a
[12:25] <StevenK> rgument `/usr/lib/libdirectfb.la'
[12:26] <pitti> Riddell: right, but it gets autosynced as soon as Debian has a new upstream version
[12:26]  * pitti hugs StevenK
[12:30] <StevenK> Right, libdirectfb doesn't provide a .la anymore
[12:34] <StevenK> directfb (1.0.1-1) experimental; urgency=low
[12:34] <StevenK> ...
[12:34] <StevenK>   * Do not ship the .la files in libdirectfb-dev.
[12:34] <StevenK> ARGH!
[12:34]  * StevenK adds Guillem Jover to his liver-gram list, and looks at slangasek.
[12:36] <StevenK> pitti: So, do we add back the .la file and clean it, or what?
[12:37] <asac> pitti: will there be a PK privilege for "can user install package" ?
[12:37] <pitti> StevenK: or rebuild all dependencies?
[12:38] <pitti> asac: nope, we don't have packagekit yet
[12:38] <StevenK> pitti: I've had to any way -- NBS. But one of them wants the .la
[12:38] <pitti> asac: for that you should call synaptics or gnome-app-isntall (the latter already has the gksu stuff)
[12:38] <asac> ok ... but if we had it, would there be an easy why to query if current user would have that privilege?
[12:38] <pitti> asac: you can ask PK to grant it, yes (dbus call)
[12:39] <asac> well ... i need to decide on whether to provide users with a "install package" feature (e.g. plugin finder dialog in firefox)
[12:39] <pitti> asac: it'll either answer YES (you got it), NO (you can't get it), or NO_AUTH (you don't have it, but can enter your password to get it)
[12:39] <asac> ah good
[12:39] <asac> so NO_AUTH would be it
[12:39] <pitti> asac: but don't count on this for hardy
[12:39] <pitti> asac: for that I'd just check if the user is in group admin
[12:39] <asac> yeah ... i think we just look for admin group for now
[12:39] <pitti> and if so, call gksu synaptic or so
[12:41] <asac> ok great ... i won't implement it right away anyway. just was curious if there is a real solution on the radar :)
[12:41] <pitti> yes, there is; depending on when/whether packagekit ever gets ready
[12:42] <asac> ;)
[12:50] <afflux> apport doesn't generate crash reports anymore on my hardy system, but I have some cases where I'd like to see one. Can you give me a hint on how to re-enable apport?
[12:59] <pitti> afflux: are you running the 2.6.24 kernel?
[12:59] <afflux> no
[12:59] <pitti> afflux: current apport needs it
[12:59] <afflux> ah
[12:59] <pitti> afflux: 2.6.24 finally adopted some patches which are needed for apport, but implements them slightly differently
[13:00] <afflux> I see... I didn't switch because it was so slow :(
[13:00] <pitti> so it won't change again in the future at least
[13:00] <pitti> yeah, I noticed some slowdown, too, but it was mostly subjective; a hard timing on boot speed didn't reveal any difference
[13:01] <afflux> Most applications, especially firefox or even gnome were starting really slow.
[13:01] <afflux> anyway, I'll have a try again
[13:01] <afflux> thanks
[13:20] <TheMuso> Can I safely assume that fontforge having a dependency wait on a package in universe, libspiro-dev is known, and that someone plans to either MIR libspiro-dev, or upload a fixed fontforge? If not, I'll file a bug
[13:21] <Hobbsee> TheMuso: oh, grrr.  i relinquish my TIL responsibility, as i did not cause that bug.
[13:22] <TheMuso> TIL?
[13:22] <Hobbsee> touched it last
[13:22]  * Hobbsee just uploaded a rebuild of it
[13:22] <TheMuso> oh
[13:24] <Hobbsee> asac: exaile's broken :(
[13:24]  * TheMuso thinks we need a script to check that a source package's build-deps are all in main, if we don't have that already.
[13:24] <Hobbsee> TheMuso: there is one
[13:24] <TheMuso> Oh ok.
[13:24] <TheMuso> Hobbsee: What is it?
[13:25] <StevenK> http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
[13:25] <Hobbsee> TheMuso: i think it's in ubuntu dev tools
[13:25] <Hobbsee> StevenK: no, not that
[13:25] <StevenK> Surely that tells most of the story?
[13:25] <Hobbsee> StevenK: only after it's been uploaded, yes.
[13:25] <TheMuso> StevenK: Preferably something to check before one uploads.
[13:26] <TheMuso> Ah yes, 404main
[13:26] <Hobbsee> that's the one.
[13:35] <mvo> a new apt is uploaded that should fix the issue with the libstdc++6 configure problem - please let me know if there are still issues or if it has unintended side-effects
[13:36] <asac> Hobbsee: exaile? universe? already ported to xul?
[13:37] <Hobbsee> asac: unsure on porting status.
[13:37] <Hobbsee> asac: but yes, the one in universe
[13:37] <Hobbsee>   File "/usr/share/exaile/xl/mozembed.py", line 29, in <module>
[13:37] <Hobbsee>     import gtkmozembed
[13:37] <Hobbsee> SystemError: dynamic module not initialized properly
[13:37] <StevenK> Mmm, yummy.
[13:37] <Hobbsee> location: /usr/lib/xulrunner-1.9b3pre/libxpcom.so
[13:37] <Hobbsee> before 3
[13:37] <asac> Hobbsee: which version of python-gnome2-extrase?
[13:38] <Hobbsee> asac:
[13:38] <Hobbsee> python-gnome2-extras:
[13:38] <Hobbsee>   Installed: 2.19.1-0ubuntu6
[13:40] <asac> damn ... i forgot to add a the version to the build-depends
[13:40] <asac> Hobbsee: anyway, pitti uploaded ubuntu7 ... which should be built agains the right xul (because its already avail)
[13:40] <asac> try to upgrade to that
[13:41]  * Hobbsee updates, again
[14:16] <pitti> asac: btw, great ffox-3.0 upgrade! feels much better now, although it still doesn't support adblock and flash :/
[14:17] <ion_> Adblock Plus works for me.
[14:17] <ion_> It probably should be used instead of the old Adblock anyway.
[14:19] <asac> flash is updated as well pitti
[14:19] <Hobbsee> pitti: why no flash?  no gnash?
[14:19] <pitti> ion_: oh, wasn't aware of that
[14:19] <stgraber> hmm, I have Adblock plus and flash9 working here
[14:19]  * Hobbsee hasn't played with flash.  it just works
[14:20] <stgraber> Only problem I see with FF3 is broken LP layout on some pages ...
[14:20] <pitti> asac, Hobbsee: I'm using the non-free plugin with nspluginwrapper (amd64)
[14:20] <ion_> Flash didn’t work for me out of the box either, but i haven’t cared about it enough to investigate yet.
[14:20] <ion_> (32-bit)
[14:20] <pitti> gnash crashes way too often for me
[14:21] <pitti> I should try it again, though
[14:21] <stgraber> running flash9 + nspluginwrapper on ff3 here and works fine
[14:21] <pitti> asac: but anyway, when I open a page with flash, the ffox plugin search does not offer me anything, neither macromedia's nor gnash
[14:21] <pitti> in ffox 2 it works fine
[14:21] <ion_> I take it the Flash plugin should go to /usr/lib/firefox-addons/plugins to work with FF3? The dir’s empty.
[14:21] <asac> pitti: ah :)
[14:22] <asac> pitti: ffox 3 doesn't have ubufox yet ... just install flashplugin-nonfree
[14:22] <asac> i updated it today to install links to xul 1.9
[14:22] <pitti> ah, ubufox
[14:22] <stgraber> ah yes, I had to copy some symlinks IIRC to have my plugins to work with FF3
[14:22] <pitti> asac: I have that installed already (for ffox 2)
[14:22] <ion_> asac: Ok, the update probably just hasn’t reached my mirror yet.
[14:22] <asac> pitti: then wait for upgrade
[14:22] <asac> most likely
[14:23] <asac> the upgrade should install the flashplayer-alternative.so in /usr/lib/xulrunner-addons/plugins/
[14:24] <asac> https://edge.launchpad.net/ubuntu/+source/flashplugin-nonfree/9.0.115.0ubuntu3
[14:24] <seb128> asac: does that mean all the plugins packages should be transitionned?
[14:24] <stgraber> asac: what about totem and vlc plugins ? I have those two in FF2 but I had to copy the symlinks by hand to have them working with FF3
[14:25] <asac> seb128: well ... totem not yet .. it uses some parts of xul api, so we can build either/or ... the other plugins should be upgraded now
[14:26] <asac> stgraber: most likely vlc can be migrated ... maybe the current .so just works when linked to the plugins dir?
[14:26] <asac> stgraber: old totem works for you?
[14:26] <asac> (in new ffox)?
[14:26] <stgraber> nope, just gave it a try and FF3 crashed
[14:26] <asac> yes
[14:26] <asac> vlc?
[14:27] <stgraber> trying vlc now
[14:28] <stgraber> I have a "no video" text appearing but it's probably a video codec issue as audio is ok
[14:29] <stgraber> trying mplayerplugin now
[14:29] <asac> stgraber: the no video text is rendered by the vlc plugin ig guess?
[14:30] <stgraber> asac: yes
[14:30] <stgraber> mplayer works fine
[14:30] <stgraber> so both can be migrated
[14:32] <asac> good ... they should be built against xul 1.9 though
[15:20]  * mvo wonders if anyone else got a "primaty superblock features different from backup, checked forced" recently
[15:21] <geser> mvo: I've seen it too when I upgraded from gutsy to hardy
[15:26] <afflux> mjg59: a number of people (I know some in the german forum.ubuntuusers.de) complain about not having s2ram in the uswsusp package and having no real statement of developers in bug #134238. They think that actually having s2ram is not more confusing than hiding it in uswsusp. Maybe you can have a look at the bug and give your statement. :)
[15:26] <ubotu> Launchpad bug 134238 in uswsusp "Please re-enable build of s2ram binary" [Wishlist,Confirmed] https://launchpad.net/bugs/134238
[15:27] <mvo> geser: thanks, found the report about it now
[15:30] <bluekuja> pitti, up for a question?
[15:32] <pitti> bluekuja: please don't ask to ask, just ask :)
[15:33] <bluekuja> pitti, Debian's gmsh is missing 2.0.7-1.1 changelog's entry (maybe the maintainer did not acknowledge the NMU) but Ubuntu got it (2.0.7-1.1ubuntu1)
[15:33] <ion_> bluekuja: Up for an answer to your question regarding whether pitti is up for a question?
[15:33] <bluekuja> pitti, should I keep it as valid?
[15:33] <bluekuja> ion_, lol
[15:34] <pitti> bluekuja: 'keep' -> you mean when merging it and writing the changelog? sure, can't hurt
[15:34] <bluekuja> ion_, just wanted to know if he was around, don't get angry now
[15:34] <bluekuja> pitti, yep, I mean adding that entry each time (e.g with other ubuntu entries)
[15:35] <bluekuja> pitti, thanks for the hint
[15:35] <pitti> bluekuja: 'each time' -> 'once', i.e. right now?
[15:36] <bluekuja> pitti, why once? if the debian package arrives to ubuntu without that entry, I should add it every time
[15:36] <bluekuja> pitti, as a remaining change then
[15:36] <pitti> bluekuja: right; well, if it causes any trouble, just drop it
[15:37] <bluekuja> pitti, so I drop it, but I keep the ubuntu entry derived from that one, right?
[15:37] <bluekuja> pitti, e.g I remove 2.0.7-1.1 but I keep 2.0.7-1.1ubuntu1
[15:37] <pitti> bluekuja: yes, please keep all ubuntu changelogs which were ever uploaded
[15:37] <pitti> yes
[15:38] <bluekuja> pitti, great, thanks
[15:42] <mvo> soren: meh, kvm does no longer work for me (on amd64), do you know anything about this? unahndled vm exit: 0x0 vcpu_id 0 (I can report a proper bug if you want)
[15:42] <soren> mvo: After today's update?
[15:42] <soren> mvo: Is your kernel up-to-date?
[15:43] <mvo> soren: kvm is 1:59+dfg-0ubuntu1 and kernel is 2.6.24-2.4 (upgraded a couple of minutes ago)
[15:43] <mvo> kvm -no-kvm works ok
[15:45] <soren> mvo: A bug report would be nice. I'll look into it *real* soon, there' just something else I need to get out of the way first.
[15:45] <mvo> soren: sure, thanks
[15:48]  * soren takes a quick break
[15:49] <mvo> soren: LP 180105
[15:49] <ubotu> Launchpad bug 180105 in kvm "unhandled vm exit" [Undecided,New] https://launchpad.net/bugs/180105
[15:49] <mvo> (just FYI)
[15:54] <wasabi> apt question using a recent example:   new mono package 1.2.6, it apparently no longer provides the package 'mono'. So, my system refuses to upgrade to 1.2.6 safely because doing so would cause a conflict with 'mono' 1.2.4.  Should this be bypassed because a given package should declare it Replaces 'mono'?
[16:01] <rpereira> Hey everybody. Does someone knows why epiphany-webkit isn't on hardy repository?
[16:07] <soren> mvo: Could you try using the modules from the kvm package? Just "sudo m-a a-i kvm; sudo rmmod kvm-intel; rmmod kvm ; sudo depmod -a ; sudo modprobe kvm-intel" ought to do it.
[16:09] <mvo> soren: sure, I will do that once my current vm session has ended
[16:10] <soren> mvo: Cool.
[16:10] <soren> mvo: Are you on intel hardware?
[16:10] <mvo> soren: no, amd64
[16:11] <soren> mvo: Well, that's what we call 64 bit Intel as well :)
[16:11] <mvo> eheh
[16:11] <mvo> its a amd-v
[16:11] <soren> I run the amd64 version on Intel Core 2 Duo.
[16:11] <soren> mvo: I see.
[16:13] <soren> mvo: This happens with all images?
[16:14] <geser> I looked at the fakeroot FTBFS and tracked it down to the configure check if shell understands "+=" but I fail to understand why the check succeeds and how to fix it.
[16:14] <soren> Oh, if it's amd, you of course rmmod kvm-amd, but you probably guessed :)
[16:14] <mvo> soren: I tested only two images that are very similar (one is the other a bit later in time) - I can test more
[16:18] <soren> mvo: Can you boot an iso at all?
[16:29] <soren> mvo: Fantastic. That's broken, too.
[16:32] <mvo> soren: rebuilding the kvm module seems to have done the trick
[16:32] <soren> mvo: eh? That worked.
[16:33] <soren> mvo: I mean: What worked?
[16:33] <soren> fsck... Typing is hard.
[16:33] <soren> I'm trying to express my confusion that m-a managed to build the modules. It's failing to build here.
[16:33] <mvo> soren: it looks like everything is back to normal with it, booting my test-image works, booting a iso works too
[16:34] <soren> mvo: I know there was an issue in 58, but I thought it had been fixed in 59, but you seem to be right.
[16:34] <mvo> soren: so 59 is ok for me now (after rebuilding the modules)
[16:34] <soren> mvo: Noted.
[16:36] <mvo> thanks for your help soren
[16:36] <soren> mvo: Thanks for pointing it out. I'm a bit confused how that slipped through.
[16:44] <soren> mvo: I've got a fix that I need to test. I'll have it uploaded so that there's a fresh, working version for you tomorrow morning.
[16:44]  * soren has to run for a few minutes.
[16:44] <mvo> soren: woah, that was quick! thanks a lot
[16:47] <geser> pitti: have you an idea what happened to the libsaxon-java binaries you moved from multiverse to universe in december ? they are gone
[16:51] <geser> it looks like soyuz ate all arch:all packages from the packages moved in bug #176139 :(
[16:51] <ubotu> Launchpad bug 176139 in libtoolbar-java "Please move package to universe" [Wishlist,Fix released] https://launchpad.net/bugs/176139
[17:18] <tjaalton> humm, the flac security update on November seems to have broken xmms-flac (bug 162704)
[17:18] <ubotu> Launchpad bug 162704 in flac "[Feisty] update of xmms-flac disables plugin" [Medium,Confirmed] https://launchpad.net/bugs/162704
[17:27] <Mez> tjaalton, I read that as "xmas-flac" - was thinking that it should have be reported in December ;)
[17:29] <tjaalton> Mez: hehe :)
[17:30] <geser> is the libstdc++6 upgrade error back in the powerpc buildd chroot?
[17:46] <slangasek> StevenK: um... but directfb stopped shipping that .la file a month ago in unstable, and it doesn't seem to have caused problems (presumably due to an accompanying soname change?)
[17:50] <pitti> geser: boggle
[17:50] <pitti> cprov: any idea where the libsaxon-java binary went to in hardy? I just moved it from multiverse to universe a while ago
[17:51] <cprov> pitti: no, let me check
[17:52] <cprov> pitti: both superseded ? https://edge.launchpad.net/ubuntu/hardy/i386/libsaxon-java/+index
[17:53] <pitti> cprov: it hasn't changed since edgy, might that be the reason?
[17:54] <cprov> pitti: no, the superseded message doesn't make sense
[17:54] <pitti> cprov: yeah, it's superseded by its own version
[17:54] <pitti> argh, subspace will implode!
[18:00] <geser> pitti: didn't get the powerpc chroot fixed or is it broken again?
[18:01] <pitti> geser: it was fixed; might be broken again
[18:01] <pitti> infinity: ^ any idea? mvo uploaded a fixed apt today, but I guess it requires manual intervention to get that one into the broken chroot
[18:01] <geser> the last build logs for powerpc have "E: Internal Error, Could not perform immediate configuration (2) on libstdc++6" again
[18:05] <infinity> Ungh, broken again?
[18:05] <infinity> geser: Example log?
[18:06] <geser> infinity: http://launchpadlibrarian.net/11137476/buildlog_ubuntu-hardy-powerpc.peercast_0.1218%2Bsvn20071220%2B2-1_CHROOTWAIT.txt.gz
[18:06] <infinity> Oh, hahha.
[18:07] <infinity> There was both a new GCC and a new glibc (the precise thing required to trigger the bug) between when I fixed the chroots and when mvo fixed apt.
[18:07] <infinity> \o/
[18:07] <infinity> I'll re-fix them shortly.
[18:50] <cprov> pitti: there might be something wrong in the domination procedure, triggered by the override you've done on 21th Dec. Please, file a bug I will investigate it tomorrow
[18:57] <geser> cprov: is bug #178102 the same problem?
[18:57] <ubotu> Launchpad bug 178102 in soyuz "(Quick) promotion and demotion can lose binaries" [Undecided,New] https://launchpad.net/bugs/178102
[18:59] <cprov> geser: yes, it's a problem in the arch-indep domination procedure
[19:02] <dBera> Hi. debian unstable has beagle-0.3.2 while ubuntu (hardy) still has 0.2.18
[19:02] <dBera> isnt there some automatic way to sync from debian packages ?
[19:08] <pitti> dBera: there is, but our version has Ubuntu changes which need to be merged
[19:10] <dBera> pitti: ok. is there any public website where i can glance at the changes ?
[19:11] <pitti> dBera: there's patches.ubuntu.com which has all our changes relative to Debian
[19:11] <pitti> dBera: merges.ubuntu.com should have it, too
[19:12] <dBera> pitti: this one ? http://patches.ubuntu.com/b/beagle/beagle_0.2.18-0ubuntu3.patch
[19:13] <pitti> dBera: probably quite messy, since we had a new upstream version earlier
[19:13] <pitti> dBera: so some filterdiff -i '*/debian/*' is in order, I think
[19:20] <dBera> pitti: the earlier patch is weird! it contains who new files which were present earlier. a few of the changes are probably ubuntu specific, can't tell for sure
[19:21] <dBera> did UVF already happen ?
[19:24] <pitti> dBera: this does not exist any more; feature freeze is in Feburary, see HardyReleaseSchedule
[19:24]  * dBera checks
[19:27] <dBera> pitti: ok thanks. the earlier 0.3.2 gets into hardy the better. we can then get some feedback from hardy testers and make at least one bugfix release before hardy ships.
[19:28] <pitti> dBera: it's still on the 'must do' todo list on http://merges.ubuntu.com/main.html
[19:31] <pitti> bryce: hm, is it just me or a ffox 3.0 bug or is http://people.ubuntu.com/~bryce/Plots/ just empty and brown?
[19:32] <bryce> hi pitti; could be a bug... it works ok on ff 2.0
[19:32] <pitti> hm, so it does
[19:33] <bryce> is ff3 on hardy?  I could give it a spin on my other machine
[19:33] <pitti> rad
[19:33] <pitti> bryce: yes, I'm using the hardy packages (as I understand it they'll become the default soon)
[19:49] <\sh> pitti: it works with konqueror...;)
[19:53] <brettalton> how do you get around using 'sudo' with Python?
[19:59] <\sh> brettalton: check out update-manager :) it's python and using sudo (gnome version)
[20:07] <brettalton> \sh: http://archive.ubuntu.com/ubuntu/pool/main/u/update-manager/update-manager_0.81.tar.gz ???
[20:08] <calc> any java packaging people around, i need to fixup a package to get it into main
[20:08] <calc> and i am running into a weird error message
[20:08] <\sh> brettalton: yepp
[20:10] <brettalton> \sh_away: they use gksu
[20:10] <brettalton> thanks
[20:16] <geser> calc: try asking man-di, he's in #ubuntu-motu and #ubuntu-java
[20:20] <calc> geser: ok
[20:55] <alex-weej> are we using upstart to its full potential yet?
[20:56] <Mithrandir> no, I would not say so.
[20:56] <alex-weej> is it just a matter of manpower to write scripts?
[20:59] <TheMuso> I don't think upstart has all the originally planned features yet.
[23:39] <ion_> benc: Sigh, nvidia_supported seems to be incompatible with the current nvidia-glx-new. I’ll take a look at it today.
[23:39] <ion_> tepsipakki: ↑
[23:39] <ion_> Oh, he’s not around.