[12:12] <mdz> BenC: hmm, it seems to drop an e1000_reset call, wonder if that's OK
[12:14] <BenC> mdz: in e1000_set_settings?
[12:14] <jdong> seb128: is there anything gnomeish in /etc/X11/Xsession.d that could possibly mess with DPMS settings?
[12:15] <BenC> mdz: That's all ethtool stuff, probably doesn't even come in the play with this use case
[12:15] <seb128> jdong: what is your issue?
[12:15] <jdong> seb128: when running KDE with gnome installed, DPMS timeouts seem to multiply by 60
[12:15] <jdong> seb128: thatis, seconds turn into minutes
[12:16] <jdong> seb128: everyone who has the problem appears to have GNOME installed
[12:16] <mdz> BenC: any idea why it gets rid of the watchdog task?
[12:16] <jdong> and from what we can tell, KDE is doing the restore correctly.. but something later on is overridding it
[12:16] <seb128> jdong: not that I know, do they use gdm?
[12:16] <BenC> mdz: According to the comments in the commit, it is replaced with a non-scheduled task
[12:16] <jdong> seb128: I do, and I see the problem
[12:16] <seb128> jdong: might be gdm doing something with it
[12:16] <jdong> seb128: hmm, interesting idea
[12:17] <Lure> jdong: I use kdm
[12:17] <seb128> dunno then
[12:17] <jdong> Lure: do you want to sacrifice your Xsession.d to experimentation?
[12:17] <mdz> BenC: doesn't make much sense to me
[12:17] <jdong> Lure: that is, move it somewhere else, make a new one only with displayconfig-restore
[12:18] <mdz> BenC: the patch seems to have 3 more or less independent parts, maybe we can narrow it down
[12:19] <mdz> the _reinit_locked stuff, irq request/release, and the watchdog
[12:19] <BenC> mdz: The one part I wonder about is this:
[12:19] <BenC> +       while (test_and_set_bit(__E1000_RESETTING, &adapter->flags))
[12:19] <BenC> +               msleep(1);
[12:21] <BenC> mdz: That has to do with timers, which would seem to be a likely trigger for our problem
[12:21] <mdz> it does the same thing as _reinit_locked
[12:21] <mdz> BenC: what's the first arg to test_and_set_bit?  is it supposed to be a bit position or a mask?
[12:22] <BenC> mdz: That's an interesting question, because that is an enum, and so one of the values is 0x0, which is not a bit at all
[12:23] <mdz> yeah, that seems ot be valid though
[12:23] <BenC> mdz: let me try the full 2.6.18 with those enums as bit values
[12:23] <mdz> I see other test_and_set_bit(0, ...) elsewhere in the kernel
[12:23] <BenC> oh, wait
[12:23] <BenC> no, that's valid
[12:23] <BenC> it's a but number, not a mask
[12:23] <BenC> s/but/bit/
[12:23] <mdz> yes
[12:24] <mdz> BenC: could something else be modifying adapter->flags?
[12:27] <BenC> mdz: Give this a try: 1eec6078ecea6a3cead2e9f35820a1fa
[12:27] <BenC> mdz: That's stock edgy kernel, minus all the adapter->flags fiddling
[12:28] <BenC> we'll take this one at a time
[12:29] <mdz> BenC: broke on the second try, but not quite in the usual way
[12:29] <mdz> actually first try
[12:29] <mdz> let me do a fresh boot
[12:30] <mdz> oh, flags is new, so no other code would be touching it
[12:30] <BenC> well, it's based on broken source, so if removing flags didn't fix things, then it isn't the culprit
[12:30] <BenC> Let's try the reinit change
[12:31] <mdz> BenC: yeah, this one won't suspend at all
[12:31] <mdz> worse than stock edgy
[12:31] <shining> did anything change recently in edgy kernel about cpufreq (centrino driver)?
[12:34] <mdz> I'm suspicious of the irq changes
[12:35] <shining> mdz: for suspend or cpufreq?
[12:36] <mdz> shining: the e1000 problem that BenC and I are working on
[12:37] <shining> ah ok. that doesn't seem to be easy :p good luck
[12:40] <BenC> mdz: next: ee221a06d71530fee7faa6f0371db2cb
[12:40] <BenC> mdz: This is stock edgy, with just the reinit_locked parts reverted
[12:40] <BenC> I'm not so sure how well that's going to work
[12:41] <shining> I'm sure speedstep-centrino worked fine before on my core duo laptop. but now it doesn't even load anymore (no such device). too bad I stopped using it, so I can't know if it stopped working after a kernel update
[12:42] <mdz> BenC: panics in the familiar way
[12:44] <BenC> mdz: next: dcfe691b1e2a4888ff792cbe97329f38
[12:44] <BenC> mdz: This one re-adds the watchdog timer
[12:47] <mdz> BenC: only?
[12:47] <BenC> mdz: Right
[12:47] <mdz> ok
[12:47] <BenC> I'm reverting back to stock edgy for each of these
[12:49] <mdz> doing the reboot dance
[12:51] <mdz> 1x OK
[12:52] <mdz> crash on 3x
[12:52] <mdz> blank screen, flashing caps lock
[12:52] <BenC> interesting
[12:53] <BenC> mdz: Let me investigate this change a bit...I got a fresh cup of coffee
[12:58] <mdz> BenC: how about we try backing out the irq changes?  I mailed you a diff
[01:00] <mdz> nm, I can build it here and try
[01:05] <mdz> BenC: ack, the diff you sent me is word-wrapped
[01:05] <BenC> mdz: you have git?
[01:05] <BenC> mdz: If so: git-diff-tree -p 2db10a081c5c1082d58809a1bcf1a6073f4db160 > temp.diff
[01:06] <mdz> BenC: yep, thanks
[01:06] <AlinuxOS> mdz, good evening or good night (I don't know your location) ;)
[01:08] <Riddell> Kamion: the language packs don't get added to the meta packages any more?
[01:09] <AlinuxOS> I've just mailed a letter, my problem is explained there...please check when you've some free time. Thank you in advance.
[01:18] <mdz> BenC: backing out the irq hunks gives me something which seems to work. 5x and counting
[01:21] <AlinuxOS> mdz, thank you for tempestive response, also sorry my for my stupid question but I don't know what should I do in this case ?
[01:22] <BenC> mdz: try this: 371c320808c3aebadd6379c4ba8d6caf
[01:23] <BenC> mdz: That pretty much does the same thing, but with less changes (leaves the request/free functions, but moved them back to where they used to be called)
[01:24] <mdz> BenC: looking good, 3x and counting
[01:26] <mdz> BenC: I'm satisfied
[01:27] <`anthony> doko_: Older Ubuntu releases need a security update release (whatever you call them) for Python 2.3 to pull in PSF-2006-001. You distribute a UCS-4 build - this is vulnerable to a buffer overrun.
[01:27] <BenC> mdz: Now the real question, stock edgy + this diff, or 2.6.18 e1000 plus this diff?
[01:27] <mdz> BenC: edgy
[01:27] <mdz> minimum changes to fix this regression
[01:28] <BenC> mdz: Ok, I sent you a copy of the diff
[01:28] <BenC> commiting and marking the bug
[01:29] <doko_> `anthony: replied by email: afaik, we do. I'll recheck tomorrow with keescook and pitti
[01:30] <keescook> `anthony: that should have been covered by http://www.ubuntu.com/usn/usn-362-1
[01:30] <keescook> are you still seeing issues with the latest build?
[01:30] <keescook> sorry, wrong USN: http://www.ubuntu.com/usn/usn-359-1
[01:30] <mdz> BenC: nice work, what's next on the kernel hit list?
[01:31] <`anthony> keescook: I don't have a test that reproduces it. That advisory doesn't mention python
[01:31] <BenC> 58742: I need to check into the dvb modules for v4l-1
[01:31] <BenC> 64433: I'm trying to decide if the suggested fix is correct
[01:31] <lifeless> `anthony: it does - at the top
[01:32] <lifeless> python2.3, python2.4 vulnerabilities
[01:32] <lifeless> CVE-2006-4980
[01:32] <`anthony> php4, php5 vulnerabilities
[01:32] <BenC> bug 58742 bug 64433
[01:32] <`anthony> ??
[01:32] <Ubugtu> Malone bug 58742 in linux-source-2.6.17 "[edgy]  Important dvb-ttpci modules are missing in edgy!" [Undecided,In progress]  http://launchpad.net/bugs/58742
[01:32] <Ubugtu> Malone bug 64433 in linux-source-2.6.17 "Use correct SATA driver for (some) MacPros" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64433
[01:32] <lifeless> ...
[01:32] <lifeless> Benjamin C. Wiley Sittler discovered that Python's repr() function did
[01:32] <lifeless> not properly handle UTF-32/UCS-4 strings.
[01:32] <`anthony> ah - there was a second link.
[01:32] <`anthony> I missed that scroll past :)
[01:32] <keescook> `anthony: yeah, sorry for the typo
[01:32] <lifeless> :)
[01:33] <mjg59> BenC: It's almost certainly correct. Most modern Intel chips should be listed in both ahci and ata_piix
[01:33] <`anthony> It also applies to 2.2, btw, which you guys have.
[01:33] <mjg59> Yes, this is greatly irritating
[01:33] <`anthony> and quite probably 2.1 - which we (python.org) don't support any more at all.
[01:33] <BenC> mjg59: So the dual listing is ok...hopefully ata_piix just wont claim it?
[01:33] <lifeless> we have 2.2 ?
[01:33] <BenC> does udev handle that?
[01:33] <keescook> `anthony: true, 2.2 is in "universe"
[01:34] <lifeless> who knew.
[01:34] <`anthony> ii  python2.2      2.2.3dfsg-4    An interactive high-level object-oriented la
[01:35] <mjg59> BenC: In this case, if both drivers can bind it, it may need manual blacklisting to pick the right one
[01:35] <mjg59> BenC: Nothing we can fix in time for edgy, though
[01:35] <`anthony> apologies in the delay in getting the python security advisory out - post 2.5, there was a bit of shellshock/PTSD :)
[01:35] <doko_> keescook: well, is it possible to fix the universe versions as well?
[01:36] <keescook> `anthony: no problemo.  :)  I'll see about 2.2; I was going to be rebuilding it to relink against openssl 0.9.8 anyway.  :)
[01:36] <`anthony> same patch as for 2.3
[01:36] <keescook> `anthony: I was just going to ask.  :)  great, I'll get to that tomorrow.  Thanks for checking in with us!  :)
[01:37] <AlinuxOS> mjg59, hello, I've mailed you a letter,please would you be so kind to check your mail when you've some free time. Thank you.
[01:38] <`anthony> I should probably hunt down a list of relevant people at various distributions, actually.
[01:38] <`anthony> What's the best email address for ubuntu?
[01:38] <doko_><EMAIL_ADDRESS>[01:38] <`anthony> No, I'm not going to go and submit a "security" bug to each of 15 different bugtrackers :)
[01:39] <doko_> keescook: ^^^
[01:39] <keescook> `anthony: yup, as doko_ says<EMAIL_ADDRESS>will hit both me and pitti.
[01:43] <keescook> `anthony: it doesn't look like python2.2 is vulnerable (at least not for the testcase that was reported)
[01:43] <`anthony> keescook: >>> sys.maxunicode
[01:43] <`anthony> 65535
[01:43] <`anthony> aha. it was built as UCS-2. How odd, when 2.3 and 2.4 are UCS-4
[01:44] <keescook> `anthony: ah, where did you find the UCS-2 details?
[01:44] <`anthony> sys.maxunicode :)
[01:45] <keescook> ah, I see.  2.4 == 1114111
[01:45] <`anthony> so the source for 2.2 still has the vulnerability, but it's fine the way it's built and distributed as a binary.
[01:46] <`anthony> that's a policy decision for you as to whether that's worth fixing, I guess.
[01:46] <`anthony> (the problem only manifests itself with ./configure --with-unicode=ucs4, which is not the default)
[01:47] <doko_> yep, I started to configure --with-unicode=ucs4 after a chat with mvloewis
[01:48] <`anthony> "_=str.upper" is my preferred approach to i18n :)
[02:08] <BenC> mdz: Ok, I'm down to just the v4l-1 bug
[02:47] <BenC> mdz: all my bugs for the kernel are taken care of now
[02:57] <mdz> BenC: excellent
[02:57] <BenC> mdz: Who can I email my change log to for approval?
[02:58] <mdz> BenC: me
[02:58] <BenC> mdz: diff too?
[02:59] <mdz> BenC: sure
[03:07] <BenC> mdz: Sent
[03:12] <sladen> mdz: 1 line wine upload to reapply a change dropped since dapper (do not install mime handlers---so that Firefox does not offer to run .exe's for security reasons)
[03:12] <mdz> BenC: that pcbios patch gives me the heebie-jeebies
[03:13] <mdz> sladen: ok
[03:13] <BenC> mdz: That was pulled from 2.6.18
[03:13] <mdz> BenC: upstream has bugs too :-)
[03:13] <BenC> mdz: check the GIT-SHA (git-diff-tree --pretty=medium <sha>) and read the comment
[03:14] <BenC> mdz: I checked it though to the email discussion about it, and it is absolutely correct
[03:14] <BenC> mdz: Otherwise, it's a regression from dapper
[03:14] <BenC> since a lot of pcmcia devices wont even be seen by PCI much less the driver
[03:15] <railz> I was curious what happened to the option 'allow browsing folder' with share folder
[03:15] <mjg59> mdz: The patch is considered correct by upstream
[03:15] <mdz> BenC: what happened with the v4l1 situation?  I thought it was mutually exclusive
[03:15] <mjg59> And restores 2.6.15 behaviour
[03:15] <railz> it's no longer available in edgy
[03:15] <mdz> mjg59: the latter is more compelling than the former; I don't expect upstream willfully applies incorrect patches :-)
[03:16] <BenC> mdz: v4l1 only drivers had been disabled in edgy...that was ok for most things since a lot of v4l2 drivers had v4l1 compatibility
[03:17] <BenC> mdz: Some didn't though
[03:17] <BenC> mdz: It's a small subset, but it's a regression from dapper on our media hw support
[03:17] <mdz> BenC: right, but I had looked at the bug before and you'd said that we couldn't enable both in some cases
[03:19] <ajmitch> Kamion: bzr-svn got UVF approval just before freeze, but wasn't uploaded for universe. Still ok to go in?
[03:19] <BenC> mdz: I checked and the cases where the driver is only v4l1, there's no v4l2 driver
[03:20] <mdz> BenC: oh, ok
[03:21] <mdz> BenC: ok, I'm happy with all of this
[03:21] <BenC> mdz: Ok, then uploading
[03:21] <mdz> I assume the v4l1 stuff is .config only; there's nothing in the diff
[03:21] <BenC> right
[03:21] <BenC> and I did test compile all of it
[03:22] <BenC> I was going to disable any drivers that spewed even a hint of warning crud, but they all compiled cleanly
[03:22] <mdz> BenC: ping me when it's processed and I'll accept it
[03:23] <BenC> compiz == the best way to impress your friends about linux, and the easiest way to lose time in an otherwise normal workflow :)
[03:23] <BenC> I can't help but to play with kiba-dock everyone in awhile
[03:23] <BenC> *everyonce
[03:24] <railz> also, I used to be on hoary and admin/share folders no longer requires admin privledges why is that?
[03:24] <railz> whereas in hoary it did
[03:24] <jdong> BenC:  you have time to play?
[03:24] <jdong> ;-)
[03:28] <BenC> jdong: I call it "alternate development time" :)
[03:29] <jdong> ha! that's good
[03:29] <jdong> sort of like my alternate study time
[03:36] <sladen> railz: could you file a bug with a screenshot if it's a regression
[03:38] <railz> sladen: will do
[03:38] <railz> actually here's a link of how it used to look:
[03:39] <railz> http://shots.osdir.com/slideshows/659_or/50.png
[03:39] <BenC> mdz: accepted, just needs approval
[03:40] <BenC> need to reboot
[03:41] <bddebian> Howdy
[04:14] <wasabi> Huh. casper-udeb/runlevel seems to have no effect.
[04:18] <mdz> BenC: accepted
[04:18] <BenC> mdz: Thanks
[04:18] <wasabi> Hmm. DId it change names to/from casper-udeb/configure-init/runlevel? What is it in dapper?
[04:29] <wasabi> Awww. Looks like that template is gone.
[04:34] <wasabi> Bah this is silly.
[04:40] <whiprush> wasabi: hey did you see the lockdown thing I wrote up for the gnome summit? Might be useful for mountain view.
[04:40] <ajmitch> hey whiprush
[04:40] <wasabi> nope.
[04:40] <whiprush> hi ajmitch!
[04:40] <whiprush> ajmitch: you too
[04:40] <wasabi> i'm getting angry right now. =(
[04:40] <ajmitch> whiprush: I've got to get to MV first
[04:40] <wasabi> I've spent 3 hours trying to boot this system with Ubuntu heh
[04:41] <whiprush> http://live.gnome.org/Glockenspiel
[04:41] <whiprush> Federico from Novell sent along his notes to the admin bof at the summit
[04:41] <whiprush> I think there are some good ideas there for basing an ubuntu spec off of.
[04:41] <ajmitch> yeah I read that write up there
[04:41] <wasabi> I'll check it out when I get home.
[04:41] <ajmitch> looks good
[04:41] <wasabi> leaving now
[04:42] <whiprush> ajmitch: I have a ticket, but haven't gotten a hotel yet. :-/
[04:42] <ajmitch> whiprush: ah, that's a pain - I can probably afford a plane ticket but would stretch it a lot for the hotel
[04:42] <whiprush> ajmitch: do you think it would be a good idea to start a spec outline or something before the summit?
[04:42] <ajmitch> definitely
[04:42] <ajmitch> always good to start with as much as possible
[04:42] <whiprush> ajmitch: dude it's the ubuntu community, someone will take care of you. :D
[04:42] <whiprush> as always, you can have my floor.
[04:42] <ajmitch> heh
[04:43] <whiprush> but apparently I snore loudly.
[04:43] <ajmitch> I can handle that
[04:43] <ajmitch> that's what earplugs are for :)
[04:43] <whiprush> ajmitch: as a bonus, I convinced a coworker to come with me, he's like wasabi, a windows/linux guy.
[04:43] <ajmitch> great!
[04:44] <whiprush> I'm pretty sure that if we can't spec something decent at MV then we should all quit computing.
[04:44] <ajmitch> so now I just need someone willing to help me with an airfare & I'll be set :)
[04:44] <whiprush> msg
[04:46] <sladen> wasabi: what "doesn't boot"?
[04:46] <sladen> whiprush: fancy doing an Ubuntu-specific report from Boston for El Fridge?
[04:47] <whiprush> sladen: possibly.
[04:47] <whiprush> if ubuntu-specific means "Corey wore the shirt" and "jdub was there" :)
[04:47] <sladen> whiprush: fantastic, I'll mark that down as a 'yes' then :)
[04:48] <whiprush> heh
[04:48] <whiprush> sladen: lots of brown desktops. :D
[04:49] <jdub> everyone was down with the brown
[04:49] <jdub> you could make a snarky comment about how wonderful it was to have engineers from all major gnome-shipping companies
[04:52] <sladen> jdub: you're not suggesting by any chance that Canonicals 2days-per-year conference allowance prevented any engineers from attending...
[04:53] <heatxsink> sup
[04:53] <heatxsink> anyone in here ever done two video cards with Ubuntu?
[04:54] <whiprush> heatxsink: try #ubuntu
[04:54] <sladen> heatxsink: yes, you'll be wanting https://help.ubuntu.com/community/XineramaHowTo and #ubuntu
[04:54] <heatxsink> tried that
[04:55] <infinity> jdub: I was there, I was just hiding.
[04:59] <mdz> mjg59: do you have an idea about 56365?
[05:01] <mjg59> mdz: I'll be taking a look at the weekend
[05:01] <mjg59> I've got a couple of ideas
[05:07] <mooey> theres a spec on launchpad (bug-reporting-tool) which dosen't seem to have anyone working on - i would like to set about getting this going, but i'm not really sure how to go about it or where even i should ask about these sorts of things
[05:08] <Burgundavia> mooey: bug reporting is something pitti has been working on
[05:09] <mooey> Burgundavia, ok. do you have an email address for pitti?
[05:09] <mooey> or a suitable means to contact him/her :)
[05:10] <Hobbsee> mooey: he'll be on here later today, i expect
[05:10] <Burgundavia><EMAIL_ADDRESS>[05:10] <mooey> thanks :)
[05:31] <wasabi_> There used to be a document someplace in the Wiki about the process of building the LiveCD.
[05:31] <wasabi_> Try as I might I can't find it.
[05:31] <wasabi_> Oh there it is. ;)
[05:32] <wasabi_> Weird. The wiki didn't load the entire page the first time I viewed these pages.
[05:32] <ajmitch> wasabi_: or it redirected you to help.u.c
[05:32] <wasabi_> Hmm. It took about 10 seconds for the page to show. Before that it just showed the header and the page footer. So I thought "oh, empty wiki page. weird."
[05:33] <ajmitch> yeah, that happens for redirects like that
[05:34] <wasabi_> whiprush: What was that you pasted earlier?
[05:34] <wasabi_> I just got home.
[05:34] <whiprush> http://live.gnome.org/Glockenspiel
[05:37] <wasabi_> Heh. This is intersting how the LiveCDCustomization stuff takes an existing livecd and just alters it.
[05:37] <wasabi_> I was sort of expecting we had a package which built a CD out of apt. :0
[05:43] <fabbione> morning
[05:44] <fabbione> ajmitch: you have been flooded with emails
[05:44] <ajmitch> yes, I saw
[05:44] <ajmitch> I've also had most of the xfonts builds fail locally due to bad build deps
[05:44] <fabbione> ajmitch: tthere are some failures due to SYSV IPC.. ignore them
[05:44] <fabbione> it claims the system is out of disk space
[05:45] <fabbione> but it's crap
[05:45] <ajmitch> right, I saw errors like that in packages like dpkg :)
[05:45] <fabbione> i just kick them back
[05:45] <fabbione> yes exactlt
[05:45] <ajmitch> a few other failures due to build depends to sort through
[05:45] <fabbione> yeah those are real FTBFS
[05:46] <ajmitch> I'll start filing some bugs & pass the list around
[05:46] <ajmitch> about 150MB of build logs so far
[05:47] <fabbione> probably.. some of them will never arrive to you > 10MB
[05:47] <ajmitch> ah
[05:47] <fabbione> not many tho
[05:47] <ajmitch> they getting bounced on my end, or are you not sending them?
[05:47] <fabbione> probably bounced on your end
[05:48] <ajmitch> ok
[05:48] <fabbione> i did remove the size check.. i think
[05:48] <ajmitch> if you wanted to change the email address at some point<EMAIL_ADDRESS>is on my home DSL, no mailservers in between
[05:48] <ajmitch> it ought to work now that I fixed the exim config :)
[05:49] <fabbione> it's not worth.. there are probably 5/6 pkgs that makes a log > 10MB and they are all in main
[05:49] <ajmitch> ok
[07:59] <fabbione> crimsun: bug 65831 is for you
[07:59] <Ubugtu> Malone bug 65831 in john "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/65831
[08:20] <Kagou> morning
[08:37] <tepsipakki> latest kernel builds have failed, but I can't see any correlation between the architectures
[08:38] <pitti> Good morning
[08:38] <fabbione> morning pitti
[08:38] <pitti> hi fabbione
[08:39] <mvo> good morning pitti
[08:39] <mvo> hey fabbione
[08:40] <siretart> morning folks
[08:40] <fabbione> hey mvo
[08:40] <fabbione> guys FYI i am batch filing bugs on FTBFS
[08:40] <fabbione> if you get one assigned is because you touched it last
[08:40] <fabbione> so sucks to be you :)
[08:41] <tfheen> doko_: python-setuptools still fails to build.
[08:41] <siretart> tfheen: okay to upload http://librarian.launchpad.net/4821656/nm-patch, as per bug #63975?
[08:41] <Ubugtu> Malone bug 63975 in network-manager "Please sponsor network-manager upload" [High,Confirmed]  http://launchpad.net/bugs/63975
[08:45] <pitti> tfheen: can you please give-back gnat-gps on i386? it should work now with the new tetex-bin
[08:46] <pitti> mooey: I'm here now, you had a question?
[08:47] <tfheen> pitti: done.
[08:48] <tfheen> siretart: is this patch properly tested?  Why aren't the bugs 6.10-targetted?
[08:50] <siretart> tfheen: I didn't follow nm the last months, but followed wpasupplicant, espc. in debian. I can assure you that with kernels > 2.6.14 ndiswrapper will only work with driver backend 'wext', and not with 'ndiswrapper', like the patch does. see also my last comment
[08:50] <siretart> tfheen: I have no idea why this isn't 6.10-targetted, but I think it should be.
[08:51] <siretart> tfheen: nm is currently broken for ndiswrapper users
[08:51] <siretart> since months!
[08:52] <Lathiat> hrm.. for avahi
[08:53] <Lathiat> im thinking we could write a separate init script for the dbus stuff that uses that defaults file
[08:53] <tfheen> siretart: contrary to people's expectations, the release team is not psychic and does not read every bug report and so we rely on people to tell us about bugs they think should be fixed for a release.
[08:53] <Lathiat> and leave /etc/init.d/avahi-daemon to work as expected
[08:53] <Lathiat> perhaps thatl help
[08:53] <siretart> and no, I cannot test it propery myself, because I don't have a bcm43xx based card, for which I could use ndiswrapper. but according to the bug reports, I find it pretty straightforward
[08:53] <Lathiat> (because the dbus system.d stuff is what actually starts avahi on boot)
[08:53] <tfheen> siretart: wouldn't this have been known since before dapper released?
[08:53] <siretart> tfheen: heh, no offense.
[08:53] <pitti> siretart: funny, my airport extreme (without ndiswrapper stuff) stopped working with NM in edgy, too
[08:54] <pitti> siretart: but on powerpc I cannot test ndiswrapper either
[08:54] <siretart> pitti: what driver backend do you use for wpa_supplicant?
[08:54] <pitti> siretart: however, why do you need ndiswrapper for bcm43xx in the first place?
[08:54] <pitti> siretart: I don't use wpasupplicant at all; all WiFis I have access to are open
[08:54] <pitti> (my main one uses Radius)
[08:55] <siretart> pitti: well, with ndiswrapper, you do use wpasupplicant ;)
[08:55] <siretart> s/ndiswrapper/network-manager/
[08:55] <pitti> n-m never picks up an IP for me any more
[08:55] <pitti> with /e/n/i and ifup it works fine
[08:56] <siretart> pitti: yes. because n-m now unconditionally starts up wpa_supplicant. and if the wrong backend get choosen, you get the behavior you see
[08:56] <pitti> ooh
[08:56] <pitti> siretart: well, I'm up for testing then, I guess
[08:56] <pitti> if my use case 'n-m with bcm43xx, open auth' is applicable
[08:57] <tfheen> siretart: find me three users for whom it fixes their problem and no regressions and I'm happy to take it.
[08:57] <siretart> tfheen: bug #42504 was reported before dapper release
[08:57] <Ubugtu> Malone bug 42504 in wpasupplicant "Cannot associate with unencrypted networks using bcm43xx chipset (ndiswrapper driver)" [High,Confirmed]  http://launchpad.net/bugs/42504
[08:57] <tfheen> (preferably today)
[08:57] <siretart> tfheen: I propose to target it for 6.10
[08:58] <fabbione> anyone here that uses reiserfs?
[08:58] <fabbione> (nothing to do with Hans's wife or stuff like that.. i just need to know)
[08:58] <torkel> fabbione: yes
[08:58] <pitti> fabbione: me
[08:58] <siretart> hm. gotta run to work, cu later!
[08:59] <fabbione> torkel: do you have main upload privs?
[08:59] <pitti> siretart: hm, I'm afraid that patch won't make a difference to me, so I'd not be a good tester
[08:59] <torkel> fabbione: no
[08:59] <fabbione> torkel: good.. pitti: you win :)
[08:59] <siretart> pitti: right. I tried to explain the problem to you
[08:59] <pitti> fabbione: I should run away really fast now, shouldn't I?
[08:59] <torkel> fabbione: yay :-)
[08:59] <fabbione> pitti: nah.. just a FTBFS
[08:59] <pitti> fabbione: oh, I have some of them already, toss it over
[09:00] <siretart> pitti: if you want the get n-m working on your notebook, first get wpa_supplicant working. It also supports unencrypted and wep 'secured' wifis
[09:00] <fabbione> pitti: yes i know.. i saw you taking them.. already did :)
[09:00] <pitti> siretart: hm, it's a dependency, I didn't really ever configure wpasupp
[09:00] <siretart> pitti: n-m obviously fails to start up wpa_supplicant correctly
[09:01] <pitti> ah, maybe
[09:01] <siretart> pitti: first, you need to find what parameters are correct, then find out what n-m does wrong, then write a patch
[09:01] <siretart> pitti: this is how this patch in question has been found
[09:01] <pitti> siretart: you forgoth: 0. get an idea what the heck wpasupplicant is doing and why/how :)
[09:02] <pitti> if I find some time, I'll take a look, but no promises
[09:02] <siretart> pitti: it 'establishes' a connection to your wifi, regardless how it is secured
[09:03] <pitti> fabbione: your libapache2-mod-python ftbfs scares me - if the first patch doesn't apply, how it could ever build before?
[09:04] <fabbione> pitti: it seems like autoconf is executed right before that
[09:04] <fabbione> so it might be that it is running when it shouldn't?
[09:04] <pitti> fabbione: ah, autoconf2.60 breakage then
[09:04] <pitti> yay
[09:04] <pitti> fabbione: yup, plausible
[09:05] <Burgundavia> mdz: the reportbug to -users volume is growing again, just fyi
[09:10] <dholbach> good morning
[09:10] <pitti> hey dholbach
[09:10] <dholbach> heya pitti
[09:11] <pitti> tfheen: libapache2-mod-python FTBFS fix uploaded (just removed 'autoconf' call from debian/rules)
[09:11] <tfheen> pitti: ok
[09:16] <mvo_> good morning dholbach
[09:16] <dholbach> heya mvo_
[09:21] <pitti> yay, gnat-gps finally built on i386 \o/
[09:22] <infinity> The one and only time it will? :)
[09:22] <dholbach> pitti: congratulations! :-)
[09:22] <pitti> infinity: no, pdfetex is happy now
[09:22] <infinity> pitti: Oh, excellent.
[09:22] <pitti> dholbach: *hug*
[09:23] <pitti> infinity: I tooked a Kleenex, wiped away tetex' tears, gave it a big hug, and now it wants to play with us again :)
[09:23] <Treenaks> KleeNTeX?>
[09:24] <fabbione> ajmitch: are you actually filing bugs for the FTBFS in universe?
[09:24] <infinity> pitti: Your efforts will not go unpuni^H^H^H^Hrewarded.
[09:24] <fabbione> ajmitch: or are you getting people to look at the logs?
[09:24] <infinity> pitti: Drinks all 'round in Mountain View. :)
[09:24] <pitti> infinity: sounds great, who pays? :)
[09:25] <pitti> Google does, right?
[09:25] <pitti> 'Google Autumn of drink'
[09:25] <infinity> I'm sure I can pay for one or two. :)
[09:26] <pitti> infinity: I look forward to fixing all the FTSUFC bugs then
[09:26] <pitti> (fails to stand up from couch)
[09:27] <infinity> FTSUFC isn't nearly as bad as FTMITTWC (fails to make it to the toilet)
[09:27] <pitti> yeah, I don't like core dumps on the carpet either
[09:27] <infinity> Often shortened to "VIC" (vomits in cab)
[09:27] <fabbione> LOL
[09:28] <infinity> Not going to name any names, though.
[09:28] <infinity> Oh look, more PAGE_SIZE breakage.
[09:29] <infinity> Quel surprise.
[09:33] <pitti> infinity: is it legitimate for a package to build-depend on linux-headers-generic?
[09:34] <pitti> infinity: reiserfsprogs needs asm/unaligned.h, which does not exist any more in /usr/include (did until dapper)
[09:35] <fabbione> pitti: well theorerically yes..
[09:35] <pitti> linux-libc-dev apparently doesn't quite Provide linux-kernel-headers
[09:35] <infinity> pitti: Well, it's either a bug that BenC doesn't provide it, or a bug that reiserfsprogs needs it.
[09:35] <pitti> fabbione: I'm just worried about the name being the same on all arches
[09:35] <fabbione> pitti: that should be ok...
[09:35] <pitti> infinity: well, it needs {get,put}_unaligned macros; that seems quite legitimate to me
[09:36] <pitti> and they aren't anywhere in /usr/include any more (I grepped)
[09:36] <infinity> pitti: We don't have l-h-generic on all arches, of course.
[09:36] <fabbione> infinity: ?
[09:36] <infinity> BenC: Alive?
[09:36] <fabbione> ah right
[09:37] <pitti> infinity: ok, I'll postpone this until this afternoon; providing the include in linux-libc-dev would be the best solution, of course
[09:37] <infinity> pitti: If it feels like legit userspace usage, I'd say the bug is in linux-libc-dev
[09:40] <pitti> fabbione, infinity: ok, I processed the current batch and will fix some other bugs now, but I should have more time to fix FTBFS; so feel free to throw bugs at me
[09:41] <fabbione> pitti: i am ... reload your page :)
[09:41] <pitti> fabbione: ah, nice; you all make them prio: high, right?
[09:42] <fabbione> yes
[09:42] <fabbione> high -> confirmed -> targetted
[09:42] <fabbione> so just reload the milestone page
[09:42] <fabbione> or check for bugs assigned to you
[09:42] <fabbione> the confirmed comes if i can reproduce the failure on more than one arch
[09:45] <dholbach> can somebody sync libopenobex1.0 (bug 65840) and wave through the telepathy-blue upload?
[09:45] <Ubugtu> Malone bug 65840 in libopenobex1.0 "Please sync libopenobex1.0 (1:1.0.0-rel-3.1) from Sid." [High,Confirmed]  http://launchpad.net/bugs/65840
[09:46] <infinity> dholbach: MMkay.
[09:46] <fabbione> dholbach: does that fix the FTBFS?
[09:46] <dholbach> fabbione: yes
[09:46] <fabbione> ok
[09:47] <dholbach> mjg59, BenC, <anybody else who might know>: could you have a look at bug 32415? I'm not sure how to deal with it.
[09:47] <Ubugtu> Malone bug 32415 in bluez-utils "Bluetooth Mouse and Keyboard Broken in Dapper Flight 4 & 6.06 beta 2" [Medium,Needs info]  http://launchpad.net/bugs/32415
[09:47] <pitti> tfheen: bogl uploaded, fixes FTBFS
[09:47] <tfheen> pitti: cheers.
[09:47] <infinity> pitti: You're a champion.
[09:48] <infinity> Can someone give me a status on these?
[09:48] <infinity>   109032 | S- | libapache2-mod-pytho | 3.2.8-1ubuntu2       | 33 minutes
[09:48] <infinity>          | * libapache2-mod-python/3.2.8-1ubuntu2 Component: main Section: python
[09:48] <infinity>   109031 | S- | wine                 | 0.9.22-0ubuntu3      | 5 hours 50 minutes
[09:48] <infinity>          | * wine/0.9.22-0ubuntu3 Component: universe Section: otherosfs
[09:48] <pitti> fabbione: gtk-perl> '1/3649 subtests failed'? c'mon, who measures that precisely? :P
[09:48] <infinity>   109027 | S- | qt4-x11              | 4.2.0-1ubuntu1       | 6 hours 20 minutes
[09:48] <infinity>          | * qt4-x11/4.2.0-1ubuntu1 Component: main Section: libs
[09:48] <tfheen> infinity: mod-python is approved.
[09:48] <infinity>   108976 | S- | telepathy-blue       | <IP_ADDRESS>~darcs2006092 | ten hours
[09:48] <infinity>          | * telepathy-blue/<IP_ADDRESS>~darcs20060926-0ubuntu4 Component: universe Section: net
[09:48] <mjg59> dholbach: I'll take a look at the weekend if nobody beats me to it
[09:48] <infinity>   108971 | S- | gst-plugins-ugly0.10 | 0.10.4-0ubuntu3      | 12 hours
[09:48] <infinity>          | * gst-plugins-ugly0.10/0.10.4-0ubuntu3 Component: universe Section: libs
[09:48] <infinity>   108871 | S- | zope-cmfmember       | 1:1.1b2-1ubuntu1     | 17 hours
[09:48] <infinity>          | * zope-cmfmember/1:1.1b2-1ubuntu1 Component: universe Section: web
[09:48] <fabbione> ARGH
[09:48] <infinity>   108839 | S- | xdg-utils            | 1.0-0ubuntu2         | 19 hours
[09:48] <dholbach> mjg59: Tahsnk so much!
[09:48] <infinity>          | * xdg-utils/1.0-0ubuntu2 Component: universe Section: utils
[09:48] <infinity>   108756 | S- | xdg-utils            | 1.0-0ubuntu1         | 21 hours
[09:48] <infinity>          | * xdg-utils/1.0-0ubuntu1 Component: universe Section: utils
[09:49] <infinity> tfheen: Thanks, accepted.
[09:49] <dholbach> infinity: xdg-utils 1.0-0ubuntu2 is the good one - fixed by Riddell
[09:49] <fabbione> infinity: libapache2-mod-python was uploaded to fix FTBFS approved by tfheen i think
[09:49] <dholbach> infinity: telepathy-blue is a 2 line fix
[09:49] <dholbach> infinity: what does the wine changelog say? I remember \sh_away uploading some sort of fix
[09:50] <infinity>    * Re-apply dropped change from dapper:  (Closes: Ubuntu #63492)
[09:50] <infinity>    + Remove insecure mailcap entries; MS Windows '.exe' files should be run
[09:50] <infinity>      using 'binfmt-misc' support instead.  (Closes: Ubuntu #24829)
[09:51] <dholbach> infinity: \sh_away can do his own cheerleading on those - I'm not sure about them :/
[09:51] <dholbach> I think that gst-plugins-ugly0.10 has a fix of keescook for a rc bug "ac3 way too soft" or something like that
[09:51] <infinity> dholbach: Actually, sladen uploaded that...
[09:51] <dholbach> oh sladen, ok - then I was completely on the wrong track
[09:51] <pitti> dholbach: yeah, that was given 'special importance' from Matt :)
[09:53] <infinity> dholbach: Does telepathy-blue need to wait on that sync I was doing, or are the two completely unrelated?
[09:53] <dholbach> infinity: unrelated
[09:53] <pitti> fabbione: can you please do me a favor? if you assign ftbfs stuff to me, can you please set it to 'in progress'? then it'll land on my special priority page
[09:56] <tfheen> sladen: please provide a debdiff and rationale for the wine changes.  They don't seem to fix and 6.10-targetted bugs.
[09:57] <fabbione> pitti: i am done for now...
[09:57] <fabbione> pitti: will do next time
[09:57] <pitti> thanks
[09:57] <fabbione> pitti: last i assigned was netkit-base
[09:57] <tfheen> dholbach: oh, wine's main.  Your decision, then.
[09:57] <tfheen> s/main/universe/
[09:58] <fabbione> tfheen: i finished mass filing for now...
[09:58] <dholbach> tfheen: as I said: I'm happy for sladen to do his own cheerleading for the changes - I'm not sure about it
[09:59] <fabbione> we just need to wait the buildd's to keep munging sources
[09:59] <dholbach> I just filed bug 65857, which is RC too
[09:59] <Ubugtu> Malone bug 65857 in gnome-panel "Change Help menu link to help.ubuntu.com" [High,Unconfirmed]  http://launchpad.net/bugs/65857
[09:59] <dholbach> it's blocked on the move of the book excerpt
[10:00] <pitti> infinity: can re remove gnutls11 or do you want to keep it for anythin?
[10:00] <infinity> pitti: I think it's pretty, and I like to look at it.
[10:00] <infinity> (Yes, I can remove it)
[10:01] <tfheen> dholbach: just get the change done in the archive and we'll get the website when mdke (or whoever) gets around to that.
[10:01] <infinity> -- edgy/multiverse build deps on libgnutls11-dev:
[10:01] <infinity> ldmud
[10:01] <infinity> pitti: ^^^
[10:01] <dholbach> tfheen: the problem is that clicking on the gnome-panel link will lead to a 404 page
[10:01] <pitti> infinity: yeah, as I said, that's the only package left that doesn't even build with gnutls11
[10:01] <dholbach> tfheen: and the URL is not fixed either
[10:01] <fabbione> pitti: can you please try to build strace on your x86 machine? it fails here with another error
[10:02] <pitti> fabbione: yeah, I just built it on amd64
[10:02] <tfheen> dholbach: can you get that finalised with the doc team or whoever's responsible ASAP?
[10:02] <fabbione> pitti: i386
[10:02] <pitti> fabbione: to confirm the fix with current pkg-create-dbgsym
[10:02] <dholbach> tfheen: I subscribed mdke
[10:02] <pitti> fabbione: I can try building it on ronne
[10:02] <dholbach> tfheen: and reply to the mail on ubuntu-devel@
[10:02] <fabbione> pitti: no, it fails way before that
[10:02] <fabbione> pitti: see /msg
[10:02] <fabbione> pitti: the dbg log stuff was from sparc
[10:03] <infinity> pitti: Err, you mean it's FTBFS anyway, so screw it? :)
[10:03] <pitti> infinity: *shrug*
[10:04] <infinity> pitti: Works for me.  I have no love lots for some random non-free mud.
[10:04] <infinity> s/lots/lost/
[10:05] <infinity> Will remove the following packages from edgy:
[10:05] <infinity>   gnutls11 | 1.0.16-14ubuntu1 | source
[10:05] <infinity> libgnutls11 | 1.0.16-14ubuntu1 | amd64, hppa, i386, ia64, powerpc, sparc
[10:05] <infinity> libgnutls11-dbg | 1.0.16-14ubuntu1 | amd64, hppa, i386, ia64, powerpc, sparc
[10:05] <infinity> libgnutls11-dev | 1.0.16-14ubuntu1 | amd64, hppa, i386, ia64, powerpc, sparc
[10:06] <infinity> ------------------- Reason -------------------
[10:06] <infinity> (adconrad) Requested by pitti, no longer in use, and no urge to support it
[10:06] <infinity> ----------------------------------------------
[10:06] <infinity> pitti: ^^^
[10:06] <infinity> Sane?
[10:06] <infinity> *poof*
[10:06] <pitti> "don't need no triplicate version" :)
[10:06] <tfheen> Riddell: how come your qt4-x11 changelog doesn't list all outstanding changes?
[10:06] <pitti> tfheen: gdome2 FTBFS fix uploaded
[10:07] <infinity> Yeah, while I've not cared much about (insert random thing I haven't cared about here) during edgy's cycle, we really need to dust off ReducingDuplication for feisty.
[10:07] <tfheen> pitti: yay you
[10:07] <tfheen> pitti: you're trying to get us to beer you through the whole conference?
[10:07] <pitti> tfheen: (well, I keep reporting these to you for approval sake; please do tell me if I shuold stop annoying you)
[10:07] <infinity> Reporting them is good.
[10:07] <infinity> I need to know what to shove through the queue.
[10:07] <pitti> tfheen: I'm trying to get me enough appetite for beer for two weeks :p
[10:07] <infinity> And we also need to know who's making us look bad. :)
[10:08] <pitti> well, with me touching all these packages, I also have to merge them *shudder*
[10:08] <infinity> ../../../interfaces/IDirectFBVideoProvider/idirectfbvideoprovider_v4l.c:47:28: error: linux/compiler.h: No such file or directory
[10:08] <infinity> Can someone explain to me why a userspace app wants compiler.h?
[10:08] <infinity> Seriously.
[10:08] <infinity> WTF?
[10:08] <Kamion> Riddell: language packs and metapackages> right - there's no metapackage for live any more, there never was for ship, so no need to upload *-meta for language pack changes
[10:09] <dholbach> LOL - did you see the humping weasel on  http://wiki.ubuntu.com/IceWeaselIcon ?
[10:09] <Chipzz> is there a list of valid values for 'Section' available somewhere?
[10:10] <tfheen> pitti: reporting is good.
[10:11] <infinity> dholbach: There's also the goatse weasel.
[10:12] <Kamion> ajmitch: bzr-svn> yes, that's fine
[10:12] <dholbach> infinity: ouch ouch ouch
[10:12] <tfheen> pitti: we might need to shuffle the merges or something.
[10:12] <pitti> oh, don't worry, I'll cope
[10:12] <fabbione> infinity: dunno.. but i filed a bug on that already and assigned to BenC
[10:12] <tfheen> pitti: who-touched-it-last-maintenance only works for so long, really.
[10:12] <fabbione> infinity: directfb fails in different ways on different arches.. all kernel headers realted
[10:13] <infinity> fabbione: Ahh, well it has two bugs (that and a PAGE_SIZE bug), I found the former only after fixing the latter. :)
[10:15] <fabbione> infinity: if you are going to fix it, you might as well take the bug..
[10:15] <infinity> Yeah, I'll snag it if I fix the compiler.h thing.
[10:15] <fabbione> sounds like a viral form of somekind...
[10:15] <fabbione> i got FTBFS... HIV was not enough
[10:16] <infinity> This whole "build the userspace linux headers from the kernel source" idea would have been great if it had also been accompanied with a "rebuild the archive right after we make the switch".
[10:16] <infinity> Oh well.
[10:17] <fabbione> infinity: we need to do that each time we change kernel or ben uploads.. go figure
[10:18] <Keybuk> infinity: it didn't help that jbailey and BenC conspired to omit headers they found distasteful, etc. :)
[10:19] <infinity> Keybuk: Well, I'm inclined to agree that we shouldn't ship compiler.h (for example), I just wish I'd have known a couple months back. :)
[10:19] <heno> Kamion, tfheen: Tested the Live CD + F5. Everything starts as it should except onboard
[10:19] <infinity> Automatic rebuilding in Soyuz will likely be my number one crusade in Mountan View.
[10:19] <heno> I found the problem and made a patch though
[10:19] <tfheen> heno: yay.  Big one?
[10:19] <heno> bug 65861
[10:19] <Ubugtu> Malone bug 65861 in casper "onboard fails to start with F5 boot" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65861
[10:19] <heno> tfheen: 1 line
[10:20] <tfheen> heno: ok, coolie.  I'll trawl the rest of my morning mail and get it applied.
[10:20] <heno> tfheen: thx!
[10:21] <heno> tfheen: a general question: do all bugs have to be targeted to get patched from now on?
[10:21] <heno> or will other minor fixes go in as well?
[10:23] <infinity> Oh wow, I'm a special kind of retarded.
[10:23] <infinity> Edit file on machine A, build source tree on machine B, wonder why it still fails the same way.
[10:23] <ajmitch> Kamion: thanks
[10:24] <Kamion> Chipzz: should be a pretty current list in debian-policy, though add "metapackages" to it
[10:24] <Keybuk> infinity: when did you last sleep?
[10:25] <Kamion> heno: nice
[10:25] <infinity> Keybuk: I don't understand the question.
[10:27] <tfheen> heno: only targetted bugs.
[10:27] <heno> ok
[10:30] <infinity> I love packages with, like, 5 minutes of autotools buggery followed by about 3 seconds of compiling.
[10:30] <infinity> Something always seems a bit wrong there.
[10:32] <dholbach> Keybuk: welcome to the bluetooth team - can you help with bug 32415?
[10:32] <Ubugtu> Malone bug 32415 in bluez-utils "Bluetooth Mouse and Keyboard Broken in Dapper Flight 4 & 6.06 beta 2" [Medium,Needs info]  http://launchpad.net/bugs/32415
[10:32] <infinity> Wow, is that all it takes?
[10:32] <tkamppeter> hi pitti
[10:32] <pitti> hi tkamppeter
[10:32] <infinity> dholbach: Welcome the "Adam's Bitch" team.  I'll start forwarding you build logs.
[10:33] <dholbach> infinity: you're so funny :-)
[10:33] <tkamppeter> I have added a comment to bug 54277, I have done on Edgy what the original poster was supposed to do on Dapper
[10:33] <Ubugtu> Malone bug 54277 in cupsys "cupsd can't access /var/log/cups/error_log permission denied" [High,Fix released]  http://launchpad.net/bugs/54277
[10:33] <infinity> That's why you love me. :P
[10:33] <ajmitch> fabbione: was going to start filing bugs this evening
[10:33] <tkamppeter> And it seems that Edgy is still suffering the bug.
[10:33] <dholbach> infinity: and because you played together with LTJ Bukem - that's SO cool
[10:34] <pitti> tkamppeter: ah, cupsd itself chowns the files back, it seems
[10:34] <fabbione> ajmitch: ok. keep in mind that there is not much time..
[10:34] <infinity> dholbach: Same show, not TOGETHER. :)
[10:34] <ajmitch> fabbione: I know
[10:34] <pitti> tkamppeter: however, did you use the official edgy packages or upstream's?
[10:34] <infinity> dholbach: But, y'know, we did hang out a bit afterward.
[10:34] <dholbach> infinity: still, that's  S O  cool!
[10:34] <infinity> dholbach: MC Conrad can really (REALLY) inhale coffee. Like.  A lot.
[10:35] <tkamppeter> I have reopened the bug and assigned it as an Edgy milestone
[10:35] <Keybuk> dholbach: that sounds somewhat PPC specific?
[10:35] <fabbione> infinity: did you file a bug on klibc already?
[10:35] <pitti> tkamppeter: well, does it actually harm?
[10:35] <dholbach> Keybuk: one guy said it was on x86 too
[10:35] <infinity> fabbione: jbailey's got the logs for all 5 arches, and has promised me he'd look into it.
[10:35] <tkamppeter> pitti, all official Ubuntu packages coming in from the usual Debian morning gymnastics.
[10:35] <pitti> ok
[10:35] <GNUro> hi all
[10:36] <GNUro> ubuntu live cd contains xfs_repair?
[10:36] <tkamppeter> according to /etc/group cupsys has only read access to error_log and so I cannot imagine how CUPS (running as cupsys) can do the logging.
[10:36] <fabbione> infinity: ok
[10:37] <pitti> tkamppeter: I assume it first opens the files and then chowns them
[10:37] <Treenaks> tkamppeter: it might have opened the file, and then dropped to another uid?
[10:38] <tkamppeter> Treenaks, this was my thought now, too, as the file is growing.
[10:38] <tkamppeter> Can we be sure that the CUPS daemon NEVER loses error_log while it is running?
[10:38] <Treenaks> the only way to "lose" it is to close the filehandle
[10:38] <Treenaks> and I wouldn't do that :)
[10:39] <tkamppeter> Once when I tested faxing with HPLIP, CUPS was not logging at all until I restarted it (I had "LogLevel debug" set in cupsd.conf all the time).
[10:39] <pitti> we should fix it nevertheless, but it doesn't seem that urgent
[10:40] <pitti> tfheen: strace FTBFS uploaded
[10:41] <pitti> tkamppeter: hm, I thought you reopened it? it's still marked as fixed
[10:41] <Kamion> mvo: something's excitingly wrong with apt-get install taskname^
[10:42] <Kamion> mvo: it seems to only handle the first task on the line
[10:42] <tkamppeter> I have set the Edgy task to "Confirmed".
[10:42] <Kamion> mvo: try 'apt-get --dry-run -q -y install edubuntu-live^ kubuntu-live^'
[10:42] <tfheen> pitti: yay.
[10:42] <tkamppeter> Ubugtu, WDYT: bug 54277
[10:42] <Ubugtu> Malone bug 54277 in cupsys "cupsd can't access /var/log/cups/error_log permission denied" [High,Confirmed]  http://launchpad.net/bugs/54277
[10:42] <pitti> tkamppeter: ah
[10:42] <infinity> infinity: Permission to upload a directfb to fix two FTBFS bugs?
[10:42] <infinity> infinity: Sure, go nuts.
[10:42] <infinity> infinity: Thanks.
[10:43] <pitti> lol
[10:43] <infinity> Keybuk: To answer your question, "a long time ago".
[10:44] <Kamion> mvo: your task regex also looks a bit suspicious
[10:44] <Kamion>    snprintf(S, sizeof(S), "^Task:.*[^a-z] %s[^a-z] .*\n", taskname);
[10:44] <Kamion> mvo: doesn't that do weird things if the task you select is at the end of the Task field?
[10:45] <tkamppeter> By the way, is someone here who has one of the printers HP LaserJet 100, 1005, 1018, or 1020?
[10:45] <tkamppeter> Sorry LaserJet 1000 and not 100.
[10:45] <pitti> argh, libgtk2-perl is giving me the creeps
[10:49] <pitti> fabbione: I can't reproduce the libgtk2-perl FTBFS you filed, but the testsuite failed in a different script in exchange
[10:50] <fabbione> pitti: i think it's related to Xvfb somehow
[10:50] <fabbione> i saw different kind of FTBFS
[10:50] <pitti> I'll get to a closer look later
[10:50] <fabbione> one of which Xvfb segfaults if X is running
[10:51] <infinity> pitti: Is that strace upload yours?
[10:51] <infinity> Ahh, so it is.
[10:51] <pitti> infinity: unless someone beat me with it, yes
[10:51] <pitti> infinity: the autoconf mangling for ftbfs fix
[10:52] <infinity> You realise we're all going to get fired in two weeks, with a big note saying "how come you can't fix this many bugs per day during the reast of the cycle?"
[10:53] <DrSpin> I know you guys are hard at work on Edgy and I can't wait but in the meantime I have a problem with GNOME on Breezy -- for no apparent reason GNOME takes a long time to load... here's the post in the main channel that received no response.
[10:53] <infinity> Just so you know.  No pressure to underperform or anything, though.
[10:53] <DrSpin> (01:45:24 AM) DrSpin: DAPPER: Gnome takes FOREVER (3-5 minutes) to start -- tried 386,686,686-SMP kernels and it's faster with SMP (hyperthreading) :: .xsession-errors contains "Gnome-Message: gnome_execute_async_with_env_fds: returning -1" -- google doesn't seem to turn up a logical solution -- tried dpkg-reconfigure gconf2 as well -- any ideas?
[10:53] <pitti> because we are just lazy bastards playing games and watching p0rn during the development cycle, aren't we?
[10:53] <infinity> DrSpin: Just because you didn't get help elsewhere doesn't make this a support channel.
[10:54] <mvo> Kamion: urgh, thanks. let me check that
[10:55] <tfheen> pitti: bogl FTBFS-ed on ia64 and ppc ; http://librarian.launchpad.net/4821823/buildlog_ubuntu-edgy-powerpc.bogl_0.1.18-1.4ubuntu3_FAILEDTOBUILD.txt.gz
[10:55] <pitti> nnng
[10:55] <DrSpin> infinity: I know... but It occurred to me that someone in here might have a quick solution -- rather than wading through conversations about wine and how do I <insert topic on wiki, forums here>
[10:56] <pitti> tfheen: will fix, thanks
[10:56] <infinity> pitti: I'll fix, that's one I've fixed a dozen times already.
[10:56] <pitti> infinity: oh, ok; thanks
[10:57] <infinity> DrSpin: And once that occurs to a few more people, we get no work done here.
[10:58] <DrSpin> infinity: understood... my apologies
[10:58] <pitti> tfheen: netkit-base ftbfs fix uploaded
[10:59] <Kamion> mvo: just trying to trace it with gdb now
[11:03] <seb128> tfheen: http://people.ubuntu.com/~seb128/gdm.debdiff, the diff is not trivial but that's basically a copy of the suspend code for hibernate (the hibernate patch was already copied from the suspend one, some parts were missing though). somebody confirmed on the bug that the patch update works fine for him
[11:04] <infinity> tfheen, pitti: bogl reuploaded.
[11:05] <tfheen> seb128: ew, ugly; it'd be slightly less bad if you didn't include the updated patch headers.
[11:05] <tfheen> seb128: approved though, it doesn't look wrong.
[11:05] <heno> Riddell: the high contrast and magnifier modes look lovely on the Kubuntu Live CD :)
[11:05] <heno> just did some testing
[11:06] <seb128> tfheen: right, will do next time, thank you
[11:07] <Keybuk> thom: around?
[11:08] <ajmitch> Keybuk: is there much in unapproved for universe? I know zope-cmfmember can be put through if it's not already
[11:08] <infinity>   109031 | S- | wine                 | 0.9.22-0ubuntu3      | 7 hours 10 minutes
[11:08] <infinity>          | * wine/0.9.22-0ubuntu3 Component: universe Section: otherosfs
[11:08] <infinity>   108971 | S- | gst-plugins-ugly0.10 | 0.10.4-0ubuntu3      | 14 hours
[11:08] <infinity>          | * gst-plugins-ugly0.10/0.10.4-0ubuntu3 Component: universe Section: libs
[11:08] <ajmitch> thanks infinity
[11:08] <infinity>   108871 | S- | zope-cmfmember       | 1:1.1b2-1ubuntu1     | 19 hours
[11:08] <infinity>          | * zope-cmfmember/1:1.1b2-1ubuntu1 Component: universe Section: web
[11:08] <infinity> ajmitch: ^^^
[11:08] <pitti> to all people having a ThinkPad: do the brightness control keys DTRT? which model do you have? (for bug 61184)
[11:08] <Ubugtu> Malone bug 61184 in hal "Screen brightness buttons don't work properly on Thinkpad Z61T" [Medium,In progress]  http://launchpad.net/bugs/61184
[11:08] <tfheen> pitti: works for me, x40.
[11:09] <infinity> pitti: I have a T43, and it works fine.
[11:09] <pitti> ok, thanks; the bug demands extending the match to other thinkpad models
[11:10] <seb128> tfheen: when would be the limit to upload an yelp package with translations update?
[11:11] <infinity> seb128: Same as the langpack deadline (right after RC), I'd suspect.
[11:11] <seb128> infinity: i:e. today?
[11:11] <infinity> tfheen: Opinion?
[11:11] <seb128> ah, after RC
[11:11] <infinity> seb128: No, final langpacks are going in right AFTER RC.
[11:11] <seb128> ok ok
[11:11] <infinity> (like, immediately after)
[11:11] <pitti> infinity: if you replace 'string="ThinkPad T60"' with 'contains="ThinkPad"' in /usr/share/hal/fdi/policy/10osvendor/10-laptop-panel-mgmt-policy.fdi and restart hal and your session, does it still work? (just to confirm a bug repoerter's claim)
[11:11] <infinity> Ish. :)
[11:12] <tfheen> seb128: it doesn't use langpacks?
[11:12] <pitti> tfheen: not the help files
[11:12] <infinity> tfheen: HTML.
[11:12] <seb128> tfheen: no, translated .xml built at build time
[11:12] <infinity> (Or ML, or whatever)
[11:12] <infinity> XML, even.
[11:12] <infinity> pitti: Why does "Restart hal and your session" sound like it will bugger my desktop? :)
[11:13] <seb128> tfheen: xml files are not language-pack-able atm
[11:13] <Keybuk> tfheen: how badly do we feel that cryptsetup doesn't work?
[11:13] <tfheen> seb128: ok.  The translation deadline was yesterday, any reason you can't upload it today?
[11:13] <pitti> infinity: /etc/dbus/event.d/20hal restart and gdmflexiserver to a different user will work as well
[11:13] <tfheen> Keybuk: with usplash or at all?
[11:14] <infinity> pitti: Alright.
[11:14] <Keybuk> tfheen: at all
[11:14] <seb128> tfheen: no, I did an upload previous week, I just wanted to do another update with updated translations before edgy, I'll do it now if that's ok
[11:14] <pitti> Keybuk: at all? my encrypted usb stick works fine
[11:14] <Keybuk> pitti: you get asked for a password on boot?
[11:14] <pitti> but I guess a dapper->edgy upgrade will break people's computers if they have encrypted hard disk partitiosn
[11:14] <tfheen> seb128: yes, now is fine.
[11:15] <pitti> Keybuk: it's not automounted at boot
[11:15] <tfheen> seb128: I'm going to start building real candidate isos on monday, so it needs to be in before then.
[11:15] <seb128> ok
[11:15] <seb128> this morning should be fine then
[11:16] <Keybuk> pitti: right, those people that have things automounted on boot, now don't, because cryptsetup won't ask for a password
[11:16] <ajmitch> infinity: please accept wine & gst-plugins-ugly0.10
[11:16] <infinity> pitti: That didn't appear to break it.
[11:17] <pitti> infinity: thanks; to be 100% sure, lshal|grep brightness?
[11:17] <tfheen> Keybuk: cryptsetup is universe.  I don't really care.
[11:17] <pitti> (without the ?)
[11:17] <siretart> Keybuk: does cryptsetup work with sysvinit?
[11:17] <infinity> udi = '/org/freedesktop/Hal/devices/acpi_brightness'
[11:17] <infinity>   info.udi = '/org/freedesktop/Hal/devices/acpi_brightness'  (string)
[11:17] <infinity>   org.freedesktop.Hal.Device.LaptopPanel.method_execpaths = {'hal-system-lcd-set-brightness', 'hal-system-lcd-get-brightness'} (string list)
[11:17] <infinity>   linux.acpi_path = '/proc/acpi/ibm/brightness'  (string)
[11:18] <tfheen> pitti: didn't you upload a fixed debug-thingy-mangler?
[11:18] <Keybuk> siretart: if we used sysvinit, we would make the same change as we did to upstart, to make the output get logged to /var/log/boot instead of to the console
[11:18] <infinity> tfheen: He did.  A few.
[11:18] <pitti> infinity: hm, that looks wrong
[11:18] <pitti> tfheen: several
[11:18] <pitti> tfheen: what breaks now?
[11:18] <infinity> pitti: I assure you that it's not wrong. :)
[11:18] <tfheen> pitti: unsure, but gcc-3.3 is still out of date.
[11:18] <infinity> tfheen: On which arch?
[11:18] <tfheen> it might just be that neither Adam nor I gave it back
[11:18] <tfheen> infinity: amd64
[11:18] <pitti> infinity: I expected laptop_panel.brightness_in_hardware=true
[11:18] <tfheen> looked like the debug problem last time
[11:19] <infinity> pitti: Well, if it did that, it'd probably also fail to work.
[11:19] <infinity> tfheen: Retrying, then.
[11:19] <pitti> tfheen: I fixed the gcc-4.0 ftbfs yesterday in pkg-create-dbgsym
[11:19] <siretart> Keybuk: err, sysvinit is still around as alternative, no?
[11:19] <pitti> infinity: ah, well, your's might not be from smbios.system.manufacturer=LENOVO then
[11:20] <infinity> pitti: How can I check?
[11:20] <pitti> infinity: lshal|grep smbios.system.manufacturer
[11:20] <infinity>   smbios.system.manufacturer = 'IBM'  (string)
[11:20] <infinity> Yeah.  I'm old skool, I guess.
[11:20] <pitti> infinity: ok, thanks a lot
[11:22] <Keybuk> siretart: not a supported alternative, no
[11:23] <siretart> Keybuk: ah, but available as alternative in universe, right?
[11:23] <infinity> Still in main, actualy.
[11:23] <Keybuk> infinity: yeah, I just fixed that ;)
[11:23] <infinity> If we really don't want to support people swapping, we should demote it to prove the point.
[11:23] <infinity> Ahh, good. :)
[11:24] <siretart> Keybuk: just for my understanding, would disabling logging (e.g. by disabling /etc/event.d/logd) 'unbreak' cryptsetup?
[11:24] <Keybuk> it's in main because we haven't kicked hppa out of the world yet
[11:24] <Keybuk> siretart: adding "console owner" to /etc/event.d/rcS would fix it
[11:24] <Keybuk> also adding a call to /usr/bin/openvt would fix it
[11:25] <siretart> Keybuk: hm. how about writing an /etc/event.d/ file for cryptsetup, and removing the old initscript?
[11:25] <siretart> s/removing/disabling/
[11:30] <Keybuk> siretart: where would it be run? :)
[11:30] <Kamion> mvo: hmm, never mind, I think that was a false alarm due to a broken local mirror
[11:30] <Kamion> mvo: I do think that the task regex should maybe be more like this?
[11:30] <Kamion>    snprintf(S, sizeof(S), "^Task:.*[^a-z] %s([^a-z] |$).*\n", taskname);
[11:30] <Kamion> or ([^a-z] .*|$)\n
[11:30] <pitti> tfheen: ok to upload a hal with fixed laptop panel FDI to fix bug 61184?
[11:30] <Ubugtu> Malone bug 61184 in hal "Screen brightness buttons don't work properly on Thinkpad Z61T" [Medium,In progress]  http://launchpad.net/bugs/61184
[11:33] <Keybuk> tfheen: ok to approve squashfs FTBFS fix, bug #65826
[11:33] <Ubugtu> Malone bug 65826 in squashfs "FTBFS in edgy" [High,Fix released]  http://launchpad.net/bugs/65826
[11:33] <mvo> Kamion: right, I check that in a bit. a unreleated question, would it be possible to get openoffice.org-l10n-en-us onto the cd? it makes apt majorly unhappy to not have it for cd-cd upgrades (without any networking). it seems like this is the only blocker for this upgrade scenario
[11:34] <pitti> shouldn't it be on the CD anyway?
[11:34] <pitti> mvo: ooo-common depends on it
[11:35] <pitti> mvo: whoops, sorry, it replaces/provides it
[11:35] <mvo> pitti: it isn't currently, only en-gb and en-za and -common
[11:35] <pitti> mvo: right, -en-us doesn't exist any more
[11:35] <seb128> dholbach: will we get ubuntu-docs translations for edgy?
[11:35] <infinity> Perhaps an empty transitional package might make apt happier here?
[11:35] <mvo> pitti: yeah, its  apt being stupid and not understanding that during the upgrade calculation
[11:36] <dholbach> seb128: I don't know - best to ask mdke or people in #ubuntu-doc
[11:36] <infinity> That's often easier than fixing apt bugs. :)
[11:36] <mvo> infinity: we have that in the archive already, we just need it on the CD and apt should be happy
[11:36] <mvo> infinity: oh yes :)
[11:36] <seb128> mdke_: ping?
[11:36] <seb128> dholbach: so nobody from distro team is looking at that? :/
[11:36] <infinity> mvo: Ahh, so we do.
[11:36] <Kamion> mvo: sure, shove it in ship
[11:36] <dholbach> seb128: I can ask the #ubuntu-doc guys
[11:36] <infinity> mvo: Given that it's a tiny package, I say toss it in ship without asking. :)
[11:37] <seb128> dholbach: please do
[11:37] <infinity> mvo: Or, better yet, listen to Kamion. :)
[11:37] <Kamion> same difference ;)
[11:37] <infinity> 'Zactly. :)
[11:37] <infinity> Kamion: Everyone should listen to you when you agree with me, I think that was the point being made. :)
[11:38] <micahcowan> What's a good way to prepare for the Mtn View conference? Read up on a slag of specs? Are some better to read up on than others?
[11:38] <Treenaks> micahcowan: beer. definitely beer.
[11:38] <micahcowan> :)
[11:39] <tfheen> pitti: yes
[11:39] <pitti> tfheen: done
[11:39] <tfheen> Keybuk: yes, please.
[11:39] <Kamion> infinity: :-)
[11:40] <Keybuk> micahcowan: I find the best preparation is sleeping for a few days in advance, because it's something you don't get to do much of whilst there
[11:41] <micahcowan> :-)
[11:42] <dholbach> seb128: <pepsiman> 07:58 < mdke> the translations are seriously error-ridden bt, <pepsiman> entities, tags were translated/moved, <pepsiman> eg "translating &thankyou; to &gracias;", <pepsiman> 07:59 < mdke> I sent an angry email to the translators about it
[11:43] <seb128> dholbach: that sucks a lot, maybe we should revert to dapper ubuntu-docs package :p
[11:43] <dholbach> seb128: propose that to the ubuntu-doc team
[11:43] <pepsiman> mdke is trying to fix it, but it may take a while
[11:44] <seb128> we don't have a while
[11:44] <pitti> ouch @ &gracias;
[11:44] <dholbach> seb128: I'll watch them throwing stones at you
[11:44] <pepsiman> seb128: he said "several hours"
[11:45] <mvo> Kamion: I updated "ship" now, thanks! do we have a plan yet when we build the next set of cd-test-images?
[11:46] <Kamion> mvo: they're still on the daily schedule
[11:46] <Kamion> but I think I'll probably do another build later today
[11:46] <mvo> Kamion: cool, thanks. if you could announce that in the channel here, that would be perfect
[11:47] <Kamion> sure
[11:48] <Keybuk> fabbione: bug #65838 is a bug in xserver-xorg-dev
[11:48] <Ubugtu> Malone bug 65838 in wacom-tools "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/65838
[11:48] <Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/tasksel.diff, http://people.ubuntu.com/~cjwatson/tmp/pkgsel.diff - both in unapproved
[11:48] <Keybuk> the headers contain two different definitions of xd86usleep, one as a macro that expands it to just usleep() and the other that defines it as a function that takes unsigned long
[11:49] <Kamion> those fix my two remaining RC bugs
[11:49] <fabbione> Keybuk: i didn't dig all of them .. just noted FTBFS and assigned to who touched last. You are welcome to reassign it :)
[11:50] <fabbione> Keybuk: i am still mass-filing
[11:50] <infinity> Kamion: Thanks, I was waiting for someone to take iptables. :)
[11:50] <fabbione> Kamion: congratulation on iptables
[11:51] <fabbione> Kamion: now.. look in a mirror and ask yourself why i didn't assign it to myself :P
[11:51] <Kamion> heh
[11:51] <Kamion> if I get stuck I can always give it back to nobody; nobody's a really excellent hacker
[11:51] <fabbione> Kamion: i am sure nobody will fix that
[11:51] <fabbione> Kamion: otherwise assign it to pitti.. he seems to be in a good mood today
[11:52] <pitti> MUST...KILL..ALL..FTBFS...*nnnngh*
[11:53] <ajmitch> pitti: we'll try & keep up the bug filing for you then :)
[11:55] <infinity> Don't tell anyone!
[11:55] <seb128> keescook: thanks for the gst ac3 fix ;)
[11:55] <mooey> pitti, howdy. can i pm please?
[11:55] <pitti> mooey: sure
[11:55] <pitti> mooey: I'll answer shortly, brb
[11:56] <ajmitch> hm, I wonder why gtk-sharp-unstable is still in the archive
[11:57] <Keybuk> tfheen: ok to upload wacom-tools to fix FTFBS bug #65838
[11:57] <Ubugtu> Malone bug 65838 in wacom-tools "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/65838
[11:59] <tfheen> Kamion: why does tasksel still depend on aptitude then?
[12:01] <tfheen> Kamion: pkgsel looks good to me
[12:02] <Kamion> tfheen: for the manual selection mode
[12:02] <Kamion> the versioned dependency is for --visual-preview
[12:03] <Kamion> you know, for iptables, it might be best to just sync with Debian
[12:03] <Kamion> +  * updated to Linux kernel 2.6.17 source
[12:03] <tfheen> Kamion: tasksel> approved
[12:03] <tfheen> Keybuk: go ahead
[12:04] <infinity> Kamion: If Debian's iptables builds, I'm certainly not 100% against that idea.
[12:04] <Kamion> it would still need to be hacked to use linux-libc-dev, so it's not a trivial option
[12:05] <Kamion> I'll see how much work it is to fix up our current version
[12:06] <infinity> tfheen: https://launchpad.net/+builds/+build/255478 <-- Enjoy.
[12:07] <Keybuk> I worry about how much time and code went into the queue tool to make it print things like "a minute", "3 hours", etc.
[12:07] <infinity> tfheen: Were there any other suspicious "this looks like P-a-s breakage" things on the out-of-date list?
[12:07] <tfheen> infinity: who-ho.
[12:07] <tfheen> infinity: none I saw, no.
[12:07] <infinity> Keybuk: That's common code throughout all of LP (perhaps from an underlying python lib even)
[12:07] <Kamion> Keybuk: instead of like "3:01" which would be much more useful and readable anyway
[12:08] <infinity> pitti: Was that hal upload approved?
[12:08] <infinity> tfheen: ^^^
[12:08] <tfheen> infinity: yes.
[12:08] <infinity> Accepted, then.
[12:09] <dholbach> tfheen: ok, to upload  http://daniel.holba.ch/temp/bluez-utils.debdiff ?
[12:09] <tfheen> infinity: directfb still blows up on amd64 and i386
[12:09] <infinity> tfheen: Seriously?  There were THREE bugs in there?
[12:09] <infinity> Serves me right for only testing on PPC.
[12:11] <infinity> Ooo, ugly.
[12:11] <tfheen> dholbach: any reason you can't rather fix it by fixing bluez-gnome?
[12:11] <tfheen> dholbach: if we're to have an upload for it, I'd rather have a fixed b-g, tbh
[12:11] <fabbione> infinity: test sparc too please. that's where i found the bug
[12:11] <dholbach> tfheen: it's a fix in bluez-gnome CVS - I can imagine that it's not small
[12:11] <infinity> fabbione: sparc built fine.
[12:12] <fabbione> infinity: hmmm ok
[12:12] <pitti> re
[12:13] <dholbach> tfheen: I'll have a look
[12:24] <pitti> ogra: bah, currently esdsink is sorted below osssink for some reason
[12:24] <ogra> heh
[12:24] <ogra> silly
[12:29] <tfheen> fabbione: could you please fix the ttf-bpg-georgian-fonts ftbfs?
[12:38] <fabbione> tfheen:
[12:39] <fabbione> tfheen: looking at it but the missing file is crucial
[12:39] <dholbach> tfheen: ok, tried bt-applet cvs, works fine, seems to not display the icon, if you have no hci<n> device, which is a first step - the code diff is ~900 lines -- it's supposed to have a gconf key, but the gconf schemas seem to not have been written yet, so you can only control it by gconf, if you added the key manually
[12:40] <Keybuk> Oct 12 12:18:55 rcS: setupcon: The console-chars utility from the console-setup
[12:40] <Keybuk> font can load only fonts witn 8 pixel width matrix.  Please install the setfont
[12:40] <Keybuk> utility from the kbd package.
[12:40] <Keybuk> Kamion: ^
[12:41] <fabbione> tfheen: no, we need mjg59 to give us the missing file.. it's an XML mess
[12:41] <tfheen> dholbach: not displaying the icon if you don't have a HCI adapter is a one-line change.
[12:42] <Kamion> Keybuk: yes, don't use one of the fonts in question then
[12:42] <Kamion> Keybuk: bug filed, wontfix until edgy+1
[12:42] <tfheen> fabbione: it's completely missing from the source, not just misplaced?
[12:42] <fabbione> tfheen: missing
[12:43] <tfheen> fabbione: ok. :-/
[12:43] <tfheen> fabbione: thanks
[12:43] <Keybuk> Kamion: which fonts are in question?
[12:43] <fabbione> tfheen: checking again..
[12:43] <Keybuk> Kamion: this is just an ordinary dapper->edgy upgrade
[12:43] <fabbione> tfheen: yeah it's missing..
[12:43] <fabbione> i don't know how to write stuff like that.. sorry
[12:44] <fabbione> Keybuk: ttf-bpg-georgian-fonts
[12:44] <tfheen> fabbione: ok, no problem.  I'll try to get it from Matthew
[12:44] <Kamion> Keybuk: hmm, I'll check whether the switch back to VGA affects this
[12:44] <tfheen> fabbione: Keybuk/Kamion's font discussion is about console-setup, not the georgian fonts.
[12:44] <Keybuk> Kamion: "switch back to vga" ?
[12:44] <tfheen> dholbach: I wonder if we should make it only display the icon when it wants to blink it
[12:44] <fabbione> oh sorry
[12:44] <Keybuk> Kamion: the console doesn't appear to be running a framebuffer
[12:45] <infinity> tfheen: brltty/{powerpc,ia64} rescued.
[12:46] <dholbach> tfheen: hm, that's a diff we'd have to maintain post-edgy
[12:46] <tfheen> infinity: cheers.
[12:46] <dholbach> tfheen: better make it not show and discuss options with upstream for edgy+1
[12:46] <Kamion> Keybuk: you're missing the point slightly but I would have to explain too much of console-setup's internals to explain why :-)
[12:46] <Kamion> Keybuk: upgrade to what vintage of edgy?
[12:46] <tfheen> dholbach: upstream thinks it should always display a useless icon?
[12:47] <Keybuk> Kamion: that reboot would have been due to an update
[12:47] <Kamion> Keybuk: and could you put your /etc/default/console-setup somewhere for me?
[12:47] <dholbach> tfheen: he wants to have it controllable by a gconf policy
[12:47] <Keybuk> http://people.ubuntu.com/~scott/console-setup
[12:47] <Kamion> Keybuk: (whether the console is actually running a framebuffer is not relevant here)
[12:47] <tfheen> dholbach: but you can't interact with it in any way except get the "about" dialog up.
[12:48] <Kamion> ah, terminus 12x6 is the default Terminus font
[12:48] <Kamion> that's irritating
[12:48] <dholbach> tfheen: I absolutely agree with you and I think it should be fixed
[12:48] <Kamion> Keybuk: ok, thanks, I'll see if I can munge this on upgrade somehow
[12:48] <dholbach> tfheen: but we should make an easy fix for the release
[12:48] <Keybuk> Kamion: my laptop appears to have FONTSIZE="16" there
[12:49] <tfheen> dholbach: is upstream around now?  As in, if I give you a diff, can you get him to agree to it?
[12:49] <Keybuk> ooh, I like TerminusBoldVGA :p
[12:49] <Kamion> yeah, that's weird, 16 is the default
[12:49] <dholbach> tfheen: it's 'holtmann' in launchpad
[12:50] <Kamion> I think there may be a really subtle use-of-debconf bug here
[12:51] <dholbach> tfheen: he's on the bluetooth team, so he'll be notified of changes to bug 65645
[12:51] <Ubugtu> Malone bug 65645 in bluez-gnome "Die systray icon die!" [Undecided,Fix released]  http://launchpad.net/bugs/65645
[12:51] <Kamion> because at some point it's obviously picked the first option rather than the one in Default:
[12:51] <infinity> Ngh, the gcc-3.3/amd64 failure isn't pitti's fault, I should have read the log before I wasted an hour on the build retry.
[12:51] <infinity> doko__: http://librarian.launchpad.net/4822231/buildlog_ubuntu-edgy-amd64.gcc-3.3_1%3A3.3.6-13ubuntu1_FAILEDTOBUILD.txt.gz
[12:51] <infinity> doko__: While you're at it, gcc-3.3 is FTBFS on ia64 too, but for different reasons.
[12:52] <Kamion> Keybuk: so do you reckon I can reproduce this by installing dapper and upgrading to edgy?
[12:52] <tfheen> dholbach: he's not on IRC?
[12:52] <pitti> infinity: we only need it to keep libstdc++5-3.3 for commercial apps, right?
[12:52] <Keybuk> Kamion: should do; this was installed fresh dapper from the CD.  kept up to date.  and then upgraded to edgy this week
[12:53] <dholbach> tfheen: I don't know - he replied to a bunch of bugs, but I never talked to him on IRC and he has no IRC nick registered in his launchpad account
[12:53] <Keybuk> I generally make a point of not touching anything in /etc as well
[12:53] <infinity> pitti: Pretty much, yeah.
[12:53] <infinity> pitti: It's also somewhat handy for GCC regression testing, but that argument's beginning to wear thin.
[12:53] <Kamion> Keybuk: all right, thanks
[12:53] <tfheen> dholbach: ok.  I'll whip up a patch and see if that's acceptable.
[12:53] <dholbach> tfheen: super
[12:54] <Keybuk> I have a vmware image that I only upgraded yesterday
[12:54] <Keybuk> let me check that
[12:54] <doko_> infinity: yes, low priority.
[12:54] <Keybuk> that's i386, but not sure that makes a difference or not
[12:54] <Kamion> I don't *think* it should
[12:54] <Kamion> Keybuk: the other is amd64?
[12:55] <dholbach> tfheen: hang on, he just attached a patch to the bug
[12:55] <Keybuk> Kamion: yes
[12:55] <Keybuk> Kamion: my vmware install and upgrade exhibits the same bug
[12:55] <Keybuk> so this is definitely replicatable
[12:55] <Kamion> apart from hppa (which asks for model) and sparc (which uses the sun4 model and asks for model), all the architectures we support are equivalent from console-setup's point of view, I think
[12:56] <dholbach> tfheen: seems he extracted the strictly necessary bits from the cvs checkout
[12:56] <Keybuk> that's an image with dapper installed from CD and updated.  and then updated to edgy from the repos
[12:56] <Kamion> ok, great, thanks, I'll just get my local mirror up to date and try that
[12:56] <Kamion> Keybuk: dapper installed from d-i or ubiquity?
[12:56] <Keybuk> Kamion: u6y
[12:57] <Kamion> righto, in progress
[12:58] <tfheen> dholbach: that patch mixes features with something not exactly what we want.
[12:58] <tfheen> dholbach: do you agree that the sane way for the icon to work is to display an icon when you can interact with it?
[12:59] <tfheen> dholbach: so since you can't put you BT device into discoverable mode or similar yet, it should only be there when somebody tries to pair.  Agreed?
[01:00] <dholbach> you can set it to discoverable mode with the version in CVS, but yeah, that's one possibility that makes sense
[01:01] <dholbach> having it around, when you have a hci device makes sense for some people too, but that's something we should have in edgy+1 with upstream's blessing.... I'm sure that if you attach a patch, Marcel will reply on it
[01:01] <tfheen> dholbach: I'm not going to pull in the version from CVS.  I want the icon to behave sensibly as described above.  Neither "display always", "display when there are adapters present", "never ever display icon" doesn't match any of those
[01:01] <tfheen> dholbach: I'm happy to have this conversation with upstream, sure.
[01:02] <tfheen> I just want us to agree to a sensible behaviour before writing code.
[01:02] <pitti> ogra: hm, I'm pretty stuck with this; gstreamer does not seem to load the esdsink automatically any more, so it doesn't even have a chance of registering itself
[01:02] <ogra> pitti, gah
[01:02] <dholbach> tfheen: for edgy, I agree, it makes sense
[01:02] <ogra> pitti, well, then my only chance is to set the gconf key, but thats darn ugly
[01:03] <dholbach> tfheen: for edgy+1, it should be configurable, and I'm sure that upstream will consider your case as another gconf option, if we talk to him about it
[01:03] <pitti> ogra: oh, I can still ask the mighty seb128, maybe he has an idea
[01:03] <dholbach> tfheen: (and we can make it default)
[01:05] <infinity> kylem: Why is palo arch:any?
[01:05] <fabbione> infinity: in the hope to take over the world? :)
[01:05] <pitti> ogra: hm, sometimes it *is* registered, and sometimes not; bwah
[01:06] <ogra> thats weird
[01:06] <infinity> fabbione: No one in their right mind would want that.
[01:06] <infinity> fabbione: It may not be as bad as silo, but it's pretty bad. :)
[01:06] <ogra> is theer a commandline to show the registered one ?
[01:07] <pitti> ogra: I didn't find one, I hacked gstreamer0.10 to printf() gst_element_register() invocation
[01:07] <ogra> ah
[01:07] <pitti> ogra: it doesn't have an useful gstreamer logging call
[01:07] <pitti> hi BenC
[01:07] <pitti> BenC: kernel panic mode on
[01:07] <fabbione> infinity: eheh
[01:08] <tfheen> fabbione: I've seen many weird misspellings, but never seen "grub2" misspelled as "palo".
[01:08] <Kamion> infinity: palo is used by debian-cd to make hppa CDs bootable. Please don't make it Architecture: hppa.
[01:08] <infinity> Kamion: I wasn't planning on it.
[01:08] <Kamion> anyway, that's probably why
[01:08] <infinity> Kamion: More to the point, I was wondering if it's worth caring that it's currently FTBFS on all arches.
[01:09] <infinity> Kamion: I'll care anyway. :)
[01:09] <Kamion> I think so, given that we use it on lithium on i386
[01:09] <Kamion> no, amd64
[01:09] <fabbione> tfheen: it's a matter of Itaglish/Ameritalian/Engrish
[01:12] <doko_> heh, Fri Oct 13 13:13:13 CEST 2006
[01:12] <doko_> where's the black cat?
[01:15] <HiddenWolf> sorry ;)
[01:16] <pitti> doko_: ugh
[01:17] <tfheen> dholbach: http://err.no/patches/bluez-gnome-disable-icon-when-inactive.diff
[01:19] <tfheen> (actually, reload, I reworked it slightly)
[01:21] <infinity> Kamion: Now that P-a-s works correctly, any objections to removing old pbbuttons binaries on !powerpc?
[01:25] <Kamion> infinity: no - done
[01:26] <dholbach> tfheen: looks good - seems to work ok
[01:27] <mvo> tfheen: http://people.ubuntu.com/~mvo/tmp/dhcp_2.0pl5-19.4ubuntu1.debdiff <- debdiff of the just uploaded dhcp
[01:27] <dholbach> tfheen: do you want to attach it to the bug report and get feedback or do you just want to go with it?
[01:27] <tfheen> dholbach: if you could get Kamion or infinity to review it and then upload, that'd be good.
[01:27] <tfheen> dholbach: or you could attach it to the bug and wait a couple of hours.
[01:27] <tfheen> I'd like it in before the weekend.
[01:27] <dholbach> tfheen: it's YOUR patch :-))
[01:28] <dholbach> I won't get blamed for uploading your patch ;-)
[01:28] <tfheen> pft.
[01:28] <dholbach> sure, I'll attach it :)
[01:28] <tfheen> just sponsor the upload or something.
[01:28] <tfheen> or I could upload it; point is I don't want to dig too much into single issues -- I'm trying to have something resembling a grand view of the situation.
[01:29] <kylem> infinity, because it can run on anything else to generate netboot images.
[01:29] <infinity> kylem: Yeah, Kamion said as much.
[01:30] <infinity> kylem: You're too slow. :P
[01:31] <kylem> it's like 7:30, i've not slept, cut me some slack. :)
[01:31] <dholbach> tfheen: done
[01:31] <tfheen> dholbach: did you get anywhere with the kubuntu bluetooth problems?
[01:33] <dholbach> tfheen: RockMan (kmobiletools upstream) said that using the patch and setting kbluepin as default passkey-agent works for him, another kubuntu user confirmed that - however it doesn't work for me yet - so I want to give it some more testing
[01:33] <dholbach> tfheen: but I'm on it
[01:34] <tfheen> dholbach: thanks; enjoy your lunch. :-)
[01:34] <dholbach> gracias - hope you lunch soon too
[01:37] <pitti> wb seb128
[01:38] <infinity> Kamion: Same for gtkpbbuttons, gtkpbbuttons-gnome, and powerprefs, if you didn't already nail the rdeps.
[01:38] <seb128> pitti: re
[01:39] <Kamion> infinity: oops, yeah, done
[01:40] <pitti> ogra: aaaaaaaaah
[01:41] <pitti> ogra: I got it
[01:41] <ogra> what is it ?
[01:41] <pitti> ogra: that is, I know the reason
[01:41] <pitti> ogra: rm ~/.gstreamer-0.10/registry.x*
[01:42] <ogra> where does that come from ? gst-register ?
[01:42] <pitti> ogra: in short: gst reads all the plugins and caches their ranks in that XML file
[01:42] <pitti> ogra: so the second time you run gst, it only reads the cache, and thus the esdsink cannot re-register itself with a different priority
[01:42] <ogra> aha !
[01:42] <ogra> hmm, tricky
[01:43] <pitti> ogra: once you rm the cache and set LTSP_CLIENT, then the cache will be regenerated with highest rank, and esdsink is always used
[01:43] <pitti> seb128: ^ this gstreamer caching behaviour breaks our alsadmixsink/ltsp sink behaviour; do you know an easy way to disable caching for a particular sink?
[01:43] <seb128> no
[01:43] <seb128> #gstreamer guys are responsive usually though
[01:44] <seb128> just ask on the chan
[01:44] <ogra> we could make gst respect LTSP_CLIENT
[01:44] <pitti> ogra: the alternative would be to have an ltspesdsink which only succeeds for LTSP_CLIENT
[01:44] <ogra> so it does skip the chache
[01:44] <pitti> ogra: that would be even cleaner
[01:44] <pitti> but a bit code-intrusive
[01:44] <pitti> at this point
[01:44] <ogra> likely
[01:44] <pitti> seb128: will do, thanks
[01:44] <seb128> np
[01:51] <dholbach> tfheen: update: kubuntu patch looks good, works, needs some integration and some more testing
[01:53] <dholbach> tfheen: (bluez-utils thingie) - i'll test some more after lunch
[01:53] <_ion> dholbach: Please see bug #65897.
[01:53] <Ubugtu> Malone bug 65897 in edgy-wallpapers "Redundant "widescreen" wallpaper in the package" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65897
[01:54] <dholbach> _ion: will do it, when i get back from lunch - thanks for that!
[02:00] <janimo> heno, Riddell: in comments of bug 58836 I see separate options for sticky keys and mouse keys. Is that the current state?
[02:00] <Ubugtu> Malone bug 58836 in gfxboot-theme-ubuntu "F5 options need to be linked to the right casper options" [Undecided,Fix released]  http://launchpad.net/bugs/58836
[02:01] <janimo> they can be separate in xubuntu as well but I'd like to keep the options close to ubuntu/kubuntu
[02:02] <Riddell> janimo: yes, they're separate
[02:03] <janimo> tfheen: http://paste.ubuntu-nl.org/26587/ permission to upload a one liner fix for gxine
[02:03] <Kamion> FYI: app-install-data-commercial, language-pack-kde-lo, language-pack-kde-lo-base, and libiddev-dev are all newer in dapper-updates than in edgy
[02:04] <Kamion> libiddev-dev may be NBS, checking
[02:04] <pitti> Kamion: uh, seems that KDE dropped that language
[02:05] <pitti> Kamion: I can do a no-change upload with a higher version number if required, but it would not change much
[02:05] <janimo> Riddell: so you have v1/v2/m1/m2 now for kubuntu even though same bug does not mention m2 right?
[02:05] <Kamion> pitti: I'd like edgy to be >= dapper-updates for all packages
[02:05] <Riddell> if the % translated goes below a certain figure it doesn't get released
[02:05] <Kamion> pitti: or else we could remove that package
[02:05] <Riddell> janimo: yeah, one of the m's doesn't get used :(
[02:06] <Kamion> (from edgy)
[02:06] <pitti> Kamion: then removing is prefered
[02:06] <Kamion> ok, will do
[02:06] <pitti> thanks
[02:06] <tfheen> janimo: you've tested this?
[02:06] <janimo> tfheen: sure
[02:07] <tfheen> janimo: approved, but I think this is the last of such minor fixes I'll accept.
[02:07] <janimo> tfheen: I always pbuild and run tests
[02:07] <Kamion> mvo: can you ensure that edgy has at least as new a version of app-install-data-commercial as dapper-updates, please?
[02:08] <janimo> tfheen: thanks
[02:08] <infinity> tfheen: As the acting RM, do you have any objections to the complete obliteration of edgy/hppa from the face of the planet?
[02:08] <seb128> tfheen: http://people.ubuntu.com/~seb128/evolution-data-server.debdiff, the patch is http://bugzilla.gnome.org/attachment.cgi?id=71859 and used by the e-d-s FC package for a month
[02:08] <heno> janimo: KDE has the kmouse tool, which is used in #4 I guess, but does nor run onBoard yet
[02:08] <infinity> tfheen: Cause it's about to happen in ~22 minutes. :)
[02:08] <tfheen> infinity: press da button!
[02:09] <tfheen> infinity: will lamont kill us?
[02:09] <janimo> heno: do you think for xubuntu I should separate mouse and sticky keys as well?
[02:09] <infinity> tfheen: No.   You could. We don't in Ubuntu just now
[02:11] <Kamion> mvo: thanks
[02:11] <tfheen> seb128: ok, approved.  Now, can we please stop attacking !milestone bugs?
[02:11] <Kamion> libiddev-dev will be NBSed once archive-cruft-check tells me I can
[02:11] <Kamion> and that'll be edgy strictly >= dapper-updates everywhere
[02:11] <janimo> heno, tfheen: I'd also like to upload a new onboard with sync to latest bzr , fixes it to work in xfce (where there;s no nautilus)) bug 65251
[02:11] <Ubugtu> Malone bug 65251 in onboard "work without nautilus" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65251
[02:11] <seb128> tfheen: I've no milestoned bugs left on my list but ok, I'll pick some non assigned ones from now
[02:12] <tfheen> seb128: there are plenty of ftbfs-es for instance.
[02:12] <seb128> yeah, doing that next
[02:12] <tfheen> thanks
[02:13] <infinity> pitti: Which FTBFS were you looking at that looked like a linux-libc-dev bug?
[02:14] <pitti> infinity: reiserfsprogs
[02:14] <infinity> Right, thanks.  BenC's awake, want to poke him in #-kernel?
[02:14] <pitti> infinity: bug 65842 (some details there)
[02:14] <Ubugtu> Malone bug 65842 in linux-source-2.6.17 "FTBFS in edgy: no asm/unaligned.h" [High,Needs info]  http://launchpad.net/bugs/65842
[02:14] <pitti> infinity: sure
[02:14] <BenC> pitti: Checking it
[02:17] <infinity> tfheen: queue filling up again, and I've not been watching the channel.
[02:17] <infinity>   109125 | S- | gxine                | 0.5.7-1ubuntu6       | seven minutes
[02:17] <infinity>          | * gxine/0.5.7-1ubuntu6 Component: main Section: graphics
[02:17] <infinity>   109124 | S- | yelp                 | 2.16.1-0ubuntu3      | 22 minutes
[02:17] <infinity>          | * yelp/2.16.1-0ubuntu3 Component: main Section: gnome
[02:17] <infinity>   109123 | S- | adept                | 2.1.1ubuntu3         | 32 minutes
[02:17] <infinity>          | * adept/2.1.1ubuntu3 Component: main Section: kde
[02:17] <infinity>   109110 | S- | dhcp                 | 2.0pl5-19.4ubuntu1   | 47 minutes
[02:17] <infinity>          | * dhcp/2.0pl5-19.4ubuntu1 Component: main Section: net
[02:17] <infinity> tfheen: Status/approval of each?
[02:17] <heno> janimo: are you putting onboard on the CD?
[02:17] <tfheen> infinity: gxine is ok, yelp's ok.
[02:18] <ajmitch> nothing new for universe? we must be slacking
[02:18] <tfheen> who uploaded adept and dhcp?
[02:18] <pitti> ogra: hmm, messing with the cache reading in gstreamer does not work unfortunately
[02:18] <ogra> :(
[02:18] <ajmitch> tfheen: mvo said he did earlier
[02:18] <pitti> ogra: and the #gstreamer guys didn't have a good hint apart from 'original patch was flawed'
[02:18] <janimo> heno: sure, and know how to start it from casper
[02:18] <lritter> hey there
[02:19] <ajmitch> sorry, mvo did dhcp
[02:19] <infinity> tfheen: There's also the qt4-x11 upload still kicking around, and Riddell seems alive now. :)
[02:19] <heno> janimo: you know or need to know
[02:19] <lritter> there is a bug which i'd personally like to see fixed, as it broke 6.06 font rendering
[02:19] <tfheen> infinity: dhcp is approved.
[02:19] <janimo> heno: I know :)
[02:19] <pitti> ogra: so, we are down to two options: (1) fix it properly with an ltspesdsink (much code, although mostly copy&paste), or (2) add a nasty hack to ltsp scripts to rm the cache at a good point
[02:19] <tfheen> Riddell: did you upload adept and qt4-x11?
[02:19] <lritter> it's in 6.06 since quite a time now, and i spent a lot of time getting this heard
[02:19] <janimo> heno: I am just trying ot make the 30accessibility diffs small so I only send the pacth once
[02:19] <heno> janimo: without at-spi I take it
[02:19] <janimo> for all xubuntu buts
[02:20] <tfheen> lritter: if it's the alternative font renderer patch for freetype, it's too late.
[02:20] <heno> right
[02:20] <ogra> pitti, hmm, the second option doesnt seem right
[02:20] <lritter> tfheen: what do you mean?
[02:20] <janimo> heno: I'd lik to start at-spi as well, it would mean xubutu can do all 5 options as ubuntu
[02:20] <tfheen> lritter: what do you mean by what do I mean?
[02:20] <pitti> ogra: well, 'right' is only the first option, but I'm not sure that tfheen is happy with it
[02:20] <heno> janimo: cool!
[02:20] <janimo> heno: but I do not know how to install at-spi if an a11y option is chosen but otherwise keep it and gnome deps off the installed system
[02:20] <lritter> tfheen: https://launchpad.net/distros/ubuntu/+source/freetype/+bug/60760
[02:20] <Ubugtu> Malone bug 60760 in freetype "turning off autohinting has no effect" [Undecided,Unconfirmed]
[02:20] <ogra> pitti, yeah, i'd guess so
[02:20] <janimo> heno: stacjed filesystems was supposed to help but it is not implemented
[02:21] <janimo> heno: another way would be to use whatever ubiquity does with optional langage supports but had not time to look at how it is done
[02:21] <janimo> Kamion: maybe you can point me to the right code to read ^^^
[02:21] <heno> janimo: oh right, we just have it installed regardless
[02:22] <ogra> pitti, i think a ltsp-sound script in /etc/X11/Xsession.d probably ... hmm
[02:22] <janimo> Kamion: to get xubuntu-at- installed only if a11y is selected, or installed anyway but not copied over to the disk
[02:22] <heno> janimo: btw, if you add yourself here https://launchpad.net/people/onboard/+members I'll approve and you can sync XFCE stuff yourself :)
[02:23] <tfheen> lritter: no patch and we're in RC freeze and not critical for the release in any way => too late.
[02:23] <lritter> rc freeze for 6.06?
[02:23] <tfheen> no, 6.10
[02:23] <lritter> how is that possible
[02:23] <lritter> ok, but the bug got in inbetween 6.06
[02:23] <lritter> when 6.06 was already released
[02:23] <lritter> so how can this not be considered?
[02:23] <siretart> zul: what compiler is used for compiling ubuntu kernel images? 'standard' /usr/bin/gcc or special settings?
[02:23] <janimo> heno: I joined :)
[02:24] <tfheen> lritter: uh, I'm not sure what you mean by "in between 6.06"
[02:24] <kristog> hello
[02:24] <lritter> tfheen: the 6.06 live cd renders the font correctly
[02:24] <lritter> tfheen: after installation, fonts are also correctly being rendered
[02:24] <lritter> tfheen: after a package update however, fonts are incorrectly being rendered
[02:24] <agutierr> hello all: someone knows why nfs doesnt mounts on boot on dapper ?
[02:24] <heno> janimo: always handy to have someone with main upload right on the team :)
[02:24] <tfheen> lritter: if it's something which only affects 6.06, that should be noted in the bug report.
[02:25] <lritter> tfheen: so how is it possible that a release final can change essentially in behaviour,
[02:25] <lritter> tfheen: but can not be fixed ;)
[02:25] <mvo> tfheen: dhcp is already upload, see http://people.ubuntu.com/~mvo/tmp/dhcp_2.0pl5-19.4ubuntu1.debdiff
[02:25] <tfheen> lritter: does it affect 6.10?
[02:25] <tfheen> mvo: yes, I just approved it.
[02:25] <lritter> tfheen: good question. is 6.10 edgy?
[02:25] <tfheen> lritter: yes.
[02:26] <lritter> tfheen: i can't tell... i had a look at edgy a few months ago, and it blasted my system ;)
[02:26] <lritter> tfheen: i wanted to have another look at it when its sufficiently stable
[02:26] <tfheen> lritter: it should be sufficiently stable now.  We're in release freeze.
[02:26] <lritter> tfheen: sounds great
[02:26] <mvo> tfheen: thanks. to fix #65850 we need a updated python-egenix-mx-base-dev, the debdiff is at: http://librarian.launchpad.net/4823082/egenix-mx-base_2.0.6ubuntu1-1ubuntu5.debdiff, then psycopg only needs a give-back
[02:26] <tfheen> lritter: and you can always test a live cd.
[02:26] <janimo> heno: Ok ping me when it needs uploading in the future :)
[02:26] <lritter> tfheen: a good argument indeed.
[02:26] <pitti> ogra: I added the status to the bug; tfheen, if you have a minute, can you please give your RM opinion on bug 65690?
[02:26] <Ubugtu> Malone bug 65690 in gst-plugins-good0.10 "should select the esdsink for LTSP_CLIENTs" [Medium,In progress]  http://launchpad.net/bugs/65690
[02:26] <lritter> tfheen: i will check and let you know.
[02:27] <heno> janimo: thanks :)
[02:27] <mvo> tfheen: I just did iptraf as well, debdiff is at #65832
[02:27] <Kamion> janimo: can the xubuntu-at-* packages be installed on the live CD?
[02:27] <Kamion> janimo: as in, just shoved into the xubuntu live seed
[02:27] <tfheen> pitti: nuke the cache, imo.
[02:28] <janimo> Kamion: yes they can
[02:28] <tfheen> pitti: (why is it even cached?)
[02:28] <pitti> tfheen: just to speed up startup, I guess
[02:28] <janimo> Kamion: if it can be figured out how to purge them from the disk as with languages
[02:28] <Kamion> janimo: right, then do so and make ubiquity-hooks/30accessibility call 'apt-install xubuntu-at-foo xubuntu-at-bar' (or whatever) if the packages should remain installed
[02:28] <janimo> Kamion: along with their deps though
[02:28] <Kamion> trivial
[02:29] <Kamion> (and yes, I mean apt-install, not apt-get install)
[02:29] <tfheen> infinity,Kamion: either of you please review and approve casper when it hits unapproved.
[02:29] <janimo> Kamion: so the purge will  take the gnome libs away like apt-get autoremove?
[02:29] <lritter> tfheen: nevertheless, congratulations
[02:29] <Kamion> janimo: yes
[02:29] <infinity> tfheen: Do you have a diff I can peruse, so I don't have to fetch it?
[02:29] <janimo> Kamion: great
[02:29] <Kamion> not autoremove though, it just removes them
[02:30] <pitti> ogra: are you fine with adding this to the LTSP session scripts?
[02:30] <Kamion> same code as is used for language packs
[02:30] <heno> Kamion: should I update the ubiquity hooks script to match the changes I made to the casper script or would you prefer to do it?
[02:30] <Kamion> heno: I'll have a look now
[02:30] <heno> ok
[02:30] <tfheen> infinity: http://err.no/tmp/foo.diff
[02:30] <ogra> pitti, commented on the bug
[02:31] <pitti> ogra: (don't forget the ~ in the path :) )
[02:31] <Kamion> heno: in future feel free to do it, though
[02:31] <ogra> ouch
[02:31] <ogra> right :)
[02:31] <tfheen> mvo: is that egenix-mx-base the debdiff against what's in Ubuntu or what's in Debian?
[02:31] <tfheen> mvo: and why doesn't the changelog list the changes from the Debian package?
[02:31] <heno> Kamion: ok, cool
[02:31] <infinity> tfheen: Your whitespace usage sucks, otherwise it looks fine.
[02:31] <lritter> is there any newer iso release than sept 28?
[02:32] <Kamion> lritter: yes, the daily builds
[02:32] <tfheen> infinity: I need to apply a suitable tool to emacs to teach it about indentation.
[02:32] <Kamion> infinity: the whitespace use in lots of casper sucks
[02:32] <lritter> are they acceptable? ;)
[02:32] <Kamion> lritter: maybe
[02:32] <lritter> :PP
[02:32] <mvo> tfheen: this is a merge of the debian changes (the update to the new python policy) to the ubuntu package. our package does not have done the python-polciy yet and that causes the FTBFS for the dependencies of this
[02:32] <lritter> ok i try one
[02:32] <Kamion> there is no newer "blessed" release
[02:32] <Kamion> the next one will be the release candidate
[02:33] <Kamion> heno: committed
[02:33] <heno> cool!
[02:34] <infinity> tfheen: casper accepted.
[02:34] <Kamion> diff from casper script to ubiquity hook:
[02:34] <Kamion> -                        gct "-s -t string /desktop/gnome/background/primary_color \#666666"
[02:34] <Kamion> -                        gct "-s -t string /desktop/gnome/background/secondary_color \#7F7F7F"
[02:34] <Kamion> +                        gct -s -t string /desktop/gnome/background/primary_color \#666666
[02:34] <Kamion> +                        gct -s -t string /desktop/gnome/background/secondary_color \#7F7F7F
[02:34] <Kamion> those quotes should die, right?
[02:34] <Kamion> I think they'll break setting of those options
[02:35] <tfheen> they shouldn't be needed at least.
[02:35] <heno> Kamion: I think so yes
[02:35] <heno> Kamion: did you catch that last 1 line change from this morning?
[02:35] <Kamion> ok, they're gone
[02:35] <Kamion> heno: no
[02:35] <tfheen> heno: I just uploaded a version with that change.
[02:35] <heno> bug 65861
[02:36] <Ubugtu> Malone bug 65861 in casper "onboard fails to start with F5 boot" [Undecided,Fix released]  http://launchpad.net/bugs/65861
[02:36] <pitti> ogra: ok, bug updated. sorry :/
[02:36] <heno> makes onboard work
[02:36] <Kamion> yes, that's fixed in casper 1.75, but the ubiquity hook is out of sync
[02:36] <heno> ok
[02:36] <ogra> pitti, fine with me
[02:37] <tfheen> mvo: you didn't answer why the changelog doesn't list the changes from Debian we still have?
[02:37] <heno> tfheen: yeah, that's what I just saw :)
[02:37] <janimo> heno: are these deps which I set a while ago still valid for current edgy? magnifying:  at-spi, gnome-orca, gnome-mag
[02:37] <janimo> heno: I see the speech packages are still in universe?
[02:38] <janimo> espeak, speech-dispatcher
[02:38] <heno> janimo: those are valid, yes
[02:38] <heno> janimo: we are just using gnome-speech this time
[02:38] <mvo> tfheen: we could sync it, but our version number is higher than the debian version number - should I update the changelog to explain this?
[02:38] <tfheen> infinity: didn't you upload a new directfb?
[02:39] <Kamion> janimo: you'll need to guard the apt-install call I suggested with a check for whether the xubuntu-at-* packages are installed
[02:39] <infinity> tfheen: Waiting on feedback from BenC.
[02:39] <Kamion> otherwise it'll install them for all derivatives
[02:39] <heno> plan to use speech-dispatcher and espeak in Edgy+1
[02:39] <infinity> tfheen: Which is waiting in line behind pitti. :)
[02:39] <janimo> Kamion: even if the packages are not on those CDs?
[02:39] <tfheen> infinity: 'k
[02:39] <infinity> tfheen: (mess with agpgart headers and non-userspace typedefs)
[02:40] <tfheen> mvo: but is the debdiff the still-remaining diff to Debian or the diff to our current version?
[02:40] <lritter> so, what does it mean, when edgy is frozen? what will be fixed?
[02:40] <Kamion> janimo: apt-install would try to install them (possibly from the network); whether it succeeds or not is a different matter
[02:40] <pitti> infinity: neeeeext, please
[02:40] <Kamion> janimo: we only want its queueing/preventing-removal behaviour, so check whether they're installed first
[02:40] <infinity> Kamion: Can you think of a clever way to find out-of-dates accross the whole dist, without invoking britney for the task?
[02:40] <tfheen> mvo: iptraf fix > approved
[02:41] <Kamion> infinity: quinn-diff maybe?
[02:41] <infinity> Kamion: I'm curious how many other things like pbbuttonsd stopped building when P-a-s started working.
[02:41] <infinity> Yeah, quinn-diff would do.
[02:41] <mvo> tfheen: oh, sorry, I misunderstood your question. its the diff between of ubuntu version
[02:41] <infinity> I may actually have a copy on drescher, come to think of it.
[02:41] <mvo> tfheen: thanks
[02:41] <heno> janimo: speech depends on Festival and gnome-speech ATM
[02:41] <tfheen> mvo: ok, approved.
[02:42] <mvo> tfheen: do you want a diff between debian<->ubuntu as well (just to be sure)?
[02:42] <tfheen> mvo: that should just be the changelog if we could just as well have synced, isn't it?
[02:43] <mvo> tfheen: yes it is
[02:43] <tfheen> mvo: if so, no need for that debdiff.  Upload away.
[02:44] <mvo> tfheen: thanks, I will make the changelog a bit more verbose and upload
[02:44] <tfheen> doko_: your eunuchs upload a month ago ftbfs on amd64.
[02:45] <infinity> tfheen: Did it die with an incompatible pointer type complaint?
[02:45] <tfheen> infinity: yes.
[02:45] <infinity> tfheen: If so, it died on ia64 with the same thing, and I assume it's not 64-bit clean.
[02:46] <tfheen> infinity: it used to build.
[02:46] <doko_> tfheen: no, it didn't build
[02:47] <tfheen> doko_: the build log is available now.
[02:47] <pitti> tfheen: reisersprogs FTBFS fix uploaded
[02:47] <tfheen> pitti: cheers
[02:47] <heno> Kamion: did the ubiquity/Orca fix make it into this morning's Live CD? I don't see it working here
[02:47] <doko_> tfheen: it was available before as well
[02:48] <infinity> That's curious that it dies now with no code changes.  Woo.
[02:48] <tfheen> doko_: not when I retried the build, no.  Then it nukes the build record.
[02:50] <tfheen> Keybuk: your gmp upload some time ago ftbfs on sparc.
[02:50] <Keybuk> gmp?
[02:50] <Keybuk> and s/sparc/amd64/ ?
[02:51] <mvo> tfheen: virkey (#65846) is fixed too, debdiff in the bugreport. do you actually want this kind of irc feedback :) ? or will you scan the uploads anyway and its just noise?
[02:51] <tfheen> uh, yes, amd64.
[02:51] <Keybuk> I don't think that was my upload ?
[02:52] <tfheen> mvo: shouldn't that be python-all-dev in the build-deps?
[02:52] <tfheen> oh, sorry, it is
[02:52] <tfheen> I'm clearly blind
[02:52] <mvo> too much reviewing :)
[02:52] <tfheen> Keybuk: LP claims otherwise.
[02:52] <Keybuk> tfheen: LP still thinks I've uploaded most of the archive at some point or other
[02:52] <infinity> He synced it in his own name. :)
[02:52] <Kamion> heno: should've done, check 'dpkg -l ubiquity', should be 1.2.0
[02:53] <Keybuk> right
[02:53] <Keybuk> I tended to do that ;)
[02:53] <Keybuk> or mom output
[02:53] <Keybuk> etc.
[02:53] <tfheen> Keybuk: any chance you could give it a shot nevertheless?
[02:53] <Keybuk> the fact it's got "unstable" in the distribution string is a bit of a give-away
[02:53] <Keybuk> tfheen: it's failing in some assembly code, so, err, no
[02:53] <Keybuk> :)
[02:53] <Keybuk> I'll see if current Debian builds on amd64
[02:53] <tfheen> thanks
[02:54] <tfheen> infinity: is gtk-sharp2 a PaS bug victim or is it NBS on sparc?
[02:54] <Keybuk> infinity: this looks like an autosync
[02:54] <Keybuk> or probably a hammer while autosyncing
[02:54] <tfheen> mvo: virtkey > approved.
[02:55] <tfheen> mvo: and yes, I want those since I use my backlog when infinity or Colin asks what I've approved. :-P
[02:55] <Riddell> tfheen: yes, I uploaded adept and qt4, adept fixes a High priority targetted bug, and qt4 was approved by mdz at the meeting yesterday
[02:56] <infinity> tfheen: Likely the former.
[02:56] <tfheen> Riddell: even so, please do make diffs and post links to them here, else I won't know if they're ok or not.
[02:56] <heno> Kamion: oh, I'm an idiot: I booted with something other than v3 and then had orca and at-spi started manually. Will test properly now ;p
[02:56] <tfheen> Riddell: so, if I could have an adept debdiff, that'd be good.
[02:57] <infinity> tfheen: Yeah, it builds arch"all packages, so it's malcc's P-a-s bug.
[02:57] <tfheen> infinity: qt4-x11 is approved.
[02:57] <heno> ubiquity is indeed 1.2.0
[02:57] <infinity> tfheen: Will perform more DB surgery to fix.
[02:57] <tfheen> infinity: cheers.
[02:58] <tfheen> crimsun: your john upload ages ago FTBFS
[02:59] <tfheen> uh, that klibc ftbfs on amd64 is.. special.
[02:59] <infinity> tfheen: gtk-sharp2/sparc rescued in the DB, qt4-x11 accepted.
[02:59] <seb128> is anybody looking at libcairo-perl ftbfs yet?
[02:59] <infinity> tfheen: klibcs is FTBFS on all arches, jbailey's handling it.
[03:00] <Keybuk> tfheen:
[03:00] <tfheen> infinity: no, latest just failed on ia64 and amd64
[03:00] <Keybuk>  gmp  (2:4.2.1+dfsg-3) unstable; urgency=high
[03:00] <Keybuk>    * Disable fat support for amd64, as it is broken upstream.  Thanks to
[03:00] <Keybuk>      Steinar H. Gunderson for initial version of patch.  Closes: #376353.
[03:00] <Keybuk>  -- Steve M. Robbins<EMAIL_ADDRESS>Mon, 17 Jul 2006 23:15:30 -0400
[03:00] <Keybuk> tfheen: ok to sync that from snapshot.d.n?
[03:00] <tfheen> Keybuk: yes.
[03:01] <Keybuk> tfheen: will check it builds first ;)
[03:01] <Kamion> exception request
[03:01] <infinity> tfheen: No, it fails everywhere, the autorebuild says so.
[03:01] <tfheen> Keybuk: please do.
[03:01] <infinity> tfheen: Just cause it once built doesn't mean it does now. :)
[03:01] <tfheen> infinity: pft.  Details. :-P
[03:01] <tfheen> infinity: I'm still trawling outofdate.
[03:02] <infinity> Yeah, I can tell. :)
[03:02] <infinity> tfheen: I've handed off directfb to BenC, if you're keeping tabs on who's got what.
[03:03] <BenC> tfheen, anybody: I'm uploading kernel 10.33, which is a two-liner fix for the build failure of the approved upload I did last night
[03:03] <tfheen> BenC: go ahead.
[03:04] <janimo> tfheen: permission to upload new snapshot of onboard from bzr, debdiff http://paste.ubuntu-nl.org/26594/
[03:05] <BenC> tfheen: Upload is done, should show any minute
[03:06] <Keybuk> tfheen: it builds
[03:07] <tfheen> janimo: while I appreciate adding accessibility stuff to xubuntu, we're way past FF.
[03:08] <janimo> tfheen: I uploaded this before FF as well but you accidentally reverted it in 0.83 ;)
[03:09] <janimo> tfheen: and it does not break ubuntu/kubuntu
[03:09] <tfheen> janimo: oh well, it looks decent enough.  Approved.
[03:09] <janimo> tfheen: and I could only start on a11y stuff ofr xubuntu once a11y in casper is settled for ubuntu which has only happened recently
[03:10] <janimo> I have a casper 30acceesibility patch in the works, I hope it will be ok to get that in before RC
[03:10] <janimo> tfheen: thanks
[03:11] <infinity> BenC: accepted.
[03:11] <janimo> doko_ : do you know what happened in edgy vs dapper that now language support packages bring in openoffice-core and writer?
[03:13] <infinity> janimo: Argh, the dummy openoffice.org-l10n-en-us package doesn't depend on "| language-support-en"
[03:13] <infinity> doko_: ^^^
[03:14] <seb128> bug #65845 is fixed with the new version to Debian
[03:14] <Ubugtu> Malone bug 65845 in libcairo-perl "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/65845
[03:14] <BenC> infinity: Thanks
[03:14] <seb128> we have 0.3 and Debian has 1.01
[03:14] <seb128> nothings Depends on libcairo-perl
[03:14] <seb128> should we just sync the new version?
[03:14] <seb128> or should I rather backport the fix?
[03:14] <infinity> seb128: If nothing depends on it, why is it in main?
[03:15] <Kamion> build-depends IIRC
[03:15] <infinity> libgtk2-perl yeah.
[03:15] <seb128> I'm fine backporting the fix
[03:15] <seb128> but the new version basically update for the libcairo API too
[03:15] <infinity> seb128: If it's simple, please do.
[03:16] <seb128> ok
[03:16] <seb128> we will have binding not matching the current cairo API
[03:17] <Kamion> seb128: will libgtk2-perl need to be rebuilt?
[03:17] <seb128> Kamion: bug #65849, I've not looked yet, but I expect so
[03:17] <Ubugtu> Malone bug 65849 in libgtk2-perl "FTBFS in edgy" [High,In progress]  http://launchpad.net/bugs/65849
[03:17] <seb128> I think that's a similar issue
[03:19] <heno> Kamion: OK, so if you kill the running version of Orca first and then launch install, it works perfectly. If Orca is already running as the user, then the root version falls over when you start install
[03:20] <heno> I'm fairly happy with that though, I guess we can describe it in notes
[03:20] <janimo> infinity: would adding that dep fix other language support packages not bringing in OOo?
[03:20] <janimo> infinity: the Ooo package names and deps confuse me
[03:20] <heno> These at-spi with multiple user issues really need fixing upstream anyway
[03:21] <Riddell> tfheen: http://kubuntu.org/~jriddell/tmp/adept.debdiff
[03:22] <Kamion> heno: ugh, I'm not sure I'm happy with that; if we're doing that then either ubiquity should be fixed to do that or I should remove the hack from ubiquity and the notes should just say to kill your own orca, run orca as root, then start ubiquity
[03:22] <Kamion> half-and-half just seems confusing
[03:22] <doko_> infinity: ok, will fix it
[03:22] <Kamion> heno: given the lateness of this, I'm quite tempted to just back out the ubiquity change
[03:22] <infinity> janimo: All the OOo langpacks need to have the alternate dep back to language-support-$foo.
[03:22] <infinity> doko_: Can you give  aonce-over and make sure all the others are right?
[03:22] <infinity> doko_: ISTR having some issues with this during the dapper release too. :)
[03:22] <heno> Kamion: I agree. It's starting to become many layers of hacks here
[03:23] <heno> Kamion: It's quite an easy workaround to describe really
[03:23] <tfheen> infinity: adept approved.
[03:23] <tfheen> Riddell: thanks.
[03:23] <infinity> tfheen: accepgted.
[03:23] <infinity> But spelled correctly.
[03:23] <doko_> $ apt-cache show openoffice.org-l10n-de |grep ^Dep
[03:23] <doko_> Depends: openoffice.org-l10n-common (>= 2.0.4~rc3), openoffice.org-common (>= 2.0.4~rc3) | language-support-de, openoffice.org-common (<< 2.0.5) | language-support-de
[03:23] <doko_> infinity: ^^^
[03:23] <doko_> looks okay
[03:24] <infinity> doko_: Yeah, -en is the one that's not okay.
[03:24] <infinity> doko_: Just wanted you to make sure all the others were alright too, that's all. :)
[03:24] <tkamppeter> pitti, doko_, mvo, mdz, HPLIP in Ubuntu is a complete mess, especially we have lost scanning support by unsuccessfully trying to get fax on board (bug 65908). I am trying to redesign the packaging now without all the obscure Debian changes, having only the original tarball and a debian/ directory, no non-debian/ changes in the .diff.gz file.
[03:24] <Ubugtu> Malone bug 65908 in hplip "libsane-hpaio.so not shipped anymore" [Undecided,Confirmed]  http://launchpad.net/bugs/65908
[03:24] <AlinuxOS> doko_, OO.org -ka localisation works great (menu entries too)! Well done!
[03:25] <doko_> AlinuxOS: thanks
[03:25] <AlinuxOS> doko_, a big thank you ! ;)
[03:25] <mvo> tfheen: it looks like we need a rebuild of tetex-bin to fix bug #65839
[03:25] <Ubugtu> Malone bug 65839 in tetex-bin "FTBFS in edgy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65839
[03:25] <doko_> mvo: we just had a rebuild ...
[03:25] <tfheen> mvo: we just had a rebuild
[03:26] <mvo> tfheen: oh, cool - then doygen just needs a give-back
[03:26] <AlinuxOS> is it possible to request
[03:26] <AlinuxOS> opps (wrong channel)
[03:26] <tfheen> mvo: no, it's a false positive from the rebuild testing.
[03:26] <AlinuxOS> mjg59, ping.
[03:26] <Kamion> tfheen: liblockfile FTBFS uploaded:
[03:26] <Kamion>   * glibc 2.4 added an eaccess declaration to unistd.h; rename our eaccess
[03:26] <Kamion>     function to eaccess_write (closes: Malone #65837).
[03:26] <Ubugtu> Malone bug 65837 in liblockfile "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/65837
[03:27] <tfheen> Kamion: approved.
[03:27] <mvo> tfheen: right
[03:27] <heno> Kamion: so yes, just back out the change. I'll work out the smoothest way to work around it and post it on access.u.c
[03:28] <Kamion> ok
[03:28] <Kamion> backed out in my bzr branch
[03:29] <AlinuxOS> Kamion, hello, is it possible to request a package bug fix in this period of freeze ?(or maybe in the near future?)
[03:31] <Kamion> AlinuxOS: depends on the bug
[03:31] <Kamion> and the fix
[03:32] <Trae> https://launchpad.net/bugs/22336
[03:32] <Ubugtu> Malone bug 22336 in acpi-support "laptop overheats when performing CPU intensive tasks." [High,Confirmed]
[03:32] <Trae> I am on Mandriva 2007 and that bug doesn't seem to affect this distro (didn't bother Gentoo 2006 either)
[03:33] <Ubugtu> Mandriva bug 2007 in Installation "Switching to alternate screens during install crashes X" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2007
[03:33] <AlinuxOS> Kamion, where can I send a mail with bug explanation ? (it's better via mail than IRC)
[03:33] <Trae> Is there something I can check here that might help fix it in Ubuntu?
[03:33] <Trae> maybe if we check how they have stuff here, then it might help fix it
[03:33] <Trae> I'd hate to think this bug won't be fixed for Edgy
[03:33] <Trae> as it'll mean almost a whole year of my laptop being unusable
[03:33] <Trae> (with Ubuntu)
[03:34] <Trae> and I can't stand any othe distro but Ubutu
[03:34] <Trae> so I'm caughtbetween a rock and a hard place
[03:34] <Trae> heh
[03:34] <Kamion> AlinuxOS: ubuntu-devel@lists (if main or restricted) or ubuntu-motu@lists (if universe or multiverse)
[03:34] <AlinuxOS> Kamion, thanks
[03:34] <BenC> yay, directfb was a one-liner fix
[03:35] <Trae> I can't code or anything but will do whatever is necessary to help debug for this issue.  (follow commands a developer gives me)
[03:35] <doko_> tfheen, Kamion: please approve the debdiffs at http://people.ubuntu.com/~doko/edgy/, all fixing build failures
[03:35] <seb128> Kamion, tfheen, infinity: http://paste.ubuntu-nl.org/26596/ fixes the libcairo-perl ftfbs, I think we should consider syncing 1.01 from Debian though, it's update for the cairo 1.2 API changes and to Debian unstable,testing without open bug
[03:35] <seb128> let me know if I should upload the patched version or if you prefer a sync
[03:36] <bddebian> Howdy
[03:36] <doko_> tfheen: for python-4suite, please see #65890
[03:36] <seb128> hi bddebian
[03:36] <bddebian> Hello seb128
[03:37] <Kamion> Keybuk: hmm, how long ago did you actually do that dapper->edgy update?
[03:37] <Kamion> Keybuk: I tried it just now and it didn't reproduce
[03:37] <BenC> tfheen, infinity: directfb is uploaded
[03:37] <Trae> no love for me today
[03:37] <Trae> heh
[03:37] <Kamion> Keybuk: could it have been before Thu, 12 Oct 2006 02:42:15 +0100 + build time?
[03:38] <Keybuk> Kamion: yes, likely before then
[03:38] <Keybuk> Tuesday probably
[03:38] <tfheen> bugs 65890
[03:38] <Ubugtu> Malone bug 65890 in python-4suite "UVF exception, fixing FTBFS to build with python2.5" [Medium,Confirmed]  http://launchpad.net/bugs/65890
[03:38] <Trae> Keybuk: hey Scott, you see my above ramblings?
[03:38] <Keybuk> Trae: no?
[03:38] <Kamion> Keybuk: ok, so it won't happen on a current upgrade, but it wouldn't hurt to try to clean up the mess
[03:39] <tfheen> doko_: looks good to me, upload away.
[03:39] <Trae> Keybuk: I'm in Mandriva 2007 right now... and (just as Gentoo) it doesn't have the laptop overheating issue.  Is there anything we could look at how they do stuff to perhaps fix it in Ubuntu?
[03:39] <Ubugtu> Mandriva bug 2007 in Installation "Switching to alternate screens during install crashes X" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2007
[03:39] <doko_> tfheen: what exactly, debdiffs plus python-4suite?
[03:39] <Trae> Keybuk: having large numers of laptops not being able to function wth Ubuntu seems like a really bad thing
[03:39] <Trae> :(
[03:40] <lritter> laptops not overheating is cpu power not used!
[03:40] <tfheen> doko_: your debdiffs look good to me.  The UVF exception is for universe and already approved by dholbach
[03:40] <seb128> doko_: I took the libperl-cairo ftbfs bug ownership since I'm working on it
[03:40] <doko_> seb128: thanks
[03:40] <seb128> np
[03:40] <Keybuk> Trae: no idea, sorry; way above my level now
[03:40] <Trae> lritter: shutting down in the middle of a compile or working  is not fun
[03:40] <Trae> who's area is this?
[03:40] <Keybuk> Trae: the best thing to do would be to see if a pristine upstream kernel over heats
[03:41] <seb128> pitti: I'll fix the libgtk2-perl ftbfs too if you are not on it yet
[03:41] <Keybuk> and if not, figure out which of our kernel patches causes the overheating
[03:41] <Trae> Or is there anyonein Ubuntu that paricularly cares about this
[03:41] <Trae> ?
[03:41] <Keybuk> or if so, which patch in mandrive causes it to *not* overheat
[03:41] <mvo> tfheen: did you approved egenix-mx-base already? I have no mail so far
[03:41] <Keybuk> Trae: BenC or mjg59 ... but without you sending your laptop to them, there's not much they can do
[03:41] <Trae> Keybuk: great queston.  I just make things pretty[tm]
[03:41] <Trae> :)
[03:41] <Kamion> mjg59 has already been asking questions on that bug
[03:42] <Keybuk> Trae: at this point, you're way beyond "oh, edit /etc/default/acpi_support and set OVERHEAT_LAPTOP to 'no'" :)
[03:42] <Trae> I can give them shell access
[03:42] <Trae> Keybuk: :(
[03:42] <tfheen> mvo: I guess I need to poke infinity or Kamion about the queue state.
[03:42] <Trae> le suckxor
[03:42] <Kamion>   109147 | S- | directfb             | 0.9.24-4ubuntu3      | three minutes
[03:42] <Kamion>          | * directfb/0.9.24-4ubuntu3 Component: main Section: libs
[03:42] <Kamion>   109138 | S- | onboard              | 0.85                 | 28 minutes
[03:42] <Kamion>          | * onboard/0.85 Component: main Section: gnome
[03:43] <Kamion>   109135 | S- | virtkey              | 0.41ubuntu1          | 48 minutes
[03:43] <Kamion>          | * virtkey/0.41ubuntu1 Component: main Section: python
[03:43] <Kamion>   109132 | S- | egenix-mx-base       | 2.0.6ubuntu1-1ubuntu | 53 minutes
[03:43] <Kamion>          | * egenix-mx-base/2.0.6ubuntu1-1ubuntu5 Component: main Section: interpreters
[03:43] <Kamion>   109127 | S- | iptraf               | 3.0.0-1ubuntu2       | 1 hour 20 minutes
[03:43] <Kamion>          | * iptraf/3.0.0-1ubuntu2 Component: main Section: net
[03:43] <Keybuk> Trae: ondemand didn't fix it for you then?
[03:43] <Trae> Keybuk: nope
[03:43] <tfheen> Kamion: directfb, onboard, virtkey, egenix-mx-base are all approved.
[03:43] <Trae> it seemed to have, but then died again not long after
[03:43] <Keybuk> Trae: ok, does a pristine upstream kernel overheat?
[03:44] <tfheen> Kamion: iptraf too is ok.
[03:44] <Trae> Keybuk: no clue, I really hate (and don't know much about) compiling kernel
[03:44] <Kamion> ok
[03:44] <Trae> that's so 1998
[03:44] <Trae> heh
[03:44] <Keybuk> Trae: unfortunately, at this point, it sounds like we have to track down a single line of kernel code that causes your laptop to overheat
[03:44] <Keybuk> which means probably about 300,000 kernel compiles and tests
[03:45] <doko_> seb128: do you want to have a look at gst-python? it's apparently a pygtk incompatibility
[03:45] <Trae> Keybuk: ok, so now tell me the bad news
[03:45] <Trae> :P
[03:45] <Keybuk> Trae: you've only got a week left to live to do it all in
[03:45] <Trae> hahahahaha
[03:45] <Kamion> log2(300000) surely ;-)
[03:45] <Trae> Keybuk: Your going down with me, I ain't going alone!
[03:45] <Trae> :)
[03:45] <Keybuk> Trae: nothing to do with me
[03:46] <Trae> heh
[03:46] <Trae> hmm
[03:46] <Trae> where does BenC live?
[03:46] <BenC> Trae: Virginia
[03:46] <Keybuk> Hicksville, Merkia
[03:46] <Trae> or the other gentleman you spoke of.
[03:46] <Trae> BenC: oh there you are
[03:47] <seb128> doko_: what bug number?
[03:47] <Trae> hmm
[03:47] <Trae> I doubt I could go very long without my laptop.
[03:47] <Trae> as it's where I do all my work from.
[03:48] <doko_> seb128: https://launchpad.net/distros/ubuntu/+source/gst-python/0.8.4-3build1
[03:55] <BenC> tfheen: Fixed iptraf uploaded (bug 65832)
[03:55] <Ubugtu> Malone bug 65832 in iptraf "FTBFS in edgy [sparc at least] " [High,Fix released]  http://launchpad.net/bugs/65832
[03:55] <BenC> hmm, maybe already fixed
[03:56] <tfheen> BenC: that's already fixed, yes.
[03:56] <BenC> tfheen: Ok, drop my upload then :)
[03:56] <infinity> Shall I reject that? :)
[03:57] <infinity> BenC: Does that mean you gave up on directfb? :)
[03:57] <BenC> infinity: I uploaded a fixed directfb already
[03:57] <tfheen> infinity: Kamion accepted that ten minutes ago
[03:57] <infinity> Oh, indeed.
[03:57] <infinity> Awesome.
[03:58] <infinity> BenC: Err, did you test directfb on amd64 too?  I suspect the FTBFS there may have been unique. :/
[03:58] <BenC> infinity: No, just i386
[03:58] <infinity> Can you test it now, for kicks?
[03:59] <infinity> (I don't have an amd64 system here anymore)
[03:59] <dholbach> tfheen: ok to upload a fix for bug 65897?  http://daniel.holba.ch/temp/edgy-wallpapers.debdiff ? (will save 1,3 M)
[03:59] <Ubugtu> Malone bug 65897 in edgy-wallpapers "Redundant "widescreen" wallpaper in the package" [Medium,Confirmed]  http://launchpad.net/bugs/65897
[04:00] <tfheen> dholbach: with the obvious fix ("not install the file")?
[04:00] <dholbach> tfheen: and a change to the wallpaper.xml to say "zoom" instead of "stretched"
[04:01] <pitti> seb128: thanks; no, I'm not at it
[04:01] <dholbach> (and autofoo stuff to not install the file, etc)
[04:02] <tfheen> dholbach: go for it
[04:03] <dholbach> tfheen: done
[04:06] <pitti> tfheen: I have a fixed evolution for bug 62593 now (just adds a desktop file to /etc/xdg/autostart); can I upload?
[04:06] <Ubugtu> Malone bug 62593 in evolution-data-server "Does not display alarms until I start evolution" [Unknown,Unconfirmed]  http://launchpad.net/bugs/62593
[04:07] <tfheen> pitti: go ahead
[04:09] <pitti> done
[04:09] <seb128> tfheen: opinion about libcairo-perl?
[04:09] <infinity> tfheen: Do you know if we need the newer one for libgtk2-perl to be happy?
[04:10] <seb128> infinity: I'm on it
[04:10] <seb128> infinity: I'm still waiting for somebody to reply to my question about libcairo-perl first though
 Kamion, tfheen, infinity: http://paste.ubuntu-nl.org/26596/ fixes the libcairo-perl ftfbs, I think we should consider syncing 1.01 from Debian though, it's update for the cairo 1.2 API changes and to Debian unstable,testing without open bug
[04:10] <seb128> in case you didn't read it before :)
[04:11] <infinity> seb128: Yeah, I'm more interested in knowing if libcairo-perl is perhaps somehow responsible for the libgtk2-perl FTBFS, that's all. :)
[04:11] <seb128> infinity: it's likely to be, let me try to rebuild libgtk2-perl now
[04:11] <infinity> seb128: I have no real opinion on the libcairo-perl UVF... It's got no rdeps, just the rbuild-dep of libgtk2-perl, so if they play nicely together, I'm not picky.
[04:12] <doko_> tfheen: all the stuff from http://people.ubuntu.com/~doko/edgy/ uploaded
[04:14] <pitti> tkamppeter: ugh, completely reverting all debian/ubuntu history doesn't really sound appropriate at that time? can't we just revert the fax changes to fix scanning?
[04:15] <BenC> tfheen, infinity: That directfb upload is probably bogus
[04:15] <BenC> I didn't realize it was a dpatch pkg
[04:15] <infinity> BenC: Well, too late now.  Give me another.
[04:28] <infinity> Right, I think it's bed time.
[04:31] <BenC> tfheen, infinity: Fixed directfb uploaded, with correct dpatch usage, and tested on amd64
[04:31] <infinity> BenC: Danke.
[04:39] <infinity> BenC: Where did you hide your fix in that upload? I can't be bothered to debdiff...
[04:39] <BenC> infinity: Yep, I modified an existing dpatch
[04:39] <infinity> Which one?
[04:40] <tfheen> seb128: I'd like us to be conservative and not grab new versions at this point
[04:41] <tfheen> seb128: so if the fix in http://paste.ubuntu-nl.org/26596/ works, I'd say we go for that.
[04:41] <seb128> ok
[04:41] <seb128> I've no idea of how usuable is the old libcairo-perl though
[04:41] <infinity> gah.
[04:41] <infinity> BenC: That wasn't clean...
[04:41] <tfheen> seb128: me neither.  It's in main, but no rdepends?
[04:42] <seb128> tfheen: libgtk2-perl Build-Depends
[04:42] <infinity> BenC: You ended up re-autotoolifying...
[04:42] <seb128> no rdepends no
[04:42] <infinity> BenC: Was that intentional?
[04:42] <BenC> infinity: I ran a "debian/rules patch" and "debian/rules unpatch", and then did "debian/rules clean"
[04:42] <BenC> infinity: So that's a failure in the debian/rules, since it does autoconf
[04:42] <infinity>  90 files changed, 30811 insertions(+), 56119 deletions(-)
[04:43] <tfheen> seb128: ok, then I'd rather we stay with what we have and just get the minimal build fix in.
[04:43] <infinity> Might want to unpack the previous version, swap in your patch, dpkg-buildpackage -S :)
[04:43] <BenC> infinity: I can do that
[04:43] <infinity> Not sure I'm comfy with that diff, even if it's just autocrap. :)
[04:43] <seb128> tfheen: ok, uploaded
[04:44] <tfheen> seb128: thanks.
[04:44] <infinity> BenC: Kay, rejecting so you can reupload the same version number.
[04:46] <infinity> BenC: Wait a sec..
[04:47] <infinity> BenC: Nevermind.  I was diffing against your -4ubuntu3 upload.  THAT was the one with autotools rape.
[04:47] <infinity> BenC: The diff between my -4ubuntu2 and your -4ubuntu4 was fine.
[04:47] <BenC> infinity: ok
[04:47] <infinity> BenC: I'll yank it from the rejected queue and accept it.
[04:47] <BenC> sounds good
[04:48] <infinity> BenC: Thanks for the fix.
[04:48] <BenC> no problem
[04:51] <infinity> Queue status update before I head to bed:
[04:51] <infinity>   109192 | S- | libcairo-perl        | 0.03-1ubuntu1        | six minutes
[04:51] <infinity>          | * libcairo-perl/0.03-1ubuntu1 Component: main Section: perl
[04:51] <infinity>   109172 | S- | evolution            | 2.8.1-0ubuntu3       | 41 minutes
[04:51] <infinity>          | * evolution/2.8.1-0ubuntu3 Component: main Section: mail
[04:51] <infinity>   109171 | S- | edgy-wallpapers      | 0.6-0ubuntu1         | 46 minutes
[04:51] <infinity>          | * edgy-wallpapers/0.6-0ubuntu1 Component: main Section: x11
[04:51] <infinity>   109170 | S- | sip4-qt3             | 4.4.5-2ubuntu1       | 50 minutes
[04:51] <infinity>          | * sip4-qt3/4.4.5-2ubuntu1 Component: main Section: devel
[04:51] <infinity>   109169 | S- | pyx                  | 0.9-2ubuntu1         | 50 minutes
[04:51] <infinity>          | * pyx/0.9-2ubuntu1 Component: universe Section: python
[04:51] <infinity>   109168 | S- | python-omniorb2      | 2.6-3.1ubuntu1       | 50 minutes
[04:51] <infinity>          | * python-omniorb2/2.6-3.1ubuntu1 Component: universe Section: devel
[04:51] <infinity>   109167 | S- | pysvn                | 1.4.2+dfsg-0.1ubuntu | 50 minutes
[04:51] <infinity>          | * pysvn/1.4.2+dfsg-0.1ubuntu1 Component: universe Section: python
[04:51] <infinity>   109166 | S- | omniorb4             | 4.0.6-2.2ubuntu1     | 51 minutes
[04:51] <infinity>          | * omniorb4/4.0.6-2.2ubuntu1 Component: universe Section: devel
[04:51] <infinity>   109165 | S- | ggz-grubby           | 0.0.13-2ubuntu1      | 51 minutes
[04:51] <infinity>          | * ggz-grubby/0.0.13-2ubuntu1 Component: universe Section: games
[04:51] <infinity>   109164 | S- | eunuchs              | 20050320.1ubuntu4    | 51 minutes
[04:51] <infinity>          | * eunuchs/20050320.1ubuntu4 Component: main Section: devel
[04:51] <infinity>   109163 | S- | python-4suite        | 1.0~rc4cvs20061012-0 | 51 minutes
[04:52] <infinity>          | * python-4suite/1.0~rc4cvs20061012-0ubuntu1 Component: universe Section: python
[04:52] <infinity>   109162 | S- | iptraf               | 3.0.0-1ubuntu2       | 51 minutes
[04:52] <infinity>          | * iptraf/3.0.0-1ubuntu2 Component: main Section: net
[04:52] <infinity> tfheen: Care to pronounce on those?
[04:53] <dholbach> edgy-wallpapers was approved by tfheen, fixes a milestone bug and gives us back 1.3M :)
[04:53] <tfheen> infinity: libcairo-perl, evolution, edgy-wallpapers, sip4-qt3, pyx, python-omniorb2, pysvn, omniorb4, ggz-grubby, eunuchs, python-4suite can all be accepted.
[04:53] <tfheen> infinity: who uploaded that iptraf?  BenC?
[04:53] <dholbach> I think that was mvo
[04:53] <BenC> tfheen: Reject my iptraf upload
[04:53] <dholbach> oh, no :)
[04:54] <mvo> yeah, I uploaded it - something wrong?
[04:54] <tfheen> infinity: if so, reject.  If not, enlighten me.
[04:54] <BenC> someone did an iptraf upload, mine should be ignored
[04:54] <tfheen> mvo: no, just a mid-air collision, most likely.
[04:54] <mvo> I did that hours ago ..
[04:54] <mvo> I'm sure BenC was sleeping then ,)
[04:54] <seb128> infinity: wait
[04:54] <seb128> infinity: no, that's fine :)
[04:55] <infinity> mvo, BenC : Interesting, you both fixed it in completely different ways. :)
[04:56] <BenC> mvo: s,asm/types.h,sys/types.h,
[04:56] <infinity> Well, mvo's wins, since it built. :)
[04:56] <keescook> dholbach: I've uploaded the 10 ssl fixes now
[04:56] <dholbach> keescook: super
[04:59] <tkamppeter> mdz, tfheen, kamion, pitti, doko_: biff, critical bug 65908
[04:59] <Ubugtu> Malone bug 65908 in hplip "libsane-hpaio.so not shipped anymore" [Critical,Confirmed]  http://launchpad.net/bugs/65908
[04:59] <Kamion> there's also a ggz-grubby sync request outstanding
[04:59] <Kamion> (IIRC)
[04:59] <Kamion> should it be rejected)
[04:59] <Kamion> ?
[05:00] <infinity> Kamion: Since I just accepted a non-sync... One would think there's  afailure to communicate. :)
[05:00] <infinity> dholbach: pipsecd, linm, dsniff, cl-ssl, clamcour, cfengine are all universe SSL rebuilds?
[05:00] <infinity> keescook: ^^^