[12:12] <mdz> BenC: crashed immediately when I attempted to suspend
[12:13] <mdz> without even a console switch, no output
[12:15] <mdz> BenC: modprobe -r e1000  hangs instantly
[12:15] <mdz> oh, no it doesn't
[12:16] <mdz> it crashed the first time I tried in X, but has worked a few times on the console so far
[12:18] <mdz> oh, the module was left unloaded
[12:19] <mdz> BenC: ok, reproduced the same panic with that module
[12:34] <BenC> mdz: ok, let me check into some of the e1000 logs
[12:38] <jdong> thx, BenC... I'll test and see if GO_SLOW does the trick
[12:40] <Kamion_> aaaaaaand now to wait for console-setup to build so that I can test this keymapper change to fix UK keymap detection so that I can test the corresponding cdebconf-keystep change so that I can upload the whole stack in reverse order
[12:52] <infinity> Kamion: Are you in need of manual archive/buildd love to make your life easier?
[12:54] <elmo> oh, what a coincidence, I was about to whine about that :)
[12:54] <elmo> (getting keyboard prompts on a dapper -> edgy upgrade)
[01:02] <Kamion> elmo: which is er kind of orthogonal to what I said?
[01:02] <Kamion> infinity: no
[01:02] <Kamion> build-deps plus overnight will take care of it
[01:04] <Kamion> elmo: 'echo GET debian-installer/keymap | sudo debconf-communicate' please?
[01:05] <elmo> kamion: 0
[01:05] <Kamion> so why is that empty?
[01:06] <Kamion> how was the original installation of that system done?
[01:06] <elmo> this is mid upgrade - it was defaulting to US, so I answered UK twice and moved on
[01:06] <Kamion> yeah, doesn't matter
[01:07] <elmo> Kamion: um.  not actually sure.  it may be a sidegrade from Debian, it's my home desktop that pre-dates Ubuntu
[01:07] <Kamion> Debian woody perhaps?
[01:07] <Kamion> or before
[01:07] <elmo> could be, yeah, I wouldn't have been running sid or etch, and it's the wrong timeframe for sarge
[01:07] <infinity> Heck, I have an Ubuntu system that started as slink.
[01:08] <Kamion> yeah, boot-floppies-era original installs are a known case that console-setup can't handle without asking questions right now
[01:08] <elmo> Kamion: ah, ok, then
[01:08] <Kamion> might be able to figure out how to snarf it from console-data/* questions in debconf
[01:08] <Kamion> but those might well be wrong too
[01:09] <elmo> oh, shiny I have an installer.log still
[01:09] <Kamion> elmo: actually 'debconf-show console-data' in a bug report would be useful
[01:09] <elmo> Mar 21 04:48:29 (none) user.info dbootstrap[83] : dbootstrap starting; built 2002.05.16-04:54+0000 for i386
[01:09] <Kamion> (bug report on console-setup)
[01:09] <Kamion> bing, boot-floppies
[01:09] <Kamion> if debconf-show console-data doesn't say much useful, then never mind ...
[01:10] <Kamion> the only other way to figure out the keymap from an installation of that vintage is to disassemble /etc/console/boottime.kmap.gz
[01:10] <Kamion> which is approximately no fun at all
[01:10] <elmo> it's 138 lines of stuff, including some hints as to the britishness of my keyboard
[01:11] <Kamion> elmo: ok, sounds useful for a bug report then
[01:11] <elmo> ok, let's see if I can file it before the upgrade takes out my browser ;-)
[01:11] <Kamion> the many lines are just due to the super-weird layout of console-data's templates
[01:12] <BenC> mdz: people.u.c:~bcollins/e1000.ko
[01:12] <Kamion> can't guarantee to fix it for edgy though, it *is* a corner case
[01:12] <BenC> mdz: Please move that to /lib/modules/`uname -r`/kernel/drivers/net/e1000/ and test it
[01:12] <Kamion> also affects folks who installed using the debootstrap-in-a-chroot-and-fiddle method, though
[01:13] <elmo> Kamion: sure
[01:13] <Kamion> which I think is probably more common
[01:14] <mdz> BenC: trying
[01:14] <infinity> Kamion: That's my preferred method of installation on a few machines. :)
[01:15] <Kamion> oh, btw, #ubuntu-installer is open for installer development and stuff
[01:15] <Kamion> I created it ages ago but forgot to mention
[01:15] <BenC> mdz: That's a backport of the 2.6.18 driver (ours is 2.6.18-rcX backport)
[01:16] <BenC> mdz: We probably want that anyway, since it has a lot of support added for newer chipsets
[01:17] <mdz> BenC: same result
[01:18] <BenC> mdz: I'm not sure I even want to consider the 2.6.19-rc1 version
[01:18] <mdz> BenC: can you send me the huge diff you generated earlier?
[01:19] <BenC> mdz: the diff to get e1000 to 2.6.19-rc1?
[01:19] <mdz> no
[01:19] <mdz> Oct 11 14:31:44 <BenC>  wow, diff between .17 and .19 e1000 is 300k
[01:20] <BenC> mdz: Yeah, I could, but it will take backporting to actually make it work
[01:20] <mdz> BenC: will the 2.6.15 driver build for this kernel?
[01:20] <mdz> maybe we can narrow down the change which introduced the regression
[01:22] <BenC> let me revert to 2.6.17 stock and see if that works
[01:22] <jdub> hey dudes, how goes edgy?
[01:23] <BenC> mdz: New module, same location
[01:24] <BenC> mdz: This is stock 2.6.17.13 code
[01:24] <BenC> if this doesn't work, then I'll revert to 2.6.16 and see what we get there
[01:24] <mdz> ok
[01:24] <BenC> then we can bisect when we have a known working version
[01:36] <BenC> mdz: Any luck
[01:36] <BenC> ?
[01:40] <mdz> BenC: with what?  the most recent e1000.ko you provided didn't seem to help
[01:40] <mdz> jdub: manageable
[01:41] <BenC> mdz: fa74227d3a2974804fc56a508d912021 <- that match the md5sum of the last one you used?
[01:44] <mdz> d374350940aac7675f737efb79ad6d6f  2.6.17-10-generic/kernel/drivers/net/e1000/e1000.ko
[01:44] <BenC> then there's a newer one :)
[01:44] <mdz> BenC: same location?
[01:44] <mdz> oh, I missed 'new module, same location'
[01:44] <BenC> hehe
[01:47] <_ion> I posted a comment to bug 33243; i'd really appreciate more information.
[01:47] <Ubugtu> Malone bug 33243 in linux-restricted-modules-2.6.15 "tmpfs setup is unexpected" [Wishlist,Rejected]  http://launchpad.net/bugs/33243
[01:49] <mdz> BenC: 4/4 successful suspends with that driver
[01:49] <BenC> mdz: How long will you be on?
[01:49] <mdz> 5/5
[01:49] <mdz> BenC: ages
[01:50] <infinity> _ion: We'd still have to use the tmpfs setup for livecds, which would get messier to implement if we had to do it differently for installed systems (since the livecd is really just an installed system)
[01:50] <BenC> mdz: Ok, we need the 2.6.18 driver because of the intel support...I'll start pumping through git-bisect and giving you modules to test
[01:51] <BenC> if we can fix this bug in the 2.6.18 driver, it will be ideal
[01:51] <BenC> mdz: Unless you think that the updated driver just isn't important enough to worry about, in which case I'll just leave it as stock 2.6.17
[01:51] <mdz> BenC: is there a place where I can browse the git log messages and diffs?
[01:52] <mdz> BenC: it depends; if the fix is small and manageable, that would be preferable to swapping it out
[01:52] <BenC> mdz: Best place is the www.kernel.org/git linux-2.6 repo
[01:52] <cjfp> how do i get 'info autoconf' to work?
[01:52] <BenC> the update I did in our tree was just a single patch to go from .17 to .18 version
[01:53] <cjfp> i have manpages-dev installed, but it doesn't have info docs
[01:53] <Kamion> cjfp: autoconf-doc
[01:54] <cjfp> ah.
[01:54] <mdz> BenC: there are a lot of trees there; which one do I want?
[01:54] <cjfp> Kamion: this package doesn't exist for me...
[01:54] <_ion> infinity: A simple "if running on livecd, use tmpfs" clause wouldn't be very difficult or messy, would it?
[01:55] <cjfp> i'm running breezy
[01:57] <mdz> BenC: so the driver which works for me is stock 2.6.17?
[01:57] <Kamion> cjfp: looks like it isn't available theen, I'm afraid. However, the version of autoconf-doc in dapper is for the same upstream version, so you can probably just use that.
[01:58] <Kamion> s/theen/then/
[01:58] <cjfp> sorry, i don't understand
[01:58] <Kamion> install autoconf-doc from dapper and be happy
[01:58] <cjfp> so apt-get install -t dapper autoconf-doc?
[01:58] <Kamion> #ubuntu for the details, please
[01:58] <Kamion> might be better to fetch the individual .deb rather than messing with apt pinning though
[01:59] <Kamion> (the lack of autoconf-doc in hoary and breezy is a bug, but not one that we can/will fix now)
[01:59] <cjfp> i already asked about info docs on #ubuntu and they were no help, but ok
[01:59] <Kamion> I'm sure #ubuntu can handle installing packages
[01:59] <cjfp> ok, i will try to find the .deb
[02:00] <cjfp> is there a development task or whatever those things are called?
[02:00] <cjfp> so that i can just get useful development packages?
[02:01] <azeem> "useful development packages" is rather broad I'm afraid
[02:01] <cjfp> okay, how about so that when i type "info some-gnu-tool" it works?
[02:01] <BenC> mdz: Right
[02:02] <Kamion> cjfp: install the relevant -doc packages until it does; see packages.ubuntu.com for searching facilities. Please, this is really off-topic here and we are trying to prepare for RC freeze tomorroow
[02:02] <Kamion> tomorrow
[02:03] <cjfp> i'm sorry, i'll leave you in peace.  good luck.
[02:04] <Kamion> thanks
[02:05] <malix0> hi all can someone test this wit Firefox http://www.massimofidanza.it/firefox/
[02:06] <HrdwrBoB> because.. you don't have firefox?
[02:07] <HrdwrBoB> yes, the popup window remained in the background in current edgy bon echo
[02:11] <BenC> mdz: test 1 is there: md5sum: 509d603dd73b9a2a0f38fcfe0c170346
[02:14] <mdz> BenC: 2/2
[02:14] <BenC> mdz: Ok
[02:15] <mdz> BenC: I just unloaded the working module and loaded this one without rebooting; assume that's OK
[02:15] <BenC> yeah, that should be fine
[02:15] <mdz> eck
[02:15] <mdz> try #4 panicked
[02:15] <Viper550> Why don't you put in the actual Firefox logo? Debian won't do it, but we've "sorta broken free" of debian!
[02:16] <HrdwrBoB> yes, it's  that simple.
[02:17] <BenC> mdz: test 2: md5sum: 509d603dd73b9a2a0f38fcfe0c170346
[02:17] <mdz> BenC: just to confirm, you saw my previous message about the panic and so we're bisecting in the right direction?
[02:17] <BenC> mdz: Right
[02:17] <mdz> ok
[02:18] <BenC> mdz: between 2.6.17.13(known good) stock and 2.6.18(known bad)
[02:19] <mdz> BenC: hmm, I get 736fd91125932795548aee05c0b76ea6
[02:19] <BenC> ah, that's right
[02:19] <BenC> not sure how I pasted the wrong one
[02:20] <BenC> probably pasted the git sha :)
[02:20] <mdz> I should blacklist it so that I don't need to reboot twice when it panics
[02:24] <BenC> mdz: Does that last one work?
[02:26] <mdz> BenC: 3x so far
[02:27] <mdz> it sometimes takes 4-5
[02:28] <BenC> mdz: test 3: md5sum: 2788929c3de1db918b7278a7eb6d7867
[02:29] <mdz> survived 5x
[02:29] <mdz> 2788929c3de1db918b7278a7eb6d7867 got it
[02:31] <AlinuxOS> mdz, could you please tell me when exactly debian-installer transaltion is no more accepted ?
[02:31] <AlinuxOS> is it tonight or tommorow morning ?
[02:31] <mdz> BenC: 5/5 OK
[02:31] <mdz> AlinuxOS: NonLanguagePackTranslationDeadline
[02:31] <AlinuxOS> yes it's 12
[02:31] <AlinuxOS> I'm reviewing debian-installer right now.
[02:32] <mdz> AlinuxOS: they will be accepted between when Kamion is awake and when the RC freeze begins
[02:32] <Kamion> AlinuxOS: was the extensive conversation earlier where we went through this not good enough for you?
[02:32] <AlinuxOS> so not now :)
[02:32] <mdz> possibly later if he needs to do a d-i upload for other reasons
[02:32] <AlinuxOS> tommorow morning :)
[02:33] <AlinuxOS> Kamion, just would like to know if deadline is near :)
[02:34] <mdz> it is
[02:34] <mdz> it has been on the release schedule for 6 months now
[02:34] <AlinuxOS> cause I'm reviewing transaltions right now.
[02:34] <Kamion> AlinuxOS: please stop constantly bugging us about this. the only thing stopping me from excluding the Georgian translation right now is that it would be unethical
[02:35] <Kamion> we had this conversation this morning; there is no need to go over it all again now
[02:35] <BenC> mdz: test 4: md5sum: 1b8fc0e0ca307ad7c1eaf6a0a0c621d2
[02:36] <BenC> mdz: This test will narrow it down to 4 commits
[02:36] <mdz> BenC: hmmm
[02:36] <mdz> BenC: after 5 successful suspend/resume cycles I just got a crash when trying to copy down the new one
[02:36] <mdz> maybe an unrelated bug in that range somewhere
[02:37] <BenC> yeah, probably something already fixed
[02:38] <AlinuxOS> I've only gently asked about a current situation... to be sure... no comments about excluding Georgian translations please! It's enough what Russian government is doing(right now) with our citizens in Russia.
[02:38] <Kamion> AlinuxOS: imagine how it would be for us if every translator came and asked us how closely they could push the deadline
[02:39] <mdz> BenC: argh yeah, that driver is borked even if I don't try to suspend with it
[02:39] <Kamion> it would be absolutely intolerable
[02:39] <BenC> mdz: Number 3 or 4?
[02:39] <mdz> BenC: 3
[02:39] <mdz> need to boot an old kernel to get 4
[02:39] <BenC> mdz: ok
[02:39] <AlinuxOS> I'm inexperienced and I know this..., but consider that I'm alone who is working on everything.
[02:39] <mdz> AlinuxOS: I've talked with you before about waiting until the last minute; I thought we understood each other now
[02:40] <Kamion> AlinuxOS: lots of people are inexperienced, but most of them learn by watching quietly rather than coming up and poking the development team with sticks twice a day
[02:41] <Kamion> and I'll thank you not to compare us to government repression
[02:42] <infinity> AlinuxOS: As I said last night, if you don't get it done on time, you don't get it done on time.  Such is life.
[02:43] <infinity> AlinuxOS: As a member of the release team, I'm not allowed to delay the world for things I couldn't deliver on time, and no one else gets that privilege either.  There's always edgy+1 if you can't get us your translations now.
[02:43] <infinity> AlinuxOS: (And, yes, the deadline may as well be "now", since it's "anytime between now and when we freeze hard", which is "soon")
[02:43] <Kamion> annoying the people who you need to get your translations in is just about the least productive strategy I can imagine
[02:43] <AlinuxOS> Kamion, "the only thing stopping me from excluding the Georgian translation right now is that it would be unethical". I'm not comparing you, don't worry... but you are very severe, with me.
[02:44] <Kamion> AlinuxOS: you're hassling the people you need to help you even when you've been told to stop. Do you not think this is behaviour that needs negative reinforcement?
[02:44] <Kamion> s/told/asked nicely/ actually
[02:44] <AlinuxOS> Kamion, infinity transaltions are ready :) I just wanted to know some more infos...that's all.
[02:45] <mdz> BenC: 4/4 with #4
[02:45] <BenC> mdz: Ok, getting down to a culprit
[02:50] <AlinuxOS> Kamion, I'm not hassling no one here, just some further questions. If something goes wrong with me is that I have no idea howto make a font related packages... so I need help. And I really need help, because some months ago there was nothing for Georgian (I mean font,fontconfig,transaltions,console fonts..etc..).
[02:51] <AlinuxOS> mjg59, ping
[02:52] <infinity> Man, I love how I'm still processing queue/new within hours of a freeze.
[02:52] <BenC> mdz: Bad news, I was going the wrong direction with the commits (this is a manual bisect so I don't have to worry about ABI differences between ubuntu and stock kernel)
[02:52] <infinity> Tres speciale.
[02:53] <BenC> mdz: 5: 1c268c8ff18c9a3cf6ffffa3fdb4c1f8
[02:53] <elmo> RAH
[02:54] <elmo> damn it, edgy still doesn't bring up network when /var is on a separate partition
[02:54] <mdz> BenC: fails
[02:55] <mdz> elmo: still? you noticed this before?
[02:55] <elmo> mdz: yes, it was broken in dapper, but I upgraded far too late for anything to be done about it
[02:56] <BenC> mdz: 6: a9f2bf93027f6e6dff44a7ea276940cf
[02:58] <mdz> elmo: is it filed?
[02:58] <mdz> BenC: failed, but slightly different symptoms
[02:59] <BenC> mdz: slightly as in "probably unrelated" or as in "same thing, just different enough to notice" ?
[02:59] <elmo> mdz: the original dapper one?  no, keybuk debugged and diagnosed it for me, and hand wavingly promised me it would be fixed by new shiny edgy.  I never filed a bug, but I should have :(
[03:00] <elmo> I'll file one now though...
[03:00] <mdz> elmo: send me the bug number please
[03:01] <BenC> mdz: I'll mark it "probably bad" and move on
[03:01] <mdz> BenC: as in "probably unrelated"
[03:01] <mdz> BenC: it blows up during boot as well
[03:01] <Kamion> elmo: do /var/lock and /var/run exist on the underlying root filesystem?
[03:02] <Kamion> (just checking, as that's a requirement for some things - should be handled by the upgrade to dapper or so though)
[03:03] <mdz> BenC: does git bisect let you say that the test result was indeterminate, so that it picks another in the same range?
[03:03] <infinity> CDBS makes me weep.
[03:03] <infinity> lp_archive@drescher:~/foo/meta-telepathy-1$ cat debian/rules 
[03:03] <infinity> #!/usr/bin/make -f
[03:03] <infinity> include /usr/share/cdbs/1/rules/buildcore.mk
[03:03] <infinity> include /usr/share/cdbs/1/rules/debhelper.mk
[03:03] <BenC> mdz: 7: 6376cf2a1bc886cfb99fa6d6a2ee44b6
[03:03] <BenC> mdz: I'm not using git-bisect, I just spit out a list of the 53 commits between the known working and known bad
[03:03] <mdz> booting with 7
[03:04] <mdz> oh, right
[03:04] <BenC> mdz: I dropped just one commit from 6 closer to "last known good"
[03:05] <mdz> BenC: 6376cf2a1bc886cfb99fa6d6a2ee44b6 fails
[03:06] <mdz> (in the usual way)
[03:06] <BenC> cool, that makes 6 irrelevant
[03:08] <BenC> mdz: 8: 5136ea9c374d445682448877552a745f
[03:12] <infinity> Lookie there, an empty new queue.  I wonder how long that will last...
[03:14] <infinity> Ngh.
[03:14] <zul> heh
[03:14] <BenC> infinity: So, is edgy+1 chroots and buildd's ready yet? ;)
[03:15] <infinity> BenC: Is that actually ready to go in the first day or two of edgy+1 along with the toolchain bootstrap?
[03:15] <mdz> BenC: 5136ea9c374d445682448877552a745f fails with the usual panic
[03:15] <infinity> BenC: The chroots are ready, yeah.
[03:15] <BenC> infinity: Yep, I have it building and booting on x86, x86_64, powerpc and sparc already
[03:15] <infinity> BenC: Sex.
[03:15] <infinity> BenC: We should have an hppa toolchain from the get-go too, so feel free to make it boot there too.
[03:15] <infinity> (Yay, working glibc)
[03:16] <BenC> infinity: Not sure about boot, I can't even get edgy booting with 2.6.17...but I can get it building
[03:16] <infinity> Well, building is a start.
[03:16] <infinity> I can help with making it boot once the edgy+1/hppa toolchain is bootstrapped.
[03:17] <infinity> (And we get to rebuild half the archive, because hppa's glibc is introducing an ABI break)
[03:17] <infinity> Woo-freaking-hoo.
[03:17] <mdz> infinity: how is the rebuild test going?
[03:17] <infinity> mdz: Slowly, but it's going.
[03:17] <mdz> speaking of mass rebuilds
[03:17] <infinity> (as of this morning)
[03:17] <mdz> infinity: what's the cause of the slowness?
[03:18] <BenC> mdz: 9: 364fe620711f36d4de99c120921e17fb
[03:18] <infinity> The "as of this morning" bit, along with the "only one machine per arch" bit.
[03:19] <AlinuxOS> Good night everyone and good work!
[03:19] <BenC> infinity: If you need libc-kernel-dev prior to upload, let me know
[03:19] <AlinuxOS> Kamion, sorry again for disturbing. (anyway debian-installer and help are ready).
[03:21] <mdz> BenC: fail
[03:22] <Kamion> AlinuxOS: thanks
[03:22] <psusi> so is there any way to get a newer version of git-core backported to dapper?  the current one is no longer compatible with kernel.org
[03:22] <mjg59> psusi: Since when?
[03:23] <mjg59> Oh, sorry, dapper
[03:23] <psusi> since the 10th I think
[03:23] <mdz> psusi: yes, the process is at http://wiki.ubuntu.com/StableReleaseUpdates
[03:23] <BenC> mdz: Ok, that leaves us a culprit, but let's rebuild the known good that right next to the bad one to be sure we did nothing wrong
[03:23] <psusi> ahh, cool... I'll have to read that if/when I get X working again
[03:24] <BenC> mdz: 10 (same as first bisect module): 509d603dd73b9a2a0f38fcfe0c170346
[03:25] <BenC> commit 9a53a2029885e0088e9149679215b95d04deb57b
[03:25] <BenC> Author: Auke Kok <auke-jan.h.kok@intel.com>
[03:25] <BenC>     e1000: add smart power down code
[03:26] <BenC> that appears to be the problem, sounds right too
[03:26] <psusi> hrm... got it up in lynx... looks like git no longer being compatible doesn't qualify for backporting
[03:26] <Kamion> smurf: FYI, uploaded keymapper 0.5.3-7 to unstable, with all your changes plus a few more to make the UK keymap detectable properly
[03:26] <Kamion> smurf: (the map_yes/map_no generation code wasn't taking alt-ness into account)
[03:28] <mdz> BenC: that one breaks in a  different way
[03:29] <BenC> mdz: Ok, give me a sec
[03:32] <infinity> BenC: At this point, I'll assume we can bootstrap glibc and gcc without new kernel headers (can't see why not), but we'll see if jbailey or doko think otherwise.
[03:38] <BenC> mdz: Does it break on suspend/resume or just general?
[03:40] <mdz> BenC: yes
[03:40] <BenC> I'll assume that means "yes, it breaks on suspend"
[03:40] <mdz> that means "yes, it broke".  I only tried it once
[03:40] <mdz> and that was a suspend test
[03:41] <BenC> that's odd, because that's the same as the first one we tried that you said worked
[03:41] <mdz> but it broke way earlier than any other
[03:41] <mdz> no, look back
 BenC: hmmm
[03:41] <mdz>  BenC: after 5 successful suspend/resume cycles I just got a crash when trying to copy down the new one
[03:41] <mdz> and then it shit the bed during the next reboot, so I had to go to another kernel to download a new one
[03:42] <mdz> so it broke outside of a suspend/resume context as well before
[03:42] <mdz> I think that revision is just hosed
[03:42] <BenC> BenC mdz: test 1 is there: md5sum: 509d603dd73b9a2a0f38fcfe0c170346
[03:42] <BenC> mdz BenC: 2/2
[03:42] <BenC> same md5sum
[03:45] <mdz> BenC: yes, keep reading though
[03:45] <mdz> BenC: oh, I'm confused by where you pasted the wrong md5sum
[03:46] <mdz> BenC: can we go one revision earlier?
[03:46] <BenC> mdz: Yeah, hold a sec
[03:48] <BenC> mdz: 11: 6fdfef162426766611b1f640138e4720f56e45f8
[03:51] <mdz> BenC: failed first try
[03:51] <mdz> when suspending
[03:52] <Snake> Can a dev tell me what ubuntu plans to do with this firefox chaos?
[03:53] <mdz> Snake: no, not until it's been discussed and agreed with mozilla
[03:53] <BenC> mdz: 12: 0b70b852c27d9535d666a18164c45f9d
[03:53] <mdz> that dialog is still in progress
[03:57] <mdz> BenC: that one looks good so far, 4x
[03:57] <mdz> 5x
[03:58] <mdz> 7x
[03:59] <mdz> BenC: I can't seem to break 0b70b852c27d9535d666a18164c45f9d
[03:59] <BenC> mdz: That's just one commit above 2.6.17.13 stock (only one we know was perfect)
[03:59] <BenC> we'll go from there
[04:01] <mdz> BenC: one more, and then I need to run to the store
[04:02] <BenC> mdz: 13: 736fd91125932795548aee05c0b76ea6
[04:02] <BenC> mdz: ok, after this just ping me when you are ready to do some more
[04:05] <mdz> BenC: 736fd91125932795548aee05c0b76ea6 seems solid
[04:05] <BenC> mdz: Ok
[04:05] <mdz> BenC: how many more do you think?
[04:05] <mdz> these go pretty fast when it works
[04:05] <mdz> slow when it doesn't
[04:06] <BenC> mdz: 11 commits between good/bad, so splitting, probably 5-6
[04:06] <mdz> should be closer to 3
[04:06] <mdz> let's try to finish it before I go
[04:07] <BenC> mdz: 14: f1fc3b0dc86d4b1064666533262eb0df
[04:10] <mdz> f1fc3b0dc86d4b1064666533262eb0df looks good
[04:10] <mdz> BenC: ^
[04:11] <BenC> mdz: 15: e494359e9a260f18d5eb18a92e5a769a
[04:15] <Kamion> mdz: mind if I upload *-meta to remove the *-live metapackages? they're useless now that Adam's switched livefs.sh to using tasks
[04:16] <mdz> BenC: e494359e9a260f18d5eb18a92e5a769a looks good
[04:17] <mdz> Kamion: let me think about that one for a minute
[04:17] <mdz> Kamion: should be safe considering that no one should have that installed
[04:18] <Kamion> and if they do, it'll have been changing wildly on them in unhelpful ways
[04:18] <mdz> Kamion: yeah, ok
[04:18] <Kamion> like insisting that they suddenly must have Estonian language support or something
[04:18] <mdz> it has occurred to me that with the combination of metapackages and autoremove, the metapackages we have must live forever :-)
[04:18] <mdz> the ones which end up on an installed system I mean
[04:18] <Kamion> seems suboptimal :)
[04:19] <Kamion> we should ponder that
[04:19] <BenC> mdz: 16: 9632301e6aa5be39f93b5b849c0462cc
[04:19] <BenC> mdz: If this one is good, it's the last, if not, then one more
[04:20] <BenC> I'm hoping it's bad, because the commit it points to doesn't look like it could cause a problem
[04:21] <mdz> BenC: took a bunch of attempts, but I panicked it
[04:23] <BenC> mdz: 17: ac6b764fe8f6a8c42d9741cb633bcc5a
[04:23] <BenC> last one hopefully
[04:23] <mdz> rebooting
[04:24] <Kamion> mdz: are we moving avahi-daemon to desktop for all derivatives?
[04:24] <Kamion> I'm just doing a full set of seed merges while I'm here
[04:25] <mdz> Kamion: at least the kde and gnome ones
[04:25] <mdz> I don't know whether xubuntu has a knob to enable it
[04:26] <mdz> if not, they might want to leave it out
[04:26] <Kamion> the daemon ships disabled until enabled by UI, right?
[04:26] <mdz> yes
[04:26] <Kamion> good good
[04:26] <Lathiat> yeh, thats causing no end of bug reports tho
[04:26] <mdz> despite unhelpful blog entries
[04:26] <Lathiat> im wondering if we can do something liek print an error message in the init script if its run interactively, or something
[04:27] <Kamion> Lathiat: that's not unprecedented; e.g. see pcmciautils
[04:27] <Kamion> the run_by_init stuff
[04:27] <mdz> BenC: panicked on me, but slightly different
[04:27] <mdz> flashing caps lock and nothing on screen
[04:27] <Kamion> Lathiat: /etc/init.d/pcmciautils
[04:27] <Lathiat> yeh but i cant see a 'run_by_init' in there?
[04:28] <Lathiat> oh this is dapper tho
[04:28] <Lathiat> is this an edgy thing?
[04:28] <Lathiat> ah, it is
[04:28] <Lathiat> that said, this would only help 'half' the cases, theres two problems that come up
[04:28] <Lathiat> 1) I installed avahi-daemon in synaptic and avahi doesn't work and
[04:29] <Lathiat> 2) I ran /etc/init.d/avahi-daemon start and it doesnt work
[04:29] <Lathiat> i guess that solves the latter but not the former
[04:30] <Kamion> ok, avahi-daemon's tiny, even edubuntu can cope with this
[04:31] <Kamion> Lathiat: solving the latter seems worthwhile anyway - people suffering from the former might have people with general Unix knowledge try to help them who would be confused by the latter
[04:31] <mdz> BenC: second attempt, freezes hard while X is still displayed and the sleep light flashing
[04:32] <mdz> I need to run, back in <30
[04:32] <BenC> mdz: Ok, that should do it, let me review these commits
[04:32] <BenC> thanks
[05:10] <mdz> BenC: back
[05:16] <jdong> BenC: sadly, GO_SLOW doesn't do the trick :(
[05:17] <jdong> BenC: and the linux-usb folks seem to be against doing max_sectors stuff from the kernel side
[05:17] <jdong> rather, they say it should be done via hal/udev scripts in userland
[05:20] <jdong> so is there a way to set max_sectors via a udev rule?
[05:52] <fabbione> morning guys
[05:59] <mdz> morning fabio
[06:00] <Burgundavia> morning fabbione
[06:00] <Burgundavia> mdz: are we going to ship with both gthumb and fspot?
[06:01] <jdong> does keybuk handle udev stuff?
[06:02] <jdong> or is there someone else here fluent in udev that can decide if my bug can be fixed?
[06:03] <fabbione> hey mdz
[06:03] <fabbione> Burgundavia: yo
[06:14] <jdong> *blick*
[06:14] <jdong> blink
[06:14] <BenC> mdz: Hey, I've looked over the diffs, but it's after 12am here, so I'll get back to you tomorrow afternoon
[06:14] <BenC> hopefully have something to test
[06:14] <jdong> umm, why is any arbitrary password unlocking gnome-screensaver?!?
[06:14] <jdong> can anyone reproduce that?
[06:15] <BenC> jdong: Nope, I just unlocked and mistyped the password the first time
[06:15] <BenC> jdong: It failed
[06:15] <jdong> BenC: I must've screwed something up restarting udev then :D
[06:15] <HrdwrBoB> jdong: still not a good failure 
[06:15] <Burgundavia> jdong: file a bug anyway
[06:15] <HrdwrBoB> in terms of security
[06:15] <Burgundavia> it should fail closed, not open
[06:16] <jdong> BenC: I commented on the bug a bit more regarding the usb device; looks like a userspace udev fix is best
[06:16] <jdong> Burgundavia, HrdwrBoB, I'll reboot and see if it's reproducable
[06:17] <BenC> jdong: Please reassign to udev then, and point to any linux-usb comments you can
[06:17] <BenC> jdong: I'll revert the GO_SLOW
[06:19] <jdong> ok, confirmed, it is caused by udev
[06:19] <jdong> stopping udev will cause gnome-screensaver to accept any password
[06:20] <jdong> is that a bug or user stupidity? 
[06:20] <BenC> bug
[06:20] <jdong> ok, I'll file it then
[06:21] <jdong> BenC: should I tag it security or leave it normal?
[06:23] <HrdwrBoB> no stupidity should cause any password to be accepted
[06:24] <HrdwrBoB> short of deliberately haxing pam or something stuipd
[06:24] <HrdwrBoB> stupid
[06:26] <jdong> bug 65615
[06:26] <Ubugtu> Malone bug 65615 in gnome-screensaver "Stopping udev causes gnome-screensaver to accept any password" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65615
[06:30] <jdong> now, this sleep thing... probably should start at 12:30AM
[06:50] <Donkeybreath> check out my site www.jpegtown.com tell me what you think of the coding, just finished it up
[06:51] <fabbione> Donkeybreath: it's offtopic here
[08:19] <pitti> Good morning
[08:20] <Fujitsu> Hey pitti.
[08:21] <pitti> infinity, mjg59: ATM booting takes about 5 minutes for me, if I remove 'splash', it's done in 56 seconds; do the usplash functions have some timeout which could cause this? (I have the segfaulting usplash variant here)
[08:22] <infinity> I have no idea.  The New and Improved usplash is a mystery to me. :)
[08:22] <pitti> infinity: heh, ok; if I would only see how it should look like :)
[08:25] <infinity> pitti: Want to look at a build log for me and tell me if this is a bug in your symbol extractor?
[08:27] <pitti> infinity: of course
[08:27] <infinity> pitti: Forwarded.
[08:33] <tfheen> pitti: which arch?
[08:34] <pitti> tfheen: amd64/nvidia, the duo infernale
[08:34] <tfheen> pitti: hmm, that's weird.  It should just segfault and run on its merry way.
[08:36] <pitti> tfheen: it looks as if the functions would hang and wait for usplash for some time
[08:38] <tfheen> pitti: hmm
[08:40] <infinity> Who feels like looking into a tar testsuite failure before I start randomly filing and assigning bugs to the first person on my list?
[08:41] <pitti> infinity: argh, it seems that hppa is the only reason why we have to keep gnutls11 :-(
[08:44] <tfheen> uh, just when did ubuntu-desktop start depending on linuxprinting.org-ppds?
[08:44] <infinity> pitti: Ingore hppa.
[08:46] <pitti> tfheen: argh, wasn't this supposed and agreed to be split into a small desktop and large supported package?
[08:46] <tfheen> pitti: I thought so, yes.
[08:47] <tfheen> I blame Scott
[08:47] <pitti> infinity: if I would fully ignore hppa, then gnutls11 could go; no reason to keep a vulnerable old version just for one multiverse package that doesn't build anyway
[08:48] <pitti> erm, my last sentence echoed very broken in xchat -- was it ok for you?
[08:49] <pitti> infinity: libtasn FTBFS> will look into it and fix pkg-create-dbgsym
[08:52] <infinity> pitti: Your grammar was just as bad in irssi as it was in xchat. :P
[08:53] <infinity> pitti: Anyhow, we can ignore hppa.  If you want gnutls11 removed, just say the word.
[08:53] <tfheen> you just have to run it through the degermanisation filter and it parses fine. ;-)
[08:53] <pitti> infinity: I meant, half of the sentence was completely missing here
[08:53] <infinity> Which half? :)
[08:54] <pitti> everything before 'go'
[08:54] <fabbione> the good one
[08:54] <pitti> anyway, /me blames solar radiation
[08:54] <fabbione> so now we have itaglish and germanish
[08:54] <pitti> fabbione: the latter is commonly referred to as 'Denglish' here :)
[08:54] <fabbione> ehhe
[08:54] <infinity> pitti: Okay, when Fabio's making fun of your English, you know it's time to go back to bed for an hour and try this whole "morning" thing again. :)
[08:55] <Fujitsu> pitti, Xchat often does things like that.
[08:55] <pitti> 'Good morning, Mr. Nitto, how do you do?' 
[08:55] <pitti> infinity: instead of going to bed, I think I'll try having some breakfast
[08:56] <infinity> Not a bad plan.
[08:56] <pitti> infinity: is hppa just lagging behind buildd-wise, or is there some other congestion I don't know about?
[08:57] <Fujitsu> 5pm isn't too early for bed!
[08:57] <Fujitsu> Just have a very, very early night :P
[08:57] <infinity> pitti: hppa isn't shipping with edgy at all, we never bootstrapped it.
[08:58] <infinity> pitti: Broken glibc, it'll be back with a working toolchain for edgy+1.
[08:58] <pitti> ah, ok
[08:58] <infinity> I commend you for not having noticed this for 4 months. :)
[08:58] <pitti> well, then let's kick gnutls11 and sleep a bit better :)
[08:59] <pitti> infinity: well, the number of hppa boxes in my vicinity is somewhere between epsilon and 0
[08:59] <tfheen> pitti: you're unable to detect both their velocity and position at the same time?
[09:00] <infinity> I was thinking the same thing...
[09:00] <pitti> tfheen: yeah, unfortunately, that's why I can't count them exactly
[09:00] <infinity> Mine's pretty easy to locate, it's being used as a coffee table.
[09:00] <infinity> One of these days, I'll spill something in it and be non-plussed.
[09:00] <Fujitsu> -shudder-
[09:01] <tfheen> infinity: it'll just drink it and burp back at you.
[09:01] <StevenK> I've seen coffee tables go faster than my hppa.
[09:01] <tfheen> zul: are you planning on getting a new xen-restricted-modules with the correct ABI into the archive?
[09:01] <pitti> tfheen: is that the promised hppa 'release'? :)
[09:01] <StevenK> Damnable 712 that it is.
[09:01] <infinity> tfheen: He can't until he fixes the headers.
[09:01] <infinity> tfheen: I was about to upload XRM for him, but it still doesn't build.
[09:01] <tfheen> infinity: oh, those are broken (again)?
[09:01] <tfheen> *sigh*
[09:01] <infinity> tfheen: Missing asm/ on (at least) i386.
[09:01] <infinity> tfheen: Just tested a few hours ago.
[09:02] <tfheen> I've only fixed that like five times.
[09:02] <tfheen> apparently, we keep losing the fix.
[09:02] <Fujitsu> tfheen, want me to break it a few times, just for you?
[09:03] <infinity> tfheen: If you want to fix it AGAIN and upload a fixed version, I'll get XRM in.
[09:03] <infinity> tfheen: I just don't want to upload XRM blindly without first testing that it builds.
[09:03] <tfheen> oh, absolutely agreed.
[09:03] <infinity> Cause it, y'know, never has.
[09:03] <infinity> (Not on i386, anyway(
[09:04] <tfheen> I should get some breakfast and get the freeze really started first, I think.
[09:04] <infinity> You want me to flip the freeze switch?
[09:05] <tfheen> yes, please
[09:05] <tfheen> bah
[09:05] <infinity> COLLISION!
[09:05] <tfheen> I'll mail u-d-a after breakfast
[09:07] <infinity> tfheen: In the u-d-a announcement, be sure to mention that unapproved uploads will most likely just be rejected, since this is the final freeze.
[09:07] <|thunder> sup guys. ive got a question no one in #ubuntu can awnser. I need to create a symlink to glibc libs to install borland kylix 3. The symlink has to reside in /usr/lib and have the same name as the lib itself excluding inline version number. Anyone got any ideas on this one ?
[09:08] <infinity> (ie: We'll want the queues completely empty by release day)
[09:08] <infinity> |thunder: You want to install libc6-dev.  You also want to not ask these questions in here.
[09:10] <|thunder> ohh, sorry to break the rules.
[09:10] <|thunder> thanks though
[09:13] <|thunder> infinity; just so you know. im still getting this. "Glibc version....FAILED"
[09:13] <|thunder> even thought that installed fine
[09:18] <infinity> Well, I know nothing of kylix, I just know what package includes libc6 development libraries. :)
[09:18] <infinity> Note that this isn't #kylix, and we've not the time to deal with it, really.
[09:20] <|thunder> mainly my question was really "where is glibc.so"
[09:20] <infinity> Well, that got answered. :)
[09:20] <infinity> Either way.  Not a support channel.  Please respect that we're working on a release here.
[09:20] <|thunder> duely noted
[09:20] <mantiena-baltix> pitti: hi, I found where is problem when partition is listed in /etc/pmount.allow but nautilus doesn't allow to enter into this partition from computer:/ locatiom ;)
[09:22] <mantiena-baltix> pitti: it's in hal
[09:24] <infinity> And dholbach wins the prize for being (probably) the very last NEW source package accepted to edgy..
[09:24] <StevenK> Where sneak in is like half an hour ago.
[09:25] <Fujitsu> RC Freeze is not applicable to universe, is it?
[09:25] <infinity> Fujitsu: I'd beg to differ.
[09:25] <infinity> Fujitsu: Though freeze exceptions for universe will be more slack.
[09:25] <infinity> Fujitsu: The whole archive is frozen, however, and will remain so until release.
[09:25] <Fujitsu> Ooh, OK.
[09:26] <infinity> Fujitsu: So, you'll need MOTU freeze exception approval (from, say dholbach), then an archive admin to approve the upload.
[09:26] <tfheen> infinity: agreed; no need for the release team to worry about universe.
[09:27] <Fujitsu> I'm too close to infinity to risk it :P
[09:27] <infinity> We have a package called "hat"?
[09:27] <StevenK> Hah
[09:28] <infinity> A package called "hat" that doesn't build on sparc, even.
[09:28] <heno> Sounds more like a Fedora package
[09:28] <StevenK> infinity: Some Haskell thing.
[09:28] <infinity> StevenK: Evidently.  Do you like haskell things enough to fix it?
[09:28] <infinity> (It's trying to include sys/byteorder.h directly)
[09:29] <Fujitsu> Haskell is... odd.
[09:29] <infinity> Bad hat.  Bad.
[09:29] <Fujitsu> Who wants to wear the hat failure on their head?
[09:29] <StevenK> infinity: I can spell it, but I'll have a look.
[09:29] <infinity> StevenK: The failure is in C code, obviously.
[09:29] <infinity> StevenK: So, you win.
[09:29] <StevenK> The "include sys/byteorder.h" told me that. :-P
[09:30] <infinity> Yeah. :)
[09:32] <StevenK> Yay, mpg321!
[09:32] <StevenK> Frame#  9822 [18446744073709547505] , ...
[09:32] <StevenK> This from a 4Mb mp3
[09:34] <tfheen> it's trying to get you to use oggs
[09:35] <StevenK> #if defined(sparc)
[09:35] <StevenK> #include <sys/byteorder.h>
[09:35] <StevenK> #endif
[09:36] <fabbione> StevenK: yeah you can
[09:37] <fabbione> it's enough you run a sparc64 kernel
[09:38] <dholbach> good morning
[09:42] <pygi> morning dholbach 
[09:42] <dholbach> hey pygi
[09:43] <infinity> dholbach: I've just nominated you Universe Release Manager, by the way. :)
[09:43] <infinity> dholbach: Whether you want it or not.
[09:44] <infinity> dholbach: All universe uploads need to go through you (or people you delegate) from here on in, then you'll need to ping an archive admin to get them out of queue/unapproved
[09:46] <dholbach> infinity: oh - why can't we let them through? i expect quite a bunch of them (unmet deps, ssl transition, etc)
[09:47] <infinity> dholbach: The whole archive is frozen.
[09:47] <infinity> dholbach: I'm happy to take large lists of "let this crap through" though. :)
[09:48] <dholbach> for hoary I uploaded until 3 hours before release ;-)
[09:48] <infinity> Still can. :)
[09:48] <dholbach> yeah, I need to be awake and prod you for everything
[09:49] <Fujitsu> We've still got a lot of stuff to do :S
[09:49] <infinity> Well, the prodding can by async.
[09:49] <infinity> Not a big deal.
[09:49] <dholbach> Hrm, I don't like the "you need to pass two people" solution
[09:49] <infinity> dholbach: Propose a "allow freezing of individual components" soyuz spec for Mountain View. :)
[09:50] <dholbach> but I guess there's no choice
[09:50] <dholbach> infinity: Ok :-)
[09:50] <dholbach> infinity: I knew it wasn't your fault
[09:50] <Fujitsu> infinity, it can't be /that/ hard to implement it...
[09:50] <infinity> dholbach: Well, if your word is that "universe isn't frozen", then it only needs to pass one person (archive-admin), since you've pre-approved the world. :)
[09:50] <infinity> dholbach: But that's your call, the release team refuses to deal with universe.
[09:51] <infinity> We'll have our hands full as it is.
[09:51] <dholbach> yeah, I can see that
[09:51] <infinity> This is going to be a bumpy release, I fear. :/
[09:51] <infinity> I'm already looking forward to edgy+1, if for no other reason than so I don't have to think about edgy.
[09:51] <Fujitsu> infinity, most are, no?
[09:52] <infinity> Fujitsu: Well, they all have bumps, but some approach release date a bit more prepared than others. :)
[09:52] <Fujitsu> True... Exceptions seem to have been more liberally applied to Edgy...
[09:52] <tfheen> dholbach: I'm writing the freeze announce now.  I'd like to have universe frozen and require approval, but your choice.
[09:53] <infinity> tfheen: Well, it's frozen regardless.  I can't change that.
[09:53] <infinity> tfheen: It's a question of whether he's giving blanket approval, or case-by-case.
[09:53] <tfheen> infinity: well, yes.
[09:53] <infinity> dholbach: So, your call, really.
[09:54] <dholbach> we already do uvf for new packages and new upstream versions - i really don't fancy approving each rebuild upload
[09:54] <infinity> dholbach: As I spot stuff in queue/unapproved, I'm likely to ask you about it anyway, so it's not a one-way street.
[09:54] <dholbach> Ok
[09:54] <infinity> (ie: Nothing will get "lost")
[09:54] <dholbach> *nod*
[09:54] <infinity> One way or another, all the uploads will either be accepted or rejected. :)
[09:55] <infinity> StevenK: It's not yet. :)
[09:55] <tfheen> dholbach: would you like to nominate a person in addition to yourself right away?
[09:55] <tfheen> StevenK: it's not like we're not itching to.
[09:55] <infinity> slomo played that role once, didn't he?
[09:55] <ajmitch> evening
[09:55] <dholbach> he's on vacation
[09:55] <ajmitch> slomo is still away
[09:55] <dholbach> not sure if ajmitch or siretart have enough time for that
[09:55] <infinity> And yeah, I have a lot of dirty hacks in hoary that I can't WAIT to go unsupported.
[09:56] <dholbach> they already help with  motu-uvf
[09:56] <infinity> I'm actually pretty happy with my work in breezy and dapper, by comparison.
[09:56] <ajmitch> dholbach: I'm fine with that if you want
[09:56] <Fujitsu> Poor old Hoary :'(
[09:56] <dholbach> ajmitch: us approving/rejecting each universe upload?
[09:56] <infinity> dholbach: Just change the U in UVF from "upstream" to "upload" and you've got a team.
[09:56] <dholbach> infinity: super
[09:56] <tfheen> infinity: upload version freeze?
[09:56] <infinity> tfheen: Sure, why not? :)
[09:56] <Fujitsu> tfheen, that's perfectly valid.
[09:57] <dholbach> ajmitch: if you're prepared to take the load, say so
[09:57] <ajmitch> dholbach: yeah, it'll be painful, but I think we can do it if there's enough checking them
[09:57] <dholbach> tfheen: fschoep told me to revert to dapper artwork - so expect 3 upload to main in a bit
[09:57] <dholbach> ajmitch: Ok
[09:57] <ajmitch> though I think that there'll be a lot of rebuilds & small fixes going in soon
[09:58] <infinity> ajmitch: It doesn't need strict checking, per se, just yay or nay approval so I'm not blindly letting everything through.
[09:58] <tfheen> dholbach: I'll point to the UVF motu team for universe, then and you can chuck people in or out of the team as you feel like?
[09:58] <ajmitch> infinity: alright
[09:58] <siretart> dholbach: I think I should be able to handle that as well
[09:58] <infinity> ajmitch: So, y'know "this was an FTBFS fix, these 12 are libssl rebuilds", etc.
[09:58] <ajmitch> hey siretart 
[09:58] <siretart> huhu ajmitch 
[09:58] <dholbach> ajmitch is Upload Liteunant
[09:58] <ajmitch> infinity: sounds manageable
[09:58] <dholbach> hi siretart
[09:58] <siretart> huhu dholbach 
[09:58] <siretart> :)
[09:59] <tfheen> dholbach: do you have any policies wrt what should be uploaded in universe?
[09:59] <infinity> dholbach: We're not using the edgy artwork?  And I just got used to it too...
[10:00] <tfheen> dholbach: artwork> 'k; I'd rather have us keep the edgy artwork, but it's not my call..
[10:00] <dholbach> tfheen: no, in the most cases I trust people
[10:00] <dholbach> tfheen: it's not my call either - I'd like to keep it too
[10:00] <dholbach> I'll prepare some   unofficial-edgy-artwork   packages ;-)
[10:00] <StevenK> dholbach: Any reason given?
[10:01] <Kamion> morning
[10:01] <ajmitch> morning Kamion 
[10:01] <infinity> Mornin'.
[10:01] <dholbach> StevenK: it does not meet the expectations of Mark and select other people and there is work underway, but not sure if it's going to make it
[10:01] <crimsun> infinity: hi, do you have a moment to look at a strange ftbfs across five arches (https://launchpad.net/distros/ubuntu/+source/vlc/0.8.6-svn20060918.debian-1ubuntu4 )? It seems to be dying on an empty .po file - which I'm certain is not empty.
[10:01] <Fujitsu> Hey Kamion.
[10:01] <dholbach> hi Kamion
[10:01] <dholbach> StevenK: that's all I know
[10:01] <StevenK> Damn it. Does anyone have a base tarball of Dapper/Edgy for sparc? My sparc insists "binary-sparc/Packages.gz was corrupt"
[10:02] <Fujitsu> StevenK, it's 36 degrees here :(
[10:02] <dholbach> Kamion: when did you go to bed?
[10:02] <ajmitch> the archive is frozen now?
[10:02] <tfheen> ajmitch: yes
[10:02] <infinity> ajmitch: Yup.
[10:02] <StevenK> Fujitsu: My panel applet says 25.
[10:02] <siretart> 09:47:16 < infinity> dholbach: The whole archive is frozen.
[10:02] <StevenK> Fujitsu: Thank $DEITY
[10:02] <ajmitch> good thing I got f-spot bugfixes in on time
[10:02] <Fujitsu> StevenK, in Melbourne?
[10:03] <siretart> infinity: will it be unfrozen again after the release candidate?
[10:03] <tfheen> siretart: no.
[10:03] <StevenK> Fujitsu: No, here. :-)
[10:03] <infinity> siretart: Probably not.
[10:03] <Fujitsu> StevenK, lucky.
[10:03] <StevenK> Fujitsu: Feel free to visit. :-P
[10:03] <siretart> i see
[10:03] <dholbach> siretart: the uvf team will approve uploads though
[10:04] <siretart> how do we approve uploads? pinging infinity via irc or using some fancy launchpad pages?
[10:04] <ajmitch> how will we view the list of frozen uploads, firstly?
[10:05] <infinity> crimsun: I assume it creates it during the build?  Since I don't see that in the source package at all.
[10:05] <fabbione> StevenK: corrupted? what mirror are you using?
[10:05] <fabbione> dholbach: ROFL
[10:05] <StevenK> fabbione: Either archive.u.c or au.archive.u.c.
[10:05] <infinity> siretart: ping me or kamion.  We could use Malone for it, but seems like a non-starter if there'll be a lot of uploads.
[10:05] <crimsun> infinity: I have to guess so. It seems to reference debian/patches/001_1008snap.translations.diff indirectly, which is confusing me.
[10:06] <Kamion> dholbach: about 4:15am
[10:06] <janimo> crimsun: hi, I fixed the xss and splash LP bugs, gxine is in the upload queue
[10:06] <crimsun> janimo: thank you!
[10:06] <infinity> ajmitch: You can see the unapproved queue here: https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=1
[10:06] <ajmitch> thanks
[10:06] <Kamion> IIRC unapproved isn't visible by mortals
[10:06] <Kamion> check
[10:06] <infinity> ajmitch: Well, I think you can.
[10:06] <infinity> ajmitch: Check, please. :)
[10:07] <Kamion> infinity: failing that I suggest we periodically dump a list of packages in unapproved onto IRC
[10:07] <ajmitch> infinity: no permission
[10:07] <infinity> Kamion: Works for me.  I was planning on pinging these guys when I saw a mess of stuff in there anyway.
[10:07] <infinity> ajmitch: We'll work something out.
[10:07] <Kamion> right, time for final(?) d-i and ubiquity uploads
[10:07] <siretart> hm.. no permissions here as well
[10:07] <Kamion> will take a little while to have Rosetta dump translations on me
[10:07] <infinity> siretart: See above.
[10:08] <Kamion> I think it's a bug, really - you can see NEW, why not UNAPPROVED
[10:08] <siretart> ok
[10:09] <malcc> Kamion: I'm pretty sure that was deliberate, so there was an answer to your why in someone's head at some point. No idea what it was anymore though
[10:09] <infinity> malcc: There's no question that it was deliberate, but that doesn't answer the why. :)
[10:09] <Kamion> malcc: I wonder if it was before UNAPPROVED was added
[10:10] <Kamion> malcc: so deliberately not ACCEPTED, REJECTED, DONE
[10:10] <Kamion> even so it's kind of odd
[10:10] <Kamion> I think everyone should be able to see a list of items in all the queues, but everyone should not be able to download files from them (once that's implemented)
[10:11] <StevenK> fabbione: Right. It's a local problem. A missing md5sum will do that.
[10:12] <siretart> hm. I'm presented an 'ACCEPT' button on the NEW queue. I wonder what happens if I press it :)
[10:13] <Kamion> although in fact the code is explicit about not allowing UNAPPROVED
[10:13] <mantiena-baltix> pitti: why 0.5.7-1ubuntu18.1 still in proposed-updates, not in updates ? you noticed some problems in new version ?
[10:13] <ogra> Kamion, would you mind taking a look at the patch in the last comment of bug 65003 ? does that seem like a valid workaround ?
[10:13] <Ubugtu> Malone bug 65003 in ltsp "debootstrap fails to remove own log file on NFS" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65003
[10:13] <Kamion> siretart: known bug that you see it - you'll get Forbidden if you click Accept
[10:13] <siretart> Kamion: ah, I see. In fact, I thought so :)
[10:14] <doko_> Kamion, tfheen: uploaded zlib, fixing FTBFS on i386
[10:15] <siretart> Kamion: btw, given that we could look at the unapproved queue, how can we check/qa the uploads?
[10:15] <Kamion> ogra: you're mistaken about the repeated unpacking/configuring thing - debootstrap always unpacks and configures all of required, then unpacks and configures all of base
[10:15] <Kamion> siretart: you can't, yet ;-)
[10:15] <siretart> ah. I see :)
[10:15] <Kamion> you'd have to get an archive admin to fetch them and put them somewhere public
[10:16] <ogra> Kamion, yes, i noticed it later
[10:16] <ogra> Kamion, in d-i it does that but tells you about the five times it attepmts it, i was mixing that up
[10:17] <Kamion> that's only if something goes wrong, as you say
[10:17] <Kamion> I'll ponder that suggested patch
[10:17] <Kamion> mantiena-baltix: see https://wiki.ubuntu.com/StableReleaseUpdates; all dapper updates are being staged through dapper-proposed now
[10:18] <ogra> Kamion, i think the real fix should be in rm/coreutils though, but it seems appropriate as workaround to me
[10:21] <Kamion> ogra: do you have a link to a more complete description of the rm bug?
[10:21] <ogra> nope
[10:21] <tfheen> I'm not convinced it's a bug in rm, but rather a bug in the nfs server.
[10:22] <ogra> tfheen, you mean it treats -rf different than rm on its own ?
[10:22] <Kamion> unless it's http://www.mail-archive.com/bug-coreutils@gnu.org/msg08031.html
[10:22] <pitti> mantiena-baltix: that's our new stable release update policy; it must be in -proposed for at least a week
[10:23] <Kamion> ogra: obviously not (the NFS server doesn't know that you said -rf) but that unlink() isn't processed in time for the rmdir() to succeed
[10:23] <tfheen> ogra: do you know how NFS works?  On a protocol level?
[10:23] <ogra> roughly
[10:24] <tfheen> you know POSIX semantics wrt accessing deleted files?
[10:24] <tfheen> and how NFS to a certain degree emulates those semantics?
[10:25] <Kamion> OH
[10:25] <Kamion> the problem is that the file is still open but NFS is implementing access to it by means of a dotfile?
[10:25] <Kamion> s/but/so/
[10:26] <tfheen> at least the NFS server thinks it's open
[10:26] <ogra> ah
[10:27] <Kamion> it probably is, it's stderr
[10:27] <tfheen> it should still allow removing the directory if there are no other files in it.
[10:27] <ogra> well, i know he's using freebsd and plugs our ltsp on top ...
[10:27] <tfheen> (yes, this can easily be painful for the NFS server)
[10:27] <Kamion> another workaround might be to redirect stdout and stderr back to where they were before (or close them) before doing the rm -rf
[10:28] <Kamion> I'll comment on the bug report
[10:28] <fschoep> dholbach: ping?
[10:28] <dholbach> fschoep: working on it :)
[10:28] <ogra> Kamion, thanks
[10:28] <fschoep> dholbach: thanks so much
[10:28] <dholbach> fschoep: de rien
[10:31] <mantiena-baltix> pitti: I found where is problem when partition is listed in /etc/pmount.allow but nautilus doesn't allow to enter into this partition from computer:/ location ;)  it's because hal set's volume.ignore property for these partitions
[10:31] <Chipzz> pitti: I have a hppa box; 2 actually
[10:32] <janimo> ogra: thanks for the ldm upload
[10:33] <Chipzz> pitti: would setting one up with breezy and giving you access to it help?
[10:33] <pitti> mantiena-baltix: aaah
[10:33] <ogra> janimo, youre welcome, but please try to get such stuff sorted earlier next time
[10:33] <pitti> mantiena-baltix: yeah, I specifically patched this so that nautilus doesn't show these partitions on a desktop, since a user could not mount them anyway :)
[10:33] <tfheen> Riddell: you broke poppler, please fix.
[10:34] <pitti> Chipzz: erm, actually not, I just wondered about the edgy archive state of hppa
[10:34] <pitti> Chipzz: but thanks a lot for the offer!
[10:34] <janimo> tfheen: please approve gxine upload, it closes two LP bugs
[10:34] <Chipzz> yw :)
[10:35] <ogra> tfheen, why are we frozen already btw ? i thought the meeting date is the time ...
[10:35] <Kamion> ogra: actually, on reflection, Steven's patch is probably the best approach
[10:36] <tfheen> ogra: don't try gaming the system.  We are freezing today, the time is explicitly undefined.
[10:36] <tfheen> janimo: debdiff, please?
[10:36] <ogra> tfheen, i'm not "gaming the system" all freezes before deliberately started with the meeting, thats why i wondered
[10:37] <mantiena-baltix> pitti: unmounted partitions are newer shown on the desktop in any case but if volume.ignore is set to true for these partitions then user should press "Reload" button manually (after he double clicks on partition) if he wants to enter into this partition from computer:/ location
[10:38] <pitti> mantiena-baltix: let's find a solution in edgy+1 which suits us both
[10:38] <Kamion> ogra: I think you can reject the ltsp part of that bug
[10:39] <ogra> right
[10:39] <Kamion> tfheen: ok to upload http://librarian.launchpad.net/4793845/debootstrap.nfs.patch ? NFS server bug or not, it seems a reasonable workaround
[10:39] <mantiena-baltix> pitti: ok, I think volume.ignore should be set to false in 20-storage-methods.fdi for unmounted partitions, this is valid for gksudo mount wrapper too
[10:39] <tfheen> Kamion: approved.
[10:40] <pitti> mantiena-baltix: yes, we'll un-ignore it as soon as the desktop can actually handle them correctly
[10:40] <Kamion> (I added an extensive comment)
[10:40] <mantiena-baltix> pitti: because unmounted hard drive partitions should be shown in computer:\ location if there will be a way to mount these with gksudo mount wrapper ;)
[10:40] <dholbach> fschoep: edgy-wallpapers and edgy-session-splashes uploaded, doing edgy-gdm-themes now
[10:41] <fschoep> dholbach: OK, did I ever tell you you are Clark Kent's alter ego?
[10:41] <fschoep> dholbach: :)
[10:41] <dholbach> Thanks :-)
[10:42] <StevenK> enervated:~# chroot /tmp/d mount -t proc proc /proc
[10:42] <StevenK> FATAL: kernel too old
[10:42] <Treenaks> kernel too old to mount /proc?!?!
[10:42] <Fujitsu> Haha.
[10:43] <StevenK> That's my sparc64 mailserver. I didn't really want 2.6 on it.
[10:43] <fabbione> StevenK: we don't support 2.4
[10:43] <fabbione> not even on sparc
[10:43] <pitti> mantiena-baltix: can we please discuss that after the edgy release?
[10:43] <StevenK> I figured.
[10:43] <pitti> mantiena-baltix: I'm afraid I really have to care for other stuff now, sorry
[10:44] <Kamion> tfheen: accepted zlib; it was just removing a couple of compiler options from the i386/x86-64 build
[10:44] <seb128> iwj: hi. Is compreg.dat of any use? Maybe the firefox postinst could rm it to workaround weird issue happening for people who have one still installed, it's creating bug #30791 now
[10:44] <Ubugtu> Malone bug 30791 in firefox "firefox 1.4.99 upgrade still have compreg.dat, creates issue" [Medium,Needs info]  http://launchpad.net/bugs/30791
[10:45] <tfheen> Kamion: thanks
[10:46] <mantiena-baltix> pitti: no problem, I just write comments about volume.ignore in bugreport about mounting non-removable partitions, because we can forget these after edgy will be released ;)
[10:46] <pitti> mantiena-baltix: yes, a bug report is appreciated; please subscribe me; thanks
[10:47] <tfheen> pitti: your mail-notification upload FTBFS due to not finding a .desktop file.
[10:47] <tfheen> (yes, I realise it's a no-change upload so probably not your fault)
[10:47] <tfheen> probably mvo's fault, actually.
[10:47] <pitti> tfheen: oh, thanks, will look into it
[10:47] <pitti> sorry
[10:49] <tfheen> powerpc-linux-gnu-g++: now: No such file or directory
[10:49] <tfheen> that's.. special, isn't it?
[10:51] <tfheen> seb128: you're probably aware of it, but your latest tsclient upload FTBFS-ed across all arches.
[10:51] <seb128> tfheen: no, I'm not
[10:51] <seb128> thank you for pointing it
[10:51] <seb128> would be nice if we had ftbfs notification ;)
[10:51] <tfheen> checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
[10:52] <ogra> tfheen, http://people.ubuntu.com/~ogra/fuse.debdiff ok to upload ?
[10:52] <seb128> tfheen: ok, fixing it
[10:53] <pitti> hi mvo
[10:53] <pitti> tfheen, dholbach: can I upload a FTBFS fix for mail-notification? (simple debian/rules fix to adapt the path to the .desktop file)
[10:54] <dholbach> pitti: sure
[10:54] <tfheen> ogra: use grep -q instead of redirecting the output.
[10:54] <mvo> pitti: if you upload it, make sure the desktop file is ok too
[10:54] <ogra> ok
[10:54] <mvo> pitti: it used to have a typo
[10:55] <tfheen> ogra: apart from that, feel free.
[10:55] <pitti> mvo: hm, what do you mean? looks fine on a first sight
[10:56] <tfheen> oh, bloody thingabob.
[10:56] <tfheen> lcome.pdfpdfetex: symbol lookup error: pdfetex: undefined symbol: _ZN4Dict3addERK10UGooStringP6Object
[10:56] <mvo> pitti: no, its all good. 
[10:57] <pitti> tfheen: bless you
[10:58] <tfheen> pitti: any idea about that?  It seems like a rebuild should fix it?
[10:58] <tfheen> pitti: http://librarian.launchpad.net/4794030/buildlog_ubuntu-edgy-i386.gnat-gps_3.1.3-2ubuntu1_FAILEDTOBUILD.txt.gz is the build log
[10:58] <pitti> tfheen: rebuild might be worth a try, but should be tested locally
[10:59] <pitti> tfheen: that smells like a poppler ABI change that tetex-bin didn't pick up
[10:59] <janimo> tfheen: the gxine debdff is basically two new patches under debian /04_poke_xscreensaver.dpatch and /05_no_splash.dpatch. If that is not easy to peek at in the queue directly I'll put a debdiff up shortly
[11:00] <tfheen> pitti: yeah, which means we might have to either rebuild everything using poppler or bump the soname.
[11:00] <tfheen> janimo: I don't have access to the queue.
[11:00] <pitti> tfheen: hmm, pdflatex works fine here
[11:01] <pitti> tfheen: texi2dvi, too. WTH???
[11:01] <tfheen> pitti: on i386?
[11:01] <pitti> tfheen: aah, i386-only FTBFS; I tested on amd64
[11:02] <pitti> can anyone on i386 please try: gzip -cd /usr/share/doc/bzip2/manual.texi.gz > /tmp/manual.texi && texi2dvi /tmp/manual.texi  ?
[11:03] <pitti> and if that fails, rebuilt tetex-bin and try again?
[11:03] <dholbach> fschoep: uploaded gdm-themes and pushed them all to bzr
[11:03] <seb128> dholbach: one of your uploads broke the cursor theme, you know about it?
[11:03] <fschoep> dholbach: OK, great - this means they're in time for the freeze?
[11:03] <janimo> tfheen: http://paste.ubuntu-nl.org/26413/ . The code is a copy of the gnome-screensaver poking code nothing new or scary
[11:03] <seb128> dholbach: no  /usr/share/themes/Human/cursor.theme installed
[11:04] <ogra> seb128, depends on the POV ;) it fixed the cursors for ltsp
[11:04] <dholbach> seb128: uh? how did you get that? ogra did you hear anything about it?
[11:04] <seb128> dholbach: a guy reported it on launchpad
[11:04] <seb128> and it's broken on my box too
[11:04] <ogra> dholbach, worked here
[11:04] <dholbach> it works for me too
[11:04] <tfheen> janimo: please add a proper description to the dpatches.
[11:05] <ogra> (on a new ltsp install though)
[11:05] <seb128> $ ls -l /etc/alternatives/x-cursor-theme 
[11:05] <seb128> lrwxrwxrwx 1 root root 36 Sep 15 09:38 /etc/alternatives/x-cursor-theme -> /usr/share/themes/Human/cursor.theme
[11:05] <seb128> $ ls -l /usr/share/themes/Human/cursor.theme
[11:05] <seb128> ls: /usr/share/themes/Human/cursor.theme: No such file or directory
[11:05] <seb128> 
[11:05] <seb128> and I've just dist-upgraded
[11:05] <seb128> which means gdm get the ugly cursor
[11:06] <seb128> ogra: it works on the desktop because GNOME forces the cursor and doesn't need to alternative
[11:06] <ogra> seb128, no it worked on the login manager ...
[11:06] <seb128> do you have that cursor.theme?
[11:06] <ogra> (before any gconf is loaded)
[11:06] <ogra> oh, wait
[11:06] <seb128> what package provides it?
[11:06] <ogra> thats still the ltsp package with the workaround that sets the alternative
[11:06] <janimo> tfheen: ah ok, although  I thought descriptive filenames were enough.
[11:07] <janimo> tfheen: so I upload with the same version number but corrections added?
[11:07] <pitti> tfheen: bah, texi2dvi works fine in ronne's i386 dchroot, too
[11:07] <ogra> seb128, sorry, the publisher apparently wasnt fast enough for me ... i tested an older pkg ... :/
[11:08] <dholbach> seb128: my fault. ogra: I'll install it to /usr/share/themes/Human/cursor.theme instead of /usr/share/*icons*/Human/cursor.theme
[11:08] <dholbach> that should fixit
[11:08] <pitti> tfheen: (it has an old libpoppler)
[11:08] <dholbach> seb128, ogra: sorry for that
[11:08] <tfheen> janimo: won't it fill the log with "can't poke the xscreensaver" for people who don't have it installed?
[11:08] <seb128> dholbach: yep that should, thank you
[11:09] <pitti> dholbach, seb128: does any of you have a current i386 edgy and some minutes?
[11:09] <dholbach> seb128: you have the bug number?
[11:09] <dholbach> pitti: yes
[11:09] <pitti> dholbach: gzip -cd /usr/share/doc/bzip2/manual.texi.gz > /tmp/manual.texi && texi2dvi /tmp/manual.texi
[11:09] <pitti> dholbach: (with tetex-bin installed) -> does the texi2dvi fail with a symbol error?
[11:10] <seb128> dholbach: bug #65600
[11:10] <Ubugtu> Malone bug 65600 in human-cursors-theme "(Edgy) gdm now uses black X cursors instead of Ubuntu Human cursors by default" [Undecided,Confirmed]  http://launchpad.net/bugs/65600
[11:10] <dholbach> i didn't have command-not-found installed
[11:10] <seb128> pitti: dholbach was faster, do you need me to test anyway?
[11:10] <pitti> seb128: nevermind, thanks
[11:10] <seb128> np
[11:10] <janimo> tfheen: it's the same code as for gnome-screensaver. If EACCESS is rececived it will no longer try to poke
[11:11] <dholbach> pitti: bash: texi2dvi: command not found
[11:11] <tfheen> janimo: oh, I'm blind; sure.  Ok, feel free to upload.
[11:11] <dholbach> pitti: and tetex-bin is installed
[11:11] <pitti> dholbach: sorry, that's texinfo
[11:11] <janimo> tfheen:do I keep same version number for the new upload?
[11:12] <dholbach> pitti: 
[11:12] <dholbach> daniel@lovegood:~$ gzip -cd /usr/share/doc/bzip2/manual.texi.gz > /tmp/manual.texi && texi2dvi /tmp/manual.texi | grep -E "(symbol|error)"
[11:12] <dholbach>  file:line:error style messages enabled.
[11:12] <dholbach> daniel@lovegood:~$ 
[11:12] <dholbach> pitti: looks good
[11:12] <pitti> dholbach: ok; and texi2dvi -p /tmp/manual.texi ?
[11:13] <dholbach> daniel@lovegood:~$ texi2dvi -p /tmp/manual.texi  | grep -E "(symbol|error)"
[11:13] <dholbach>  file:line:error style messages enabled.
[11:13] <dholbach> daniel@lovegood:~$ 
[11:13] <tfheen> janimo: ask infinity or Kamion to reject 1ubuntu5 first or bump the version number.  Either's fine.
[11:13] <janimo> tfheen: uploaded, added LP bug numbers to changlog and fixed the dpatch descriptions
[11:13] <pitti> dholbach: you have libpoppler1_0.5.4-0ubuntu2_i386.deb ?
[11:13] <tfheen> janimo: this is why you should ask a member of the release team before uploading.
[11:14] <dholbach> pitti: 0.5.4-0ubuntu3
[11:14] <tfheen> Kamion: you broke *ubuntu-meta ; ubuntu-live no longer exists.  Feel like fixing that? 
[11:14] <janimo> Kamion: please reject gxine_0.5.7-1ubuntu5
[11:14] <pitti> dholbach: ok, thanks; hmm, very mysterious
[11:15] <janimo> so I can reupload it fixed
[11:15] <janimo> thanks
[11:15] <dholbach> tfheen: judging by the changelog it was deliberate
[11:15] <seb128> dholbach: how did you do that, he did build
[11:15] <seb128> didn't
[11:15] <seb128> https://launchpad.net/distros/ubuntu/+source/poppler/0.5.4-0ubuntu3
[11:15] <dholbach> seb128: because I used showsrc instead of show
[11:16] <dholbach> seb128: lalalalala
[11:16] <seb128> :p
[11:16] <dholbach> pitti: sorry, is 0ubuntu2
[11:16] <seb128> you know about dpkg -l, right? ;)
[11:16] <pitti> dholbach: heh
[11:16] <tfheen> dholbach: I don't think the FTBFS was deliberate.
[11:16] <dholbach> tfheen: no, I shouldn't think so.
[11:16] <Kamion> the FTBFS wasn't, I'll check that
[11:16] <Kamion> but ubuntu-live is going away
[11:16] <pitti> dholbach: still, http://librarian.launchpad.net/4794030/buildlog_ubuntu-edgy-i386.gnat-gps_3.1.3-2ubuntu1_FAILEDTOBUILD.txt.gz is mysterious
[11:16] <seb128> pitti: do you know why ekiga didn't get its debsym moved on your people page?
[11:16] <pitti> dholbach: it only fails on i386, and the amd64 build used the same libpoppler
[11:16] <Kamion> let me just get this d-i upload done first
[11:17] <tfheen> Kamion: please do.
[11:17] <pitti> seb128: let me track it
[11:17] <dholbach> pitti: urg :-/
[11:18] <tfheen> dholbach: syncropated ftbfs-ed; http://librarian.launchpad.net/4797234/buildlog_ubuntu-edgy-i386.syncropated_0.1.2-0ubuntu1_FAILEDTOBUILD.txt.gz
[11:18] <pitti> dholbach: maybe you could try a local build of gnat-gps?
[11:19] <dholbach> tfheen: checking in a bit
[11:19] <dholbach> pitti: getting the source
[11:21] <pitti> dholbach: ouch
[11:21] <dholbach> no problem :)
[11:21] <dholbach> I always thought I'd need some more gnat packages on my laptop ;)
[11:22] <tfheen> pitti: and your gnomesword upload failed to build due to libsword changing underneath you.  I'm looking at that.
[11:24] <pitti> seb128: fixed; I blame cosmic rays
[11:25] <Hobbsee> pitti: damn them.  havent you written something to get rid of them yet?
[11:25] <pitti> apt-get install lead-shield on rookery :)
[11:26] <Hobbsee> hehe
[11:26] <seb128> pitti: thank you :)
[11:29] <dholbach> tfheen: syncropated fixed
[11:31] <Kamion> janimo: the older one, I assume?
[11:32] <tfheen> if there are any ichtux/ubuntu christian edition people about: gnomesword ftbfs with the new libsword-dev.
[11:32] <Kamion> janimo: done, although in future I'd rather you just superseded it with a new version
[11:32] <dholbach> seb128, ogra: human-cursors-theme fixed
[11:34] <dholbach> whoever drives that part of launchpad now: please accept edgy-gdm-themes, edgy-session-splashes, edgy-wallpapers, human-cursors-theme
[11:35] <iwj> seb128: No, compreg.data is an anachronism.  Nothing should be creating it.
[11:36] <Treenaks> iwj: so why is stuff still crashing when it exists? Shouldn't it also just be ignored?
[11:36] <seb128> iwj: it happens for a bunch of people still, what about just making the postinst rm it?
[11:36] <tfheen> dholbach: technically, you should ask a member of the release team to review them before uploading. :-P  They're trivial rollbacks to edgy?
[11:36] <dholbach> yes, I even tested them
[11:36] <dholbach> human-cursors-theme has a fix
[11:37] <tfheen> dholbach: testing> that being a new experience for you?
[11:37] <pitti> dholbach: testing? wimp! :)
[11:37] <iwj> seb128: I'm not sure that would be sufficient.  Some other package's maintscript is creating it.
[11:37] <iwj> Treenaks: This is Mozilla code we're talking about - don't ask questions like that.
[11:37] <dholbach> tfheen: Tell me what you think
[11:37] <iwj> seb128: So it could easily be created after firefox was last upgraded.
[11:38] <Treenaks> iwj: because of brain-hurt, of because looking at mozilla code invalidates the trademark license?
[11:38] <iwj> What we need to do is find out _why_ it's being created.  There's probably one thing that's doing it.
[11:38] <iwj> Treenaks: It's huge and old and full of cruft.
[11:38] <Treenaks> of=or
[11:38] <tfheen> dholbach: debdiffs would be nice.
[11:38] <pitti> infinity: argh, finally got to the libtasn1-3 FTBFS; debian/rules uses "--dbg-package libtasn1-3", while the manpage mandates "--dbg-package=libtasn1-3"; will fix
[11:38] <dholbach> tfheen: hang on
[11:39] <pitti> infinity: (fix in pkg-create-dbgsym to accept that syntax as well, I mean)
[11:39] <seb128> iwj: right, I agree on that, the issue is that's not reproducible easily and people who get it didn't install anything to get datas before the upgrade
[11:39] <tfheen> gnat-gps ftbfs on amd64, but with another error.
[11:39] <tfheen> *sigh*
[11:40] <iwj> seb128: If I arrange for the firefox postinst to remove this file, it will only help if the thing that's creating it is upgraded before firefox.  But that seems unlikely; it's probably a gecko embedder.
[11:40] <seb128> iwj: yeah, might be
[11:40] <iwj> Certainly there is no harm in it.  It would mean also that reinstalling firefox would fix the problem.
[11:42] <iwj> I think in edgy+1 I might do some crazy thing with inotify.
[11:44] <dholbach> tfheen: http://daniel.holba.ch/temp/ <- 4 debdiffs
[11:44] <janimo> Kamion: thanks, I'll know next time
[11:45] <sivang> morning
[11:45] <Kamion> ok, that's *-meta fixed
[11:46] <iwj> seb128: How often do you get these reports ?  We could collect installed package lists from people and compute the intersection.
[11:48] <seb128> iwj: I think we got around 10 people complaining about the "gmail is not working" issue for a month
[11:48] <tfheen> dholbach: go ahead.  Please close the artwork bugs as well when you upload.
[11:48] <seb128> iwj: I had the issue too during the Wiesbaden sprint, we just figured yesterday it's due to the compreg.dat
[11:49] <dholbach> tfheen: I already uploaded them - they're sitting in the queue
[11:49] <dholbach> tfheen: I'd like fschoep to close the bugs - aiui there's still ongoing work
[11:49] <Kamion> dholbach: all four accepted
[11:50] <dholbach> Kamion: thanks a lot!
[11:50] <Kamion> tfheen: in unapproved: tsclient gxine fuse dist-upgrader
[11:50] <fschoep> tfheen: dholbach: I can close the bugs, I was waiting for the sign that the "new" art stuff was in
[11:50] <dholbach> fschoep: oh - I thought tere was still work ongoing?
[11:51] <tfheen> Kamion: tsclient, gxine, fuse approved, dist-upgrader I have not heard anything about.
[11:51] <iwj> seb128: Hmm.  OK, I will arrange for the postinst to delete it - and to grumble to stderr.
[11:51] <seb128> iwj: thank you
[11:51] <iwj> seb128: But we should do something more proactive for edgy+1.
[11:51] <fschoep> dholbach: there was, but I haven't received word from above so we can't do anything
[11:51] <Kamion> mvo: ^-- ?
[11:51] <iwj> I don't think this will make the problem go away but it will probably make it easier to fix.
[11:51] <iwj> It's annoying not to be able to do anything more useful.
[11:52] <seb128> iwj: I'll try to set debug for it when I do dapper to edgy upgrades
[11:52] <mvo> Kamion: I just uploaded a one-line fix. I can put the diff to people.u.c if you want
[11:52] <iwj> Can you confirm that it's always created in the same place ?
[11:52] <fschoep> Only thing to change might be applying the patch in bug 57588 to the old GDM
[11:52] <Ubugtu> Malone bug 57588 in edgy-gdm-themes "GDM themes do not have pam-message item" [High,In progress]  http://launchpad.net/bugs/57588
[11:52] <iwj> seb128: Thanks.
[11:52] <seb128> iwj: /usr/lib/firefox/components/compreg.dat
[11:52] <iwj> Right.
[11:52] <dholbach> fschoep: alright-y
[11:53] <fschoep> dholbach: don't worry about it though - I mean, I was waiting for Mark but he hasn't sent me anything in the last fourteen hours or so and I've been up almost all night
[11:53] <Kamion> mvo: please
[11:55] <Kamion> -            loggging.warning("_tryMarkObsoleteForRemoval failed for '%s' (%s)" % (pkgname,e))
[11:55] <Kamion> +            logging.warning("_tryMarkObsoleteForRemoval failed for '%s' (%s)" % (pkgname,e))
[11:55] <Kamion> oh, that's obviously trivial, will approve
[11:55] <tfheen> Kamion: oh, happy enough with that, yes.
[11:55] <mvo> Kamion: http://people.ubuntu.com/~mvo/tmp/dist-upgrader-20060928.1238.diff <- spott the error ,)
[11:55] <Kamion> mvo: that's an entirely different diff ...
[11:55] <iwj> seb128: I have edited the bug appropriately.
[11:56] <mvo> Kamion: rurg
[11:56] <fschoep> tfheen: dholbach: I set bug 64317 and 64318 to "Fix Released" to get them off the list.
[11:56] <mvo> Kamion: the wrong one
[11:56] <Ubugtu> Malone bug 64317 in evolution "Copying mail from imap / exchange to local mailbox looses data." [Undecided,Needs info]  http://launchpad.net/bugs/64317
[11:56] <Ubugtu> Malone bug 64318 in zsh "shell dumps core while accessing libnss-ldap" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64318
[11:56] <Kamion> mvo: never mind, I think we've got it
[11:56] <dholbach> fschoep: rock and roll
[11:56] <tfheen> fschoep: I hope you typoed both of those bug numbers.
[11:56] <mvo> Kamion: ok
[11:57] <fschoep> tfheen: No I didn't, Ubugtu is in the wrong I think
[11:57] <fschoep> Oh I did
[11:57] <fschoep> Sorry
[11:57] <fschoep> tfheen: Bug 64137 and 64138
[11:57] <Ubugtu> Malone bug 64137 in edgy-gdm-themes "Edgy RC needs new Human GDM theme" [Medium,Fix released]  http://launchpad.net/bugs/64137
[11:57] <Ubugtu> Malone bug 64138 in edgy-wallpapers "Edgy RC needs new Human wallpaper" [Medium,Fix released]  http://launchpad.net/bugs/64138
[11:57] <fschoep> That's better
[11:57] <pitti> tfheen: I'd like to upload a new pkg-create-dbgsym which fixes the libtasn-1-3 FTBFS
[11:57] <fschoep> I'm 20% awake right now, so apologies
[11:57] <seb128> iwj: oh, I pointed the wrong bug number previously, bug #57888 is the new issue due to it
[11:57] <Ubugtu> Malone bug 57888 in firefox "GMail and Ajax websites not working with Firefox 2.0 backend" [Undecided,Unconfirmed]  http://launchpad.net/bugs/57888
[11:58] <seb128> iwj: should it be marked as dup of the other one?
[11:58] <pitti> tfheen: one-line fix in the dh_strip wrapper plus added test case
[11:58] <seb128> iwj: thank you for the bug update
[11:59] <tfheen> pitti: go ahead.
[11:59] <pitti> tfheen: uploaded
[11:59] <pitti> infinity: ^ this fixes libtasn-1-3 ftbfs
[11:59] <fschoep> iwj: are the Firefox themes going to be 0.5.4, the branch and all builds but I can't find this version on Launchpad?
[12:02] <dholbach> pitti: it seems it builds for hours
[12:03] <tfheen> mvo: are you doing upgrade testing?
[12:03] <mvo> tfheen: yes, I can do this
[12:03] <tfheen> mvo: great, thanks.
[12:04] <mvo> (and did that to a certain extend the last days on and off)
[12:04] <tfheen> mvo: yeah, I just hadn't heard you explicitly said "I'll do upgrade testing", so I asked. :-)
[12:04] <mvo> :)
[12:04] <mvo> "I'll do upgrade testing"
[12:04] <mvo> (for the records ,9
[12:07] <Tonio_> hi
[12:07] <sivang> hey Tonio_ 
[12:10] <iwj> fschoep: Uh ?
[12:10] <fschoep> iwj: remember I did some changes this week, you updated the branch and all, but no package was built from the new source it seems
[12:10] <iwj> fschoep: Oh, I seem to have forgotten to actually do the upload.  Sorry.
[12:10] <fschoep> iwj: right, that part I was talking about ;)
[12:11] <iwj> It's done now.
[12:11] <fschoep> iwj: no problem though, I imagine you have more important things right now
[12:11] <fschoep> iwj: thanks
[12:11] <iwj> The theme testing (and hence upload) got tangled up with a firefox change.
[12:11] <fschoep> Oh dear, not something that messes up the themes again I hope?
[12:13] <fabbione> ajmitch: ping?
[12:14] <Kamion> fschoep: I noticed that the search engine box icon and text entry box are misaligned; is that related?
[12:14] <fschoep> Kamion: yes
[12:14] <Kamion> good
[12:14] <fschoep> Kamion: the new package should fix everything and more
[12:19] <iwj> fschoep: No, I just couldn't test it straight after making it because my install's firefox was in a mess because I was doing a new ff at the same time.  When the ff was fixed all was well but I only uploaded ff and not the themes package.
[12:19] <fschoep> iwj: I see, I hope all is well now and the fixed themes are in :)
[12:20] <fschoep> iwj: thanks a ton as I probably already said
[12:20] <Kamion> tfheen: FYI this firefox-themes-ubuntu changelog is:
[12:20] <Kamion> +  * Updated to latest bzr (revno: 24), changes by Frank Schoep:
[12:20] <Kamion> +    - Implemented pressed icon states for the main, small, bookmark
[12:20] <Kamion> +      and help toolbar
[12:20] <Kamion> +    - Added a renderDarkened() function to render pressed icon versions.
[12:21] <tfheen> fschoep: what bugs does that touch?
[12:21] <fschoep> These:
[12:21] <Kamion> fschoep: weird that $pressed and $disabled are different ways round in createbookmarks and createhelp
[12:21] <Kamion> fschoep: is that an artifact of the Mozilla API?
[12:21] <fschoep> Bug 65196
[12:21] <Ubugtu> Malone bug 65196 in firefox-themes-ubuntu "[Edgy]  New Firefox 2.0rc2 looks ugly with Human theme" [Unknown,Fix released]  http://launchpad.net/bugs/65196
[12:22] <fschoep> And 64472
[12:22] <fschoep> Bug 64472
[12:22] <Ubugtu> Malone bug 64472 in firefox-themes-ubuntu "Icons dissapear when mouse is clicked and held down" [Medium,Fix released]  http://launchpad.net/bugs/64472
[12:22] <fschoep> Kamion: I don't know what goes on in the mind of those Mozilla folks
[12:22] <fschoep> Kamion: I just look at what they want and work from there
[12:22] <fschoep> Kamion: a lot of things are inconsistent
[12:22] <Kamion> fschoep: as long as it's intentional
[12:23] <fschoep> Kamion: it is, but I'm pretty sure that the bookmarks thing is a bug in Firefox
[12:23] <fschoep> Kamion: I just copied their behaviour
[12:23] <fschoep> Kamion: the default theme with disabled buttons looks like crap, so mine do too
[12:23] <Kamion> tfheen: I'd like to do *something* about the theme definitely - the most recent version looks a lot worse
[12:24] <tfheen> Kamion: ok, approved.
[12:24] <fschoep> Kamion: 0.5.4 is *worse*?
[12:24] <fschoep> than 0.5.3?
[12:24] <Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/firefox-themes-ubuntu.diff
[12:24] <Kamion> fschoep: no, 0.5.3 is worse than earlier themes
[12:25] <pitti> tfheen: FYI, my own milestone bug list is empty now; I'll look into the other milestone bugs, unless you have something specific for me
[12:25] <fschoep> Kamion: that's because of Firefox moving to RC2
[12:25] <Kamion> yeah, I realise that
[12:25] <fschoep> Kamion: they tend to break theme stuff all the time :)
[12:25] <Kamion> sorry, 0.5.3 + rc2
[12:25] <Kamion> I've accepted 0.5.4
[12:25] <fschoep> OK, great - it looks a lot better
[12:26] <fschoep> Matt also asked if we could make the Human one default?
[12:26] <fschoep> I think iwj and the Xubuntu guy(s) looked at that earlier
[12:26] <pitti> tfheen: ok for me to fix bug 61184? it only affects certain Thinkpads, but it's easy to fix (no code, just FDI changes)
[12:26] <Ubugtu> Malone bug 61184 in hal "Screen brightness buttons don't work properly on Thinkpad Z61T" [Medium,In progress]  http://launchpad.net/bugs/61184
[12:27] <Keybuk> chilly in here, today
[12:28] <tfheen> Kamion: the firefox-themes-ubuntu build-deps on php?
[12:28] <fschoep> tfheen: shoot me
[12:28] <fschoep> tfheen: I used PHP to script the theme building and it works
[12:29] <tfheen> oh well
[12:29] <fschoep> tfheen: it's maintainable
[12:29] <tfheen> fschoep: I won't enter a discussion about PHP with you with fear of causing permanent bodily harm to you.
[12:29] <fschoep> tfheen: iwj probably wants me dead for it, but it was the first bit of code I wrote for Ubuntu in a voluntary fashion
[12:29] <tfheen> s/with/for/
[12:30] <fschoep> tfheen: please don't look at the makefile that builds a debian package
[12:30] <tfheen> Kamion: it looks good enough to me, the bookmarks bit is strange, but if that's how it works, that's how it works..
[12:30] <fschoep> tfheen: it's that way in the default theme
[12:30] <fschoep> tfheen: I just mimic what they want
[12:30] <tfheen> pitti: yay, excellent.  Please do attack the list of unassigned milestone bugs, yes.
[12:31] <tfheen> Keybuk: why did you add linuxprinting.org-ppds to -desktop?
[12:32] <Kamion> tfheen: am I waving through unapproved universe uploads?
[12:32] <Kamion> I can always do a quick review of them myself
[12:32] <tfheen> dholbach: ^^
[12:32] <Keybuk> tfheen: I did?
[12:33] <Keybuk> was it one of those that went from a depends to a recommends
[12:33] <Keybuk> and was originally held in main because of that?
[12:33] <Keybuk> that's most likely
[12:33] <tfheen> Keybuk: no, main is fine, desktop isn't fine.
[12:33] <Keybuk> tfheen: it was a dep of something in desktop in dapper
[12:33] <tfheen> I explicitly moved it from Depends to Recommends in order for it not to be in desktop.
[12:33] <tfheen> it wasn't in dapper, iirc
[12:33] <Keybuk> oh, I see
[12:33] <Keybuk> then move it to supported :)
[12:33] <tfheen> 'k
[12:33] <Keybuk> I couldn't find any rationale for it vanishing, so thought it was just an accident
[12:34] <Keybuk> or even move it to universe
[12:34] <Keybuk> I tend to assume that if something is in main, was a depends, became a recommends, but didn't also get demoted -- that it was an accident, rather than deliberate
[12:35] <dholbach> Kamion, tfheen: if ajmitch, siretart and I got a list of universe uploads we could check if they got Universe/Upstream/Upload/U... approval before
[12:35] <tfheen> yeah, supported is fine.
[12:35] <Kamion> dholbach: your xdg-utils patch updates are wrong - they produce duplicate code in xdg-email at least
[12:35] <dholbach> Kamion: uh? I'll double-check
[12:35] <infinity> pitti: Thanks for the libtasn FTBFS fix.  How do you feel about hunting a tar test suite failure on i386? :)
[12:35] <Kamion> dholbach: could you upload -0ubuntu2 correcting that?
[12:36] <dholbach> Kamion: sure, in a bit
[12:36] <pitti> infinity: can do, as long as I have the necessary stuff on ronne
[12:36] <infinity> Build-Depends: debhelper (>> 5), gettext, autoconf, autotools-dev
[12:36] <pitti> infinity: any details?
[12:36] <infinity> Should be okay. :)
[12:36] <Kamion> dholbach: it could be it was an older update that broke it, I don't know
[12:36] <pitti> yeah
[12:36] <Kamion> but either way, it's wrong :)
[12:36] <infinity> pitti: I'll bounce you the log.
[12:36] <dholbach> Kamion: just looking at libflaim and libxflaim that Mark wanted to see go in - i'll do xdg-utils after that
[12:37] <Kamion> dholbach: currently the list is xdg-utils and gnome-phone-manager; I'm looking at the latter now
[12:38] <Kamion> gnome-phone-manager is fine, accepted
[12:39] <dholbach> Kamion: thanks a lot
[12:43] <pitti> infinity: can you please try a give-back on gnat-gps on i386? a local rebuild doesn't have that linking problem and it worked on other arches
[12:43] <infinity> pitti: It's been tried a few times.
[12:43] <pitti> oh, ok
[12:43] <Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.2.0.diff <- OK to upload? most of the changes to incorporated source packages aren't very relevant; I wouldn't mind a second eye on the orca change down near the end though
[12:44] <pitti> infinity: tar test suite works fine on ronne/i386, btw
[12:44] <infinity> pitti: Cock.  Really?  It fails on my laptop and on the buildds.
[12:44] <infinity> pitti: I thought it might be kernel-related, but the laptop is an edgy kernel, and the buildd it fails on is 2.6.15... Hrm.
[12:45] <infinity> pitti: Oh, wait, but ronne isn't a real i386, so it could still be kernel.
[12:45] <pitti> infinity: I can install an i386 dapper to track it down, will just take a bit
[12:46] <infinity> pitti: I can track it later, I'm just trying to pawn off some stuff 'cause it's late for me. :)
[12:47] <pitti> infinity: trying on my i386 server now (but that has 2.6.18 custom upstream kernel)
[12:47] <dholbach> tfheen: it seems that kdebluetooth needs changes to be happy with libbluetooth 3.7
[12:48] <dholbach> tfheen: and we got a bug report about passkey stuff for kde - not sure how to handle that one
[12:48] <dholbach> tfheen: debian just had an upload for the kdebluetooth <-> bluez-libs 3.7 fixage
[12:49] <tfheen> Kamion: it looks correct to me.
[12:49] <tfheen> dholbach: how big are the changes?
[12:50] <dholbach> tfheen: hang on
[12:50] <Kamion> good good, I was paranoid with try
[12:50] <tfheen> Kamion: yeah, you could have skipped the outer finally and just have let cmdline go out of scope
[12:50] <tfheen> Kamion: but what you have there should be good
[12:51] <Kamion> I don't trust python's gc to close files when they go out of scope
[12:51] <Kamion> IME it doesn't do so reliably
[12:51] <cbx33> seb128: Hi - I there is a bug with pessulus
[12:51] <seb128> cbx33: hi
[12:51] <cbx33> it is broken
[12:51] <seb128> cbx33: which one?
[12:51] <Kamion> I've had ubiquity bugs in the past due to leaked fds from files I thought had been automatically closed
[12:51] <cbx33> because the file I created in the patch...
[12:51] <cbx33> the gconfapplierscp
[12:51] <cbx33> is not present on thesystem
[12:51] <cbx33> gconflockdownapplierscp
[12:52] <cbx33> it's in the diff....but never gets installed
[12:52] <cbx33> sorry Kamion ..... /me is all in a panic now...
[12:52] <dholbach> tfheen: http://people.ubuntu.com/~dholbach/kdebluetooth-debian.debdiff
[12:52] <Kamion> I mean for your program names :-)
[12:53] <seb128> cbx33: I don't understand the issue, do you have a patch?
[12:53] <dholbach> tfheen: but it needs merging into our package and testing (and it doesn't fix the bluetooth passkey kde issue)
[12:53] <cbx33> oh....was following convention in package ;)
[12:53] <cbx33> http://archive.ubuntu.com/ubuntu/pool/main/p/pessulus/pessulus_2.16.1-0ubuntu1.diff.gz - is the latest diff right? - in tehre I create a file called Pessulus/lockdownappliergconfscp.py
[12:54] <cbx33> but I must not have added it to the install file
[12:54] <cbx33> so it gets created but nuver installed
[12:54] <cbx33> does that make sense?
[12:54] <tfheen> dholbach: looks safe enough to me -- Riddell, can you take a look at http://people.ubuntu.com/~dholbach/kdebluetooth-debian.debdiff and see if you'd want it in?
[12:56] <Kamion> Keybuk: I was up hideously late last night and need a bit of rest now. Can you take over the unapproved queue? The xdg-utils upload in there has some wrong bits in the xdg-email patch - I've asked dholbach to fix that
[12:56] <Kamion> deliberately leaving it in the queue for comparison purposes
[12:56] <Keybuk> Kamion: yup, was just talking to Tollef about that
[12:56] <Kamion> ok
[12:56] <dholbach> Kamion: thanks a lot again - take your time resting!
[12:57] <Kamion> phone me if the sky falls in
[12:57] <cbx33> seb128: what file would I edit to make it install the new module....?
[12:57] <tfheen> dholbach: would you agree that we close the door for NEW packages now?  Unless they're fixing critical bugs, that is.
[12:58] <Riddell> tfheen: yes please
[12:58] <pitti> infinity: ah, I get the tar issue on my i386 sarge server; I'll look into it
[12:58] <Riddell> dholbach: although shouldn't it be a patch in debian/patches?
[12:58] <seb128> cbx33: I'll have a look in a moment
[12:58] <tfheen> Riddell: do you have any thoughts on the "kde doesn't have a passkey helper" problem?
[12:58] <cbx33> ok np
[12:58] <Keybuk> tfheen: gettext decision time? :)
[12:59] <pitti> infinity: (interesting, it works on proper sarge and fails in edgy chroot)
[12:59] <Riddell> tfheen: got a bug number?
[12:59] <tfheen> dholbach: ^^ kde pin helper bug no?
[12:59] <dholbach> Riddell: that's the raw debian debdiff
[12:59] <dholbach> Riddell: as of 20 minutes ago in incoming.debian.org
[12:59] <dholbach> Riddell: I'll make it nice and pretty
[01:00] <tfheen> Keybuk: 
[01:00] <tfheen> argh
[01:00] <dholbach> tfheen, Riddell: bug 56651
[01:00] <Ubugtu> Malone bug 56651 in bluez-utils "Missing passkey-agent binary" [Unknown,Fix released]  http://launchpad.net/bugs/56651
[01:00] <tfheen> Keybuk: I'm tempted to ask Adam to spend copious amounts of his free time on hacking the RCS files since I'm worried about bumping the version at this point.
[01:01] <Keybuk> tfheen: I'm inclined to suggest that given Adam and I have spend n hours trying to patch 0.14, without success, any potential success would be more error-prone at this point than just an update to a known "ok" version
[01:01] <tfheen> that's a point, too.
[01:01] <tfheen> but a 21MB diff _scares_ me.
[01:01] <Keybuk> the new version would only affect packages will called "gettextize" or "autopoint" in their build process
[01:01] <Keybuk> fwict, most of the diff is support for new languages and updates to the hello files
[01:01] <iwj> tfheen: Just FAOD, I take it it's OK to upload a new firefox which attempts to help workaround the compreg.dat problem by deleting the file, as described in my last comment in bug 30791 ?
[01:01] <Ubugtu> Malone bug 30791 in firefox "firefox 1.4.99 upgrade still have compreg.dat, creates issue" [Medium,Confirmed]  http://launchpad.net/bugs/30791
[01:02] <tfheen> iwj: ok, approved.
[01:02] <iwj> tfheen: Thanks.
[01:03] <tfheen> Keybuk: *sigh*, I'll hate myself for this when the build failures haunt us, but ok.  New version.
[01:03] <Keybuk> tfheen: I sympathise, but I do think that's less hate than all the Ubuntu-using upstream developers shipping lots of broken tarballs
[01:04] <tfheen> yes, they'll hate us even more.
[01:04] <Riddell> dholbach: any idea how it decides which bluetooth passkey agent to run?
[01:05] <tfheen> Riddell: iirc it uses dbus activation
[01:05] <Riddell> dholbach: I'm sure we had this in previous releases, where it's a bash script that would run /usr/lib/kdebluetooth/kbluepin if it existed, else the gnome one
[01:05] <Riddell> hmm, dbus sounds new
[01:06] <dholbach> Riddell: i'll take care of the ftbfs/compatibility fix now and take a brief look at it after that - I have no idea at all
[01:06] <dholbach> tfheen: we still need to seed bluez-passkey-gnome (once it's out of MIR)
[01:06] <tfheen> dholbach: you've written the report?
[01:07] <dholbach> tfheen: ARRR!
[01:08] <tfheen> dholbach: was that a "yes"?
[01:08] <dholbach> yes :-)
[01:09] <tfheen> pitti: could you fast-track the bluez-passkey-gnome MIR?
[01:09] <dholbach> I think I even said so, yesterday. For reference: https://wiki.ubuntu.com/MainInclusionReportBluezGnome
[01:09] <fabbione> doko_, mvo: dpkg: error processing python-apt (--purge):
[01:09] <fabbione>  subprocess pre-removal script returned error exit status 1
[01:10] <pitti> tfheen: doing now
[01:10] <doko_> fabbione: on a buildd?
[01:10] <fabbione> doko_: yes
[01:10] <doko_> fabbione: please point me to the log
[01:11] <fabbione> doko_: check your email :)
[01:11] <doko_> thanks
[01:11] <fabbione> doko_: it's not a buildd in LP.. it's local sparc rebuild the world
[01:11] <fabbione> but the chroots are the same
[01:12] <mvo> fabbione: oh jesus - do you have logs? that smells like python-central
[01:13] <Keybuk> Configuration file `/etc/init.d/bluetooth'
[01:13] <mvo> fabbione: can you pleae CC me too?
[01:13] <Keybuk> Configuration file `/etc/init.d/bluetooth'
[01:13] <Keybuk>  ==> Modified (by you or by a script) since installation.
[01:13] <Keybuk>  ==> Package distributor has shipped an updated version.
[01:13] <Keybuk> gnargh
[01:13] <Keybuk> known?
[01:13] <pitti> dholbach: what does this bt-applet do, in short?
[01:13] <tfheen> Keybuk: I've seen it, but I have no idea why it happened.
[01:13] <fabbione> mvo: on the way to you too
[01:13] <pitti> dholbach: store PINs and ask for them if it doesn't know it yet?
[01:13] <mvo> fabbione: thanks!
[01:13] <dholbach> pitti: notify you, if another device wants to pair with the box over bluetooth and lets you enter a pin
[01:14] <pitti> dholbach: ah, ok; it's just a frontend for the bluez tools, I assume?
[01:14] <Keybuk>   108806 | S- | poppler              | 0.5.4-0ubuntu4       | four minutes
[01:14] <Keybuk>          | * poppler/0.5.4-0ubuntu4 Component: main Section: text
[01:14] <Keybuk>   108804 | S- | libflaim             | 4.9.966-0ubuntu1     | nine minutes
[01:14] <Keybuk>          | * libflaim/4.9.966-0ubuntu1 Component: universe Section: libs
[01:14] <iwj> seb128: http://paste.ubuntu-nl.org/26419/, opinion ?
[01:14] <Keybuk>   108805 | S- | libxflaim            | 5.1.969-0ubuntu1     | ten minutes
[01:14] <Keybuk>          | * libxflaim/5.1.969-0ubuntu1 Component: main Section: libs
[01:14] <tfheen> Keybuk: if that poppler has "fixes FTBFS" in the changelog, it's approved.
[01:15] <Keybuk> tfheen: dholbach said libflaim and libxflaim were things Mark wanted?
[01:15] <seb128> iwj: looks good to me
[01:15] <tfheen> Keybuk: yes.  => universe, though
[01:15] <Keybuk> *nods*
[01:16] <Keybuk> tfheen: poppler changelog contains only this
[01:16] <Keybuk>    * Clean sources before upload
[01:16] <Keybuk> Riddell: 
[01:16] <tfheen> Keybuk: ok, good, and Riddell is the uploader?
[01:16] <Keybuk> yes
[01:16] <tfheen> approved.
[01:16] <tfheen> (there was a config.status in the previous source package which caused a FTBFS)
[01:16] <dholbach> pitti: It should be.
[01:17] <pitti> tfheen: I didn't test bluez-passkey-gnome, but I trust dholbach that it actually works; packaging-wise it's fine
[01:17] <dholbach> it works
[01:17] <tfheen> pitti: it worked for me.
[01:17] <dholbach> and Upstream is in the bluetooth team as well
[01:17] <Keybuk> brb
[01:17] <dholbach> so he'd know pretty quickly if stuff was broken :)
[01:19] <dholbach> Riddell: http://people.ubuntu.com/~dholbach/kdebluetooth-ubuntu.debdiff - that's the diff I'm going to apply - currently testbuilding
[01:19] <Keybuk> seb128: panel crashed on update again
[01:19] <Keybuk> dholbach: why is there a useless bluetooth logo in my notification area?
[01:19] <seb128> Keybuk: what did you update?
[01:20] <Keybuk> BenC: still got a floating "kernel direct mapping up to" message on the screen at boot
[01:20] <dholbach> Keybuk: that's the bluez-passkey-gnome thing
[01:20] <Keybuk> seb128: http://people.ubuntu.com/~scott/upgrade.txt
[01:20] <dholbach> Keybuk: you can either remove the package or disable it in gnome-session-properties
[01:20] <Keybuk> dholbach: yes, why does it have an icon?  the icon doesn't do anything
[01:20] <dholbach> Keybuk: that's the best I can offer, sorry
[01:20] <Kaloz> the new xubuntu gdm thema makes me sick :P i hope the old one will be available :P
[01:21] <Keybuk> can't you comment out the icon code?
[01:21] <seb128> hum, lot of upgrades :/
[01:21] <dholbach> Keybuk: I'd prefer if upstream would do that in a clever and proper way.
[01:21] <seb128> Keybuk: are the applet still working, context menu on them working, etc?
[01:21] <Keybuk> seb128: the context menu still worked, but couldn't click anything
[01:21] <cbx33> I kept getting panel applets crashing
[01:21] <Keybuk> the main menu worked too, but again, couldn't launch anything
[01:22] <Keybuk> some notification icon applets vanished at the point of crash
[01:22] <dholbach> Keybuk: bug 65645
[01:22] <Ubugtu> Malone bug 65645 in gnome-bluetooth "Die systray icon die!" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65645
[01:22] <seb128> hum :/
[01:22] <cbx33> for exmaple terminal services applet wou'dnt load
[01:22] <cbx33> still doesn't 
[01:22] <seb128> cbx33: I've fixed that applet yesterday, do you still get the isuse?
[01:23] <Riddell> dholbach: looks good
[01:23] <cbx33> just gonna reboot and test
[01:23] <dholbach> Riddell: gracias
[01:23] <cbx33> I had it with the new note taker a few times too
[01:23] <cbx33> seb128: I'll be right back
[01:24] <Keybuk> usplash is still borked too :-/
[01:25] <infinity> pitti: You have a weird definition of the word "interesting". :/
[01:28] <dholbach> pitti, tfheen: I seed bluez-gnome to supported, alright?
[01:29] <tfheen> dholbach: please
[01:30] <dholbach> tfheen: ok
[01:30] <cbx33> seb128: it's fixed now ;)
[01:30] <cbx33> sorry for the scare
[01:30] <cbx33> the tsclient applet
[01:30] <seb128> np
[01:30] <seb128> thank you for trying :)
[01:30] <cbx33> tomboy notes was doing it but seems fine now too
[01:31] <cbx33> I did try to look at the pessulus package to see how to fix it....but coudn't see what is up.....must be me being stupid
[01:31] <cbx33> I have to go and teach a python class now
[01:32] <cbx33> bbl
[01:33] <seb128> cbx33: I've pessulus fixed, I'm about to upload
[01:35] <seb128> tfheen: http://people.ubuntu.com/~seb128/pessulus.debdiff ok to upload?
[01:36] <seb128> tfheen: it's basically one file added to the Makefile.in list
[01:37] <Keybuk> seb128: they really haven't put much thought into this new rhythmbox, have they?
[01:37] <Keybuk> it has to rescan portable media every time you start it
[01:37] <Keybuk> so it's indexing the same 40GB again, and again, and again
[01:37] <tfheen> seb128: ok, approved.
[01:37] <ogra> hmm, i have either a udev or a kernel regression here ...
[01:37] <Keybuk> and it even forgets the fact I like the browser open for that media
[01:37] <Keybuk> ogra: kernel
[01:37] <ogra> Keybuk: heh
[01:37] <ogra> my external usbdisk isnt recognized with the usb hub in the chain 
[01:37] <seb128> Keybuk: it's like that since ever
[01:38] <Keybuk> seb128: not true, the dapper rhythmbox - you had to add your player to the library
[01:38] <seb128> Keybuk: rescanning removable media every time
[01:38] <Keybuk> and then it was always available when it started
[01:38] <ogra> it works fine without the hub ...
[01:38] <Fujitsu> Keybuk, I /could/ suggest you file a bug... But I think I'd get attacked.
[01:38] <Keybuk> ogra: usb 2 disk, usb 1 hub
[01:38] <ogra> Keybuk: both should be usb2
[01:38] <ogra> and it worked before
[01:39] <ogra> must be the last kernel upload i guess
[01:39] <Keybuk> have you checked with the previous kernel?
[01:39] <dholbach> tfheen: done
[01:40] <ogra> it worked on my outdated system (i'm typing from a test install of 20061012)
[01:42] <Keybuk> Fujitsu: bugs already exist
[01:42] <ogra> Keybuk: linux-image-2.6.17-10-386        2.6.17-10.28 is the one installed in my old system, ii  linux-image-2.6.17-10-386        2.6.17-10.30 is what the fresh install brought 
[01:43] <Keybuk> ogra: ok, so boot .28 then and see if that makes a difference
[01:43] <ogra> and udev has teh same version ... so i guess its a change in the recent kernel
[01:43] <Keybuk> it's nothing to do with udev
[01:43] <Keybuk> sheesh
[01:43] <Keybuk> stop blaming udev for every hardware glitch you encounter
[01:43] <Keybuk> udev receives uevents from the kernel, and processes rules for them
[01:43] <Keybuk> nothing more
[01:44] <Keybuk> if you have strange topological errors with usb devices, it's hardware or kernel
[01:44] <ogra> right
[01:44] <Keybuk> if a device has the wrong permissions, then it's a udev bug
[01:44] <Keybuk> if a device has the wrong name, then it's a udev bug
[01:44] <Keybuk> if a device doesn't show up at all, then it's almost certainly a kernel bug
[01:44] <ogra> but tracking that bug top down, i start at udev because i know the scripts arent run ... then look at why it doesnt get triggered ...
[01:45] <ogra> so indeed i mention udev as well :)
[01:46] <Hobbsee> antoniac: please remove the away message.
[01:46] <Keybuk> Hobbsee: probably wise to mention that when he's back, no? :)
[01:47] <Hobbsee> Keybuk: i figured removing him with that as his removal message was a little brutal.  but that's what i usually do.  :)
[01:47] <tfheen> Hobbsee: doit! :-)
[01:47] <Hobbsee> tfheen: remove you too?
[01:47] <Hobbsee> :P
[01:47] <\sh> mons
[01:47] <\sh> +i
[01:47] <Hobbsee> hey \sh 
[01:48] <Hobbsee> Keybuk: there :P
[01:48] <tfheen> Hobbsee: nah, I'm nice, you know that.
[01:49] <ogra> would be a bit hard to get the RC done 
[01:49] <\sh> sladen: regarding you bugreport #63492 what would you propose? security or usability?
[01:50] <infinity> pitti: Another dbgsyms build failure...
[01:51] <dholbach> Riddell, tfheen: i just did a successful file transfer from the box to the phone with konqueror (using kdebluetooth) - ok to upload?
[01:51] <pitti> infinity: still thinking about the tar issue; that seems to be a real bug, and I think I have a vague idea now
[01:51] <pitti> infinity: can you please forward the log? I'll care for it after tar
[01:51] <infinity> pitti: Yeah, It's gcc-4.0, so it's a slightly large log. :/
[01:51] <pitti> ouch
[01:51] <infinity> pitti: You might just want an extract. :)
[01:52] <pitti> infinity: or just copy it on chinstrap
[01:52] <Hobbsee> tfheen: :)
[01:54] <tfheen> Kamion: the d-i build blew up on i386
[01:55] <tfheen> Kamion: .. and all other arches
[01:55] <Fujitsu> Fun fun fun.
[01:56] <Riddell> dholbach: more than I've ever done, go ahead :)
[01:57] <dholbach> alrighty
[01:57] <dholbach> done
[01:57] <Keybuk>   108809 | S- | firefox              | 1.99+2.0rc2+dfsg-0ub | 17 minutes
[01:57] <Keybuk>          | * firefox/1.99+2.0rc2+dfsg-0ubuntu2 Component: main Section: web
[01:58] <tfheen> Keybuk: iwj upload with changelog along the lines of "nuke compreg.dat in postinst"?
[01:58] <tfheen> Keybuk: if so, approved.
[01:58] <Keybuk> tyup
[02:00] <Riddell> dholbach: there's a patch to bluez-utils to let it still work with the current kdebluetooth pin helper
[02:00] <Riddell> dholbach: http://www.kmobiletools.org/node/228
[02:01] <Riddell> dholbach: there's also a dbus branch in the works but I think we don't want to try beta code at this stage
[02:02] <dholbach> Riddell: you want to look at that? i do xdg-utils in the meantime
[02:02] <Riddell> dholbach: well I have no bluetooth hardware at all to test with
[02:03] <Ng> if you guys want a hand testing bluetooth stuff, I have suitable hardware and a desire to see it rock as hard as possible :)
[02:03] <pitti> Ng: can never hurt :)
[02:03] <jsgotangco> bt rocks
[02:06] <infinity> tfheen: I'm approving a new pkg-create-dbgsyms disabling an anal build-time check that causes several build failures (we'll re-enable the anal check in edgy+1 again to catch the affected packages, but the bug it's catching isn't worth uploading them all for)
[02:06] <tfheen> infinity: thanks
[02:06] <tfheen> Keybuk: can you tend to https://launchpad.net/distros/ubuntu/+source/gettext/+bug/65063 please?
[02:07] <pitti> Keybuk, tfheen: I need to upload another pkg-create-dbgsym with a removed sanity check which causes gcc-4.0 and maybe others to FTBFS; we don't want to fix those packages at this point
[02:07] <Ubugtu> Malone bug 65063 in gettext "Doesn't support datarootdir" [High,Confirmed]  
[02:07] <infinity> tfheen: Basically, packages that call dh_strip on binaries not actually being built (say, gcc-4.0 and lib64stdc++6)
[02:07] <dholbach> tfheen: Riddell proposes to use http://people.ubuntu.com/~dholbach/bluez-pin-exec-patch.diff on bluez-utils as an attempt to fix bug 56651 for kde - I can't make heads nor tails of the patch to be honest - I can see if it builds and see how it behaves with ubuntu and kde
[02:07] <Ubugtu> Malone bug 56651 in bluez-utils "Missing passkey-agent binary" [Unknown,Fix released]  http://launchpad.net/bugs/56651
[02:07] <infinity> pitti: Upload at will. :)
[02:07] <pitti> done
[02:08] <infinity> And util-linux is another asm/page.h victim, I'll fix that one.
[02:09] <tfheen> dholbach: hmkay.  I understand what and how the patch works.  It's an ugly hack, but we don't want to ship without bluetooth support in KDE either.
[02:09] <dholbach> tfheen: I'll get testing and playing with it
[02:09] <Riddell> it seems to need something to start passkey-agent
[02:10] <tfheen> we'd still need to actually ship the passkey helper
[02:10] <dholbach> Riddell: if you want, you can do xdg-utils in the meantime - can you upload as 0ubuntu2 so kamion/keybuk can compare with the old upload?
[02:10] <tfheen> which we don't ATM
[02:10] <Riddell> dholbach: I'd rather see the 0ubuntu1 upload first to see how they compare
[02:10] <dholbach> Riddell: hang on
[02:11] <infinity> pitti: accepted.
[02:13] <cbx33> thanks seb128 tfheen
[02:13] <dholbach> Riddell: http://daniel.holba.ch/temp/xdg-utils_1.0-0ubuntu1.debdiff
[02:15] <Keybuk> tfheen: "tend to" ?
[02:15] <tfheen> Keybuk: get the new version in?
[02:15] <Keybuk> tfheen: am in the process of testing and making sure it's ship-shape at the moment
[02:15] <Keybuk> obviously I didn't want to just download the new one and chuck it in without even checking it against a few packages first
[02:16] <tfheen> Keybuk: ok, excellent.  That's is as good a tending to as I could ask for.
[02:16] <tfheen> mvo: did you get the necessary information to fix the duplicated hostid bug yesterday?
[02:18] <mvo> tfheen: I have all the information we have, it may not be enough though and we may have to unconditionally reconfigure all popcon package to be sure that it is fixed
[02:18] <tfheen> mvo: ok, if you're not busy with something else, can you please upload a package which does that?
[02:19] <mvo> tfheen: let me dig a bit more into the logs, but I can do it in max. 1h
[02:20] <tfheen> mvo: thanks
[02:20] <tfheen> infinity: do you have any clue about 63693 ?
[02:22] <seb128> cbx33: np, thank you for pointing it
[02:22] <mvo> Kamion: what versions of popcon where not reconfigured on install from the live-cd? only edgy versions? or was that a problem in dapper too?
[02:23] <ogra> pitti, hmm, the gstreamer autosink seems still buggy 
[02:23] <ogra> i get reports from perple where it didnt select esd at all
[02:24] <Riddell> dholbach, Kamion: I'm not sure where the duplicate code is in the xdg-utils patch xdg-email-generic
[02:24] <dholbach> Riddell: we fixed the patch differently, I saw - could be my attempt was wrong
[02:26] <seb128> tfheen: http://people.ubuntu.com/~seb128/xchat.debdiff : 3 simple crasher fixes from upstream for xchat-gnome, upstream asked if we can ship them (crasher tend to bugzilla flood with the new bug-buddy)
[02:26] <Riddell> dholbach: out fix to the open_kde part is the same
[02:28] <tfheen> seb128: shouldn't the first one return something if user is null?
[02:28] <tfheen> seb128: the other two look good to me
[02:29] <Riddell> dholbach, kamion: oh, I see it, open_generic() is duplicated, I'll fix that
[02:30] <seb128> tfheen: right, is the first one ok if I make it return NULL in the case where there is no return atm?
[02:30] <tfheen> seb128: yes, that should be good  (as long as whatever calls this handles a NULL return value)
[02:31] <seb128> yeah, should be fine, there is already a case where it returns NULL
[02:31] <seb128> I'll double check
[02:31] <tfheen> then it's fine with me
[02:36] <doko_> tfheen, Kamion, mvo: chinstrap:~doko/python-apt.debdiff: ok to upload to restore dep on python-central?
[02:37] <tfheen> doko_: which bug does it fix?  (And can you please put patches somewhere web-accessible in the future?)
[02:39] <doko_> tfheen: fabbione reported that on the channel, python-apt doesn't work without python-central installed.
[02:40] <tfheen> doko_: hmm, ok.  I'm fine with it if mvo doesn't protest.
[02:40] <tfheen> but please do file bugs in malone, I miss stuff going on in the channel once in a while.
[02:41] <mvo> tfheen: fine with me (assuming doko_ tested it and everything)
[02:42] <tfheen> doko_: ^^ so upload away.
[02:42] <doko_> tfheen: uploaded
[02:48] <Kamion> tfheen: meh, will investigate
[02:48] <Kamion> mvo: I didn't start reconfiguring popularity-contest until 12 September; I think it was a problem in dapper
[02:49] <Kamion> Riddell: was open_generic and something else about generic
[02:51] <Keybuk>   108829 | S- | supertransball2      | 1.5-3build1          | 25 minutes
[02:51] <Keybuk>          | * supertransball2/1.5-3build1 Component: universe Section: games
[02:51] <Keybuk>   108827 | S- | tipa                 | 2:1.3-4build1        | 40 minutes
[02:51] <Keybuk>          | * tipa/2:1.3-4build1 Component: universe Section: tex
[02:51] <Keybuk>   108826 | S- | kdebluetooth         | 0.99+1.0beta1-12ubun | 50 minutes
[02:51] <Keybuk>          | * kdebluetooth/0.99+1.0beta1-12ubuntu7 Component: main Section: kde
[02:52] <Keybuk> dholbach: tipa by ajmitch, "rebuild with new debhelper to set versioned depends on xfonts-utils"
[02:53] <Keybuk> dholbach: supertransball2 by StevenK, "rebuild to pick up libsdl-sgec2 -> liibsdl-sge change"
[02:53] <tfheen> Keybuk: kdebluetooth is uploaded by dholbach and has something like "make kdebluetooth work with libbluetooth2 >= 3.7-1 ?
[02:53] <Keybuk> tfheen: yes
[02:53] <dholbach> Keybuk: tipa and supertransball2 are fine
[02:53] <tfheen> Keybuk: ok, approved.
[02:54] <Keybuk> okies
[02:54] <mvo> Kamion: ok, thanks. then I will reconfigure the popcon uuid now on upgrade for all users. but after 20days (that is when the old entries are cleaned) we have reliable data again
[02:55] <Keybuk> dholbach: flaim's gone through too
[02:55] <Keybuk> I NBS'd the old binary as nothing used it
[02:55] <Keybuk> (popular library)
[02:55] <dholbach> Keybuk: tahnks a lot
[02:56] <geser> should bug 63396 be targeted for edgy?
[02:56] <Ubugtu> Malone bug 63396 in imake "Upgrading to edgy beta leavs imake and makedepend" [Medium,Confirmed]  http://launchpad.net/bugs/63396
[02:56] <tfheen> geser: it already is?
[02:57] <tfheen> Kamion: the xorg entries on http://people.ubuntu.com/~cjwatson/testing/edgy_outdate.txt ; are those false positives or is something broken and I don't see it?
[02:58] <Keybuk> doko_: what was libintl.jar for?
[02:58] <geser> tfheen: sorry then
[02:59] <tfheen> Kamion: oh, or those are probably NBS-es?
[02:59] <Kamion> yes, there are xorg NBSes I've been too scared to remove
[02:59] <Kamion> though none of them are actually seeded
[02:59] <doko_> Keybuk: that was gettext?
[03:00] <Kamion> tfheen: weren't we going to put xbase-clients and xutils back, or am I hallucinating?
[03:00] <tfheen> Kamion: at least xbase-clients, yes.
[03:00] <Keybuk> doko_: yes, it vanished
[03:01] <doko_> looking ...
[03:02] <doko_> $ dpkg -L gettext-base|grep libintl
[03:02] <doko_> /usr/share/java/libintl.jar
[03:02] <doko_> /usr/share/gettext/libintl.jar
[03:02] <doko_> Keybuk: ^^ ??
[03:02] <Riddell> Kamion: if I upload a new xdg-utils 1.0 should I include the .orig?
[03:03] <Kamion> Riddell: err, can't actually remember, shouldn't hurt to include it
[03:03] <Keybuk> doko_: yes, 0.15 isn't building it
[03:03] <Kamion> (provided it's the same, obviously)
[03:03] <Keybuk> doko_: it has a gettext.jar instead
[03:03] <Keybuk> which has different contents
[03:04] <pitti> ogra: can you please help me to remember the issue?
[03:04] <tfheen> mjg59: ttf-bpg-georgian-fonts FTBFS-ed.
[03:05] <doko_> Keybuk: is 0.15 for edgy?
[03:05] <ogra> pitti, after first login the audiosink is set to alsa instead of gstreamer
[03:05] <pitti> ogra: you mean s/gstreamer/esound/?
[03:05] <ogra> i tried to find the patch that reads LTSP_CLIENT and forces esd usage, but i dont seem able to find it
[03:05] <doko_> anyway, I'm not aware of any users for libintl.jar in main
[03:05] <Keybuk> doko_: likely, yes
[03:05] <ogra> pips1, right
[03:05] <Keybuk> tbh, it looks like a build problem
[03:05] <ogra> pitti, right
[03:06] <pitti> ogra: hm, I applied that in dapper IIRC, maybe it got lost during the merge
[03:06] <ogra> pitti, i thought you added a check for that variable somewhere, but i cant find it by grepping through the dapper package even
[03:07] <ogra> pitti, is it in gst-plugins-base0.10-0.10.7 or in gnome-media ?
[03:07] <pitti> ogra: should be the former
[03:07] <ogra> nothing ... hmm
[03:08] <tfheen> pitti: your latest xmms upload (yes, ancient) FTBFS-ed.  I retried it and it still failed.
[03:08] <tfheen> pitti: could you give that a poke?
[03:08] <pitti> tfheen: yup, I'm still debugging tar, though; will do after that
[03:09] <tfheen> pitti: thanks.
[03:10] <tfheen> hmm, is ZhengPeng Hou on irc and around?  There's a problem with scim-chewing.
[03:11] <doko_> Keybuk: I don't see any gettext.jar in upstream gettext-0.15
[03:12] <Hobbsee> tfheen: freeflying
[03:12] <infinity> tfheen: I need to do a test install here in vmware to try to reproduce #63693, but if I can reproduce it, the fix should be simple and non-intrusive ehough.
[03:12] <infinity> enough, too.
[03:12] <Hobbsee> tfheen: not here at the moment
[03:12] <tfheen> infinity: thanks a lot
[03:12] <tfheen> Hobbsee: thanks.
[03:13] <Hobbsee> infinity: uh?  where are you?
[03:13] <doko_> Keybuk: ahh, that's gettext-tools, which isn't shipped in 0.14.
[03:18] <tfheen> pitti: lucky you, you touched quagga last and win yet another FTBFS.  (Might be libc-header-related; only affects i386 and ppc, it seems)
[03:18] <pitti> yay
[03:19] <pitti> . o O { actually, why do I bother test-building stuff before I upload??? }
[03:20] <tfheen> pitti: since it ftbfs anyway, you mean?
[03:20] <pitti> tfheen: yes; well, since I only test on amd64, it evaded me precisely :)
[03:21] <pitti> tfheen: added to my TODO list
[03:21] <tfheen> doko_: python-setuptools FTBFS-ed
[03:22] <ogra> pips1, intrestingly the code seems never to have looked for LTSP_CLIENT to be set, i'm courious how that worked before ...
[03:22] <ogra> s/pips1/pitti
[03:22] <ogra> *sigh*
[03:23] <pitti> ogra: hm, ISTR that I patched this...
[03:23] <ogra> your patch moves priorities around, but doesnt add any heck for LTSP_CLIENT
[03:23] <ogra> *check
[03:24] <Riddell> where is anastacia located these days?
[03:24] <ogra> Riddell, still the same place ?
[03:24] <Riddell> I have http://people.ubuntu.com/~mdz/anastacia.txt but it's not there
[03:25] <ogra> http://people.ubuntu.com/~cjwatson/anastacia.txt (since dapper iirc)
[03:25] <Keybuk> doko_: 0.15 doesn't seem to build any of the java stuff :-/  looks like its a bug in the upstream packaging
[03:26] <doko_> Keybuk: I can have a look; do you have a preliminary package?
[03:26] <doko_> tfheen: missing b-d on python-all-dev; ok to upload?
[03:26] <Keybuk> doko_: I don't think having a look will help
[03:26] <tfheen> doko_: yes, please.
[03:26] <Keybuk> I can see what the problem is
[03:27] <doko_> the sources are in the package
[03:27] <Keybuk> the gettext-runtime subtree is missing things from its configure.ac
[03:27] <tfheen> doko_: pychecker FTBFS as well
[03:27] <Keybuk> though I don't understand how this works in Debian *shrug*
[03:29] <elmo> Keybuk: !
[03:29] <tfheen> doko_: python-qt[34]  FTBFS as well
[03:29] <elmo> Keybuk: my home machine with a separate /var is still broken in edgy :-(
[03:33] <doko_> tfheen: pychecker: proposing a sync from unstable; 0.8.17-3 passes the tests
[03:34] <tfheen> doko_: you've tested it?  If so, I'm happy enough to take it.
[03:35] <doko_> tfheen: yes, built, installed, removed, works
[03:35] <Kamion> oh well, I haven't been able to test this d-i upload because I need to upgrade the world first, but it should fix the immediate problem
[03:35] <tfheen> doko_: please ask for a sync, then.
[03:35] <Keybuk> elmo: ?
[03:35] <Keybuk> elmo: be more descriptive
[03:36] <tfheen> Kamion: any chance you could do a quick NBS run?  There are a couple of obvious and harmless ones which will clean up the outdate list a bit
[03:36] <Kamion> yeah
[03:37] <tfheen> thanks
[03:37] <Keybuk> doko_: it looks like they only support building the jar with javac, not with gcj
[03:37] <troy_s> hey guys... great work on edgy.  
[03:38] <Kamion> tfheen: do you know about compiz-kde? Can I remove that?
[03:38] <tfheen> Kamion: no idea.
[03:38] <tfheen> Riddell: ^^ ?
[03:39] <Kamion> -- edgy/universe i386 deps on python2.4-libbtctl:
[03:39] <Kamion> telepathy-blue
[03:39] <Kamion> dholbach: can you or somebody fix that up?
[03:39] <doko_> Keybuk: that's ok, gcj-4.1 registers an alternative for javac
[03:40] <Keybuk> checking for Java compiler... no
[03:40] <Keybuk> heh
[03:40] <Keybuk> configure:4285: checking for Java compiler
[03:40] <Keybuk> configure:4447: found /usr/bin/gcj
[03:40] <Keybuk> configure:4534: gcj -C -d . conftestlib.java
[03:40] <Keybuk> configure:4672: result: no
[03:40] <infinity> Hobbsee: I'm at home, why do you ask?
[03:41] <infinity> Hobbsee: Oh, you mean where *was* I?  My (ex-)wife's apartment.
[03:41] <Hobbsee> infinity: yes, i asked where you were.  ahh.  couldnt see any logical place you'd be doign ubuntu stuff on a thursday night late at night apart from at home
[03:42] <Kamion> BenC: please (a) tell me and (b) changelog it when you do stuff like renaming *-itanium-di to *-mckinley-ddi
[03:42] <Kamion> -di
[03:42] <Kamion> BenC: is that really a good plan, BTW?
[03:42] <Kamion> at this stage?
[03:43] <infinity> Hobbsee: I lead a strange and interesting life with two homes right now.  Her DSL sucks, though.
[03:43] <StevenK> infinity: Doing Ubuntu work at my mothers house is like that.
[03:43] <StevenK> Sucky 256/64 connection.
[03:44] <Riddell> Kamion, tfheen: I know nothing about compiz-kde, although it was only every a placeholder package so I don't suppose we're loosing anything by deleting it
[03:44] <infinity> StevenK: 512/128 at Zofia's, but with the recent death of Veridas, her new ISP is congested and unhappy, so it may as well be 256/64.
[03:44] <Keybuk> doko_: heh, it looks increasingly like this assumed that gcj's version is 3.x and tries to parse it :)
[03:44] <Keybuk> and thus fails when it's 4.x
[03:44] <Kamion> BenC: actually, never mind, I'm hallucinating with the aid of the cruft checker :-)
[03:44] <Hobbsee> infinity: ahh.
[03:44] <StevenK> infinity: I could suggest Exetel. :-P
[03:44] <Kamion> I think it just gets really confused when the kernel hasn't built
[03:45] <tfheen> Kamion: ok, nuke compiz-kde, then
[03:46] <Kamion> done
[03:46] <Kamion> tfheen: shall I get rid off xlibs-dev?
[03:46] <Kamion> s/off/of/
[03:47] <tfheen> Kamion: no, I'll talk with rodarvus about it at the meeting, if he's there.
[03:47] <tfheen> (or tomorrow if not)
[03:48] <infinity> StevenK: I'm pretty happy with iinet, but I'm paying for the connection at her place, and wasn't thrilled about the idea of dropping that much on two ADSL2+ lines.
[03:48] <mvo> tfheen: could you please have a look at http://people.ubuntu.com/~mvo/tmp/popularity-contest_1.33ubuntu2.debdiff 
[03:48] <StevenK> infinity: Good point.
[03:49] <Kamion> tfheen: ok, then it's just libbtctl (dependency from telepathy-blue), libgtkada2 (dependency from gnat-gps), linux-source-2.6.17 ia64 udebs (weird, don't understand), and xorg
[03:49] <Kamion> (xbase-clients, xlibs-dev, xutils)
[03:51] <tfheen> mvo: your changelog doesn't document both changes you're doing?
[03:51] <tfheen> Kamion: thanks a lot.
[03:51] <mvo> tfheen: right, I will mention the fix for the FTBFS as well
[03:52] <tfheen> mvo: good.  And approved once you do
[03:53] <mvo> thanks
[03:54] <seb128> tfheen: http://people.ubuntu.com/~seb128/evolution-data-server.debdiff fixed evolution-exchange bug targeted for edgy (subfolders not being listed)
[03:55] <tfheen> seb128: and it works?  If so, approved.
[03:55] <tfheen> it's small enough, but I don't know the intracies of exchange, so hard to review
[03:55] <seb128> tfheen: it works according to Novell guys, I've no exchange setup to test
[03:55] <seb128> tfheen: it's basically a revert from the commit which broke the feature with a small change
[03:56] <tfheen> seb128: ok, approved.
[03:56] <seb128> uploaded, thank you
[03:57] <Kamion> hmm, we should either include ttf-dzongkha and ttf-khmeros in desktop, or exclude those languages from ubiquity
[03:57] <Kamion> they probably want to be in main, at least, so that language-support-* can depend on them
[03:58] <tfheen> Keybuk: can you make cyrus-sasl2 use libkrb-dev instead of heimdal-dev?  It FTBFS.
[04:00] <tfheen> Keybuk: and can you make fetchmail not ftbfs, please?
[04:00] <tfheen> and with that, I'm going home for some food before the meeting.
[04:00] <Keybuk> W: Unable to locate package libkrb-dev
[04:01] <tfheen> libkrb5-dev, sorry
[04:04] <dholbach> Kamion: alright, will do it - thanks.
[04:07] <dholbach> Kamion, Keybuk: can you promote bluez-gnome to main?
[04:07] <jsgotangco> yes!
[04:10] <mvo> tfheen: popularity-contest is uploaded now
[04:21] <dholbach> can somebody give back galago-gtk-python?
[04:22] <pitti> tfheen: xmms ftbfs fix uploaded
[04:25] <seb128> tfheen: opinion on https://launchpad.net/distros/ubuntu/+source/launchpad-integration/+bug/60426 edgy or next cycle?
[04:25] <Ubugtu> Malone bug 60426 in launchpad-integration "uses gnome prefs if kde and gnome are installed." [Low,Fix committed]  
[04:26] <Riddell> seb128: in edgy+1 it should use xdg-utils
[04:26] <seb128> Riddell: right, but do you need the "workaround" for edgy?
[04:26] <BenC> has the installer been rebuilt with the latest kernel yet?
[04:27] <Kamion> BenC: I've uploaded it, should be building soon
[04:27] <BenC> Kamion: cool, thanks
[04:28] <jdong> Kamion: is it a known alternate installer problem that atheros cards do not function at install time?
[04:28] <infinity> BenC: Feel like looking at some devmapper-hates-the-kernel-headers FTBFS logs for me?
[04:29] <ogra> tfheen, there is an edubuntu-artwork upload in the queue ... could you please approve it (do i need a debdiff for it ?)
[04:29] <jdong> Kamion: I tried a search through launchpad, and learned that I suck at searching :)
[04:29] <BenC> infinity: Sure
[04:29] <BenC> infinity: URL?
[04:29] <Kamion> dholbach: done
[04:29] <infinity> BenC: Email.  Which address should I send them to?
[04:29] <BenC> jdong: No, lp sucks at matching
[04:29] <dholbach> Kamion: thanks.
[04:29] <Kamion> jdong: it was in ~breezy, but should be fixed; is /lib/modules/blah/volatile mounted in the installedd?
[04:29] <Kamion> installer
[04:30] <BenC> infinity: Any known email address is fine (bcollins@ubuntu.com), they al go to my inbox :)
[04:30] <jdong> Kamion: I gotta check when I get a chance, but I did an alternate edgy amd64 install yesterday....
[04:30] <jdong> Kamion: it detects the card and gives an ath0 interface, it associates to my AP correctly
[04:30] <jdong> Kamion: but there is no communication with the network
[04:30] <jdong> after install, it worked perfectly
[04:30] <Kamion> that sounds like missing firmware or something
[04:31] <BenC> jdong: Check to make sure linux-restricted-modules-`uname -r` is installed
[04:31] <infinity> Gar, Perl testsuite failure on amd64..
[04:31] <infinity> ext/Time/HiRes/t/HiRes....................FAILED at test 14
[04:31] <jdong> BenC: on the installer?!
[04:31] <Kamion> dunno though, the module's there
[04:32] <jdong> right, the modules there and probed
[04:32] <jdong> the ath0 interface is created
[04:32] <Keybuk> BenC: any clue as to my strange kernel message?
[04:32] <infinity> BenC: Sent.
[04:32] <Kamion> jdong: ath_hal too?
[04:32] <jdong> yeah
[04:32] <BenC> jdong: I thought you said the installed system is broke, and the livecd worked
[04:32] <BenC> Keybuk: I missed it, can you repaste?
[04:32] <jdong> BenC: no, the installer environment is broke, the installed AND live both works
[04:32] <Keybuk> BenC: when the kernel boots, the last line on the screen is "kernel direct mapping tables up to BLAH BLAH BLAH"
[04:33] <BenC> jdong: so like alternate is broken?
[04:33] <jdong> BenC: right
[04:33] <Keybuk> and that line persists, all through the boot, and even after the getty is loaded
[04:33] <jdong> Keybuk: I get that on my amd64 boxes too
[04:33] <BenC> jdong: There's an lrm udeb for this stuff, I think
[04:33] <infinity> That's pretty sketchy, since nic-r-m and l-r-m contain exactly the same objects...
[04:33] <Kamion> there is, and he has it loaded
[04:33] <infinity> And if the objects weren't linking correctly, you'd not get an ath0 at all.
[04:33] <BenC> Keybuk: persists or repeats?
[04:33] <jdong> BenC: persists
[04:34] <jdong> BenC: it's stuck on the bottom of vt1 for ever and ever and ever.....
[04:34] <doko_> tfheen, Kamion: http://people.ubuntu.com/~doko/qt/, fixing the qt failures
[04:34] <jdong> BenC: it seems to only happen on amd64 though....
[04:34] <Keybuk> BenC: I suspect it's just printed there, and nothing gets round to clearing that line with our quiet boot
[04:34] <BenC> Keybuk: Not clearing it would be a console-setup issue, right?
[04:34] <Keybuk> BenC: it shouldn't be printed at all
[04:34] <Keybuk> we don't run "clear" in the boot sequence for obvious reasons
[04:35] <BenC> Keybuk: I can fix the line, if you give me the exact message
[04:35] <Keybuk> "kernel direct mapping tables up to %d"
[04:35] <Keybuk> or %lu or some numbers, anyway
[04:35] <jdong> it's a hex number
[04:35] <jdong> memory address, I would think
[04:35] <BenC> hrmm
[04:35] <BenC> that's an "early_printk"...
[04:35] <Keybuk> Google says it's part of Xen ?
[04:37] <BenC> Keybuk: Ok, fixed...nope, it's not part of xen that I can tell (no xen here)
[04:37] <Keybuk> ok
[04:37] <BenC> Keybuk: If I do another kernel upload, it will be fixed
[04:37] <zul> xen eh?
[04:38] <Keybuk> zul: the top hit was [xen-source]  :)
[04:38] <jdong> BenC: you can revert the GO_SLOW, too
[04:38] <jdong> and hey hey, Keybuk's here...
[04:38] <Keybuk> ?
[04:38] <Keybuk> keybuk's always here
[04:38] <Keybuk> keybuk works here
[04:38] <elmo> Keybuk: remember eons ago when you diagnosed dapper not bringing up the network on my machine?  it's because I have a small / and a RAID 0 which has var on it.  this confuses the jiggery pokery you do with /var/run/network (or wahtever it is)
[04:39] <jdong> Keybuk: what's your opinion on doing max_sector workarounds in userspace via udev rules?
[04:39] <Keybuk> elmo: why does it confuse it?
[04:39] <Keybuk> jdong: poking sysfs from udev rules?  common use case
[04:39] <zul> Keybuk: top hit for what sorry i have people talking me at work
[04:40] <Keybuk> zul: don't worry
[04:40] <jdong> Keybuk: ooh, then bug 61235 is awaiting you :D
[04:40] <Ubugtu> Malone bug 61235 in udev "USB mass storage stops working after a while" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61235
[04:40] <zul> Keybuk: er ok :)
[04:40] <Keybuk> jdong: edgy+1
[04:41] <elmo> Keybuk: meh, I've no idea, I'll go and find it in IRC logs I guess
[04:41] <jdong> aww ok :(
[04:41] <Keybuk> jdong: also it appears that only fixes it for you, not for others on the bug
[04:41] <Keybuk> elmo: you have a /var/run and /var/lock directory on the root filesystem?  (under the /var mount)
[04:41] <zul> where is the popcon stats anyways?
[04:41] <jdong> Keybuk: yeah, at first I thought it was the same bug but later realized differently
[04:41] <thom> zul: popcon.ubuntu.com ?
[04:41] <zul> thanks
[04:41] <thom> cor, someone's pimped that webpage
[04:42] <elmo> Keybuk: I think we determined I did, yeah, you had me run some bind magic
[04:42] <Keybuk> jdong: should be echo -n 128 > $p/max_sectors, no?
[04:42] <Keybuk> elmo: ok ...
[04:42] <tfheen> seb128: lp-integration > that is 6.10-milestoned.  Did you or mdz or somebody else add that milestone?
[04:42] <jdong> Keybuk: something along those lines; the last comment is the udev rule I came up with
[04:43] <jdong> Keybuk: it looks really hairy, so I'm sure I did something wrong :D
[04:43] <Keybuk> jdong: I'd like more info about the effect of that rule before applying it by default
[04:43] <seb128> tfheen: no, I think I did, I use milestone as a "keep on the radar for", not as "blocker for"
[04:43] <tfheen> doko_: python-kde3, python-qt[34]  ok with me ; upload away.
[04:43] <jdong> Keybuk: only for RockChip USB devices, it sets the max transferred sectors to 128 per command
[04:43] <jdong> Keybuk: this slows down transfer speeds for that device
[04:44] <jdong> Keybuk: when you transfer too fast (anything above 128) to the device, it'll disconnect from the USB
[04:44] <tfheen> seb128: ok, upload away.
[04:44] <tfheen> pitti: thanks.
[04:44] <tfheen> ogra: if you're confident in it, I can wave it through.
[04:44] <tfheen> Keybuk: what does the unapproved queue look like now?
[04:44] <seb128> tfheen: thank you
[04:44] <ogra> tfheen, i am ... but if you need one, i have a debdiff
[04:44] <Keybuk> tfheen: largish
[04:44] <jdong> Keybuk: and I know of no other RockChip vendor names other than the USB chipset used by common cheap Chinese MP3/MP4 players
[04:44] <mvo> Kamion: is the debian-installer using apt-get now to install the ubuntu-desktop task?
[04:44] <Keybuk>   108873 | S- | util-linux           | 2.12r-11ubuntu2      | 15 minutes
[04:44] <Keybuk>          | * util-linux/2.12r-11ubuntu2 Component: main Section: base
[04:44] <Keybuk>   108871 | S- | zope-cmfmember       | 1:1.1b2-1ubuntu1     | 15 minutes
[04:44] <Keybuk>          | * zope-cmfmember/1:1.1b2-1ubuntu1 Component: universe Section: web
[04:44] <Keybuk>   108870 | S- | edubuntu-artwork     | 0.1.0-43             | 15 minutes
[04:44] <Keybuk>          | * edubuntu-artwork/0.1.0-43 Component: main Section: gnome
[04:45] <Keybuk>   108867 | S- | xmms                 | 1.2.10+cvs20060429-1 | 20 minutes
[04:45] <Keybuk>          | * xmms/1.2.10+cvs20060429-1ubuntu2 Component: main Section: sound
[04:45] <Keybuk>   108860 | S- | telepathy-blue       | 0.0.1.1~darcs2006092 | 35 minutes
[04:45] <Keybuk>          | * telepathy-blue/0.0.1.1~darcs20060926-0ubuntu3 Component: universe Section: net
[04:45] <Keybuk>   108858 | S- | popularity-contest   | 1.33ubuntu2          | 45 minutes
[04:45] <Keybuk>          | * popularity-contest/1.33ubuntu2 Component: main Section: misc
[04:45] <Keybuk>   108857 | S- | evolution-data-serve | 1.8.1-0ubuntu3       | 45 minutes
[04:45] <infinity> Keybuk: util-linux is mine, I'll approve it.
[04:45] <Keybuk>          | * evolution-data-server/1.8.1-0ubuntu3 Component: main Section: gnome
[04:45] <Keybuk>   108841 | S- | xchat-gnome          | 1:0.13-0ubuntu9      | 1 hour 10 minutes
[04:45] <Keybuk>          | * xchat-gnome/1:0.13-0ubuntu9 Component: main Section: gnome
[04:45] <Keybuk>   108839 | S- | xdg-utils            | 1.0-0ubuntu2         | 1 hour 40 minutes
[04:45] <Keybuk>          | * xdg-utils/1.0-0ubuntu2 Component: universe Section: utils
[04:45] <infinity> (FTBFS fix)
[04:46] <tfheen> Keybuk: edubuntu-artwork, xmms, popularity-contest, evolution-data-server xchat-gnome are ok.
[04:46] <pitti> Keybuk: xmms and i smy FTBFS fix
[04:46] <tfheen> I think the xdg-utils one is fine too, but I haven't seen either of the diffs so I'd like Kamion to look at that.
[04:46] <BenC> infinity: It's interesting, I fixed this already once
[04:46] <infinity> BenC: Not hard enough, apparently. :)
[04:47] <infinity> BenC: devmapper obviously chokes, as does anything that build-deps on it.
[04:47] <BenC> infinity: Uploading a fixed package now...basically, you can't include linux/types.h, and add "typedef unsigned int __kernel_dev_t"
[04:47] <pitti> tfheen: good and bad news; I fixed the original quagga FTBFS, just to find the same pdftex symbol error; but now I can care for that, too :)
[04:47] <dholbach> telepathy-blue is just a dependency change to make it installable
[04:47] <Keybuk>   108871 | S- | zope-cmfmember       | 1:1.1b2-1ubuntu1     | 18 minutes
[04:47] <Keybuk>          | * zope-cmfmember/1:1.1b2-1ubuntu1 Component: universe Section: web
[04:47] <Keybuk>   108860 | S- | telepathy-blue       | 0.0.1.1~darcs2006092 | 38 minutes
[04:47] <Keybuk>          | * telepathy-blue/0.0.1.1~darcs20060926-0ubuntu3 Component: universe Section: net
[04:47] <Keybuk> that leaves those towo
[04:48] <infinity> BenC: Havint to include that typedef in a userspace header reeks of a bug elsewhere.
[04:48] <Keybuk> pitti: 
[04:48] <Keybuk>  o bluez-gnome: bluez-passkey-gnome
[04:48] <Keybuk>    [Reverse-Depends: Edgy supported seed] 
[04:48] <Keybuk>  o command-not-found: command-not-found command-not-found-data
[04:48] <Keybuk>    [Reverse-Depends: Edgy desktop seed, command-not-found] 
[04:48] <tfheen> pitti: thanks and thanks.
[04:48] <infinity> BenC: But whatever fix works, I'm cool with it for now. :)
[04:48] <Keybuk> neither of those have MIRs or main approval?
[04:48] <pitti> Keybuk: I approved bluez-gnome some hours ago
[04:48] <BenC> infinity: Since __kernel_dev_t is pretty static, It is safe
[04:48] <pitti> Keybuk: indeed I never looked at c-n-f
[04:49] <Kamion> mvo: no, haven't done that yet
[04:49] <Kamion> mvo: I thought you were going to have a look at the feasibility of fixing aptitude first?
[04:49] <Keybuk> pitti: I don't see it in the queue?
[04:49] <Kamion> Keybuk: I just promoted bluez-gnome
[04:49] <Keybuk> pitti: oh, someone stuck it under promoted ?
[04:50] <BenC> infinity: Uploaded, so you may want to push that through
[04:50] <Keybuk> Kamion: ok
[04:50] <pitti> Keybuk: apparently someone moved it already
[04:50] <Kamion> Keybuk: it's in the other queue now :)
[04:50] <Keybuk> Kamion: note that I've already done the rest :p
[04:50] <mvo> Kamion: it does not look easy to fix in aptitude, very generic code
[04:50] <Keybuk> Kamion: so we may end up with some soyuz mid-air collisions in a moment
[04:50] <tfheen> Kamion: isn't beagle NBS on sparc?
[04:51] <infinity> BenC: Accepted, thanks.
[04:51] <tfheen> Kamion: same for brltty on ppc
[04:51] <BenC> infinity: IMO, it's a devmapper bug that it uses __kernel_dev_t instead of dev_t, but I wont get in the middle of that
[04:51] <Keybuk> dholbach: telepathy-blue fixes the dep on python2.4-bttctl ?
[04:52] <dholbach> Keybuk: yes, please
[04:52] <Kamion> Keybuk: I just did bluez-gnome after dholbach asked, nothing else
[04:52] <BenC> infinity: It may be one of those things where "we always used it, and now we can't change"
[04:52] <infinity> BenC: Nonsense, change can always happen. :)
[04:52] <Kamion> tfheen: dunno if archive-cruft-check understands that
[04:53] <infinity> BenC: Think of all the bloody s/PAGE_SIZE/sysconf(_SC_PAGESIZE)/ uploads I've made.. *sigh*
[04:53] <tfheen> Kamion: can you make it understand it with an appropriately sized bat?
[05:06] <Keybuk> doko_: fixed the libintl.jar problem with java-gcj-compat-dev
[05:06] <Keybuk> their configure is busted for gcj detection, basically
[05:08] <siretart> xmms is in main? interesting..
[05:08] <pitti> tfheen: yup, a tetex-bin rebuild fixes the pdfetex symbol; yay ABI changes; I'll do a no-change upload, okay?
[05:09] <doko_> Keybuk: hmm ... in that case I would like to propose another solution: registering a javac alternative in ecj-bootstrap, and depending on that package. java-gcj-compat-dev sucks in too much.
[05:09] <Keybuk> that solution sounds edgy+1 :)
[05:09] <doko_> or you teach gettext to use ecj instead of javac
[05:09] <tfheen> pitti: I'm worried about poppler silently breaking the ABI
[05:10] <pitti> tfheen: I'll check the other rdepends, too
[05:10] <doko_> Keybuk: as the worst case, make a symlink from ecj to javac for the gettext build
[05:10] <tfheen> pitti: thanks.  If those are fine, I'm fine with a no-changes rebuild.
[05:11] <Keybuk> doko_: I'm afraid it cannot be taught to do that
[05:11] <Keybuk> it is hardcoded to look for "javac" or "gcj"
[05:11] <doko_> Keybuk: ln -sf /usr/bin/ecj javac; PATH=.:$PATH configure ...
[05:13] <Keybuk> doko_: *shrug* my way worked
[05:13] <pitti> Riddell: can you please check if kpdf plays well with the current poppler? pdfetex crashes with a weird 'symbol not found' error; I'll check the other rdepends
[05:13] <Riddell> pitti: ok
[05:14] <doko_> Keybuk: as long as you don't have a dep on libgcj*, that's maybe ok
[05:15] <doko_> pitti: I've seen that error as well, building gnat-gps, but cannot reproduce it here locally.
[05:15] <pitti> doko_: exactly; that'll be fixed with the tetex-bin rebuild as well
[05:15] <pitti> doko_: the very same as with quagga FTBFS, crashes through texi2dvi
[05:22] <seb128> mdz: bug #63481 for the panel freeze
[05:22] <Ubugtu> Malone bug 63481 in gnome-panel "gnome-panel freezes after dist-upgrade" [Medium,Needs info]  http://launchpad.net/bugs/63481
[05:27] <pitti> ogra: is there a bug for the gstreamer ltsp issue
[05:27] <ogra> pitti, yep
[05:27] <ogra> bug #65690 i think
[05:27] <Ubugtu> Malone bug 65690 in gst-plugins-good0.10 "should select the esdsink for LTSP_CLIENTs" [Medium,Unconfirmed]  http://launchpad.net/bugs/65690
[05:27] <pitti> ogra: hm, I just read my bugs inbox and didn't see it, thanks
[05:28] <ogra> probably LP is delayed again ...
[05:31] <mooey> i'm trying to fix a bug that deals with default / preferred browsers -- does kde have an alternative of gnome-open / gnome-www-browser?
[05:32] <Riddell> mooey: kfmclient
[05:32] <mooey> thanks
[05:32] <giftnudel> sivang: ping session and freespace detection
[05:34] <sivang> giftnudel: yeah ? :)
[05:35] <giftnudel> sivang: is capacity the whole capacity, volumesize the current size of the medium and freespace bytes the rest which is free to save stuff on?
[05:36] <sivang> giftnudel: that what I would think , why?
[05:36] <giftnudel> I've got something to test for you which seems to work nicely sometimes ;)
[05:36] <sivang> somttimes? ;-)
[05:37] <giftnudel> well, if it can't unmount the cd, it won't work (but shouldn't crash either)
[05:37] <sivang> ah, then I think we can aloways unmount the cd if need before a certain action
[05:38] <giftnudel> I did that, but sometimes, the cd is still busy and I don't know why ...
[05:38] <sivang> giftnudel: what's your method of calculating anyway?
[05:38] <giftnudel> but anyhow, I will sent you the DeviceInfo.py (it's not a major change, just some additions) please tell me what you think
[05:38] <giftnudel> sivang: cdrecord -msinfo -v
[05:39] <giftnudel> this is very reliable (the only reliable way to do so as I found out)
[05:40] <jdong> can anyone familiar with git comment on bug 43210 for me?
[05:40] <Ubugtu> Malone bug 43210 in dapper-backports "Git-core is out of date" [Undecided,Unconfirmed]  http://launchpad.net/bugs/43210
[05:40] <jdong> is git something worth backporting?
[05:40] <giftnudel> sivang: you've got mail
[05:41] <sivang> giftnudel: thank you, I shall read later today
[05:43] <fabbione> jdong: i find it hard to believe that's not compatible.. use wiki.u.c/KernelGit <- to test yourself
[05:43] <jdong> fabbione: thanks
[05:43] <fabbione> it's KernelGit+something... i can't remember the exact page
[05:45] <zul> https://wiki.ubuntu.com/KernelGitGuide
[05:46] <pitti> Riddell: ok, abiword and evince work fine, and tetex-bin works again after rebuild; if kpdf works as well, then a mere rebuild should do fine
[05:48] <fabbione> mvo: there were 2/3 things that were messing up
[05:48] <fabbione> but imake in edgy is provided by xutils-dev or something
[05:48] <fabbione> and for some reasons we don't pull it in
[05:48] <fabbione> till before Kamion cleared the NBS there was another package from dapper, sliping in the edgy Packages file
[05:48] <Kamion> Provides aren't always enough for apt
[05:49] <Kamion> particularly not if the old package remains installed
[05:49] <Kamion> you'd probably want Conflicts/Replaces/Provides anyway surely
[05:49] <fabbione> Kamion: yes.. i know. i don't recall all the details off-hand
[05:49] <Kamion> ... which it does have
[05:49] <Kamion> so it needs a transitional package because the package management system isn't up to it *shrug*
[05:50] <Kamion> see specs by iwj passim
[05:53] <seb128> BenC: you didn't reply yesterday, if you do an another upload, could you consider the change from #64433? It would make one of the GNOME dudes happy. If you can't that's fine too
[06:00] <BenC> seb128: Sure thing
[06:12] <cipher_nemo> Should I use the ubuntu wiki to post about brand-name PCs which fail on ubuntu dapper install (works with Debian sarge)?
[06:13] <dholbach> iwj: Hi, do you think bug 35333 and bug 62802 are easy to fix (if you should do a firefox upload), disregard them, if it's too much trouble
[06:13] <Ubugtu> Malone bug 35333 in firefox "xpcshell is unusable due to lack of wrapper script" [Medium,Unconfirmed]  http://launchpad.net/bugs/35333
[06:13] <Ubugtu> Malone bug 62802 in firefox "missing static libraries" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62802
[06:16] <pitti> dholbach: why do we need static libs?
[06:16] <pitti> if we have them, somebody could use them, which would suck
[06:16] <iwj> dholbach: Is 35333 really that big a problem ?
[06:17] <dholbach> iwj: I just had a look if another one of chpe's bugs was fixed and it was, so I stumbled over those two - I wasn't sure if they were hard or easy to fix.
[06:17] <iwj> dholbach: I don't want to ship the run-mozilla.sh script from upstream because it's completely insane.
[06:17] <dholbach> I see
[06:17] <iwj> Ideally we'd set the rpath so it would Just Work (tm).
[06:17] <dholbach> I know that seb128 asked for xpcshell on another occasion already - I don't know the use-cases for it, to be honest.
[06:17] <iwj> I had a go at that but it doesn't seem to have completely taken.
[06:18] <pitti> Riddell: kpdf works fine for me
[06:18] <dholbach> iwj: don't bother then.
[06:18] <iwj> dholbach: It does work; the workaround - setting LD_LIBRARY_PATH is both trivial and documented.
[06:18] <dholbach> iwj: thanks anyway. :-)
[06:18] <pitti> tfheen: so, only tetex-bin needs a rebuild, other rdepends work fine; ok for me to upload?
[06:18] <iwj> dholbach: OK :-).
[06:18] <Riddell> pitti: great
[06:19] <tfheen> pitti: approved.
[06:19] <dholbach> iwj: chpe is always a big help and hacks on the the gnome firefox-related bits (using ubuntu), so if I could make him happy, ... ;-)
[06:19] <pitti> tfheen: uploaded; I'll defer the quagga upload until the new tetex-bin is in the archive to avoid yet another ftbfs
[06:20] <iwj> dholbach: Right.
[06:20] <tfheen> pitti: please tell me when you do the quagga upload so I can give-back the ftbfs which gave us the first hint of this problem.
[06:21] <pitti> tfheen: yup
[06:29] <janimo> tortoise_:, heno: hi could either of you commit the patch in bug 65251
[06:29] <Ubugtu> Malone bug 65251 in onboard "work without nautilus" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65251
[06:29] <janimo> it was part of the upload I made for 0.82 a few days ago but got reverted by accident
[06:31] <heno> janimo: looks good. I'll let tortoise_ apply the actual patch though (being the maintainer)
[06:33] <janimo> heno: thanks
[06:41] <pitti> Keybuk: can you please approve the tetex-bin upload? it holds up quite a few ftbfs issues
[06:41] <Keybuk> pitti: tfheen
[06:41] <pitti> Keybuk: 1820: <tfheen> pitti: approved.
[06:41] <tfheen> Keybuk: also, please approve the python-{setuptools,qt3,qt4,kde3} uploads from doko_
[06:48] <wasabi_> So... where do we stand on EFI? This neato server board I just bought seems to support an EFI shell.
[06:48] <wasabi_> Oooh elilo
[06:56] <tortoise_> janimo: done
[06:57] <sivang> hi janimo , what's up?
[07:00] <janimo> tortoise_: thanks, planning a package upload in the next days?
[07:00] <janimo> sivang: hi
[07:01] <tortoise_> janimo: Not in my power to do so.  Have to ask one of the ubuntu-core-devs
[07:09] <dholbach> janimo, Gloubiboulga: bug 57588 might affect xubuntu-artwork too
[07:09] <Ubugtu> Malone bug 57588 in edubuntu-artwork "GDM themes do not have pam-message item" [Undecided,Unconfirmed]  http://launchpad.net/bugs/57588
[07:09] <dholbach> just fyi
[07:09] <pygi> pitti, ping? :)
[07:09] <pitti> hey pygi 
[07:09] <pygi> hey pitti 
[07:09] <pygi> some nice news again :) Libburn completely working on freebsd :)
[07:10] <pitti> nice
[07:12] <pygi> :)
[07:14] <Riddell> pitti: I confirm today's kpdf with today's poppler is working fine for me
[07:14] <pitti> Riddell: thanks
[07:15] <sivang> hey pygi !
[07:15] <pygi> sivang, !!!!
[07:15] <sivang> pygi: new release to package for edgy+1 when it opens? :-)
[07:15] <pygi> sivang, you saw the above? :)
[07:15] <Gloubiboulga> dholbach, thanks
[07:15] <pygi> sivang, dunno, we'll see, a lot of work in libisofs to be done (and a lot in cdrskin + libburn still)
[07:16] <janimo> tortoise_: I can upload ( Id id so with 0.82) but will ask for permission as it's a freeze
[07:16] <janimo> dholbach: thanks
[07:16] <sivang> pygi: yes, what does 'work' includes? 
[07:16] <pygi> sivang, I want to have Kamion's features ready for 0.2.4 :)
[07:16] <pygi> sivang, told ya already :) HFS, HFS+, and eltorito :)
[07:16] <sivang> pygi: should then get cracking on getting some good specs and updated ones.
[07:16] <dholbach> janimo: I'll add a task for you, if not you can just reject it
[07:16] <pygi> sivang, we have good specs I believe :)
[07:16] <janimo> dholbach: ok, thanks
[07:16] <dholbach> super
[07:17] <sivang> pygi: okay, cool. btw, what about switching out from trac but still using svn? (possible as well)
[07:17] <pygi> sivang, dunno :)
[07:17] <pygi> what's so wrong with trac?? :)
[07:18] <Gloubiboulga> janimo, I'll take care of the gdm bug
[07:18] <janimo> Gloubiboulga: thanks
[07:19] <sivang> pygi: hmm, it's awkward and we'll win pretty nice feature planning features in LP :-)
[07:19] <pygi> sivang, I've told you stuff, bleh =)
[07:20] <sivang> pygi: let's go to privmsg
[07:22] <tfheen> tkamppeter: is there any reason why we can't ship the firmwarE?
[07:22] <tfheen> s/E/e/
[07:23] <sivang> tkamppeter: is printdrake in python?
[07:24] <tkamppeter> sivang, printerdrake is Perl
[07:25] <tkamppeter> tfheen, the firmware is copyrighted, I perhaps need to talk with HP guys on the summit.
[07:25] <sivang> tkamppeter: ah
[07:26] <tkamppeter> tfheen, but if we have auto-download of printer drivers from the FSG OpenPrinting database, HP can put the firmwares into their packages.
[07:26] <tfheen> tkamppeter: we should be able to get a redistribution agreement or something for it, I'd imagine.
[07:27] <tkamppeter> Yes, that's it.
[07:27] <tkamppeter> tfheen, but if all works fine, only FSG needs this agreement and Edgy+1 does the rest.
[07:36] <JanC> bah, since the last python2.4 update, it also suffers from the python-central bug--now both installed python versions aren't properly configured anymore  :-(
[07:36] <janimo> Gloubiboulga: does gnumeric require latest goffice and latest gsf to build and run?
[07:36] <Gloubiboulga> janimo, yes
[07:38] <Gloubiboulga> tfheen, is it ok to upload a new xubuntu-default-settings : http://tiber.tauware.de/~gauvain/x-d-s.debdiff ?
[07:39] <tfheen> Gloubiboulga: yes, looks good to me.  Feel free to upload.
[07:39] <Gloubiboulga> thanks
[08:00] <keescook> dholbach, tfheen: I have a fix for bug 39275.  Okay to upload?
[08:00] <Ubugtu> Malone bug 39275 in gstreamer "AC3 videos sound WAY too soft" [Unknown,Fix released]  http://launchpad.net/bugs/39275
[08:16] <mdz> BenC: what's next in tracking down this e1000 bug?
[08:17] <BenC> mdz: I need to talk to davem, fabbione says he's aware of a similar problem on sun4v
[08:19] <mdz> BenC: the bisecting didn't result in any leads?
[08:20] <BenC> mdz: It resulted in a couple of commits, but the only one that looked like it could cause a problem, was fixing a problem just as bad as the one it seems to be causing
[08:20] <BenC> and it was pretty complicated, lot of locking fixes
[08:20] <BenC> I don't have time to try to understand the locking symantics to fix the fix
[08:30] <fschoep> mdz: ping?
[08:31] <dholbach> keescook: you rock
[08:32] <keescook> cool.  :)
[08:32] <keescook> should I wait for tfheen to okay the upload too?
[08:32] <jcole> does the mini.iso installer for edgy use the new debian gtk installer?
[08:32] <jcole> http://wiki.debian.org/DebianInstaller/GUI
[08:32] <keescook> I also have a security upload for edgy as well (xorg package, one-line change)
[08:33] <fschoep> Can anyone point me to the head of the documentation team? Launchpad isn't helpful.
[08:34] <pitti> ROCK! fresh new tetex-bin, now without poppler troubles
[08:35] <pitti> tfheen: new tetex-bin is in the archive, I upload quagga now; please give-back gnat-gts for that, too
[08:35] <mdz> fschoep: pong
[08:38] <jcole>  /j #ubuntu-boot
[08:38] <jcole> oops
[08:48] <fschoep> mdz: who leads the docteam?
[08:51] <mdz> fschoep: points of contact are at https://wiki.ubuntu.com/DocumentationTeam/Contact
[09:01] <siretart> dholbach: anything to do on the unapproved queue?
[09:01] <dholbach> siretart: i don't know - Kamion, keybuk, infinity, tfheen would know
[09:02] <siretart> okay. I've set my irssi hilights for this channel, I'll try to notice if something is to do
[09:02] <dholbach> siretart: how are you?
[09:05] <siretart> dholbach: Oh, writing a thesis makes you quite busy, you know? ;) - anyway, I'm trying to catch up with my ubunut work, and I think I managed it so far :)
[09:06] <siretart> the move is finally finished, so I can concentrate now on the thesis fully :)
[09:06] <dholbach> siretart: i remember :)
[09:06] <siretart> dholbach: how are things going on your side?
[09:07] <dholbach> siretart: quite busy too, but good to see that bugs and todo lists are shrinking away :-)
[09:07] <siretart> :)
[09:14] <keescook> where does checkrdepends come from?  apt-cache isn't helpful, and neither is google.  I'm feeling crazy.  :)
[09:15] <dholbach> dlocate?
[09:15] <dholbach> dpkg -S?
[09:15] <dholbach> apt-file? :)
[09:16] <keescook> dholbach: well, as in, I want it, but I can't find it's origin to go get it from.  :)
[09:16] <dholbach> apt-file the
[09:16] <dholbach> then
[09:17] <siretart> pygi: I've seen it. whoohoo
[09:18] <pygi> siretart, :)
[09:19] <keescook> dholbach: no luck.  is this tool only on the archive machines?  (https://wiki.ubuntu.com/ArchiveAdministration is the only thing that talks about it)
[09:20] <dholbach> keescook: oooh, that might be
[09:21] <keescook> dholbach: ah well, I will stick with apt-cache until I have access to those machines.  ;)
[09:21] <dholbach> http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=checkrdepends&searchmode=searchfiles&case=insensitive&version=edgy&arch=i386 is empty too
[09:21] <keescook> dholbach: yup, did that too
[09:21] <keescook> :)
[09:22] <keescook> dholbach: during freeze are you the RM for universe uploads, or does everything need tfheen's approval regardless of repo?
[09:23] <keescook> I've got two universe uploads to do (milestone fix and security fix), and I'm just trying to understand the process.  :)
[09:24] <dholbach> keescook: keybuk, tfheen, Kamion and infinity will all ask, if they process the queue - if nobody of you speaks up for an upload, they will assume that I know and ask me :-) :-)
[09:24] <dholbach> keescook: luckily the most cases were easy enough
[09:25] <keescook> dholbach: okay, so I should go ahead and do the two uploads?
[09:25] <dholbach> keescook: if it's easy and simple enough, yeah, sure
[09:36] <dholbach> good night
[09:36] <keescook> cya dholbach
[09:37] <dholbach> bye keescook
[09:38] <siretart> sleep well, dholbach !
[09:38] <dholbach> siretart: later, yeah - but you too! :-)
[09:38] <siretart> :)
[09:55] <ajmitch> morning all
[09:55] <_ion> Good evening.
[09:57] <zul> later
[10:10] <mdz> BenC: any word from davem?
[10:10] <BenC> mdz: He says it is unrelated, so I'm trying to backout the commit that the bisect pointed to, from a 2.6.18 version and get it compiled for you
[10:11] <mdz> BenC: ok, I'm around
[10:11] <BenC> I gotta get the kids off the bus, then I'll get it to you
[10:24] <wasabi_> heh. dapper is totally failing to deal with these md devices
[10:37] <BenC> mdz: test ready: 50ae5b06fc3e011a6a8e14ce40f4017d
[10:42] <mdke_> can someone help me with something very basic? If I have a bunch of files name "index.xyz.html", where xyz is a variable, how can I rename them all to "index.html.xzy" using one command?
[10:44] <neuralis> mdke_: for i in *xyz.html; do mv "$i" `basename "$i" xyz.html`html.xzy; done
[10:44] <mdke_> wow, that sounds spiffy, trying
[10:44] <BHSPitMonkey> showoff
[10:46] <mdke_> neuralis: doesn't seem to work. It's "xyz" that varies...
[10:46] <mdke_> so I have index.en.html, index.fr.html etc
[10:47] <neuralis> you said it's a variable, by which i assumed you mean it's a $VARIABLE.
[10:47] <mdke_> maybe I expressed myself badly, sorry
[10:48] <mdke_> I mean it varies from file to file
[10:49] <neuralis> sec
[10:50] <BHSPitMonkey> anyone seen keybuk recently?
[10:51] <Ng> for i in `ls index.*.html` ; do echo mv $i index.html.`echo $i | sed -e 's/index.\(.*\).html/\1/'` ; done
[10:51] <Ng> then remove the echo if you're happy
[10:51] <Ng> not the cleanest it could be, but it works ;)
[10:53] <mdke_> Ng: yes, I'm happy :) What do I remove, exactly?
[10:53] <Ng> "do echo mv" becomes "do mv"
[10:53] <Ng> it do the command instead of echo what you would have done
[10:53] <Ng> -it+te
[10:53] <Ng> gah, my typing sucks so much today...."ie"
[10:54] <mdke_> got it, and it works. Thanks!
[10:54] <Ng> I should probably be sent to some kind of shell hell for not doing it more cleanly though ;)
[10:54] <Ng> maybe a place with no bash, only csh ;)
[10:54] <_ion> rename -n 's/\.([^.] +)\.html$/.html.$1/' *
[10:54] <_ion> Remove -n after you've verified the result.
[10:55] <Ng> see that's much nicer :)
[10:55] <neuralis> mdke_: ah, okay, you were helped while i was out.
[10:55] <mdke_> :)
[10:56] <mdke_> for some reason, it has broken some of the styling in the html
[10:56] <mdke_> how odd
[10:57] <Kamion> jcole: no; while I've been involved with the Debian graphical installer at various levels for a while, I still don't think it's quite up to scratch
[10:58] <Kamion> keescook: pitti wrote checkrdepends
[10:58] <wasabi_> nice. no elilo on dapper install?
[10:58] <Kamion> keescook: http://people.ubuntu.com/~cjwatson/checkrdepends is the current version
[10:59] <mdke_> Ng: that script doesn't touch the inside of the files right? it's very odd that the styling has broken on them
[10:59] <keescook> Kamion: ah-ha!  Thanks.  I looked for it in ~pitti earlier.  :)
[11:00] <Kamion> interface-wise it's rather nasty - it would be better if the suite were either first, or had a sensible default
[11:00] <Kamion> but shrug, it does the job
[11:00] <Ng> mdke_: you saw the echo output, all it does is call mv and last time I checked there's no way mv can change a file. Is it not more likely that apache/whatever is treating the files differently now they aren't called .html?
[11:01] <Ng> perhaps one of those strange things whereby a browser goes into sloppy/strict rendering modes of its own accord, but I'm really very doubtful that command would have broken the files
[11:02] <BenC> mdz: ping?
[11:02] <mdke_> Ng: I'm just viewing them on my filesystem, without apache
[11:02] <mdz> BenC: have booted with the new module, testing now
[11:02] <Ng> mdke_: try renaming one of the "broken" ones back to .foo.html and see if it renders properly
[11:03] <mdke_> Ng: yes works :) Ok presumably apache will make it work
[11:03] <Ng> mdke_: do they not have proper doctype headers?
[11:03] <Ng> that usually seems to convince browsers to behave predictably (in as much as browsers ever do that ;)
[11:03] <wasabi_> oh nice. it ftbfs in dapper ad64 haha
[11:03] <wasabi_> amd64
[11:04] <mdke_> Ng: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
[11:04] <Ng> weird. stupid browsers!
[11:05] <mdke_> yeah. Anyway, I'm happy it will work
[11:05] <mdz> BenC: 5x OK
[11:08] <BHSPitMonkey> anyone seen keybuk recently?
[11:12] <tkamppeter> mdz, keybuk, New foo2zjs package on http://www.freestandards.org/~till/tmp/ubuntu/edgy/foo2zjs/ to address bug 65618
[11:12] <Ubugtu> Malone bug 65618 in foo2zjs "Package broken/incomplete, missing firmware files" [Low,Needs info]  http://launchpad.net/bugs/65618
[11:12] <BenC> mdz: So that resolves it?
[11:14] <BenC> mdz: e1000: rework driver hardware reset locking
[11:14] <BenC> mdz: That's the patch I backed out
[11:17] <mdz> BenC: yes, that driver seems to work well
[11:17] <BenC> mdz: Ok, one more test, give me 5 minutes
[11:17] <mdz> BenC: can I see the diff?
[11:18] <mdz> going to make some lunch, will check back from time to time
[11:19] <AlinuxOS> mjg59, hello... ping
[11:36] <BenC> mdz: next test: 502570b8f8f51eb60056efc7dc9fee4c
[11:39] <mdz> BenC: testing
[11:51] <jcole> Kamion: oh ok, it appears it only supports i386 and amd64 too
[12:00] <mdz> BenC: 5x OK
[12:00] <BenC> mdz: Ok, the first test was stock edgy kernel, with that problem patch reverted, the second test was 2.6.18 stock version with the same patch backed out
[12:01] <mdz> sounsd compelling
[12:01] <BenC> I'm leaning to do the 2.6.18 - the problem commit reverted
[12:01] <BenC> s/-/minus/ to be clear
[12:02] <mdz> what else is in 2.6.18 which we don't have in edgy?
[12:03] <BenC> mdz: in e1000 or in general?
[12:04] <mdz> BenC: e1000
[12:04] <mdz> BenC: I assume you're not talking about moving the rest of the kernel to 2.6.18 ;-)
[12:04] <Seq> I was wondering if anybody using edgy had beagle indexing gaim logs at all? Mine doesn't seem to, but I haven't found anything on launchpad yet
[12:05] <seb128> anybody around to approve http://people.ubuntu.com/~seb128/gaim.debdiff ?
[12:05] <mdz> BenC: I'd like to see the diff for the problem commit
[12:05] <zul> ooh...move it to 2.6.18 :)
[12:05] <mdz> seb128: sure
[12:05] <seb128> that's just changing again the "stop the glowing effect" default option again
[12:05] <seb128> (we did for dapper and the patch got dropped on the road during edgy)
[12:05] <mdz> seb128: yep, no problem
[12:05] <seb128> mdz: thank you
[12:06] <seb128> uploaded
[12:06] <ajmitch> zul: somehow I don't think he means the whole kernel :)
[12:07] <BenC> mdz: Sent