[01:17] <RAOF> I've recieved some FTBFS mail from xserver-xorg-video-intel on {hppa,ia64,sparc,powerpc}.  But these archs aren't specified in the -intel Arch: list; why have the builds been queued at all?
[01:19] <TheMuso> RAOF: Very good question.
[01:21] <Hobbsee> RAOF: because soyuz doesn't use it?
[01:21] <Hobbsee> RAOF: it needs to be put in p-a-s, afaik
[01:21] <jcristau> it is in p-a-s
[01:21] <RAOF> Another question would be why these archs _aren't_ on the arch list, because it appears to build fine.
[01:22] <RAOF> Until the binary-arch target gets called with DH_OPTIONS-
[01:22] <RAOF> Until the binary-arch target gets called with DH_OPTIONS=-s, and dh_* complains that $ARCH isn't on the arch list.
[01:22] <jcristau> RAOF: if you have an intel graphics chip on powerpc, i want to see it
[01:23] <RAOF> Ah.  _That's_ why it's not on the arch list? :)
[01:23] <jcristau> yes
[01:23] <RAOF> Fair crack o' the whip
[01:29] <Hobbsee> drat.  merges.ubuntu.com isn't working.
[01:31] <Hobbsee> cjwatson: can you poke it into working, please?  :)
[01:32] <cjwatson> no (as in no access to do so). Ask Keybuk when he gets back from travelling or doko when he gets back from sick leave
[01:33] <Hobbsee> okay, will do, thanks.
[07:05] <dholbach> good morning
[07:11] <dholbach> bryce: do you think you could comment on bug 272145 and subscribe ubuntu-archive if that's OK?
[09:33] <didrocks> dholbach: hi \o/
[09:33] <dholbach> hi didrocks :)
[09:34] <didrocks> dholbach: do you know when the next EMEA membership meeting will be attending as the previous one has been canceled (https://wiki.ubuntu.com/Membership/RegionalBoards/EMEA)
[09:34] <dholbach> didrocks: no, no idea - it might be worth mailing the regional board about it
[09:36] <didrocks> dholbach: I wasn't aware of a dedicated ML for that. Thanks, I will look for it :)
[09:36] <dholbach> I think there is, if there isn't mail the members of the board :)
[09:37] <didrocks> found it, LP was my friend. Thanks Daniel :)
[10:35] <stefanlsd> didrocks: let me know if u have any luck from that, i was also sheduled to attend..
[10:42]  * soren wuold like to request some archive admin love for ec2-init (source NEW in Intrepid)
[10:43] <dholbach> hiya soren
[10:47] <highvoltage> hiya soren
[10:47] <soren> hi, guys. :)
[10:48]  * ogra wonders why he just read "Totem BBQ plugin" in cjwatson's last mail ... its not even lunchtime 
[10:49] <jussi01> ogra: nice one :P
[11:02] <thekorn> exit
[11:12] <didrocks> stefanlsd: ok. I will keep you in touch
[11:40] <ogra> cjwatson, is there any special code thats not in the livecd-rootfs package on cdimage that prevents recommends from being processed for the squashfs ? i'm getting weird errors trying to build a local ubuntu-mobile image with the livecd-rootfs from the archive (mono-common installing binfmt-support which prevents proc from unmounting)
[11:40] <cjwatson> ogra: I think it just relies on apt for that
[11:40] <ogra> but uses recommends ?
[11:40] <cjwatson> ogra: cdimage doesn't have a separate livecd-rootfs package - it just uses what's in the archive
[11:40] <ogra> weird
[11:41] <cjwatson> it should use recommends, but it may depend on the base system you use
[11:41] <ogra> why do we get proper livecds then ? it should expose the same issue
[11:41] <cjwatson> because it relies on the base system's apt
[11:41] <cjwatson> if you're building on a hardy system then it won't work
[11:41] <ogra> aaah !!!
[11:41] <ogra> indeed
[11:41] <cjwatson> our live filesystem builds use a chroot-in-chroot approach; intrepid live filesystems are built starting from an intrepid chroot
[11:42] <cjwatson> so you'll need to do the same
[11:42] <ogra> you mean from a hardy chroot ?
[11:42] <cjwatson> intrepid live filesystems are not built from a hardy chroot, no ...
[11:42] <cjwatson> though if you're building a hardy filesystem, sure, use a hardy chroot
[11:43] <ogra> no, i'm building intrepid on an intrepid system
[11:43] <ogra> which makes it indeed install recommends ...
[11:44] <cjwatson> well, that's as designed. However, we should make livecd-rootfs cope with binfmt-support being installed
[11:44] <ogra> and in turn pulls binfmt-support in from mono-common ... which prevents unmounting proc ... if we use an intrepid chroot on cdimage that should happen there as well, no ?
[11:44] <cjwatson> that's easy and I'll fix it now
[11:44] <ogra> yeah, indeed
[11:44] <ogra> but i wonder why we get proper livefs'es
[11:44] <cjwatson> binfmt-support is installed in our live filesystems
[11:45] <ogra> that recommends exists since ages ... and should apply there as well
[11:45] <ogra> oh
[11:45] <ogra> why does it block here then ?
[11:45]  * ogra scratches head
[11:45] <cjwatson> however, because the livefs buildds are running on a hardy kernel without the binfmt_misc module loaded, binfmt-support fails to mount /proc/sys/fs/binfmt_misc
[11:45] <ogra> aha !
[11:45] <ogra> ok, thats clear
[11:47]  * ogra hacks around that for his local testbuilds for now ... 
[11:47] <cjwatson> I've committed a fix to livecd-rootfs bzr
[11:48] <ogra> thanks
[11:50] <ogra> hmm, doesnt that need to go into "cleanup" as well ?
[11:51] <cjwatson> no, cleanup looks at the MOUNTS variable set out there
[11:51] <ogra> ah, k
[11:51] <cjwatson> in fact it's the only thing MOUNTS is used for ...
[11:51] <cjwatson> I'll move that up to cleanup for clarity
[12:04] <lool> cjwatson: Ah thanks for the explanation and the quick fix
[12:04] <lool> Didn't think of the kernel not allowing binfmt
[12:05]  * ogra sighs ... if i now would get uncorrupt packages files from the archive i could actally make use of the fix ... 
[12:07] <cjwatson> I uploaded livecd-rootfs with that, btw
[12:08]  * ogra saw that, thanks
[12:08] <ogra> but somehow i always get corrupt Packages files atm
[12:09]  * ogra goes to make a coffee hoping the issue resolves itself inbetween
[12:16] <ogra> ah, better :)
[12:28]  * ogra grumbles ... its all seb128's fault ...
[12:29] <ogra> The following packages have unmet dependencies:
[12:29] <ogra>   ubuntu-mobile: Depends: nautilus but it is not going to be installed
[12:29] <ogra> seems i have to spend my day with twiddling thumbs ....
[12:34] <lool> ogra: Can't we fix this with some rebuilds?
[12:34] <ogra> lool, i think i just have to wait until all nautilus builds are there
[12:35] <ogra> nautilus-cd-burner, nautilus-share and nautilus have to be there together ... likely only one has built yet
[12:35] <lool> nautilus is only missing on hppa
[12:36] <lool> ncb is at 2.23.90 on all arches
[12:36] <ogra> nautilus-cd-burner ainst uploaded ...
[12:36] <ogra> *isnt
[12:37] <lool> ogra: We can fix that too  :-P
[12:38] <ogra> i'm not sure i want to fiddle in sebs area and break stuff
[12:38] <torkel> lool: by cloning seb128, so he uploads stuff faster?
[12:39] <lool> ogra: Actually we're up-to-date in terms of ncb; latest is 2.23.90
[12:39] <seb128> what is broken on what architecture?
[12:39] <seb128> there is no update breaking nautilus
[12:39] <ogra> seb128,
[12:39] <ogra> The following packages have unmet dependencies:
[12:39] <ogra>   ubuntu-mobile: Depends: nautilus but it is not going to be installed
[12:39] <ogra>                  Depends: nautilus-cd-burner but it is not going to be installed
[12:39] <ogra>                  Recommends: nautilus-share but it is not going to be installed
[12:40] <seb128> I mean it's not waiting on other updates
[12:40] <lool> ogra: What's the reason for the uninstallability?
[12:40] <ogra> trying to build a livefs here
[12:40] <seb128> sudo apt-get install nautilus
[12:40] <ogra> seb128, lpia
[12:40] <lool> ogra: Try apt-get install nautilus nautilus-cd-burner nautilus-share
[12:40] <seb128> I guess it's an arch all any mismatch during the time between the i386 and lpia builds
[12:40] <seb128> should be autosolved in the next run
[12:41] <ogra> yeah, thats what i expected
[12:46] <ogra> lool, btw: nautilus: Depends: nautilus-data (>= 1:2.24) but 1:2.23.92-0ubuntu1 is to be installed
[12:47] <ogra> just a sync prob
[12:50] <seb128> it built on i386 and lpia so next published run should fix the issue
[12:50] <seb128> try updating that might already be fixed now
[12:51] <pochu> cjwatson: hi. do you know if the "Generating server key" dialog in totem is from the new BBC plugin?
[12:51] <cjwatson> pochu: it's not
[12:51] <cjwatson> I don't see that string anywhere in the totem source
[12:52] <ogra> seb128, trying every 10 mins anyway ... i have a looping script :)
[12:57] <lool> Hmm lots of DEBUG output in my .xsession-errors; don't think it's my doing to turn this on
[12:57] <pochu> same here
[12:57] <lool> x session manager stuff
[12:58] <james_w> lool: I believe the last gnome-session upload turned that off
[12:58] <lool> ah just need to re-login, thanks
[12:58] <lool> i was trying to find out what's happening to the totem bbc plugin
[13:06] <ogra> yippie, finally all in sync
[13:06]  * ogra watches his livefs build going on
[13:52] <siretart> any reason why we call halt on shutdown with -i? This causes the network interfaces to be shut down with the consequence that this breaks wol and iscsi (at least this was just reported to me)
[13:52] <siretart> cf. bug #71418
[13:53] <ogra> we dot want iscsi and wol users ... they just file new bugs :P
[13:53] <liw> what is wol?
[13:53] <ogra> wake on laugh
[13:54] <liw> ah, wake-on-lan?
[13:54] <siretart> ogra: I take that as a joke, yes?
[13:54] <siretart> liw: right
[13:54] <ogra> siretart, indeed
[13:57] <siretart> TBH, I see no reason to do that, and I'm inclined to just change the default in sysvinit.
[13:58] <ogra> i'd agree, but probably ask Keybuk ...
[13:59] <siretart> keyb<tab><tab>: ^^
[13:59] <siretart> damn..
[13:59] <ogra> yeah
[13:59] <ogra> he is likely jetlagged
[14:00] <liw> Keybuk is likely to just replace shutdown with a new program, called downstop
[14:02] <TheMuso> o/c
[14:06] <pitti> hello everyone
[14:06] <geser> Hi pitti
[14:06] <ogra> welcome back pitti
[14:20] <TheMuso_> i/c
[15:04] <rgreening> hey all. I was going to work on packaging compiz 0.7.8. Anyone willing to take my diff and build/upload once done? :) (Assuming we can put 0.7.8 in Intrepid).
[15:30]  * ogra scratches head why evolution and epiphany get installed in ubuntu-mobile
[15:34] <rom1v> hi
[15:34] <rom1v> will flash player 10 in default repositories in intrepid?
[15:35] <rom1v> I know it's a RC, but it supported pulseaudio and should avoir some crashes of firefox
[15:35] <rom1v> s/supported/supports natively/
[15:47] <ogra> hrm
[15:48] <ogra> seems totem-mozilla pulls in epiphany instead of using the "Provides: www-browser" entry from midbrowser
[15:48] <ogra> at least thats my only idea ...
[15:50] <seb128> ogra: Recommends: epiphany-browser | www-browser
[15:50] <ogra> seb128, yeah
[15:50] <ogra> but thats the only connection i see to epiphany at all in the seed
[15:50] <ogra> midbrowser should fulfll www-browser"
[15:51] <seb128> well, try to apt-get install using -o Debug::something
[15:51] <seb128> mvo can tell you the something to use ;-)
[15:52] <ogra> i need a clean chroot first i guess
[15:52] <mvo> ogra: apt-get install -o debug::pkgdepcache::autoinstall=true
[15:52] <mvo> ogra: (or dist-upgrade of course)
[15:53] <rom1v> will flash player 10 integrated in intrepid (medibuntu)?
[15:58] <kirkland> I'm hoping someone can provide me some background that I'm missing... I've heard multiple times now that there's efforts and hope inside of Ubuntu to do away with group-based permissions for devices.  pitti and mdz said as much in Bug #156085 ...  What's the reasoning and rationale for this?  Is it documented somewhere in the wiki?
[15:59] <ogra> mvo, hmm, no epiphany-borwser in there
[16:00] <ogra> how the heck does it get into the image ...
[16:02] <mvo> ogra: if you give me instructions what to look for (or how to reproduce etc) I can investigate
[16:03] <ogra> mvo, well, i just test the ubuntu-mobile liveimage (locally built using a modified livecd-rootfs)
[16:03] <ogra> and somehow epi shows up in there
[16:05] <ogra> the only thing i see in the seed that could even remotely cause that is totem-mozilla that has  Recommends: epiphany-browser | www-browser ... though midbrowser is in the seed and provides www-browser
[16:06]  * ogra waits for the publisher run to build a new image 
[16:07] <mvo> ogra: is it possible that install ordering plays a role here? i.e. that before midbrowser gets "markedInstall()" totem-mozilla is processed?
[16:07] <ogra> it might be
[16:07] <ogra> i have moved totem-mozilla to the very bottom of the seed file, but according to cjwatson that cant happen
[16:08] <ogra> we discussed such cases before
[16:08] <cjwatson> seeds shouldn't significantly influence the order in which apt does the marking
[16:08] <ogra> i just noticed there was still a task header in the seed file pointing to ubuntu-desktop ...
[16:08] <ogra> though i dont see how that could pull in epi either
[16:08] <cjwatson> the only way in which they could influence it would be by way of making the Packages file look different (e.g. the list of dependencies of a metapackage)
[16:09] <cjwatson> seed *ordering* has absolutely no effect on apt, either way
[16:09] <ogra> right
[16:09] <ogra> could the leftover task stuff have any influence ?
[16:09] <ogra> -Task-Key: ubuntu-desktop
[16:09] <ogra> -Task-Seeds: desktop-common
[16:09] <ogra> i just dropped this now
[16:09] <cjwatson> I can't imagine how
[16:10] <cjwatson> that affects tasksel, and the Task-Seeds has some effect on germinate's resolution algorithm, but that's all; neither of those are seen by apt
[16:10] <ogra> right
[16:10] <cjwatson> can I see the build log?
[16:11] <ogra> no, i dont have one
[16:11] <ogra> i wait for the publisher to promote the last ubuntu-mobile-default-settings, then i can do a new build and will log it
[16:12] <ogra> that should reveal something i hope
[16:15] <cjwatson> this is the sort of situation that has revealed bugs in apt in the past; unfortunately they tend to be very very subtle bugs in the sort of area where if you change it you break the rest of the distro
[16:16] <ogra> well, i wouldnt have a prob to apply a hack that removes epi if ubuntu-mobile is used in livecd-rootfs for the moment
[16:17] <ogra> if the above would be the actul case
[16:17] <ogra> *actual
[16:17] <ogra> but first lets see whats going on
[16:17]  * ogra pokes the publisher ... go ... copy to archive ... 
[16:31] <yao_ziyuan> intrepid's pidgin 2.5.1 has a bug related to "smooth scrolling"
[16:32] <yao_ziyuan> when it is enabled (it is, by default), the scrolling may not catch up with text flows in an irc channel
[16:32] <_Zeus_> really?
[16:32] <_Zeus_> can't confirm
[16:33] <yao_ziyuan> use intrepid alpha 6's pidgin to watch #wikipedia
[16:33] <yao_ziyuan> it's very hot right now
[16:33] <seb128> bugs should go on launchpad
[16:34] <yao_ziyuan> just disable smooth scrolling and the bug is gone
[16:37] <_Zeus_> im in #ubuntu
[16:38] <_Zeus_> yeah, sorry, i can't duplicate it
[17:16] <ogra> yay, finally the publisher has run
[17:16]  * ogra starts a new build
[17:31] <ldp> hello
[17:55] <cjwatson> today is one of those days when I wish I *really* understood termios
[17:55] <cjwatson> (bug 273189)
[17:59] <cjwatson> ah, this is what Stevens is for
[18:00] <ogra> cjwatson, hrm, looks like me removing the Task stuff from the seed http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/mobile.intrepid/revision/1307 results in the metapackage to fall apart http://paste.ubuntu.com/49371/
[18:01] <cjwatson> err, yeah, you probably ought to talk to me *before* removing Task headers from seeds ;-)
[18:01]  * ogra doesnt get why ... the mid seed doest have that section either
[18:01] <ogra> well, its bzr ... easily reverted
[18:01] <ogra> but i wonder why that didnt happen with mid
[18:01] <cjwatson> well, it depends what you want to happen
[18:01] <cjwatson> the stuff you had in the seeds said "please include everything in the desktop-common seed in this task"
[18:02] <ogra> i just found it not appropriate ... sine most of mobile duplicates desktop
[18:02] <cjwatson> by removing it, you have said that you no longer want that to happen, and germinate-update-metapackage is acting accordingly
[18:02] <cjwatson> it's not removing the entirety of your seed by any means
[18:02] <cjwatson> but if you want the stuff in desktop-common (NOTE THIS IS NOT DESKTOP) then you should leave it in; if you don't, you should remove it
[18:02] <ogra> no, just the stuff from desktop-common, i see
[18:02] <ogra> so i leave that one line ?
[18:03] <ogra> or the whole stuff from the top ?
[18:03] <cjwatson> the Task-Key: ubuntu-desktop was probably wrong, but you should replace it with a different key package, not remove it
[18:03] <ogra> ok
[18:03]  * ogra fixes
[18:03] <cjwatson> the point of Task-Key is to say that the task should only be displayed by tasksel if that package is present
[18:03] <cjwatson> if you remove it, then your task will appear on all installation media, which you don't want ;)
[18:04] <ogra> right
[18:04] <ogra> i'll change it to ubuntu-mobile instead
[18:04] <cjwatson> yes, that's reasonable
[18:22] <tkamppeter> pitti, hi
[18:47] <mathiaz> slangasek: hi - is the daily -server iso creation enabled again ? The last daily iso available on cdimage is 20080917.
[18:56] <mathiaz> radix: hi - I'm looking at bug 268765 - I'm not sure that an hourly cron job is necessary. Would a daily cron job be enough ?
[18:59] <mvo> hourly would certainly be more friendly to the servers and mirrors
[19:00] <mvo> eh, I mean, "daily would ..."
[19:00] <mathiaz> mvo: how often is update-notifier run ?
[19:03] <mvo> mathiaz: daily
[19:12] <slangasek> mathiaz: mmm, re-enabled now
[19:13] <slangasek> mathiaz: sorry, I think that was overlooked because I was waiting to hear back from mythbuntu
[19:13] <slangasek> superm1: ping
[19:13] <superm1> slangasek, yup disks looked good
[19:14] <slangasek> superm1: "disks" - 20080921?  I should push these as alpha-6 alternates?
[19:14] <superm1> yeah
[19:14] <superm1> that's the one i used
[19:23] <slangasek> superm1: published, cheers
[19:24] <superm1> thank slangasek
[19:25] <slytherin> Hi all. Can anyone please tell me whet is the reason daily builds are not done post alpha6?
[19:29] <slangasek> a delay in turning the cronjob back on, while waiting for one of the flavors to catch up
[19:35] <slytherin> slangasek: which flavor? lpia?
[19:35] <slangasek> flavor, not architecture; it was mythbuntu.
[19:35] <slytherin> oops
[19:35] <slytherin> slangasek: so when can I expect new daily build?
[19:36] <slangasek> within 24h
[19:36] <slytherin> cool. Thanks
[19:36] <slytherin> By the way, any idea why OOo is failing to build again for powerpc?
[19:39] <slangasek> well apparently, because it doesn't build on anything but x86 now
[19:39] <slytherin> :-(
[19:42] <slangasek> ERROR: error 65280 occurred while making /build/buildd/openoffice.org-2.4.1/ooo-build/build/OOH680_m17/bean/native/unix
[19:42] <slangasek> that's the ppc failure
[19:43] <slangasek> /usr/bin/ld: cannot find -ljawt
[19:43] <slangasek> and that's the root error
[19:57] <slytherin> looks something related to java, but have no idea why it is not failing on 386 for same reason.
[20:02] <slytherin> slangasek: just a hint, probably doko has more clue. The failure might be related to the fact that default-jdk on powerpc points to cacao and not openjdk.
[20:23] <mathiaz> slangasek: what do you think about asking openldap administrators if they want to convert slapd.d/ (as suggested in https://lists.ubuntu.com/archives/motu-council/2008-September/001528.html) ?
[20:25] <slangasek> mathiaz: what's the alternative to converting, if they say no?  I didn't think the code was still present to manage the package elsewise?
[20:26] <mathiaz> slangasek: right - if they say no, slapd/no_configuration could be set to no
[20:26] <slangasek> well, ok
[20:26] <mathiaz> slangasek: and basically none of the maintainers script would run
[20:27] <slangasek> in that case, this should be made very clear in the prompt
[20:27] <slangasek> but for my part, I don't think a question is /needed/
[20:28] <mathiaz> slangasek: considering that there is slapd/no_configuration, the advanced sysadmin could set it to no before doing the upgrade
[20:29] <slangasek> yes
[20:29] <slangasek> I certainly disagree that the config file format is an "essential decision" to be left in admins hands
[20:29] <mathiaz> slangasek: ok - so I'll make sure that slapd/no_configuration won't run any maintainer script.
[20:30] <slangasek> isn't that already the case?
[20:30] <mathiaz> slangasek: I think so.
[20:33] <slangasek> jdstrand: I think we need to put our heads together on bug #270328 at some point; it looks like we have some very bad interaction between auth-client-config and pam-auth-update, and I think auth-client-config probably needs to be commenting out more than it currently does
[20:34] <jdstrand> slangasek: what do you think needs to be commented out? it corrently comments out non-comments in a distinctive way
[20:35] <slangasek> jdstrand: it needs to comment out the comments :-)
[20:35] <jdstrand> slangasek: well, that is quite a change I think...
[20:35] <slangasek> jdstrand: there are certain comment lines that pam-auth-update uses as sentinels, and if they're not commented out, pam-auth-update will obliviously continue to update
[20:36] <jdstrand> slangasek: wouldn't it be easier to just check for pre_auth-client-config?
[20:36] <slangasek> the user in the bug report did: upgrade to new pam and get the pam-auth-update setup; run auth-client-config (somehow, even though he didn't know it); then upgrade something that triggered pam-auth-update again and broke the world
[20:37] <slangasek> well, currently pam-auth-update treats any of those lines verbatim
[20:37] <slangasek> I guess we could argue about which tool's responsibility it is to parse comments ;)
[20:37] <jdstrand> slangasek: I am not totally up on the pam-auth-update mechanism, but it seems the problem was the 3rd step
[20:38] <slangasek> sure
[20:38] <jdstrand> slangasek: it didn't honor changes made by the user via auth-client-config
[20:38] <jdstrand> (side-stepping the fact that the user didn't know he did that)
[20:38] <jdstrand> slangasek: but, maybe I don't see the whole picture...
[20:39] <jdstrand> s/user/user claims he/
[20:39] <slangasek> well, I'm arguing that auth-client-config should be the tool that stops the third step from destructively munging stuff, rather than asking pam-auth-update to recognize auth-client-config specifically
[20:41] <jdstrand> slangasek: I can see that, but I can also see that it the user uses a tool to update his pam config, then it is conceptually the same as the user doing it without the tool
[20:41] <jdstrand> slangasek: and pam-auth-update should detect that, no?
[20:41] <mathiaz> slangasek: hm - manual_configuration_wanted is only called with a new install is made - not in postinst_upgrade_configuration.
[20:41] <slangasek> can you propose a method for detecting it reliably?
[20:42] <jdstrand> slangasek: yes-- grep for pre_auth-client-config
[20:42] <slangasek> jdstrand: er, no
[20:42] <slangasek> jdstrand: a method for detecting reliably /that a user has updated his config without the tool/ that will break things
[20:43] <jdstrand> slangasek: no-- like I said I don't know the pam-auth-update system
[20:43] <jdstrand> slangasek: but I was talking conceptually
[20:43] <slangasek> jdstrand: the assumption that pam-auth-update makes is that if the magic comments are present, everything between them is to be managed by pam-auth-update
[20:43] <jdstrand> ie, the admin actively did it as opposed to packaging, etc
[20:44] <slangasek> right; and conceptually, pam-auth-update currently treats the two cases the same - if you comment out these lines, using auth-client-config or by hand, things will break ;)
[20:45] <jdstrand> slangasek: so you look for the sentinel, if it is there, you (effectively do a) sed?
[20:45] <slangasek> effectively
[20:46] <jdstrand> slangasek: so non-matching 'sed' lines are ignored?
[20:47] <jdstrand> (left in)
[20:47] <slangasek> well, it's not exactly line-based so the analogy breaks down somewhat; but yes
[20:47] <slangasek> there's actually a whole block that's left untouched, with the expectation that it's provided by the template and doesn't require management
[20:48] <jdstrand> slangasek: so if a user is reckless and doesn't remove the sentinels but adjusts by hand, is there detection for that?
[20:48] <slangasek> and then there's a block which is parsed and then overwritten
[20:48] <slangasek> no; if there were detection for that, we shouldn't need sentinels...
[20:48] <jdstrand> slangasek: so you are asking if I could also comment out the sentinels?
[20:49] <slangasek> yes
[20:50]  * ogra cries
[20:51] <jdstrand> slangasek: this is likely not something I can do well before beta
[20:52] <jdstrand> slangasek: it will likely require quite a bit of testing
[20:52] <slangasek> jdstrand: do you agree with it in principle, or should I find a different approach?
[20:52] <jdstrand> slangasek: I'm not sure I agree-- cause it only fixes part of the problem-- a reckless user still gets in trouble
[20:53] <jdstrand> slangasek: is it possible to compare what you expect to be there with what is there?
[20:53] <slangasek> only by encoding the information about that block in places I didn't want to have it
[20:53] <slangasek> the intention was to have this section managed entirely via the template
[20:54]  * jdstrand thinks
[20:57] <jdstrand> slangasek: is there some sort of a hook you use to call the pam-auth-update mechanism?
[20:58] <slangasek> it's called from maintainer scripts of packages which provide PAM modules
[20:58] <jdstrand> slangasek: btw, a quick way to fix this for beta is to scan for that string I mentioned, until a proper solution is found
[20:58] <slangasek> and may end up in the System->Administration menu for intrepid if all goes well
[20:59] <slangasek> jdstrand: I'm not sure why having pam-auth-update scan for that string is any quicker or less error-prone than having auth-client-config modify the sentinel comments :-)
[20:59] <jdstrand> slangasek: I was just thinking maybe something could be done in preinst-- before anything is unpacked, to try to capture the current state of things
[20:59] <slangasek> the preinst of what?
[21:01] <jdstrand> the packages being updated. but this is more 'thinking out loud' to fix the 'reckless user' scenario
[21:01] <slangasek> there shouldn't be any need to resort to a preinst
[21:02] <slangasek> since the only thing touching the config is pam-auth-update itself, which could save the state; but I don't think that's the issue, we want to keep the config from getting broken, not just save a copy of the good config :-)
[21:03] <jdstrand> slangasek: right-- but if the saved state is not what you expect it to be, then you've caught your reckless user, haven't you?
[21:03] <slangasek> oh, you're asking to save the template block
[21:03] <jdstrand> I'm not suggesting anything, other than thinking of a way to detect user changes
[21:04] <jdstrand> :)
[21:04] <jdstrand> trying to think of a way...
[21:04] <slangasek> I think I'd almost rather have pam-auth-update know directly what pam modules are supposed to be in that block, hmm
[21:04] <slangasek> which isn't a good idea, for $handwavy_reason
[21:10] <jdstrand> slangasek: is it fair to say that auth-client-config cannot be used with the new pam framework?
[21:10] <slangasek> jdstrand: the config needs to be controlled by one or the other; they don't play well together
[21:10] <jdstrand> slangasek: meaning, a user prefers to use auth-client-config
[21:10] <jdstrand> ok
[21:10] <slangasek> given that a-c-c comments out key bits of the pam-auth-update stack :-)
[21:11] <jdstrand> but a user can't really choose to use auth-client-config anymore-- as pam-auth-update is in packaging
[21:11] <slangasek> but, /if/ pam-auth-update detects "manual" editing of the file (like, the sentinel comments have gone away), the next pam-auth-update call will ask a one-time question of whether the user wants to overwrite
[21:11] <slangasek> (defaulting to 'no')
[21:12] <jdstrand> slangasek: yes, and I see that I can make auth-client-config work by doing that. I just wonder about other tools, homegrown scripts, admins, etc
[21:13] <slangasek> anything that overwrites the PAM config completely will be detected by pam-auth-update
[21:13]  * jdstrand nods
[21:13] <jdstrand> basically, the sentinel has to be gone
[21:13] <slangasek> and editing the options passed to the managed PAM modules will be handled transparently, with no need to choose
[21:14] <slangasek> it's just the case of leaving those sentinels in place, but commenting out other bits of the framework, yes
[21:15] <jdstrand> slangasek: are these sentinels expected to change, be added to, etc?
[21:15] <slangasek> the sentinels themselves should never change
[21:18] <jdstrand> slangasek: I didn't realize beta freeze is on the 25th-- there is really no way I can do this before then
[21:18] <jdstrand> slangasek: I can try to get a fix going-- but auth-client-config might need to be removed if I can't
[21:19] <slangasek> well, if we agree on the solution, I think I could get some time in on implementing it?
[21:19] <jdstrand> slangasek: I'd really prefer some way to detect user changes, as people are still going to shoot themselves in the foot regardless of what happens with a-c-c
[21:20] <slangasek> detecting user changes reliably in all cases would have to come at the expense of some of the smoother management features, I fear
[21:23] <jdstrand> slangasek: is it unreasonable to grep for pre_auth-client-config and prompt the user saying there were user changes? or does the fact that the sentinels are there, regardless of detecting the a-c-c string, cause other issues?
[21:23] <kirkland> bryce: hiya, i was wondering if you had any thoughts on: https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/218105
[21:24] <slangasek> jdstrand: the only issue I have with grepping for pre_auth-client-config is that it means pam-auth-update will treat a-c-c-altered config files different from those edited directly by the user
[21:25] <jdstrand> slangasek: that might be where there is a disconnect-- I don't see a difference between user changes via a-c-c and a text editor. can you explain?
[21:25] <slangasek> jdstrand: er, a-c-c will have added a "pre_auth-client-config" line, and a user would not?
[21:25] <jdstrand> (conceptually)
[21:26] <slangasek> so at that point, we're special-casing a-c-c :)
[21:26] <jdstrand> slangasek: well, obviously :)
[21:27] <jdstrand> slangasek: I guess my point is that you are able to capture one class of user changes fairly easily in this manner. another class is those who do remove the sentinals. (a-c-c is obviously a subclass of those who don't remove them, but at least you can catch some)
[21:28]  * slangasek happens, in a timely fashion, across a post on pam-list@ about LDAP authentication problems on a Red Hat system, fixed by typing: "authconfig --enablemd5 --enableldap --enableldapauth --ldapserver=10.100.223.63 --ldapbasedn="dc=ldaptest,dc=local" --enableldaptls --enablecache --enablelocauthorize --enablesysnetauth"
[21:28] <jdstrand> slangasek: I also recognize that you don't want to be special casing all kinds of stuff
[21:29] <slangasek> gee, I'm glad we don't have authconfig
[21:30] <slangasek> jdstrand: right; I still think it'd be better if a-c-c commented out the sentinel lines, but if you're not convinced of this, I'll look for them in pam-auth-update
[21:34] <jdstrand> slangasek: hmm... seems that if there isn't a way to check for these things, then I have to change a-c-c
[21:34] <slangasek> hmm?
[21:35] <slangasek> there is a way, 1) I write code to check for a-c-c comments, 2) I upload it :)
[21:35] <jdstrand> slangasek: well, yes-- but you didn't seem to like that
[21:35] <slangasek> I don't
[21:35] <jdstrand> slangasek: really I care about wasted effort
[21:35] <slangasek> just like you don't like the alternative :-)
[21:35] <jdstrand> whether it's yours or mine is no matter
[21:36] <jdstrand> slangasek: I was hoping to be able to detect the class of problems of users not removing the sentinels-- in which case a-c-c is covered
[21:37] <jdstrand> slangasek: if that is not possible, I acquiesce that a-c-c should be changed-- as it seems to be the only other program to modify pam configuration in Ubuntu, and the alternative is it breaks things
[21:38] <jdstrand> and by 'it' I of course mean pam-auth-update :P
[21:38] <slangasek> in the future we might be able to detect the class of problems; but I think that's subtle enough that it's not likely to be done before beta, either
[21:40] <jdstrand> slangasek: I'll give it a go
[21:41] <slangasek> ok
[21:42] <ogra> cjwatson, still here ?
[21:43] <bryce> kirkland, taking a look
[21:43] <slangasek> jdstrand: thanks for your patience :)
[21:43] <ogra> cjwatson, i tried mvo's suggestion to use apt-get install -o debug::pkgdepcache::autoinstall=true ubuntu-mobile, there is a ton of stuff that doesnt belong into the seed http://people.ubuntu.com/~ogra/log
[21:43] <kirkland> bryce: thx!
[21:44] <jdstrand> slangasek: sure. I just updated the bug accordingly
[21:45] <ogra> Installing epiphany-browser as dep of totem-mozilla ...
[21:45] <ogra> Installing xscreensaver as dep of xscreensaver-gl
[21:46] <ogra> recommends are definately not resolved correctly
[21:46] <slangasek> ogra: what's not correct with the above?
[21:47] <ogra> totme-mozzilla: Recommends: epiphany-browser | www-browser
[21:47] <ogra> the metapackage depends on midbrowser which provides www-browser
[21:47] <slangasek> and it's not correct because another www-browser is already installed?
[21:47] <slangasek> ah
[21:48] <slangasek> the package is ubuntu-mobile?
[21:48] <ogra> xscreensaver-gl should be fulfilled with gnome-screensaver but pulls in xscreensaver additionally
[21:48] <ogra> right
[21:48] <ogra> using livecd.sh
[21:48] <ogra> so only apt is involved
[21:48] <ogra> no germinate or something
[21:48] <slangasek> looks like totem-mozilla and midbrowser are both recommends rather than depends
[21:49] <slangasek> but the ordering should still be correct
[21:49] <ogra> right
[21:49] <ogra> there shouldnt be any depends
[21:49] <slangasek> i.e., Recommends: midbrowser should be resolved first, such that it's satisfied before reaching totemz-mozilla
[21:49] <slangasek> sounds like an apt bug, then
[21:50] <ogra> strange
[21:50] <ogra> it should show up on the ubuntu-desktop cds as well then
[21:50] <ogra> or i have a newer apt than the build chroot
[21:51] <bryce> kirkland, yeah sounds like kvm needs to learn about libXrandr ;-)
[21:52] <kirkland> bryce: okay, can you drop a note to that effect in the bug?  any pointers would be hot ;-)
[21:52] <bryce> kirkland, I see similar such weird behaviors with most apps that take over full screen - games, mplayer, etc.
[21:52] <bryce> alright
[21:52] <ogra> mvo, can we look into that tomorrow ? ^^^
[21:52] <kirkland> bryce: cool, maybe just reference another source package i could look at for proper behavior
[21:56] <mvo> ogra: sure
[21:56] <mvo> ogra: if you mail the full log I'm happy to check it out
[21:57] <ogra> mvo, http://people.ubuntu.com/~ogra/log
[22:12] <bryce> kirkland, ok I filled in some info on bug #218105
[22:12] <kirkland> bryce: big thanks
[22:13] <bryce> kirkland, if you do get that fixed up, I'd be interested in seeing the patch.  I suspect there's a lot of client apps that'll need similar fixing up (games particularly)
[22:13] <kirkland> bryce: do you think this is doable for intrepid, or too invasive given FF?
[22:13] <bryce> too invasive
[22:14] <kirkland> bryce: k, thanks.
[22:14]  * bryce ponders
[22:14] <kirkland> bryce: i'll keep you in the loop
[22:14] <bryce> there's actually several different bugs there, maybe one could be addressed
[22:14] <mdke> andrew_sayers: around?
[22:15] <andrew_sayers> mdke: yeah.
[22:15] <mdke> andrew_sayers: could we move to #ubuntu-doc?
[22:15] <andrew_sayers> Sure.
[22:16] <bryce> kirkland, nope, I think you're going to need to code up something to hook into libXrandr, and that'll be a non-trivial bit of code, and will take a good bit of testing
[22:17] <bryce> kirkland, depends a lot on how your fullscreen routine is implemented - if it already knows xrandr but is just incomplete, that might be workable, but I'll bet it's completely xrandr-ignorant so is going to take a couple week's work to code something up
[22:17] <kirkland> bryce: okay, no problem.  we'll try to address that upstream with kvm between intrepid/jaunty then
[22:17] <ion_> If i start a guest session, it doesn’t seem to receive any keyboard/mouse events.
[22:18] <ion_> I don’t even have to ctrl-alt-Fx away from it, alt-Fx is enough.
[22:18] <kirkland> bryce: grep -r xrandr on kvm sources = 0 hits
[22:18] <bryce> hah
[22:18] <bryce> well, try grep -ir randr
[22:21] <geser> bryce: do you know if xserver-xorg-video-radeonhd is still actively developed? I ask because I see RV6xx sometimes mentioned in the changes for the -ati driver and wonder now if I still have the preferred driver for a RV670 based card installed (I use currently -radeonhd)
[22:22] <bryce> geser, afaik there's still development on it, but -ati is the one getting most of the focus now
[22:23] <bryce> geser: have you tried -ati with that card?
[22:23] <geser> not yet, when I bought the card I installed -radeonhd as the description mentioned the used chipset
[22:24] <geser> will try -ati the next days
[22:24] <jcristau> geser: yes, it's still being actively developped by novell
[22:32] <bryce> geser: fwiw, I have a rv635 that works with -ati, and I see RV670 mentioned in the source code so presumably it's supported
[22:42] <geser> bryce: I've done a quick check with -ati and it works (I guess it's using the radeon module)
[22:42] <geser> do you know which one it better? -radeon or -radeonhd?
[22:46] <cjwatson> ogra: I have a suspicion that installing it as a task rather than as a metapackage will help
[22:46] <bryce> geser: -radeon should pretty much have everything -radeonhd has, plus has support for older cards going back quite a ways.  I'd suggest using -radeon over -radeonhd
[22:46] <ogra> cjwatson, well, but livecd-rootfs doesnt do tasks
[22:46] <cjwatson> ogra: that ought to mark all the packages in the task for install *first*, and *then* go through resolving missing dependencies/recommendations
[22:47] <cjwatson> ogra: sure it does!
[22:47] <bryce> geser: in Ubuntu we really only officially QA -radeon, not -radeonhd, so if there are bugs with the former we'll help troubleshoot, but with the latter you're more on your own
[22:47] <geser> bryce: thanks
[22:47] <cjwatson> ogra: that's what those "^" symbols are for
[22:47] <ogra> cjwatson, oh ? how ?
[22:47] <ogra> ah
[22:47] <cjwatson> ogra: however, ubuntu-mobile doesn't have a task yet; we'd need to get that fixed
[22:47] <cjwatson> which requires a Launchpad code change ...
[22:48] <cjwatson> can you mail me a reminder to take that up with Team Soyuz?
[22:48] <ogra> cjwatson, meh, mid neither, i just copied the mid stuff and renamed s/mid/mobile/
[22:48] <cjwatson> ogra: (this may be why we don't have this problem in the desktop, because we use tasks there)
[22:48] <ogra> cjwatson, will do, thanks
[22:48] <ogra> yeah
[22:48] <ogra> indeed
[22:49] <cjwatson> we just need to have Soyuz pay attention to the mobile seeds when doing task generation
[22:49] <ogra> seems mid is the only metapackage without using ^
[22:49] <ogra> in the code ...
[22:50] <cjwatson> the mid seed doesn't even have any Task-* headers
[22:50] <ogra> wasting my day on a missing ^ ... yay
[22:50] <ogra> yeah
[22:50] <ogra> thats what made me drop mine first
[22:50] <ogra> it might even be fine for mid, not sure
[22:51] <cjwatson> by luck, perhaps
[22:51] <ogra> well, most hildon pkgs are native and have hard deps
[22:51] <ogra> i doubt you'll find many recommends there anyway
[22:51] <cjwatson> this has nothing to do with recommends AFAICS
[22:52] <cjwatson> it's purely about the order in which broken dependencies are resolved
[22:52] <ogra> but they all come from recommends here
[22:52] <ogra> at least for me
[22:52] <cjwatson> (er, sorry, perhaps that was confusing - by "broken" I mean "temporarily broken while apt has installed the top-level stuff but not resolved the dependencies yet")
[22:52] <cjwatson> ogra: understood, but I think you'd see precisely the same effect if they were dependencies
[22:52] <cjwatson> that's what I mean
[22:52] <ogra> which appear to be resolved in a backwards order
[22:52] <ogra> ah
[22:53] <cjwatson> it's an ordering problem, not a dependency vs. recommendation problem
[22:53] <ogra> yeah
[22:53] <ogra> understood
[22:53] <cjwatson> the problem (I think) is that apt is resolving the dependencies depth-first rather than breadth-first
[22:54] <cjwatson> so it goes:
[22:54] <cjwatson>  ubuntu-mobile
[22:54] <cjwatson>   -> totem-mozilla
[22:54] <ogra> yeah, i had something similar with java
[22:54] <cjwatson>    -> epiphany-browser | www-browser (pick epiphany-browser)
[22:54] <cjwatson>   -> midbrowser (oh dear, never mind)
[22:54] <ogra> right
[22:55] <cjwatson> germinate actually does the same kind of thing, but (like apt with task installation) it starts by installing all the seed entries, and then iterates through resolving their dependencies one by one (depth-first)
[22:55] <cjwatson> whereas here you're starting with a single package and going depth-first
[22:56] <ion_> Does aptitude have equivalent behavior?
[22:57] <cjwatson> I suspect that finding the optimal set to install is computationally hard (not wanting to throw around terms like NP-complete casually but it wouldn't surprise me) and that there is no particularly easy simplification
[22:57] <cjwatson> I haven't checked aptitude, but it's a perfectly natural way for a dependency resolver to work
[22:57] <cjwatson> you don't skip around between nodes of the tree because that makes backtracking a complete pain in the arse
[22:58] <cjwatson> so I am very reluctant to claim it as an apt bug as such
[22:59] <cjwatson> it's certainly not optimal, but other similar simplifications of the global hard problem probably also have their drawbacks
[23:01] <ogra> reminder mailed
[23:02] <cjwatson> thanks
[23:03]  * ogra seees apt-proxy hanging the 10th time on python-gtkglext1 and decides its time to find a stable apt proxy implementation
[23:05] <ogra> so someone said i should try approx ... lets see
[23:05] <mathiaz> ogra: I've been using apt-cacher-ng
[23:05] <mathiaz> ogra: and it works well for me.
[23:05] <ogra> well, apt-proxy used to work well for me the last years ...
[23:05] <ogra> but i'm getting tired of the hangs
[23:06] <mathiaz> ogra: right - I used apt-proxy for a while but also found that it would hang often.
[23:09] <stgraber> ogra: I'm also using apt-cache-ng on some servers, work fine.
[23:09] <stgraber> at home I usually have a transparent squid proxy so I don't need it
[23:10] <ogra> well, i like the fact that i can carry my archive with me on the laptop
[23:10] <ogra> so i prefer local proxies for that stuff
[23:10] <stgraber> ok, so apt-cacher-ng is what you need
[23:53] <slangasek> mathiaz: hum, are you going through the u-m-s list at the same time as me? :)
[23:53] <mathiaz> slangasek: nope
[23:53] <slangasek> oh, ok
[23:54] <slangasek> just the one bug then :)
[23:54] <mathiaz> slangasek: I've already been working on the landscape-client bug
[23:54] <slangasek> ah