[00:59] <crimsun> superm1: negligibly more latency than direct/raw (hw:0), but that's not the primary concern - introducing the regression of inaudible audio for a significant use case (non-Free Flash) is unacceptable by default for an LTS.
[01:07] <TheMuso> crimsun: Any thoughts on the dnsoop issue reported?
[01:07] <TheMuso> dsnoop
[02:34] <crimsun> TheMuso: it's likely because his usb speakers don't expose any capture; I asked for verification.  We can wrap the module-alsa-* portion in .nofail if that's the case.
[02:34] <TheMuso> crimsun: Right.
[05:10] <superm1> if the section needs to be overridden just for a single binary package compared to what it is now, should I do an upload to change this, or is that ignored and an archive admin needs to override the section?
[05:10] <superm1> i thought it was the latter, but wanted to make sure
[05:10] <StevenK> Both
[05:11] <StevenK> The latter usually happens first
[05:13] <superm1> so at this stage in the game, maybe do an upload that fixes it, subscribe ubuntu-archive and ask for it to be properly overridden when it's released?
[06:11] <dholbach> good morning
[06:17] <xtknight> hello.  i'm wondering about Bug 212546.  this seems like something that'll be universally annoying to people (change in behavior from gutsy)
[06:17] <xtknight> https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/212546
[06:17] <ubotu> Launchpad bug 212546 in pidgin "pidgin no longer flashes/notifies on taskbar upon receipt of message" [Undecided,New] https://launchpad.net/bugs/212546
[06:17] <ubotu> Launchpad bug 212546 in pidgin "pidgin no longer flashes/notifies on taskbar upon receipt of message" [Undecided,New]
[06:44] <pitti> Good morning
[06:45] <StevenK> Morning pitti
[06:46] <warp10> Good morning
[06:47] <pitti> hey StevenK, moin warp10
[06:47] <warp10> hey pitti!
[06:55] <geser> Guten Morgen pitti
[08:22] <tkamppeter> pitti, hi
[08:22] <Silicium> hi all
[08:26] <mantiena> hi all
[08:27] <mantiena> are there any plans to update language-packs before final release ?
[08:47] <pitti> hi tkamppeter
[08:47] <pitti> hey geser
[09:05] <pitti> Riddell: can you please have a quick look at bug 60448?
[09:05] <ubotu> Launchpad bug 60448 in xorg ".xsession_errors file grows out of control & saturates disk space" [High,Fix released] https://launchpad.net/bugs/60448
[09:07] <Silicium> is there a bug with grub on preseed?
[09:08] <Silicium> or a change in the installer between beta and RC ?
[09:16] <mantiena> pitti: maybe you could tell me if there are any plans to update language-packs before final release?
[09:16] <\sh> Silicium, what doesn't work?
[09:17] <Silicium> grub install
[09:17] <pitti> mantiena: again? They were just updated over the weekend
[09:17] <pitti> mantiena: so, no; those are the final packs
[09:17] <Silicium> i have commented out the grub lines in preseed and test again
[09:17] <pitti> mantiena: we have plenty of time to update them post-release
[09:18] <mantiena> pitti: you are not right, language packs aren't updated in this weeked, latest language-packs-gnome are ﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿20080415 :(
[09:18] <pitti> mantiena: right, that's the latest export that LP provides
[09:18] <pitti> mantiena: exported on April 15, langpacks built on April 18, uploaded on April 19
[09:19] <pitti> mantiena: I meant that they were built on the buildds over the weekend
[09:24] <Silicium> argh
[09:24] <Silicium> grub cannot install in /target/
[09:24] <Silicium> lets debug :/
[09:25] <Silicium> OH
[09:25] <Silicium> there is a new feature :)
[09:25] <Silicium> publish debug logs
[09:25] <Silicium> o/
[09:26] <mantiena> ﻿﻿﻿﻿﻿﻿pitti, so, you are misleading translators :(
[09:26] <mantiena> pitti: LanguagePackTranslationDeadline date is April 17 at https://wiki.ubuntu.com/HardyReleaseSchedule
[09:27] <mantiena> ﻿our team did lots of hard work in April 16 - April 17
[09:27] <pitti> mantiena: the confusion seems to be that translators think that they can update strings until April 17, but from the distro side we need to have the packages ready in the archive at this date
[09:28] <pitti> but we have some 5 days turnaround time for that
[09:28] <mantiena> pitti: is it so hard to update language packs now ?
[09:28] <pitti> mantiena: well, it isn't lost, we'll update translations maybe two weeks after hardy's release
[09:28] <pitti> mantiena: as I said, a complete turnaround takes 5 days; next LP export is available Thursday morning, and building/uploading/buildd'ing the packs takes another 2
[09:29] <pitti> so it's not hard, it's impossible
[09:29] <Silicium> hmm
[09:29] <Silicium> looks like a pkgsel problem
[09:29] <pitti> mantiena: we should really clarify that in the wiki docs, I agree
[09:29] <thom> Silicium: might be better in #ubuntu-installer
[09:29] <Silicium> yea
[09:39] <tkamppeter> pitti, I have done a small fix in foomatic-rip on Ricoh's request, bug 129999
[09:39] <ubotu> Launchpad bug 129999 in gasp-code "Bad things happen when setting the background color in begin_graphics()" [Undecided,Invalid] https://launchpad.net/bugs/129999
[09:39] <pitti> tkamppeter: I saw it; IMHO that should go into -updates, though (SRU)
[09:39] <tkamppeter> Sorry, bug 219999
[09:39] <ubotu> Launchpad bug 219999 in foomatic-filters "foomatic-rip does not handle enumerated-choice options with choices "True" and "False" correctly, leading to Duplex on most Ricoh printers not working" [High,In progress] https://launchpad.net/bugs/219999
[09:41] <tkamppeter> pitti, what about the crasher fixes on s-c-p of last week? Will they go into Hardy or are there also an SRU?
[09:42] <pitti> tkamppeter: those were uploaded earlier, they might make it
[09:45] <seb128> pitti: I've uploaded a gedit-plugins new version on the upstream request (the current version was setting an incorrect translation domain and breaking some gedit translations when installed), the package is in universe and I'm granting the GNOME exceptions there, so please accept the update ;-)
[09:45] <pitti> seb128: yessir
[09:46]  * seb128 hugs pitti
[09:46] <seb128> danke ;-)
[09:47] <pitti> seb128: done
[09:51] <mantiena> ﻿﻿pitti, it's a pitty if there are no way to include our work in final release :( about 7-8 people traslated lots of strings from our team, I see simmilar situation in other teams too, look for example at https://translations.launchpad.net/ubuntu/hardy/+source/firefox-3.0/+pots/firefox - about ~20 teams improved firefox translation after April 15
[09:53] <pitti> mantiena: it will be in -updates, and in the point release, too
[09:54] <mantiena> ﻿﻿﻿﻿yea, I understand this, but we though, that we are in time to have good translations in 8.04 release :)
[09:54] <highvoltage> moral of the story, keep an eye on the release cycle dates!
[09:54] <mantiena> highvoltage: hehe, we followed official ReleaseShedule
[09:54] <seb128> highvoltage: they did, the schedule is not clear
[09:55] <\sh> Silicium, -server daily from yesterday worked like a charm...(standard install)
[09:55] <highvoltage> seb128: ah, I see
[10:01] <mantiena> ﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿seb128: maybe I can simply add note, that real translation deadline is 2 days before LanguagePackTranslationDeadline in https://wiki.ubuntu.com/IntrepidReleaseSchedule ? Also it would be wise to﻿ fix Ubuntu﻿ReleaseSchedule template, if there are such
[10:01] <seb128> mantiena: better to speak to slangasek or pitti rather and let them do the required changes
[10:01] <pitti> right
[10:03] <mantiena> ﻿﻿﻿﻿﻿pitti: so, you will change ﻿﻿https://wiki.ubuntu.com/IntrepidReleaseSchedule by yourself ?
[10:03] <pitti> I clarified it on https://wiki.ubuntu.com/LanguagePackTranslationDeadline
[10:06] <mantiena> ﻿﻿pitti: I think it's not enough to clarify this on﻿﻿ https://wiki.ubuntu.com/LanguagePackTranslationDeadline - lots of translators already have read ﻿﻿https://wiki.ubuntu.com/LanguagePackTranslationDeadline ﻿and they will look only on ﻿ReleaseSchedule
[10:06] <mantiena> I think it's not hard to add small note
[10:06] <mantiena> in ﻿﻿https://wiki.ubuntu.com/IntrepidReleaseSchedule
[10:06] <ln-> what are those empty squares you are outputing?
[10:07] <dholbach> stgraber: are you going to update iso.qa.ubuntu.com with new ISOs? :)
[10:07] <seb128> dholbach is iso testing addict now ;-)
[10:07] <mantiena> ﻿﻿﻿﻿﻿﻿﻿﻿ln-: I don't see any ﻿squares :(
[10:08] <dholbach> seb128: hardly ;)
[10:08] <Fujitsu> mantiena: You're using Pidgin?
[10:08] <ln-> mantiena: what are those things in the begin of your line, before my nick?
[10:08] <pitti> mantiena: done
[10:08] <seb128> dholbach: iso will changes again no? is there a point to do a round of testing on the current ones?
[10:09] <dholbach> seb128: 20080421 fixed a bug I found in an earlier ISO ;)
[10:10] <mantiena> ﻿﻿﻿﻿﻿pitti: thanks
[10:11] <mantiena> Fujitsu: yes, I don't found any other IRC client in Ubuntu 8.04 LiveCD
[10:11] <mantiena> s/don't/didn't/
[10:12] <Fujitsu> Right, that'll probably be Pidgin trying to tell us he's typing a message.
[10:13] <ln-> ... ... .... well that's exactly what i wanted someone else's Pidgin to tell me.
[10:14] <ln-> sounds extremely stupid behavior.
[10:14] <Fujitsu> ln-: Right, it's stupid for IRC. Other Pidgin users that I've seen have trailing inverted Is, rather than leading spaces.
[10:14]  * laga doesn't see it in irssi
[10:15] <Fujitsu> It doesn't happen for many.
[10:15] <Fujitsu> Must be some strange plugin.
[10:15] <ln-> it appears the character is "ZERO WIDTH NO-BREAK SPACE", so depending on the font it may show as... zero-width space.
[10:15] <Fujitsu> Aha.
[10:15] <laga> maybe pidgin can become the new MS comic chat? :)
[10:16] <ln-> and apparently the font i'm using doesn't have that character.
[10:16] <Fujitsu> laga: It's about as comical and ridiculous.
[11:22] <stgraber> dholbach: the release managers usually add the ISOs as they build them :)
[11:33] <asac> ogra: ok, i recovered from the work-grave and could do classmate image testing now. appreciated?
[11:56] <pitti> asac: "grave"? I hope you mean "rave"? :-)
[11:57] <asac> :)
[11:57] <asac> yeah ... indeed it was a rave in the grave ;)
[12:19] <dholbach> stgraber: ahhh ok :)
[12:29] <sladen> 2002 era fashions: http://news.bbc.co.uk/1/hi/technology/7358483.stm
[12:36] <Keybuk> tkamppeter: meh, spoke to soon
[12:36] <Keybuk> tkamppeter: even after removing the firmware, I get about 1-2 prints before the printer fails
[12:41] <Silicium> pitti: you are here?
[12:41]  * pitti jumps over to "there"
[12:41] <Silicium> :)
[12:42] <Silicium> i have a problem installing pgsql in preseed
[12:42] <Silicium> so then i have created a post install script running while preseed
[12:42] <ogra> asac, absolutely
[12:42] <Silicium> the setup is sucessfully
[12:43] <Silicium> but another pakage using the pgsql as depency does not correcly install
[12:43] <Silicium> cause cant connect to the database
[12:44] <pitti> Silicium: so you have a cluster created? (check with pg_lsclusters)
[12:44] <Silicium> cjwatson saays you are the maintainer of pgsql so i ask you
[12:44] <Silicium> nope
[12:44] <Silicium> so i have a syslog from preseed
[12:44] <pitti> Silicium: hm, then it obviously didn't work
[12:44] <pitti> Silicium: do you see anything like "/dev/null: permission denied" in the log? that's one common reason of failure which i saw in hardy
[12:44] <Silicium> nope
[12:45] <pitti> Silicium: hm, can you show me the log? does it have the package installation output?
[12:45] <Silicium> see query for the debug url
[12:46] <pitti> Silicium: I didn't get a /query; you need to be registered to send /querys on freenode
[12:46] <Silicium> oh
[12:46] <pitti> (at least to other registered people)
[12:46] <Silicium> mom
[12:47] <Silicium> i kno
[12:47] <Silicium> i know
[12:47] <Silicium> now you get a qry :)
[12:49] <Silicium> so is partially german, if needed i can re run the setup in english
[12:49] <pitti> Silicium: did you get my response?
[12:49] <Silicium> nope
[12:49] <pitti> oh argh; seems I haven't been registered either since my server rebooted, sorry
[12:50] <Silicium> :)
[12:50] <Silicium> np
[12:50] <Silicium> same here
[12:50] <pitti> *blush*
[12:53]  * Hobbsee waves
[13:06] <asac> ogra: throw instructions at me then
[13:06] <ogra> asac, well, install it, use it :)
[13:06] <ogra> test susend/resume
[13:07] <asac> ogra: throw instructions at me :)
[13:07] <asac> i forgot the procedure
[13:07] <asac> sorry
[13:08] <ogra> asac, install you mean ? they are at the top on http://people.ubuntu.com/~ogra/classmate/images/8.04/
[13:09] <asac> ogra: ok, will test after lunch (~1h from now)
[13:11] <ogra> teake your time :)
[13:17] <pitti> ogra: ugh, devilspie??
[13:17] <pitti> ogra: LTSP installs unsupported packages by default, hmmm
[13:17] <pitti> ogra: there is no bug # in the ltsp changelog, so hard for me to judge approval
[13:18] <ogra> pitti, --kisok is by no means used by default, promoted or anything else :)
[13:18] <ogra> its an extra plugin you need to specify
[13:19] <ogra> pitti, same as the mythbuntu plugin, just seeit as universe part of ltsp :) it doesnt install any deps if you dont attempt to create a dedicated kiosk chroot
[13:20] <ogra> pitti, and its for a regression in that plugin that has no bug number ... just a nice to have (else firefox will run windowed on kiosk systems)
[13:21] <pitti> ogra: ok, thanks
[13:21] <highvoltage> that's interesting.
[13:40] <amitk> bryce: what would be the best place (package?) to add custom config options to xorg.conf?
[14:29] <alex_joni> is a line "Build-Depends: foo | bar, baz" acceptable?
[14:30] <ScottK> As long a foo is a real package and not a virtual package, yes.
[14:31] <alex_joni> I am trying to add a Build-Depends: for lyx-qt|lyx
[14:31] <ScottK> Should be fine then.
[14:31] <alex_joni> (that package changed name from dapper to hardy)
[14:32] <ScottK> Which is the hary one?
[14:32] <alex_joni> ScottK: it's complaining that the package is not found..
[14:32] <ScottK> hary/hardy
[14:32] <alex_joni> lyx
[14:32] <TheMuso> asac: After seeing the latest feedback on bug 192888, I'm not at all willing to upload that change.
[14:32] <ubotu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents" [High,Confirmed] https://launchpad.net/bugs/192888
[14:35] <ScottK> alex_joni: I'm not sure.  I'd expect that to work.  Packaging questions are generally better asked on #ubuntu-motu.
[14:35] <alex_joni> ScottK: cool, will move to there
[14:35] <elmo> sbuild will chose the first of an or'ed dependency
[14:35] <elmo> if you're targetting the package at hardy, use the hardy name first
[14:36] <ScottK> alex_joni: ^^^
[14:36] <alex_joni> elmo: it's targeted at both hardy & dapper
[14:36] <alex_joni> dapper likes lyx-qt, hardy lyx
[14:36] <alex_joni> ok, then I'll work around this
[14:39] <asac> TheMuso: yes, I agree its too risky to take for final .. we should try hard to fix this for 8.04.1
[14:39] <TheMuso> asac: Agreed.
[14:40] <ogra> who knows probably someone comes up wit a fix to libflashsupport in the meantime and the prob is moot :)
[14:41] <asac> TheMuso: milestoned for 8.04.1
[14:41] <asac> ogra: i am pretty sure that nobody can fix libflashsupport :)
[14:41] <ogra> asac, someone will
[14:42] <ogra> fedora uses it all over the place
[14:42] <asac> ogra: well. good for us ... they are insane then ;)
[14:42] <ogra> well, that means someone will try to fix it at least :)
[14:42] <asac> ogra: libflashsupport implements a contract from years ago ... who knows maybe they completely miss to implement some symbol
[14:43] <ogra> i dont care about their sanity :)
[14:43] <AstralJava> Well, even NTFS is writable these days... /me shrugs
[14:43] <ogra> they use nspluginwrapper everywhere though
[14:43] <asac> ogra: after release we will talk to adobe to sort this out. the real solution is to use ESD
[14:43] <ogra> so the problem wont be exposed as much
[14:43] <asac> ogra: right ... that fixes the crashes of firefox, but flash crashes anyway :)
[14:43] <ogra> haha
[14:44] <asac> but yes, we should use nspluginwrapper as well.
[14:44] <asac> thats sane ;)
[14:45] <ogra> well, it points the user to the acual problem ...
[14:45] <asac> indeed
[14:46] <asac> the real problam is that you blow libflashssupport into adobes house :)
[14:46] <asac> so the problem is libflashsupport :)
[14:46] <ogra> hich is wrong as well, since its pulse code now ... but they get warare of it at least
[14:46] <ogra> heh
[14:46] <ogra> *aware
[14:47] <asac> yeah
[14:49] <cr3> where's the process for getting something into hardy at this point?
[14:49] <nebajoth> I doubt there IS one
[14:49] <Hobbsee> cr3: new package?
[14:49] <nebajoth> its going to be released in days
[14:49] <cr3> Hobbsee: just an update
[14:49] <cr3> Hobbsee: patch even
[14:49] <Hobbsee> cr3: does it fix a release critical bug?
[14:49] <Hobbsee> or is it otherwise very very important?
[14:50] <cr3> Hobbsee: I'm not sure what constitutes "release critical bug". is fixing a bug from people saying  "Wow! This pisses me off!" and "I don't tolerate this kind of !@#$" release critical?
[14:50] <Hobbsee> cr3: depends.  bug #?
[14:55] <seb128> cr3: what is the issue exactly?
[14:55] <cr3> Hobbsee: bug #201336
[14:55] <ubotu> Launchpad bug 201336 in hwtest "report contains package information" [Undecided,Fix committed] https://launchpad.net/bugs/201336
[14:56] <cr3> seb128: personal information such as packages and versions are being submitted without the knowledge of the enduser
[14:56] <cr3> seb128: so, I have simply added a summary page before submission to at least inform the user about this
[14:57] <seb128> cr3: is the packages list something really required?
[14:57] <cr3> seb128: according to the launchpad folks responsible for the hardware database, yes
[14:58] <ogra> seb128, that info shall be made available to you as bug triager t some point (if teh user allows this) ... would you like to have that info ?
[14:58] <seb128> cr3: if you add a non translated dialog nows there is some users who will get angry
[14:58] <seb128> ogra: no, apport already has those informations
[14:58] <cr3> seb128: between having something done behind the user's back and having not translated, what do you think might be more important?
[14:58] <ogra> users will be able to link their hwtest info to bug reports in the future ...
[14:58] <seb128> cr3: I would remove the "include packages informations" rather
[14:59] <ogra> with a simple checkbox
[14:59] <seb128> to be honest I don't think hwtest is really ready to be used but that's an another topic
[14:59] <seb128> my preferred choices would be
[14:59] <seb128> - don't include those informations
[14:59] <seb128> - show a summary
[14:59] <seb128> - do nothing
[14:59] <seb128> but I'm not the one deciding there
[14:59] <seb128> you want to talk to slangasek or pitti
[15:00] <ogra> do nothing as in "leave as is" ?
[15:00] <seb128> ogra: yes
[15:00] <cr3> seb128: that's in order of preference, right? I actually tried to negotiate your #1 with the LP folks, specifically, I suggested having a checkbox to give the choice to the enduser whether they want to send package information or not. However, the LP folks said that information was required and I believe their relaxng schema enforces it anyhow.
[15:00] <Mithrandir> it doesn't sound RC, if anything it sounds like something that can be fixed in an SRU.
[15:01] <seb128> cr3: yes
[15:01] <cr3> Mithrandir: if you guys say so, I'll go with it. just wanted to bring this to your attention :)
[15:01] <seb128> we should just not use hwtest in 8.04, fix it and use it in 8.04.1
[15:02] <cr3> it currently sends useful information though, that'd be unfortunate :(
[15:02] <seb128> we have a similar application for years, I'm not convinced it does anything useful so far
[15:03] <seb128> and the thing really lacks a maintainer
[15:03] <seb128> almost all the bugs are untouched on launchpad apparently
[15:03]  * TheMuso sighs. Users wanting us to ship paviewcontrol.
[15:03]  * TheMuso can't remember why we chose not to...
[15:05] <ogra> seb128, but hwtest has a maintainer (a whole team even) i dont think hwtest now is worse than hwdb ever was, its an improvement in any case
[15:05] <seb128> ogra: maybe they should start looking at bugs then ;-)
[15:06] <ogra> heh
[15:06] <ogra> rather at the schedule :)
[15:07] <ogra> its not easy to grasp and know when you can do what if you dont work with it regulary
[15:07] <cr3> seb128: point well taken, I should be more regular in my bug triaging :(
[15:07] <seb128> cr3: anyway better to ask pitti or slangasek about it when they will be around still, better to avoid bad comments from some users because we didn't consider the bug
[15:08] <cr3> seb128: yeah, I'm fine either way with their decision. thanks for the advice and for the kick in the butt about checking my bugs :)
[15:09] <seb128> cr3: that's alright, I just noticed that this issue has been reported some weeks ago, and it would have been easier to deal with it before the freeze, but everybody has lot to do, etc so it's easy to be behind on triage
[15:10] <cr3> seb128: hwtest is more of a personal project and I work on it mostly evenings. however, these days, I've even been doing my usual work evenings. this will get better soon :)
[15:12] <seb128> cr3: alright ;-) The comment was not against you, but since we ship it by default we should have somebody in the team looking at the issue, you don't have to be this somebody ;-)
[15:14] <cr3> seb128: heh, don't worry, this project is something that is close to my heart so I actually enjoy the opportunity of maintaining it. I also appreciate the privilege of having such user feedback, it's always good to hear from folks even if it's to complain :)
[15:15] <seb128> cr3: btw in case you didn't notice I did the category change we talked about in hardy
[15:17] <cr3> seb128: yeah, your revision update kinda surprised me, I already had an update poised for hardy with the category: GTK;System;Settings;
[15:18] <pitti> hi cr3; what's up?
[15:20] <cr3> pitti: just wanted to bring your attention to bug #201336 for hwtest in which a user says: "Wow! This pisses me off!" and "I don't tolerate this kind of !@#$". I have a fix for this where I simply display a summary of the information about to be submitted.
[15:20] <seb128> cr3: you were not on IRC and the change was really needed
[15:20] <ubotu> Launchpad bug 201336 in hwtest "report contains package information" [Undecided,Fix committed] https://launchpad.net/bugs/201336
[15:20] <james_w> could a buildd admin give back lvm2 on powerpc please? It was hit by the ntpdate problem on saturday, and hasn't been kicked yet. https://edge.launchpad.net/ubuntu/+source/lvm2/2.02.26-1ubuntu9/+build/566009
[15:20] <cr3> seb128: agreed, thanks for that :)
[15:21] <elmo> james_w: done
[15:22] <james_w> thanks elmo
[15:22] <cr3> pitti: if you don't think that's critical, I'm fine with submitting an update after the release. if you think this could make it before release, I think this would be appreciate by some folks.
[15:23] <pitti> cr3: that sounds like a feature freeze/UI freeze/string freeze exception?
[15:24] <cr3> pitti: UI freeze, it was more than just a string change
[15:25] <pitti> cr3: yes, I mean all of those
[15:25] <cr3> but there was no additional windows and the user experience is exactly the same, except that the user won't get so pissed off :)
[15:25] <cr3> pitti: heh, I thought it was a question :)
[15:26] <cr3> pitti: I don't want you to spend too much time on this unless you think it's worthwhile, we're all crazy busy nearing release. do you think 8.04 or 8.04.1?
[15:27] <pitti> cr3: my gut feeling is .1 to not rush this in and break things; a package list isn't that private, is it? at least not more than your hardware/system identification?
[15:28] <pitti> cr3: but displaying the report before makes sense indeed; it's just very late for that :/
[15:28] <cr3> pitti: if I know you're running a kernel with an exploit because you haven't done updates, that could present a problem :)
[15:30] <cr3> pitti: it's a very simple report, no details at all: The following information will be sent [blah blah]. Distribution details, Device information, Processor information, Packages installed, Test results.
[15:31] <pitti> cr3: can you please ping someone from the doc team about it, whether it's ok for them to change this right now?
[15:31] <cr3> pitti: a more detailed report would've required major work which I wouldn't dare submit for an exception.
[15:32] <cr3> pitti: where would I do that? #ubuntu-doc? :)
[15:32] <pitti> cr3: ah, I see; if the doc team is fine with it (maybe because they did not document hwtest at all), then we should consider it
[15:33] <emgent> lol
[15:33] <pitti> cr3: http://lists.ubuntu.com/mailman/listinfo/ubuntu-doc is the ML
[15:33] <emgent> ops wrong window.
[15:34] <pitti> cr3: yes, IRC is fine as well, if you can catch someone
[15:37] <cr3> pitti: just to make sure I understand, if ubuntu-doc documents the shortcoming of hwtest then that'll be fine. otherwise, we should consider the bugfix in hwtest. is that right?
[15:38] <pitti> cr3: I mean if ubuntu-doc is fine with making that change now; i. e. it won't break documentation (or they'll update it)
[15:38] <seb128> I think it's late for this cycle
[15:38] <cr3> pitti: ah, thanks for the clarification. much appreciated :)
[15:39] <seb128> you will break translations in any case
[15:39] <pitti> yeah :/
[15:46] <pitti> ogra: just curious, why does ltspfs have debian/patches/? isn't ltsp maintained upstream in bzr?
[15:48] <ogra> pitti, yes, but not the packaging
[15:48] <ogra> and we're in deepfreeze, i dont introduce new upstream versions :)
[15:48] <pitti> ogra: oh, surprising
[15:48] <pitti> ogra: that's fine :)
[15:49] <asac> ogra: ok classmate image is booting ... lets see
[15:49] <ogra> with hardy i pulled debians package for the first time, i think vagrant just wanted to be polite and added dpatch
[15:49] <asac> ogra: ill use german install?
[15:50] <asac> or plain english for now?
[15:52] <ogra> as you like
[15:57] <amitk> ogra: ping regarding team ppa for cmpc
[15:57] <ogra> amitk, what team should that be ?
[15:58] <amitk> ogra: do you already have a cmpc team in launchpad?
[15:59] <ogra> nope, but i need one anyway to put the cmpc packages under as upstream
[16:00] <ogra> amitk, i meant how do you wat the ACL to look like :)
[16:00] <ogra> *want
[16:04] <ogra> amitk, ok, i got a general cmpc-developers team https://launchpad.net/~cmpc-developers
[16:08]  * ogra hugs pitti 
[16:08] <tkamppeter> pitti, bug 220041 is a one-line-fix, can we still get this into Hardy?
[16:08] <ubotu> Launchpad bug 220041 in system-config-printer "CUPS Printer Setup dialog deceiving" [Medium,In progress] https://launchpad.net/bugs/220041
[16:10] <asac> ogra: classmate image is broken for me
[16:10] <asac> ogra: after install i get UUID= ... and are asked to enter maintenance shell
[16:10] <ogra> asac, in what way ?
[16:10] <ogra> ugh
[16:11] <asac> fsck.ext3 ... unable to resolve 'UUID='
[16:11] <amitk> ogra: I applied for membership. Could you also activate the PPA for this team..
[16:11] <asac> ogra: ill reboot and try english install i guess :)
[16:11] <ogra> asac, you dont have a UUID value at all ?
[16:11] <asac> ogra: image is hardy-classmate-20080417.1.img
[16:11] <asac> ogra: let me boot again to look in fstab
[16:12] <mathiaz> slangasek: could you check why the latest version of likewise (0ubuntu3) hasn't been published ?
[16:13] <ogra> asac, dont have a second USB key plugged in there or so during install. right ?
[16:13] <pitti> mathiaz: because I accepted it from unapproved like 2 minutes ago
[16:13] <asac> ogra: no i don't
[16:14] <asac> just the one from the image
[16:14] <ogra> hmm
[16:14] <asac> hitting ctrl+d makes it boot properly though
[16:14] <asac> currently logging into desktop
[16:15] <ogra> amitk, accepted and activated  https://edge.launchpad.net/~cmpc-developers/+archive
[16:15] <asac> ogra: ok in fstab there are /boot /live/cow and /var with a valid UUID
[16:15] <ogra> asac, right
[16:15] <asac>  /home has none though
[16:15] <ogra> and in menu.lst ?
[16:15] <ogra> oh ?
[16:15] <ogra> let me check
[16:16] <asac> its juust UUID= /home ext3 ...
[16:16] <ogra> ouch
[16:16] <ogra> thats indeed wrong
[16:16] <amitk> ogra: perfect. I'll upload a kernel there later. Meanwhile, don't forget to add that archive to sources.list :)
[16:16] <mathiaz> pitti: great ! thanks :) - it will be published in the archive within a few hours then.
[16:17] <ogra> amitk, i wont, for sure ... thanks :)
[16:17] <ogra> asac, can you mail me /var/log/cmpcinstaller.log ?
[16:19] <asac> let me try wifi to get net :)
[16:19] <asac> ok NM works ;)
[16:20] <ogra> my reference install of this image definatey has a UUID for /home
[16:20] <asac> ogra: http://paste.ubuntu.com/7676
[16:20] <amitk> ogra: have you published the scripts that you use to roll these classmate images? I need it for another customer...
[16:22] <asac> ogra: anythin else you need?
[16:22] <asac> ill keep it running for now. let me know
[16:23] <ogra> asac, fdisk -l output for /dev/sdb
[16:23] <ogra> amitk, see pm
[16:24] <asac> ogra: http://paste.ubuntu.com/7677
[16:24]  * ogra scratches head
[16:25] <amitk> ogra: what pm?
[16:25] <ogra> amitk, the one i just sent :)
[16:25] <asac> ogra: http://paste.ubuntu.com/7678
[16:26] <ogra> asac, yes, the formatting fails already
[16:26] <asac> maybe because there was edubuntu installed before? :)
[16:27] <ogra> nope
[16:27] <asac> ogra: let me know if there is something i can do to help you ;)
[16:28] <asac> i could retry :)
[16:28] <ogra> yes, i bet it works the second time ...
[16:28] <asac> ogra: so do you need more info from this broken install?
[16:28] <asac> ogra: how do those uuid get generated?
[16:30] <ogra> asac, vol_id <devicename>
[16:30] <ogra> the prob is that there is no vol_id if the formatting fails
[16:30] <pitti> tkamppeter: I'll have a look
[16:33] <asac> ogra: ok retry?
[16:33] <asac> 3
[16:33] <asac> 2
[16:33] <asac> :)
[16:34]  * asac restarts classmate to do another install
[16:35] <asac> ogra: i have three USB devices wen selecting boot device:
[16:35] <asac> USB:M-Sys uDiskOnChip
[16:35] <asac> USB:Generic Storage...
[16:35] <asac> USB:Corsair Flash ...
[16:35] <asac> the latter is my disc
[16:36] <ogra> right
[16:36] <ogra> Generic is the SD reader
[16:37] <ogra> M-sys is the internal disk
[16:37] <asac> ogra: ok i try German again ;)
[16:38] <ogra> i suspect the sync call after fdisk fails
[16:38] <ogra> so this install should wrok fine
[16:38] <asac> ogra: but that should be reproducible?
[16:38] <asac> hmm
[16:38] <asac> why would it fail the first time and not now?
[16:39] <ogra> if the ioctl fails you dont have the new partition table available ... after a reboot you will ... hmm, actually no ...
[16:40] <asac> ogra: so did the layout change from previous hardy install i made?
[16:40] <ogra> the installer zeroes out the partition table before it starts fdisk
[16:40] <ogra> yes, /var got its own partition, /home moved one down
[16:43] <emgent> tseliot: :)
[16:43] <tseliot> ﻿emgent: hi
[16:51] <asac> ogra: ok reinstall helped
[16:51] <asac> ogra: ill leave it to you how to fix it now ;)
[16:51] <ogra> asac, right
[16:51] <asac> most lkely ou need to change partition layout to test that on my system again :)
[16:52] <asac> if you have a fix we can figure something out :)
[16:52] <ogra> asac, well, i guess i need to virtually re-plug the device
[16:52] <ogra> i'll think about something
[17:02] <ogra> Hobbsee, did you notice that your shermans-aquarium fix requires a fix in libgai0 as well ?
[17:02] <Hobbsee> ogra: yeah.  thought it got synced too, dammit.
[17:02] <mlind> seb128: still around? could you take a look at bug #211693
[17:02] <ubotu> Launchpad bug 211693 in gnome-mount "nautilus cannot eject ipod while eject(1) does" [Low,Triaged] https://launchpad.net/bugs/211693
[17:03] <Hobbsee> ogra: requested the sync now
[17:03] <ogra> :)
[17:03] <seb128> mlind: what about it?
[17:04] <Hobbsee> ogra: i got more concerned over LP dying for 14 hours over the weekend.
[17:04] <seb128> mlind: ETOOMUCHTODO
[17:05] <mlind> seb128: lol, maybe for point release then :)
[17:29] <tkamppeter> pitti, thanks for taking the s-c-p fix in.
[17:40] <pitti> tkamppeter: no problem
[17:40] <james_w> does anyone know of a change that may have "fixed" bug 218868?
[17:40] <ubotu> Launchpad bug 218868 in aalib "libaa1-dev uninstallable; causes FTBFS in other packages" [Critical,New] https://launchpad.net/bugs/218868
[17:40] <james_w> someone has tested for me and says that the installed file doesn't have the space which has been accused of causing the problem.
[17:51] <bryce> amitk: depends on the config options...  generally these days we've been trying to set default options in the drivers themselves, however it is also possible to set them in dexconf in the xorg package.
[17:52] <bryce> amitk: if the option is important, it's usually always better to set via the driver, since xorg.conf is only generated on fresh installs or if the user deliberately reconfigures
[17:52] <superm1> pitti, an archive admin needs to override the section for a binary package that's already in place right?
[17:53] <pitti> superm1: right
[17:53] <superm1> okay i'll just subscribe ubuntu-archive then to a bug
[17:53] <superm1> thanks
[17:53] <pitti> superm1: but it should be fixed in the package at the next opportunity, too
[17:53] <superm1> i did in the package already, but it didn't take effect
[17:53] <superm1> so i assumed that was why
[17:53] <pitti> no, it won't
[17:53] <pitti> exactly
[18:12] <cjwatson> bryce: do please remember to add patches to debian/patches/series if necessary ;-) just fixed xkeyboard-config ...
[18:13] <cjwatson> (or quilt push -a; quilt import or whatever)
[18:13] <bryce> whoops
[18:25] <amitk> bryce: I want to enable SHMConfig to allow for synaptics control
[18:26] <mjg59> amitk: By default?
[18:26] <amitk> mjg59: no.. for a classmate image
[18:26] <ogra> amitk, oh, why do we need that ?
[18:26] <mjg59> amitk: I really wouldn't recommend shipping anything to anyone with that set
[18:27] <bryce> mjg59: am I remembering correctly that SHMConfig presents a security concern?
[18:27] <mjg59> Yes
[18:27] <amitk> ogra: mjg59: Is there a better solution for keypad locking?
[18:27] <mjg59> Yes. Implement XInput properties.
[18:28] <amitk> ogra: sorry.. not classmate. I am confusing my vendors here....
[18:28]  * ogra doesnt really understad what amitk is doing there
[18:28] <ogra> ah
[18:28] <ogra> ok
[18:28] <ogra> phew
[18:28] <mjg59> amitk: But if you mean with existing code, then no. There's no secure way of implementing it.
[18:29] <bryce> amitk: there was a bug (with a patch) on adding SHMConfig by default, but the memory access situation was determined to be a  security issue, so the patch was not accepted
[18:29] <kees> amitk: err... I thought the synaptic controls had already been added to the mouse controls (by mjg59)
[18:29] <mjg59> kees: No, only a subset of them
[18:29] <amitk> mjg59: It has to be existing code. We can't devote a whole lot of time to this one.
[18:29] <mjg59> amitk: Then it's not possible
[18:30] <syke> hi
[18:30] <syke> can someone with an amd64 laptop help me try to reproduce something?
[18:32] <mjg59> amitk: SHMconfig generates a shared memory segment that's world writable. Any user can alter the coordinate mapping on the pad in order to trigger mouse presses at arbitrary points on the screen
[18:33] <mjg59> amitk: And if you enable this for anyone, I swear that I will write an exploit for it :)
[18:33] <mjg59> Oh, also it'll utterly fail in the fast user switching case
[18:34] <amitk> mjg59: point taken. I'll enable it with the warning 'mjg59 is out to get you' :)
[18:34] <mjg59> amitk: Seriously. It's not in the slightest bit acceptable for this to go in anything that ships to anyone.
[18:35] <bryce> ogasawara_: 36978 looks like a kernel bug (can't ping the machine).  Can you take a look?
[18:35] <ogasawara_> bryce: sure
[18:35] <jdong> mjg59: is there a better method of implementing a touchpad-keyboard interlock that doesn't come with the implications of SHMConfig?
[18:35] <amitk> mjg59: ok. I'll inform the vendor.
[18:35] <mjg59> jdong: Yes. Implement XInput properties.
[18:36] <amitk> TeTeT_: discussion with mjg59 ^^^
[18:36]  * jdong googles xinput properties
[18:36] <bryce> amitk: there was also a follow on patch to the bug I mentioned earlier, which the submitter claimed did not have the security issue, but I don't think that was reviewed.
[18:36] <mjg59> jdong: They don't currently exist. It's analagous to the xrandr properties
[18:36] <amitk> bryce: do you have a bug number?
[18:36] <mjg59> jdong: Essentially, allow input drivers to provide properties
[18:36] <bryce> amitk: one sec
[18:37] <mjg59> Then they can be runtime configured within the confines of the existing X security model
[18:37] <bryce> amitk: 155937
[18:38] <bryce> mjg59: I'd love to get your thoughts on the follow up patch in that bug.
[18:39] <bryce> (although it's too late for hardy, and hopefully xinput will be ready to go by intrepid...)
[18:40] <tjaalton> altough synaptics is dead upstream
[18:41] <mjg59> bryce: Yeah, that's an improvement. However, it still means that remote X clients can influence the input stream in a way they currently can't
[18:42] <mjg59> Also, that any user with admin privileges can screw everyone else. Though given sudoers, that's a given.
[18:42] <mjg59> I dislike tying desktop functionality to an admin group, though. It encourages people to make normal users admins
[18:44] <bryce> mjg59: thanks, yeah I suspected as much.  I'll update the bug.
[18:44] <syke> I entered the flash bug here: https://bugs.launchpad.net/ubuntu/+bug/220317
[18:44] <ubotu> Launchpad bug 220317 in ubuntu "flash hangs when screen blanks on laptop with hardy" [Undecided,New]
[18:45] <syke> if there's any info I can/should add to help debug, let me know
[19:41] <ogra> grumble ... where is dholbach ?
[19:48] <james_w> slangasek: hi. I'd like your opinion on bug 218868. It's milestoned, but no-one seems to be able to reproduce at the moment.
[19:48] <ubotu> Launchpad bug 218868 in aalib "libaa1-dev uninstallable; causes FTBFS in other packages" [Critical,New] https://launchpad.net/bugs/218868
[19:49] <slangasek> james_w: looking
[19:49] <james_w> There is a proposed patch, but I have no idea if it is correct as I can't reproduce. Normally I would just mark it incomplete, but as it is milestoned I wanted your input.
[19:50] <cjwatson> IIRC install-info got made more sane
[19:50] <slangasek> james_w: right, hadn't tried to reproduce that yet; assumed it was really there because the symptoms are very familiar
[19:50] <slangasek> cjwatson: in the time since infinity's most recent autobuild test, though?
[19:51] <cjwatson> though, hmm, yeah, that can't be right, that bug is recent
[19:55] <slangasek> infinity: need more info on bug #218868, it seems no one (incl. me) is able to reproduce this with a current hardy
[19:55] <ubotu> Launchpad bug 218868 in aalib "libaa1-dev uninstallable; causes FTBFS in other packages" [Critical,New] https://launchpad.net/bugs/218868
[19:55] <elmo> infinity's sick today
[19:56] <slangasek> ok
[19:56] <slangasek> who else might have an inside view of the pkgautotest framework?
[19:56] <elmo> pkgautotest?
[19:56] <elmo> so not using that
[19:56] <elmo> it's a dak buildd setup
[19:56] <slangasek> ok then
[19:57] <elmo> I can give the package back and/or manually install libaa1-dev, see if it's reproducible, I guess
[19:57] <cjwatson> aalib.info in the archive has:
[19:57] <cjwatson> START-INFO-DIR-ENTRY
[19:57] <cjwatson> * AA-lib: (aalib).              An ASCII-art graphics library
[19:57] <cjwatson> END-INFO-DIR-ENTRY
[19:57] <cjwatson> none of that leading space business
[19:57] <cjwatson> my guess is that it breaks when rebuilt
[19:57] <cjwatson> the autobuild test uses its own output ...
[19:57] <elmo> oh, right, yeah, we're doing opportunistic use of rebuilt binaries now
[19:58] <slangasek> ahyes
[19:58] <slangasek> james_w: ^^ does that help?
[19:58] <cjwatson> so this comes back to install-info changes in dpkg
[19:58] <cjwatson> or possibly makeinfo/whatever changes
[19:58] <james_w> slangasek: probably, yes. I'll test that now.
[19:59] <elmo> I have the built deb
[19:59] <elmo> and confirm it has the sapce
[19:59] <elmo> can provide it/url to it anyone if that's useful
[20:01] <james_w> elmo: thanks, but rebuilding locally shows the issue, so that's enough for me.
[20:02] <cjwatson> james_w: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451268
[20:02] <ubotu> Debian bug 451268 in texinfo "librep-doc: confusing INFO-DIR-ENTRY makes postinst fail" [Grave,Open]
[20:02] <cjwatson> scroll down towards the end
[20:03] <cjwatson> and also Debian #457741
[20:03] <ubotu> Debian bug 457741 in texinfo "please make makeinfo behave as before wrt drientries" [Wishlist,Open] http://bugs.debian.org/457741
[20:03] <elmo> 'wishlist'
[20:03] <cjwatson> james_w: basically suggests that this is a texinfo bug
[20:04] <cjwatson> james_w: ... except also that it's a mistake in texinfo files, since the patch installed by upstream reads:
[20:04] <cjwatson> +      /* The zsh manual, maybe others, wrongly indents the * line of the
[20:04] <cjwatson> +         direntry in the source.  Ignore that whitespace.  */
[20:05] <james_w> ok, so I should send this patch to joeyh?
[20:05] <cjwatson> james_w: I just linked the already-fixed Debian bug to the LP bug ;-)
[20:05] <james_w> cjwatson: thanks
[20:06] <cjwatson> so either merge if appropriate, or consider it as a backport from unstable if not
[20:08] <cjwatson> james_w: would a bzr-git import and a cherry-pick be appropriate?
[20:22] <mvo_> bzr-git?
[20:36] <james_w> cjwatson: I'm not sure
[20:47] <jdstrand> slangasek: would you mind looking at the penultimate comment in bug 155947
[20:47] <ubotu> Launchpad bug 155947 in libnss-ldap "libnss-ldap: calls to initgroups() causes boot to hang when using 'bind_policy hard'" [Undecided,Triaged] https://launchpad.net/bugs/155947
[20:48] <jdstrand> kirkland: ^^
[20:49] <slangasek> jdstrand: nss_initgroups_ignoreusers -- ah, lovely nss_ldap
[20:49] <kirkland> jdstrand: looking
[20:49] <jdstrand> so *finally* I found the cause
[20:49] <jdstrand> the question is the solution
[20:50] <jdstrand> slangasek, kirkland: I had 2 thoughts
[20:50] <jdstrand> a) update ldap.conf to list the different users
[20:51] <slangasek> patch libnss-ldap to know to skip all users with uid < 1000?
[20:51] <jdstrand> b) use a modified pre 251-6 solution that will add a file to /var/run when a successful lookup is found.  if this file does not exist, all lookups are soft, if it does exist, libnss-ldap honors bind_policy in /etc/ldap.conf
[20:52] <jdstrand> 'b' seems appropriate, as if /var/run doesn't exist, no big deal, boot continues
[20:52] <jdstrand> slangasek: yes, that would be c)
[20:52] <jdstrand> (I thought of that too)
[20:53] <slangasek> c) seems correct to me per se
[20:53] <jdstrand> slangasek: currently the bind policy defaults to hard
[20:53] <slangasek> yes, which is the sane default for it
[20:53] <jdstrand> I thought so too, but it horribly breaks things right now :)
[20:53] <kirkland> jdstrand: you and i have discussed (c) previously
[20:53] <jdstrand> do you see any problems with c)
[20:53] <slangasek> because of peripheral bugs, not because the policy of 'hard' is wrong
[20:53]  * jdstrand nods
[20:54] <kirkland> jdstrand: now, it seems, you've got a lot more evidence behind why that would solve this
[20:54]  * jdstrand nods again
[20:54] <slangasek> I don't see any problems with c); I do think that this is .1 stuff, AIUI this is not a regression and this should get some testing before it's thrust at users
[20:55] <kirkland> slangasek: well, it could be argued that this is a regression introduced by gutsy
[20:55] <kirkland> slangasek: gutsy was where this problem surfaced
[20:55] <jdstrand> slangasek: it is actually a regression for dapper -> hardy
[20:55] <jdstrand> slangasek: it was a feisty -> gutsy regression that never got fixed
[20:55] <slangasek> ah
[20:55] <kirkland> slangasek: and there is the angle that jdstrand mentions, dapper -> hardy installs could be rendered un-login-able
[20:56] <slangasek> still, I think deferring until .1 is the best course of action here
[20:56] <highvoltage> ogra: hmm, how do I force a shutdown on the cmpc? I installed the latest image, and when it said "rebooting", I pulled out to fast and now it has a kernel panic :(
[20:56]  * jdstrand worries about all those dapper desktops upgrading to hardy
[20:56] <kirkland> slangasek: bind_policy soft hack in the mean time?
[20:56] <slangasek> I believe the general plan is that dapper upgraders will be suggested to wait until .1 before upgrading
[20:57] <slangasek> I don't think a soft bind policy is any better, release-management-wise
[20:57] <slangasek> kirkland, jdstrand: looking at it from the other side, then - how soon do you guys think you could have c) implemented?
[20:57] <jdstrand> slangasek: well, hmm, I totally see your point, but this is a real bummer for enterprise environments...
[20:58] <slangasek> and will there be a configuration setting to turn off this check?
[20:58] <kirkland> slangasek: it's definitely a hack.  but what is going to be our recommended course of action, when users complain about this?  those that do upgrade from dapper -> hardy on day 1
[20:58] <jdstrand> slangasek: I think I could have a patch for c) either today or early tomorrow
[20:59] <kirkland> jdstrand: i can help with that, and the testing thereof
[20:59] <slangasek> jdstrand: incl. a new config option to control the behavior?
[20:59] <jdstrand> slangasek: that would take longer... and would break string freeze
[20:59] <slangasek> hrm?
[20:59] <slangasek> I'm not talking about a debconf /question/ about it
[21:00] <slangasek> just that it be configurable at runtime by editing the config file, not just a compiled-in setting
[21:00] <jdstrand> slangasek: well, that would make it easier I suppose
[21:00] <jdstrand> slangasek: as I do have other things I'm working on, I'd say end of day tomorrow?
[21:01] <slangasek> that's the safest way I see to ensure that we haven't mis-estimated in thinking that no one in their right mind would need to reference system accounts through LDAP ;P
[21:01] <jdstrand> slangasek: if I don't make it (or my patch stinks), it could still be .1
[21:01] <slangasek> jdstrand: ok, I'll accept it if it's end-of-day tomorrow (and passes muster too, obviously)
[21:01] <jdstrand> slangasek: I think that is totally reasonable-- we can add a note in there about hard bind policy, etc
[21:03] <jdstrand> slangasek: ok thanks
[21:15] <bryce> bdmurray: this report seems to not be getting generated:  http://people.ubuntu.com/~brian/reports/gt5subscribers/xorg.html
[21:18] <bryce> mario_limonciell: on bug 199455, you said you were able to reproduce it.  AMD is interested in taking a look but has trouble reproducing it.  Would you mind describing what you did to trigger it?
[21:18] <ubotu> Launchpad bug 199455 in linux-restricted-modules-2.6.24 "[fglrx] __driCreateNewScreen_20050727 () from /usr/lib/dri/fglrx_dri.so" [Critical,Confirmed] https://launchpad.net/bugs/199455
[21:19] <Amaranth> ah, attentive upstream binary driver, that's new
[21:20] <bryce> Amaranth: indeed
[21:36] <ogra> asac, ping
[21:36] <ogra> asac, can you open that page  ? https://bugs.freedesktop.org/enter_bug.cgi?product=LTSP  ... it makes my FF error out with XML error
[21:37] <ScottK> Opens on my Dapper desktop FWIW.
[21:37] <ogra> hardy with latest firefox
[21:38] <ogra> i get a cert error for the self signed cert first and then it drops me to an xm error here
[21:38] <ogra> *xml
[21:38] <asac> ogra: what version of language-pack-gnome-XX-base?
[21:38] <SEJeff> ogra, WFM
[21:38] <ogra> no idea, i upgraded today, checking
[21:39] <SEJeff> Did you restart ff after upgrading?
[21:39] <ogra> 20080415
[21:39] <ogra> SEJeff, it didnt tell me to
[21:39] <asac> ogra: 20080415ubuntu1 you need
[21:39] <ogra> ah,k
[21:39] <asac> ogra: let me know
[21:39] <ogra> willdo
[21:40] <jdong> zul: yo, trying out xen in hardy and finding bug 151327 well and alive... :-/
[21:40] <ubotu> Launchpad bug 151327 in linux-restricted-modules-2.6.24 "[fglrx] binary graphics drivers don't load with Xen (2.6.22 and 2.6.24)" [Medium,Confirmed] https://launchpad.net/bugs/151327
[21:40] <jdong> unknown symbols kmap_prot and a few others
[21:40] <ScottK> ogra: Works with current Firefox-3.0 on Hardy Kubuntu.
[21:41] <SEJeff> ogra, Ditto for hardy ubuntu
[21:41] <ogra> yeah, apparently ...
[21:46] <tseliot> jdong: a Xen developer should modify the ﻿firegl_public.c in order to fix that bug.
[21:48] <tseliot> jdong: a patch can be found here: http://ati.cchtml.com/show_bug.cgi?id=531
[21:48] <ubotu> ati.cchtml.com bug 531 in Installation "ATI drivers don't work under FC6 with Virtualization enabled (XEN)" [Major,Resolved: duplicate]
[21:48] <Kopfgeldjaeger> n8
[21:49] <jdong> tseliot: I believe that patch is added
[21:49] <jdong> tseliot: the problem is that the xen hypervisor doesn't seem to export a few needed symbols to the kernel symbol table
[21:49] <jdong> [   61.480621] fglrx: Unknown symbol xen_invlpg_mask
[21:49] <jdong> [   61.480809] fglrx: Unknown symbol kmap_prot
[21:49] <jdong> [   61.481570] fglrx: Unknown symbol kmap_atomic_prot
[21:49] <jdong> specifically, those three
[21:54] <zwnj> dput-ing a new package in my ppa, ﻿i get this error:  Unable to find bicon_0.2.0.orig.tar.gz in upload or distribution.
[21:55] <zwnj> can someone help me on this please?
[21:58] <mario_limonciell> bryce, i can reproduce it yes
[22:00] <mario_limonciell> bryce, i don't have any other use case outside of using mythtv to do it though.
[22:00] <mario_limonciell> bryce, and it's just a matter of starting myth with the driver active
[22:00] <bryce> ok, is it just ... ah ok
[22:00] <mario_limonciell> bryce, followed by watching a show for a little bit
[22:00] <mario_limonciell> and then quiting
[22:00] <bryce>  
[22:00] <mario_limonciell> and it crashes on the quit
[22:01] <Lightkey> bryce, maya, 3dsmax, renderman
[22:01] <mario_limonciell> they do the same thing?
[22:02] <bryce> mario_limonciell: I think lightkey was giving a list of 3d apps ;-)
[22:03] <bryce> mario, ok thanks that should be sufficient.  I bet they just hadn't tried running from myth
[22:03] <laga> mario_limonciell: to make it easier reproducible, is it sufficient to run mythtv /some/video/file.avi ?
[22:04] <mario_limonciell> i'm not sure that will reproduce it
[22:04] <laga> not sure if the ati guys want to install a mysqld :)
[22:07] <mario_limonciell> laga, i'd be reluctant to think that it would be sufficient.  the whole DRI surface might (and probably) is only made when the mythfrontend app is made rather than when just the video playback is started
[22:08] <laga> good point.
[22:14] <bryce> mario_limonciell: unrelated question...  I'm debating about upgrading my mythtv box, vs. a clean install + manually moving my programs over.  How robust do you think the gutsy->hardy mythbuntu upgrade process is?
[22:15] <bryce> (I'm going to do a full backup either way, but want to take the approach that consumes the least amount of time/effort)
[22:16] <mario_limonciell>  bryce there is only one known issue with the upgrade afaik right now
[22:16] <mario_limonciell> bryce, that being that if you had vnc4server installed
[22:16] <bryce> ok
[22:16] <mario_limonciell> you will need to 'reconfigure' vnc in the new upgrade
[22:16] <mario_limonciell> it migrates you over to x11vnc
[22:16] <mario_limonciell> since vnc4server crashes the x server
[22:16] <bryce> good, I don't have any vnc on it
[22:16] <bryce> hmm, bug id on that?
[22:16] <mario_limonciell> there is a cx88 LUM bug too, but there is a fix already on its way for it
[22:17] <mario_limonciell> bryce, yeah bug 180619
[22:17] <ubotu> Launchpad bug 180619 in vnc4 "Xorg module VNC cores on keyboard input" [Undecided,Confirmed] https://launchpad.net/bugs/180619
[22:18] <bryce> btw, I don't know if kees mentioned it already but he did an upgrade last weekend and discovered a bad xfs issue
[22:18] <mario_limonciell> its because the integrated xserver-xorg is old
[22:18] <laga> mario_limonciell, bryce: if /var/lib/myth* is on nfs, the postinst scripts will fail AFAIK
[22:18] <mario_limonciell> kees, didn't mention it to me..
[22:18] <mario_limonciell> oh yuck
[22:18] <mario_limonciell> is that the one bryce ?
[22:19] <kees> bryce: it's not "an XFS issue".  XFS is it's own issue, I just got very unlucky.
[22:19] <bryce> mario_limonciell: ok.  I think he narrowed it down to being a very xfs oriented error, not mythtv's fault per se
[22:19] <bryce> kees, ah ok
[22:19] <laga> mario_limonciell: in the alt disk, when install the master backend task, i get "apache2-mpm-prefork: collies: apache2-mpm", "apache2-mpm-worker: collides: apache2-mpm". apache2-mpm doesn't seem to be a package?
[22:19] <kees> bryce: I could have very well just happened to do a regular gutsy update and it could have eaten me.  it's just that XFS happened to barf in the middle of the libc update.  *roll eyes*
[22:19] <mario_limonciell> laga, are any of them explicitly dependent?
[22:20] <bryce> ah..  <kees> bryce_: heh, well, it's not really myth that's the problem.  XFS ate libc :(
[22:20] <mario_limonciell> kees, ooh that's rough
[22:20] <jdong> can someone look at the patch on bug 192605 please?
[22:20] <ubotu> Launchpad bug 192605 in virt-manager "virt-manager does not detect bridge br0" [Undecided,Confirmed] https://launchpad.net/bugs/192605
[22:20] <laga> mario_limonciell: apache2 | httpd on mythweb, but i'm not quite sure where it comes from. i do blame mythweb ;)
[22:20] <jdong> that bug still affects Hardy :-/
[22:20] <kees> mario_limonciell: yeah, I'm rather proud of myself for getting it fixed.  nasty.
[22:26] <megabyte405_> hey folks - fixing the little packaging issues with abi if anyone's following that bug.  Should I re-roll abiword-2.6.2-0ubuntu1 or make abiword-2.6.2-0ubuntu2?
[22:30] <mario_limonciell> laga, well do you suppose the issue may be transient?
[22:31] <mario_limonciell> also remeber your diskless fix didn't show up until after last night's disk was made
[22:31] <laga> no. we've had some reports about this being broken.. i'm not sure if the cause was the same
[22:31] <laga> i'm doing some more tests now
[22:42] <laga> mario_limonciell: i've got the full, non-engrish error message now.
[22:42] <mario_limonciell> pastebin?
[22:43] <laga> "the following packages have unmet dependencies:" \n "apache2-mpm-prefork: conflicts: apache2-mpm" \n "apache2-mpm-worker: conflicts: apache2-mpm"
[22:44] <laga> and then comes the usual "E: broken packages" \n "tasksel: aptitude failed (100)"
[22:44] <laga> i'll upload it.
[22:47] <laga> mario_limonciell: http://www.pastebin.ca/992524
[22:48] <mario_limonciell> laga, hm
[22:49] <mario_limonciell> what apache stuff is in the seeds right now, any?
[22:49] <laga> mario_limonciell: i'll take a look, but we've got prefork and worker debs on the disk
[22:50] <mario_limonciell> laga, i'm not sure that information is very complete to the true problem
[22:50] <mario_limonciell> apache2-mpm isn't even in apt these days
[22:50] <laga> yes.
[22:50] <mario_limonciell> is it perhaps really freaking out at
[22:50] <mario_limonciell> #
[22:50] <mario_limonciell> Apr 21 21:38:44 in-target: E:
[22:50] <mario_limonciell> #
[22:50] <mario_limonciell> Apr 21 21:38:44 in-target: Couldn't find package language-pack-en
[22:50] <laga> and i think the meta package itself installs w/o a problem
[22:50] <mario_limonciell> oops sorry flood.
[22:50] <laga> mario_limonciell: the frontend task works
[22:51] <mario_limonciell> so tasksel oddities then
[22:51] <laga> the seeds for ship lists apache2-mpm-worker
[22:51] <mario_limonciell> take a look at how ubuntu server gets around this maybe for their apache task
[22:51] <laga> which provides apache2-mpm
[22:53] <cjwatson> mario_limonciell: that language-pack-en error shouldn't matter
[22:53] <cjwatson> laga: what task is trying to be installed here?
[22:54] <laga> cjwatson: mythtv-backend-master
[22:54] <laga> i wonder if http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.hardy/revision?start_revid=adconrad%400c3.net-20060914004830-b39703af5ab366e7&filter_file_id=lampserver-20060725122202-f0300b6c185376b6 might be related?
[22:56] <cjwatson> possible, but what's trying to install apache anyway?
[22:56]  * cjwatson pokes at germinate output
[22:56] <laga> cjwatson: mythweb most likely
[22:57] <mario_limonciell> mythweb comes in as a recommend
[22:57] <mario_limonciell> which depends on apache probably
[22:57] <cjwatson> ah, recommends: mythweb
[22:57] <cjwatson> yeah
[22:57] <cjwatson> apache2-mpm-prefork    | apache2        | libapache2-mod-php5                 | Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com> |          229690 |             504
[22:57] <cjwatson> apache2-mpm-worker     | apache2        | apache2                             | Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com> |          233498 |             512
[22:58] <cjwatson> libapache2-mod-php5 explicitly only works with prefork or itk
[22:58] <cjwatson> I suspect a similar seed workaround will work, but am checking
[22:59] <laga> yes, i can see these debs on the disk
[23:04] <cjwatson> laga: http://paste.ubuntu.com/7707/ does the right thing
[23:05] <laga> cjwatson: your ability to make things work by adding a simple line continues to amaze me.
[23:05] <laga> thanks
[23:05] <jdong> soren: poke on bug 192605; the connection.py patch solves the bug for me and is bitesized. Probably not release critical but still good to have for 8.04.x
[23:05] <ubotu> Launchpad bug 192605 in virt-manager "virt-manager does not detect bridge br0" [Undecided,Triaged] https://launchpad.net/bugs/192605
[23:05] <cjwatson> laga: so much more efficient that way. :)
[23:11] <soren> jdong: Yeah.. What I completely fail to grasp is why it works for me without the patch.
[23:12] <jdong> soren: odd :-/
[23:12] <soren> Quite.
[23:13] <jdong> other than that one anomaly, libvirt/virt-manager has treated me quite well. I am impressed
[23:13] <laga> jdong: just wondering - can you enable KVM after creating a qemu VM in virt-manager? i couldn't find a button for that
[23:13] <jdong> soren: is there any reason why the virt-manager GUI doesn't offer a way to connect to qemu:///system rather than qemu:///user?
[23:14] <jdong> laga: I don't see a GUI button for that either
[23:14] <jdong> laga: that's probably still a matter of editing the .xml file
[23:14] <laga> also, the network dialog was greyed out for me, but i didn't RTFM.
[23:14] <laga> a nice piece of software, though.
[23:16] <soren> jdong: No particular reason, no.
[23:16] <jdong> laga: you needed to start virt-manager -c qemu:///system
[23:16] <jdong> laga: by default it starts ///user, which can't config networking
[23:16] <jdong> laga: it's not in TFM either.... :)
[23:16] <jdong> hence the question I just posed :)
[23:16] <laga> oh. nice.
[23:17] <jdong> yeah, a bit of suffering in the UI dept
[23:17] <laga> and in the FM dept ;)
[23:25] <cjwatson> laga: would you mind also applying http://paste.ubuntu.com/7712/ for me? In the course of fixing bug 218604, I'm trying to get rid of the cdimage hack I installed for mythbuntu, and this gives it enough metadata to know that it needs to suck everything in desktop into the outer tasks
[23:26] <ubotu> Launchpad bug 218604 in tasksel "networkless expert install offers tasks which aren't on the CD" [Undecided,Invalid] https://launchpad.net/bugs/218604
[23:30] <ogra> cjwatson, he just said goodnight in #ltsp
[23:30] <cjwatson> bugger
[23:30] <cjwatson> mario_limonciell: can you help with the above?
[23:31] <cjwatson> I can maintain the code but would rather not
[23:36] <mario_limonciell> cjwatson, yeah i can do that
[23:39] <mario_limonciell> cjwatson, okay it's committed
[23:45] <jdong> lol bug or feature: gnome-terminal allows detaching a tab from a window with a single tab
[23:45] <jdong> in which case it just closes the current window and makes a new one with the same session attached to it.
[23:46] <SEJeff> jdong, How did you pull that one off?
[23:46] <jdong> SEJeff: tabs->detach tab
[23:46] <SEJeff> jdong, Nice. probably worth filing an upstream RFE to fix
[23:56] <mario_limonciell> whoops jdong.  Looks like reproducing your bug took my ssh session that connects me to IRC w/ it :)
[23:57] <cjwatson> mario_limonciell: great, thanks
[23:57] <cjwatson> I'll prod the cdimage code to match as soon as I've tested it
[23:57] <mario_limonciell> cjwatson, this won't break the disks in tonight's build though right?
[23:57] <mario_limonciell> oh.  okay.
[23:57] <cjwatson> I'm hoping I'll get it committed in the next six hours, yes :)