[00:03] <YokoZar> Is the new volume control applet an Ubuntu-originated thing or an upstream thing?
[00:03] <YokoZar> (or both)
[00:05] <persia> I was under the impression there was a new upstream for it that had so far only been adopted in Ubuntu.
[00:18] <TheMuso> YokoZar: The new volume control is a DX team thing afaik.
[02:11] <lfuser-119> hello.
[03:58] <jdong> *scratches head*
[03:58] <jdong> what are the new lucid compiz bindings?
[03:58] <jdong> I just noticed super-a seems to do what alt-shift-up used to do
[04:02] <jdong> never mind, ccsm answered that question
[04:18] <RoAkSoAx> jdong, shoudl bug 530945 stay as backport or should be a SRU ?
[04:19] <jdong> RoAkSoAx: if the debdiff in #5 on the orig bug is correct, then SRU
[04:19] <jdong> or something equally trivial
[04:20] <RoAkSoAx> jdong, ok thanks. I'll change the bug report then :)
[04:27] <arose> Is there anyone who is even remotely responsible for maintaining xfonts-base, and more specifically the misc-fixed fonts? It's kind of frustrating to see that 4 (or 2 depending on perspective) old changes from upstream haven't been integrated
[04:28] <crimsun> arose: X Strike Force <debian-x at lists dot debian>
[04:40] <arose> Seems it finally has been merged... Would be nice to know not to waste time reporting bugs in launchpad in the future...
[05:26] <TheMuso> 7/c
[06:07] <robert_ancell> TheMuso, are you familiar with the new package process to add a package to Universe?
[06:07] <robert_ancell> growlf (one of the developers of gdm2setup) is working on getting that into Universe (bug #531138)
[06:09] <robert_ancell> growlf, it should be called "gdm2setup" not "python-gdm2setup".  The "python-" prefix is only required for libraries
[06:10] <growlf> Ahh.  ty.  Shall I change that in the bug?
[06:10] <ScottK> Also we're past feature freeze for Lucid, so it'll need a compelling justification for getting in now.
[06:11] <growlf> Do you want that here and now - or in an email?
[06:11] <ScottK> In the bug.  It needs to get made into a feature freeze exception request
[06:11] <robert_ancell> ScottK, does that apply for packages in Universe?
[06:12] <ScottK> robert_ancell: Absolutely.
[06:12] <robert_ancell> ok
[06:12] <growlf> Ah. ok.
[06:12] <growlf> Thank you.  Once I have that in - what is the next step I should take?
[06:13] <robert_ancell> growlf, So my guess is that this wouldn't be included in Lucid (as it is easily installable from the PPA)
[06:13] <robert_ancell> ScottK, Should the bug subscribe any groups? There doesn't seem to be any info in https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages as to who to pass the bug to
[06:14] <ScottK> Subscribe ubuntu-release.  Look for general feature freeze exception information.
[06:15] <robert_ancell> ScottK, and if it wasn't in feature freeze?
[06:15] <ScottK> New packages get reviewed on REVU
[06:15] <ScottK> !REVU
[06:24] <robert_ancell> growlf, ok, next step upload to revu as in the above comment
[06:30] <dupondje> linux-backports-modules-nouveau-2.6.32-15-generic still in NEW ?
[06:31] <dupondje> yep seems so :( and now nouveau is broken because of it :
[06:31] <dupondje> :(
[06:31] <StevenK> I'm working on it
[06:34] <ejat> how about the other php-* ?
[06:34] <Chipzz>  
[06:39] <StevenK> dupondje: Accepted. It will take around 90 minutes, at best, to hit archive.u.c
[06:41] <ejat> StevenK: owh ok thanks .. how bout the other php-* package?
[06:42]  * persia highly suggests leaving archive admins to their work unless something is blocking a critical development workflow or is exceptional.  Time spent on IRC is time not spent processing the queues.
[06:42] <lifeless> I suggest replacing archive admins with a small cron script.
[06:43] <StevenK> ejat: No php-* packages are in NEW, the only one I can find is mapserver
[06:43] <persia> lifeless: For some AA work, I think we can replace with a python script, but some of it still requires human intelligence (although the tools are slowly improving).
[06:43] <lifeless> persia: indeed
[06:44] <ejat> StevenK: but it will remove some other package rite?
[06:44] <persia> (but there's 3 bugs that need be sorted before the python script can be deployed)
[06:44] <StevenK> ejat: I'm not sure I understand what you mean.
[06:45] <ejat> StevenK: http://paste.ubuntu.com/387442/
[06:46] <StevenK> ejat: I have no idea why that is.
[06:46] <persia> ejat: Those packages need porting.  That needs a developer, not an archive-admin.
[06:46] <persia> (or else your archive is out of date)
[06:46] <ejat> StevenK + persia .. ok thanks for the acknowledgement ..
[07:13] <kirkland`> pitti: could you accept the most recent eucalyptus package for karmic-proposed?
[07:15] <dupondje> StevenK: thanks :)
[07:24] <lucent_> innocent question here, where to learn modern methods for adding Ubuntu package generation from a project source code?
[07:24] <lifeless> #ubuntu-motu is a good place to chat about that
[07:25] <lucent> thanks!
[07:32] <lucent> lifeless: it's kind of quiet in -motu
[07:33] <lucent> I wonder if the process is any different than http://www.debian.org/doc/maint-guide/
[07:35] <didrocks> highvoltage: stgraber: thanks :)
[07:40] <pitti> Good morning
[07:41] <pitti> sebner: in that generality, no; please file a bug with "ubuntu-bug storage"
[07:41] <pitti> kirkland`: will do SRUs soon again
[08:20] <dholbach> good morning
[08:22] <mtx_init> Good Night here in NY
[10:05] <dholbach> ArneGoetje, Riddell: I was having a look at bug 463181 - seems like kde-i18n-zhcn is not in lucid any more?
[10:27]  * cjwatson speeds up grub-probe filesystem queries by a factor of >10
[10:28] <cjwatson> I like lots-of-bang-for-your-buck work
[10:37] <ev> nice!
[10:54] <tseliot> mvo: I think bug #467490 is really bug #459829 which should be fixed, at least in theory. Any ideas?
[10:55] <Riddell> dholbach: yes kde-i18n-zhtw isn't in lucid, it was translations for KDE 3
[10:56] <dholbach> ArneGoetje: ^
[10:56] <dholbach> thanks Riddell
[11:00] <tseliot> cjwatson: is it ok to perform other operations after doing a db_stop in postinst scripts?
[11:00] <cjwatson> what kind of operations?
[11:01] <cjwatson> you should, in general, not use db_stop at all unless you are absolutely sure you know what it does
[11:01] <tseliot> cjwatson: even things such as rm -f some_file
[11:01] <cjwatson> it's a workaround for things better handled in other ways
[11:01] <cjwatson> rm -f is fine
[11:01] <pitti> cjwatson: oh, it's that much "not recommended"?
[11:01] <cjwatson> but db_stop can break things you really don't expect
[11:01] <cjwatson> pitti: yes
[11:01] <pitti> cjwatson: I usually do it after I know I'm done with it, since later stderr output used to confuse it
[11:02] <cjwatson> please don't - I can advise on other, better approaches
[11:02] <cjwatson> it doesn't even really help much with that
[11:02] <cjwatson> in many situations, STOP is effectively ignored (e.g. within the installer), so you need to make sure output doesn't go to debconf anyway
[11:03] <pitti> cjwatson: ok, thanks; it's been years since I touched debconf, should I ever get to that case again, I'll do RTFM
[11:03] <cjwatson> the only thing STOP was ever really useful for was making sure to disconnect debconf fds from daemons, and it's better to close fds explicitly at daemon startup
[11:03] <cjwatson> basically it's nothing but trouble :)
[11:03] <tseliot> cjwatson: I was asking as this script doesn't seem to remove the file (possibly because of dpkg --compare-version): http://pastebin.ubuntu.com/387535/
[11:04] <cjwatson> that's completely wrong
[11:04] <cjwatson> just delete the db_stop, what's it for anyway!
[11:05] <cjwatson> I don't think it would cause the script not to remove the file, though
[11:08] <tseliot> cjwatson: so if I remove db_stop will debconf require user interaction and execute my .config script? (just to be sure)
[11:12] <cjwatson> tseliot: after calling db_stop, any following debconf commands may *break*.  it's not a clean shutdown
[11:12] <cjwatson> tseliot: in any case, if that's in a postinst, the config script is executed before that db_stop - so it won't make any difference to that
[11:12] <cjwatson> tseliot: if you don't want the config script to interact with the user, then don't call db_input/db_go in it :-)
[11:13] <tseliot> cjwatson: ah, so is it wrong to call db_stop at the end of the .config script too? http://pastebin.ubuntu.com/387542/
[11:13] <tseliot> (this is in nvidia-common)
[11:14] <tseliot> it seemed to make sense when I read the documentation (a long time ago)
[11:14] <cjwatson> it's almost always wrong to call db_stop at all
[11:14] <cjwatson> yes, it's wrong there
[11:15] <tseliot> cjwatson: ok, thanks
[11:15] <cjwatson> just remove it from both your config and postinst, and things will probably work better with no downside :)
[11:15] <tseliot> sure
[11:37] <tseliot> cjwatson: I get no debconf prompt if I remove db_stop
[11:38] <cjwatson> run with DEBCONF_DEBUG=developer to see what it's doing
[11:38] <cjwatson> the question's probably just marked as seen from a previous run, or something
[11:40] <tseliot> cjwatson: do you mean export DEBCONF_DEBUG=developer and install the package?
[11:40] <tseliot> as it doesn't show anything this way
[11:41] <tseliot> or is it something that I have to put in either the .config script or in the postinst script?
[11:42] <cjwatson> I mean export DEBCONF_DEBUG=developer; if that isn't showing anything then perhaps your sudo configuration is eating the environment variable.  Try 'sudo DEBCONF_DEBUG=developer ...'
[11:43] <tseliot> ah, ok
[11:45] <tseliot> cjwatson: yes, that worked: http://pastebin.ubuntu.com/387559/
[11:47] <tseliot> cjwatson: I guess it's my fault. Thanks for your suggestion
[11:47] <cjwatson> tseliot: right, so by the looks of things either /usr/bin/nvidia-detector doesn't exist or nvidia-detector returns none
[11:48] <tseliot> the latter
[11:48] <cjwatson> tseliot: that config script has another serious bug right now
[11:48] <tseliot> cjwatson: oh, what is it?
[11:48] <cjwatson> tseliot: config scripts may only use things on the filesystem that are in Essential packages, plus debconf itself
[11:48] <cjwatson> because they're run at preconfiguration time
[11:48] <tseliot> oh
[11:49] <cjwatson> tseliot: if you have to use nvidia-detector, then you need to move all that stuff to the postinst; the cost is that you lose preconfiguration
[11:49] <cjwatson> if nvidia-detector is a relatively simple shell script then you might be able to embed it in the config script as an alternative, or something
[11:50] <tseliot> cjwatson: what do you mean? I'm already sourcing /usr/share/debconf/confmodule in the postinst
[11:50] <tseliot> nvidia-detector is a python script which relies on a library included in the same package
[11:53] <cjwatson> tseliot: but when the config script is executed, your package may not have been unpacked yet
[11:53] <cjwatson> /usr/share/debconf/confmodule is safe because it's in debconf; config scripts may rely on Essential packages *plus debconf*
[11:54] <tseliot> cjwatson: right. Is there a way to call the config script in the postinst?
[11:55] <cjwatson> tseliot: if you want that, just move the contents of the config script into the postinst, and delete the config script
[11:55] <tseliot> I need to warn users about the fact that they're using an obsolete driver with a UI
[11:56] <cjwatson> the only purpose of having a separate config script is to enable preconfiguration; if the structure of your questions is such that you can't use preconfiguration, then there's no point having a separate config script
[11:56] <cjwatson> as long as you know that doing it this way means that upgrades will be interrupted in the middle to ask a question
[11:57] <cjwatson> that said I suppose you're testing whether the binary exists
[11:57] <tseliot> cjwatson: yes, this shouldn't interrupt upgrades with update manager as u-m deals with these things first (right mvo?)
[11:57] <cjwatson> but what happens if this is a new installation?
[11:57] <cjwatson> tseliot: er, no!
[11:57] <cjwatson> tseliot: update-manager isn't special in this regard
[11:58] <cjwatson> it doesn't magically reach in and run config scripts in a screwy way
[11:58] <tseliot> cjwatson: I think update-manager includes part of nvidia-common already
[11:58] <cjwatson> that is done by debconf, in the manner I described
[11:58] <cjwatson> tseliot: we can't have correctness depend on people using update-manager
[11:59] <tseliot> cjwatson: so the debconf UI will be used only for example if users dist-upgrade from the command line
[11:59] <cjwatson> tseliot: the way you have it written right now, any upgrade using apt will use (at best) the version of nvidia-detector from the previous installed version of the package
[11:59] <mvo> tseliot: sorry, I was not following the discussion. u-m includes parts of nvidia-common to do detection and removal of old drivers. but it should still work for people without (as cjwatson said). but if that means that people using apt-get see a debconf dialog in the middle of the upgrade that is IMO acceptable
[11:59] <cjwatson> mvo: the thing is that it will get the logic wrong ... it'll use the previous version of nvidia-detector, etc.
[11:59] <tseliot> right
[11:59] <cjwatson> or maybe no version at all
[12:00] <mvo> cjwatson: oh, sorry. I missed that bit of the discussion
[12:00] <cjwatson> so it really needs to be moved into the postinst
[12:00] <cjwatson> if update-manager has special nvidia-specific logic to make sure obsolete drivers go away before this question is even asked, basically duplicating the logic, then that's fine
[12:01] <tseliot> yes, I assume that's the way it works now
[12:01] <cjwatson> I agree that it's acceptable for people using apt-get to see a debconf dialog in the middle, if there's no alternative and if update-manager works around that bit specially.  what isn't acceptable is for upgrades using apt-get to actually be *wrong*
[12:01] <tseliot> mvo: is this correct?
[12:02] <cjwatson> so in that case, the correct fix is indeed to move the config script contents into the postinst
[12:02] <tseliot> yes, definitely, that's a bug
[12:02] <mvo> tseliot: update-manager has this logic, it embeds bits of nvidia-common from lucid on build and runs in on karmic->lucid (and hardy->lucid of coruse)
[12:03] <mvo> I have not tested if its still working, but if the interfaces have not changed it should
[12:03] <mvo> the code around it in u-m has not changed
[12:04] <tseliot> cjwatson: so I should get rid of the config script and use this as the postinst script, right? http://pastebin.ubuntu.com/387565/
[12:05] <mvo> tseliot: I'm happy to look at the u-m integration/test it after UI freeze
[12:05] <tseliot> mvo: so that should work and I only have to fix the bug in nvidia-common so that we cover both cases correctly
[12:05] <mvo> tseliot: ok, cool
[12:05] <cjwatson> tseliot: you need to put '. /usr/share/debconf/confmodule' on the second line, and you can maybe get rid of the [ -x /usr/bin/nvidia-detector ] test now if that binary is in the same package or a package you depend on; otherwise, yes, that looks fine
[12:07] <tseliot> cjwatson: yes I forgot to paste the line that sources debconf
[12:07] <tseliot> ok, let me try again
[12:12] <tseliot> cjwatson: it works great now. Thanks for your help
[12:12] <cjwatson> np
[12:30] <apw> cjwatson, we looked at the kernel package section use and fixed them sometime back with a patch from you irrc, are you happy with that
[12:30]  * apw is trying to get our debian standard compliance up to the latest
[12:38] <zul> morning
[12:39] <zul> pitti: can you also approve php-interbase as well?
[12:44]  * dholbach hugs pedro_!!!
[12:44]  * pedro_ hugs dholbach back
[12:48] <highvoltage> ok you guys can let go now
[13:07] <pitti> zul: what's the bug#? I didn't get mail about it apparently
[13:07] <zul> pitti: 530932
[13:08] <pitti> zul: done
[13:08] <pitti> zul: btw, I don't think you need to ask for individual packages -- there's no doubt for packages which are now uninstallable and need a 5.3 version
[13:08] <sebner> pitti: did you get my message about my external harddrive? if not I'd be glad to remessage
[13:08] <pitti> sebner: I answered with "please ubuntu-bug storage"
[13:09] <pitti> sebner: without further information there's nothign I can do, I'm afraid (it seems to work well for most people)
[13:09] <zul> pitti: ok ill do that in the future with regards to php
[13:09] <sebner> pitti: didn't get that :), running that while the exterinal drive is attached right?
[13:10] <pitti> sebner: not quite; it'll tell you
[13:10] <pitti> it's an interactive process
[13:12] <sebner> pitti: grr, before you waste your time and energy on me: It's magically working now
[13:12] <sebner> pitti: just tried it, 2 days ago it wasn't and wasn't workingit :(
[13:12] <pitti> :)
[13:14] <sebner> pitti: I'm really sorry
[13:14]  * pitti isn't sorry about things working :)
[13:17] <sebner> pitti: sure but wasting time is not nice, next time I'll try again right before contacting you :)
[13:17] <pitti> sebner: no prob, didn't take any time
[13:18]  * sebner hugs pitti :)
[13:18] <ogra> and wasting time with success messages cant be that bad :)
[13:21] <sebner> heh
[13:28] <didrocks> persia: asac: StevenK: finally, I'll have to add f-spot again, gthumb is too much work to put again in main and fit netbook screens. As it brings mono, do you want it on the armel version too?
[13:31] <cjwatson> apw: I think it's OK these days; I haven't noticed any problems at the NEW-queue stage for a while
[13:32] <apw> cjwatson, thanks, i think that covers all the items
[13:33] <apw> the kernel has a perf tool which is kernel version tied and as we can install multiple kerenls must produce binaries with version number ... for the manuals i am thinking that just the latest version would do ... whats the best way to achieve that
[13:34] <Keybuk> apw: didn't we already work this out?
[13:34] <apw> Keybuk, we decided to install binaries as /usr/bin/perf-2.6.32-15-generic ... thats is ok, its the manuals i am wondering about
[13:34] <Keybuk> "the manuals" ?
[13:34] <apw> man perf stat ... manuals
[13:34] <Keybuk> yeah they just say "perf"
[13:34] <Keybuk> because we said we'd put a /usr/bin/perf that had
[13:35] <Keybuk> #!/bin/sh
[13:35] <Keybuk> exec $0-$(uname -r)
[13:35] <Keybuk> in it :p
[13:35] <apw> right ... so happy with that ... looking for advice as to how to package the manuals for it
[13:35] <Keybuk> whatever ships that can ship the man page :)
[13:35] <Keybuk> I doubt it'll change much
[13:35] <Keybuk> after all, the kernel package doesn't actually include its own manuals either
[13:36] <apw> well t
[13:36] <apw> the manuals are pretty estensive for perf
[13:36] <apw> i guess i could include the perf script in the main kernel source package and package that too l ike t
[13:36] <apw> the linux-doc package which seems to be self-replacing
[13:37] <apw> Keybuk, ok will try that than
[13:51] <directhex> where do the u1ms people live on irc?
[13:52] <dholbach> directhex: /j #ubuntuone
[13:59] <Omahn> mvo: Have you seen bug #530632? ttx suggested I made you aware.
[14:01] <mvo> Omahn: I haven't, let me check
[14:01] <mvo> Omahn: so this happend during the upgrade? or after the upgrade was completted? could you please attach the logs from /var/log/dist-upgrade/* ?
[14:02] <Omahn> mvo: It's during the upgrade.
[14:02] <Omahn> mvo: I'll upload the contents of /var/log/dist-upgrade/* shortly.
[14:04] <mvo> Omahn: thanks!
[14:13] <Omahn> mvo: Uploaded.
[14:13] <pitti> $ cat /etc/default/locale
[14:13] <pitti> LANG="de_DE.UTF-8"
[14:13] <pitti> $ echo $LANG
[14:13] <pitti> de_DE.utf8
[14:13] <pitti> so, does anybody know what magic rewrites $LANG on login?
[14:14] <ogra> gdm ?
[14:14] <ogra> (guessing)
[14:14] <ArneGoetje> yes, gdm does
[14:14] <cjwatson> better question: why does anything care about the difference, given that they're aliases
[14:14] <pitti> hm, on a VT it's not rewritten
[14:15] <pitti> cjwatson: oh, I have a bug to fix in gnome-menus, which cares
[14:15] <pitti> ArneGoetje, ogra: thanks
[14:18] <cjwatson> pitti: I'm almost happy that gdm is doing this, because it's shaking out bugs like that
[14:18] <pitti> I'm still not quite up to date why lucid suddenly switched to .utf8; /usr/share/i18n/SUPPORTED still has them in "UTF-8" form
[14:19] <pitti> I'm going to make the gnome-menus cache robust against that, I was just curious
[14:19] <cjwatson> .utf8 is glibc's canonical internal form; .UTF-8 is the form it advertises in SUPPORTED
[14:19] <cjwatson> (.utf8 is what you always got from 'locale -a')
[14:19] <ArneGoetje> pitti: anyways, .utf8 and .UTF-8 work both
[14:19] <cjwatson> so I don't know exactly why it changed but I can imagine things like something trying to canonicalise the name
[14:20] <cjwatson> I don't know exactly why the canonical internal form isn't the same as SUPPORTED, though it's been that way for a long time so presumably historical
[14:20] <ogra> ArneGoetje, many scripts and tools blindly rely on UTF-8
[14:21] <cjwatson> ogra: they're buggy and always needed to be fixed anyway
[14:21] <ArneGoetje> ogra: yep, it was the common way to write the locale codes until recently
[14:21] <ogra> cjwatson, i didnt say they dont need fixing :)
[14:21] <cjwatson> (and I don't think it's all *that* many, though I know there are some common ones; most applications just use setlocale and are done with it)
[14:22] <Omahn> mvo: On a different note, is it possible to get my application for the sru-verification team from 2008 approved? :-)
[14:23] <mvo> Omahn: probably :) bdmurray is now in charge I think
[14:23] <ogra> cjwatson, well, tha fact that locale-gen doesnt/didnt (i dont know if it was fixed yet) accept .utf8 is a bit strange
[14:23] <cjwatson> yes
[14:23] <cjwatson> that's just one tool though :)
[14:24] <ogra> well, a quite essential one
[14:24] <cjwatson> sure
[14:24] <ogra> :)
[14:24] <cjwatson> I was just debating the "many", by way of indicating that I don't think the problem is a very serious one if we pull our fingers out and fix the handful of places where it causes major problems
[14:24] <ogra> true
[14:30] <Omahn> mvo: Your automatic build system appears to have already replicated my initramfs upgrade issue
[14:31] <Omahn> http://people.ubuntu.com/~mvo/automatic-upgrade-testing/2010-03-01-09:08:07/dapper-hardy-lucid-ubuntu/apt-term.log
[14:33] <mvo> Omahn: thanks, I targeted the bug now
[14:34] <mvo> Omahn: just there? or in the normal lts-ubuntu profile as well?
[14:34] <mvo> Omahn: was your upgrade a dapper install before ?or is it just coincidence?
[14:35] <ArneGoetje> BTW: can anyone here help me to debug my gdm? I cannot log into my system anymore and I don't know where to start looking... :(
[14:35] <Omahn> mvo: Conincidence. Our machines are all hardy originally.
[14:35] <seb128> ArneGoetje, what happens when you try to log in exactly?
[14:36] <Omahn> mvo: Do you publish the scripts to perform those tests BTW? I would be very interested in having a copy running locally in our environment.
[14:38] <mvo> Omahn: oh yes - its in the auto-upgrade-tester package, and in bzr under lp:update-manager (in the AutoUpgradeTester subdir)
[14:39] <mvo> Omahn: its pretty flexible, but not well documented, I'm happy to help you if you have specific questions
[14:39] <Omahn> mvo: Thanks, I'll check it out.
[14:39] <ArneGoetje> seb128: when gdm starts up, I see my username, then select it. Then gdm does some checking in the background and fails with something, then resets the screen and I get the same screen as before. Then I select my username again and the bottom bar changes to display the comboboxes for selecting language and stuff... normally it should also display the Password field, but it never shows. This only happens on my account, another test account is fine, even
[14:39] <seb128> weird
[14:40] <seb128> do you have anything special for your account like protected userdir?
[14:40] <ArneGoetje> seb128: no
[14:41] <ArneGoetje> seb128: I have one suspicion...
[14:41] <seb128> ArneGoetje, which is?
[14:43] <ArneGoetje> seb128: I have tried what happens if I put a language code in an invalid format into ~/.dmrc. gdm just restarted and that's when this weird behaviour started. After that I restored the ~/.dmrc entry to the correct form and even moved the whole file out of the way... didn't fix the problem... dies gdm store the buggy entry somewhere else?
[14:43] <seb128> ArneGoetje, /var/cache/gdm
[14:44] <ArneGoetje> s/dies/does/
[14:44] <seb128> it does store the .dmrc there to handle protected userdirs
[14:44] <seb128> so it can read the config before asking the password
[14:44] <ArneGoetje> seb128: thanks! Yes, it still has the buggy file there.
[14:44] <seb128> np
[14:45] <seb128> please open a bug saying that gdm breaks when you break that file content
[14:45] <ArneGoetje> seb128: ok, will do
[14:45] <seb128> thanks
[14:46] <ArneGoetje> seb128: yay, works again! :)
[14:46] <seb128> good!
[15:01] <cjwatson> mvo: re http://lists.debian.org/debian-devel/2010/02/msg00424.html, is the new API going to land in lucid (soon)?
[15:01] <cjwatson> or indeed
[15:01] <cjwatson> juliank: ^-
[15:02] <juliank> cjwatson: Well, mvo said he would like to do it. But there are some compatibility issues wrt progress reporting which I am going to fix today.
[15:03] <juliank> In the end, it depends on whether a freeze exception is granted for it
[15:03] <cjwatson> right - it would just be rather easier for me to merge a germinate patch right now if I knew it was going to land in lucid
[15:03] <cjwatson> since then I won't have so much skew to deal with
[15:04] <mvo> cjwatson: its the goal, it will make the next lts upgrade much simpler as well
[15:04] <cjwatson> right
[15:04] <mvo> lots of balls to juggle currently, I want to look at it tomorrow (when UI freeze is over)
[15:05] <mvo> I looked last week and it was 98% there, some compat issues with the progress (as juliank said)
[15:05] <mvo> but nothing that looks like a real blocker
[15:06] <juliank> The only things that are a bit broken are InstallProgress & CdromProgress; some other issues I noticed while writing the >20 patches for the packages will be fixed in 0.7.93.4.
[15:08] <mvo> juliank: thanks, please let me know and I have another look
[15:08] <cjwatson> poo.  I got rid of "GRUB loading" and left the dot and newline in
[15:09] <cjwatson> more tedious boot testing ...
[15:19]  * apw just tried to install a package and apt has decided to remove a heap of stuff listing them as foo{u}, isi think previously they were marked as auto installed and not required and told me how to remove them, but suddently its removing them, is that expected?
[15:19] <apw> either that or my machine is toast
[15:20] <mvo> apw: this sounds more like aptitude, apt just informs about autoremovalbles
[15:20] <apw> ahh crap so it is, damn a typeo on my behalf, why is aptitude installed anyhow
[15:23] <cjwatson> aptitude is in ubuntu-minimal because tasksel needs it if you select manual package selection in the server installer
[15:24] <cjwatson> it's not ideal but the cost is tolerable
[15:24] <cjwatson> might sort that out one day
[15:24] <cjwatson> the alternate and desktop CDs could live without it
[15:27] <ion> seb128: How can the CSD patch for Gtk be tested? I take it there’s a theme that uses the functionality.
[15:28] <seb128> ion, GtkWindow::client-side-decorated = 1 in your gtkrc
[15:28] <seb128> but it will not look correct without a specific theme
[15:28] <ion> Thanks
[15:29] <seb128> I think people are working on making a theme using it
[15:29] <ion> Alright
[15:29] <seb128> wait a few extra days I would say
[15:29] <seb128> I will try to check and let you know
[15:29] <ion> Thanks
[15:44] <ogra> bah, gtk is still building on armel
[15:45] <ogra> bloat ! 3h buildtime are to much for a toolkit !
[15:48] <seb128> ogra: gtk doesn't take that long to build
[15:48] <seb128> it's just built several times
[15:48] <ogra> ah
[15:48] <seb128> static, udeb, directfb
[15:48] <seb128> + normal
[15:49] <ogra> (i wasnt seriously ranting :) )
[15:49] <seb128> it's something which annoys me too
[15:49] <seb128> I would like to drop the static build at least
[15:50] <ogra> for what is that ? d-i in debian ?
[15:50] <seb128> no, udeb is for d-i
[15:50] <seb128> and directfb somewhat
[15:50] <ogra> and directfb i guess
[15:50] <ogra> yeah
[15:51] <ogra> we should probably just switch the whole distro to fltk :)
[15:51] <ogra> would also prevent all kde vs gnome discussions :)
[15:51] <seb128> lol
[15:55] <juliank> mvo: I pushed the changes to debian-sid; if you could run some tests with it I can prepare the merge as well (the only difference now being that Python 3.1 is disabled here; because python3.1 is in universe, whereas python-apt is in main)
[15:56] <mvo> juliank: great
[16:00] <cjwatson> seb128: sounds like directfb is going to go away in the not too distant future
[16:01] <cjwatson> at least the d-i uses of it
[16:01] <seb128> yeah, I've read some blog posts about that
[16:05] <Keybuk> I have learned that the Linux VT layer was not so much designed, as vomited into the existance from the bowels of the earth
[16:06] <tseliot> lol
[16:06] <Keybuk> it was apparently written to roughly match what they thought the X code assumed BSD/SVR did at the time
[16:06] <Riddell> siretart: are you able to advise on http://thread.gmane.org/gmane.comp.kde.devel.general/60401 ?  are we behind on our ffmpeg?
[16:13] <cjwatson> 16:12 <Keybuk> cjwatson: will it matter whether the VT is in VT_AUTO or VT_PROCESS ?
[16:13] <cjwatson> Keybuk: moo
[16:14] <cjwatson> (dunno yet)
[16:14] <cjwatson> I don't think so, but I could be missing something
[16:14] <Keybuk> the confusion I had was whether there was a font-per-VC
[16:15] <Keybuk> or whether the font applied to every console
[16:18] <Keybuk> the code appears confused on this issue too ;-)
[16:20] <siretart> Riddell: we have backported the av_lockmgr stuff to 0.5 because we were asked by the geexbox guys at fosdem
[16:21] <siretart> Riddell: it is included in the 0.5.1 release, which we published yesterday
[16:21] <siretart> Riddell: I'm currently working on the package, and will upload it to lucid shortly
[16:21] <siretart> Riddell: as for that specific question, it was decided to bump MICRO instead of MINOR in libavcodec for that feature backport
[16:22] <siretart> Riddell: does this answer your question?
[16:23] <Riddell> siretart: so this AVLockOp enum will appear in your upload today?
[16:23] <cjwatson> Keybuk: "depends"
[16:24] <cjwatson> Keybuk: vgacon is one-font-to-rule-them-all, currently; fbcon is font-per-VC
[16:24] <siretart> Riddell: today I'm not sure, I don't feel very well today. But I should manage it this week
[16:24] <cjwatson> Keybuk: BTW what's the current best way to blacklist fbcon so that I can test this properly
[16:24] <cjwatson> ?
[16:24] <Keybuk> cjwatson: blacklist=fbcon ?
[16:24] <Keybuk> though you'd need <driver>.modeset=0 and blacklist=vga16fb I guess too
[16:24] <cjwatson> juliank: in your transition plan, you mentioned applying Breaks to python-apt for anything that isn't yet converted; have you considered just applying Breaks for everything using the old API, with appropriate versioning?  I think that would be nicer to partial upgrades
[16:25] <cjwatson> Keybuk: ok, thanks
[16:25] <Riddell> siretart: lovely thanks
[16:26] <juliank> cjwatson: In fact I meant that if pkg p version v still uses the old API, python-apt gets a Breaks: p (<< v+1).
[16:26] <cjwatson> juliank: right, just clarifying whether there'll be a Breaks even if squeeze has >= v+1
[16:26] <cjwatson> I think there should be
[16:26] <Keybuk> cjwatson: all the current ioctl()s seem to ignore whatever tty you use
[16:26] <Keybuk> and just fiddle with vc_cons[fg_console]
[16:26] <Keybuk> which is somewhat scary
[16:28]  * Keybuk thinking what if you do that ioctl mid-vt-switch for example <g>
[16:28] <juliank> cjwatson: Do you want a package with Breaks: against more than 20 other packages?
[16:29] <cjwatson> juliank: I don't see why not, if it's accurate
[16:29] <cjwatson> I don't subscribe to the theory that upgrade compatibility should be dropped after each release :-)
[16:30] <cjwatson> one of my packages still (theoretically) has some code for upgrades from Debian 1.2; it's easier to leave it there than to remove it
[16:30] <Riddell> shtylman: seen my conversation with siretart above?
[16:30] <cjwatson> Keybuk: I was sort of hoping there was a VT lock somewhere, but haven't looked too hard ...
[16:30] <Keybuk> cjwatson: HAHAHAHA
[16:31] <Keybuk> no such thing
[16:31] <cjwatson> there's vga_lock at least
[16:31] <cjwatson> but I think that's for the VGA hardware
[16:31] <Keybuk> it may not matter
[16:31] <Keybuk> if it's not storing anything inside vc-> ?
[16:31] <Keybuk> it could just want a reference to any vc
[16:32] <cjwatson> I used a separate font_data structure fairly deliberately
[16:32] <cjwatson> s/structure/array/
[16:32] <cjwatson> and all the vgacon_ functions take a struct vc_data *
[16:32] <cjwatson> so fg_console is probably only examined once
[16:32] <shtylman> Riddell: ahh
[16:32] <Keybuk> where do they get that vc_data ?
[16:32] <shtylman> Riddell: for that mailing list question...
[16:33] <Keybuk> cjwatson: if there's a vc_data-per-vc this implies that there's a font-per-vc
[16:33] <Keybuk> which means in order to set the fonts, you need to first chvt
[16:33] <Keybuk> chvt 1 ; set font ; chvt 2 ; set font ; chvt 3 ; set font ; etc.
[16:33] <cjwatson> no, KDFONTOP takes a structure that includes the vt number
[16:33] <Riddell> shtylman: yes, seems like he'll need to wait for siretart to do that upload
[16:33] <cjwatson> at least I think it does
[16:34] <Keybuk> ah, KDFONTOP seems to be the one that operates on the vc you open
[16:34] <Keybuk> [PG]IO_FONT[X] seem to operate on vc_cons[fg_console]
[16:34] <cjwatson> oh yes that's right
[16:34] <cjwatson> right, there are old ioctls that are fgconsole only
[16:34] <cjwatson> but they shouldn't be used any more if KDFONTOP is available
[16:34] <cjwatson> which it always is nowadays
[16:34] <Keybuk> in which case, does it matter if KDFONTOP checks vc->vc_mode ?
[16:34] <shtylman> Riddell: should we comment as such? I imagine he will try again or something...
[16:35] <Keybuk> if vt7 is in KD_GRAPHICS, do we really need to set a font for it?
[16:35] <Keybuk> it's only ever going to have plymouth and X on it
[16:35] <cjwatson> isn't there sometimes graphics stuff on vt1?
[16:35] <Keybuk> I guess
[16:35] <cjwatson> that was certainly the original problem way back when
[16:35] <Keybuk> if you try and set the font while an svgalib app is running
[16:35] <Keybuk> or a framebuffer app
[16:35] <Keybuk> etc.
[16:36] <cjwatson> having vgacon not store the font only in video memory is probably more important than the mode check
[16:36] <Keybuk> yeah
[16:37] <cjwatson> you're right that removing the KD_TEXT check might not strictly matter since we don't nowadays put the splash screen on vt1; I think there was a point at which we did and it mattered
[16:37] <Riddell> shtylman: it would seem like a good idea to tell him what he needs to do
[16:37] <cjwatson> I think I wanted to do it just so that I never had to think about KD_TEXT vs. KD_GRAPHICS ever again
[16:37] <Keybuk> indeed
[16:38] <cjwatson> p.s. you can *really* screw up your console by copying font data around incorrectly within the kernel
[16:38] <Keybuk> and like you say, the other consoles (fbcon) already handle this
[16:39] <Keybuk> making vgacon consistent would be a good thing
[16:39] <cjwatson> one question I had was whether vgacon is being kept deliberately memory-light
[16:40] <cjwatson> that would mean it's desirable to stick with one-font-to-rule-them-all
[16:40] <cjwatson> OTOH the code I have would share memory if you put the same font on all VCs ...
[16:40] <Keybuk> or whether it puts it in vga memory because you can only have one font
[16:41] <Keybuk> and because the ioctls only let you set it for whatever is the active console right now
[16:41] <cjwatson> so I think the footprint is no more than about 1KB for a 256-char font
[16:41] <Keybuk> so they never bothered extending it to support multiple
[16:41] <Keybuk> and the newer ioctls came along later
[16:41] <cjwatson> yeah, it's quite possible
[16:41] <cjwatson> given the general maintenance level of VT code
[16:41] <cjwatson> "we didn't need anything else in 1995"
[16:42] <cjwatson> I certainly *hope* people see that putting the font in VGA memory and forgetting about it is a horrible mistake nowadays, once I get as far as LKML
[16:46] <smoser> slangasek, Keybuk somewhere between my 20100224 build and 20100228, ramdiskless boot started failing on eucalyptus.  Between those 2 builds, the big differences are mountall-2.6 and upstart 0.6.5-4
[16:46] <mvo> juliank: InstallProgress.writefd  seems to be broken again (I'm pretty sure I fixed that earlier). could you please have a look?
[16:46] <Keybuk> smoser: started failing how?
[16:46] <smoser> booting with a ramdisk "fixes" the problem.
[16:47] <smoser> well, the cloud-init job doesn't run (MOUNTED=/ ...)
[16:47] <smoser> i can get debug output if i add a job to turn it on
[16:48] <mvo> juliank: the release upgrade tries to access it and crashes http://paste.ubuntu.com/387717/
[16:48] <smoser> so there are 2 interesting pieces of information : 1.) ec2 instances still boot without ramdisk (its just eucalyptus that fail) 2.) eucalyptus can be worked around by giving a ramdisk
[16:49] <smoser> the kernel is the same in 20100224 and 20100228
[16:49] <Keybuk> how does it fail?
[16:49] <Keybuk> the mountall and upstart changes are minor
[16:49] <Keybuk> largely consisting of Depends changes
[16:50] <smoser> well, no messages after kernel messages
[16:50] <Keybuk> in fact, the only change not a Depends change is a change to Upstart that should make it *more* likely to work with a ramdisk
[16:50] <juliank> mvo: should be fixed now
[16:50] <juliank> Forgot to call the constructor of the parent class.
[16:51] <shtylman> Riddell: I myself an unclear on what he needs to do... other than wait :)
[16:51] <smoser> Keybuk, i'll get you some info with a 'initctl log-priority X' job. but i dont really know what else to do.
[16:51] <Keybuk> smoser: that'd be a great start
[16:51] <smoser> what X do you want?
[16:51] <mvo> juliank: cool, thanks
[16:51] <Keybuk> along with --debug from mountall as well
[16:51]  * mvo updates
[16:52] <smoser> Keybuk, how to add --debug in mountall ?
[16:52] <Keybuk> edit the job
[16:52] <smoser> k
[16:54] <smoser> Keybuk, you want 'debug' or 'info' ?
[16:55] <juliank> mvo: If it works for you, I'll update the timestamp, upload it; and could post a merge bundle for the ubuntu branch as a merge request bug.
[16:55] <Keybuk> info is fine for upstart
[16:55] <Keybuk> debug for mountall
[16:56] <mvo> juliank: ok, also that is not needed, I have a local merge ready here
[16:56] <mvo> juliank: let me test again
[16:58] <juliank> mvo: I also have one ready here, and debian/changelog and debian/control are the only changed files compared to Debian.
[16:59] <mvo> juliank: ok
[16:59] <juliank> I do this to check if there are some things in the Ubuntu branch which could also be in the Debian branch without problems.
[17:01] <juliank> So, once your tests are done; report back and I'll do a "dch -r" and upload 0.7.93.4; then you can merge the timestamp change and upload 0.7.93.4ubuntu1
[17:04] <mvo> juliank: sounds good, its currently running a big upgrade, when that is done I check with gdebi again
[17:04] <mvo> juliank: about ~1h (need to get some dinner too while the upgrade runs)
[17:12] <smoser> Keybuk, what if i told you it doesn't seem to want to fail with debug enabled :(
[17:15] <Keybuk> smoser: then I would cry
[17:24] <smoser> Keybuk, i'm fighting eucalyptus stability demons now. i'll open a bug and subscribe you. if you had to guess, which package at this point, upstart or mountall
[17:33] <mathiaz> zul: bug 531454 - 3.4.6 is a bug fix only release
[17:33] <mathiaz> zul: not sure you need to ask a FFe for this
[17:50] <zul> mathiaz: not sure either better safer than sorry
[17:55] <smoser> Keybuk, bug opened 531494 . I did get a recreate with debug, the serial console output is attached there.
[17:55] <smoser> bug 531494
[17:55] <sebner> jdstrand: I'm making some progress but I'm kinda stuck with a FTBFS. This is the most b0rken I've ever seen (mostly because it uses *huuuge* cdbs)
[17:56] <jdstrand> sebner: can you paste how it breaks?
[17:59] <sebner> jdstrand:
[17:59] <sebner> jdstrand: http://pastebin.com/qap0AJEh
[18:00] <jdstrand> sebner: you can't use ln in that manner
[18:00] <sebner> jdstrand: I have to hardcode python2.6?
[18:00] <jdstrand> sebner: well, unless the globs resolve to one place
[18:01] <jdstrand> sebner: is it hardcoding 2.5 currently?
[18:01] <sebner> jdstrand: aye
[18:02] <jdstrand> sebner: I would just hardcode it at 2.6 then
[18:02] <sebner> jdstrand: I'll give it a try
[18:10] <sebner> jdstrand: ho ho ho I have a deb! I'll polish it a little bit and upload it then. I need a core-dev anyways for uploading but would you mind taking a look later?
[18:10] <jdstrand> \o/
[18:11] <jdstrand> sebner: attach it to the bug, I'm subscribed and can look at it
[18:12] <sebner> jdstrand: .. and you better accept it as I don't ever want to touch such a crappy package (crappy cdbs package with huuge b0rken rules file) ever again in my life :P *muahaha*
[18:12] <jdstrand> hehe
[18:13] <sebner> jdstrand: If somebody would have told me earlier that the DM of moin is the DM of cdbs ....
[18:16] <sebner> jdstrand: are you happy with a debdiff or do you prefer a .diff.gz (debian.tar.gz) as the update isn't trivial. A debdiff might be a lot easier to review imho though
[18:19] <jdstrand> sebner: the debdiff should be between the Debian's 1.9.2-1 and your version-- am I missing something?
[18:19] <jdstrand> sebner: that is what I would prefer
[18:20] <juliank> mvo: BTW: gdebi should be ported to apt.debfile sometime.
[18:21] <sebner> jdstrand: Nah, I know what a debdiff is .. but sometimes sponsors want a .diff.gz/interdiff whatever on big new new upstream versions when Ubuntu version is far behind. Debdiff also makes me happy ;)
[18:22] <mvo> juliank: and the other way around too, the DebPackage code contians a bunch of fixes that need to be re-imported
[18:22] <mpt_> tremolux, hi, I'm very impressed by the Back+Forward buttons :-)
[18:23] <tremolux> mpt_: cool!  I'm very glad
[18:27] <sebner> jdstrand: do you know that's the IRC nick of the maintainer?
[18:28] <mvo> juliank: gdebi-gtk is complaining about http://paste.ubuntu.com/387771/
[18:28] <mpt_> tremolux, any chance to fix bug 426999 now?
[18:29] <jdstrand> sebner: sorry, no
[18:29] <tremolux> mpt_: agreed, that would be a very nice one to fix, I will look at it now
[18:29] <mpt_> thanks
[18:29] <sebner> jdstrand: np
[18:29] <tremolux> mpt_: sure!
[18:33] <juliank> mvo: It should be fixed now.
[18:34] <juliank> mvo: I just added all the missing returns in front of the commands I called.
[18:37] <mvo> juliank: thanks, checking again. "apt_pkg.Dependency.UntranslatedDepType we did not bother, right?
[18:40] <juliank> mvo: Added it to the list of renaming exceptions in python/generic.cc.
[18:41] <juliank> i.e. in _PyApt_NewNameForAttribute
[19:09] <juliank> mvo: I still have some large documentation updates planned for 0.7.94; but I guess as they are not-to-be-translated developer docs, they are not affected by the documentation string freeze.
[19:10] <juliank> The main part is adding short docstrings to the stuff in apt_pkg.
[19:10] <juliank> You can see how this should look like in apt_inst; it's full with documentation strings.
[19:11] <juliank> Planned for the week starting Mar 22.
[19:13] <mvo> juliank: yeah, I think devel docs like this are fine
[19:17] <mvo> juliank: nice work, progress looks good
[19:18] <juliank> mvo: I still need to port the quiet progress mode from apt-get to the python implementation.
[19:19] <mvo> juliank: bug #531518 (fyi)
[19:19] <juliank> mvo: Yes, I already added 3 comments to it (added one, fogot something, added second one, forgot something, added third one)
[19:22] <mvo> heh :)
[20:07] <mpt_> tremolux, how's it going?
[20:13] <tremolux> mpt_: the bug you mean?  unfortunately I haven't dug into it too deeply yet, had lunch and then two intervening things, sorry
[20:13] <mpt_> ok, np
[20:16] <jibel> mvo, hi, I've been working on the xapian search today with some interesting results http://pastebin.com/LhHnVQNn
[20:17] <smoser> slangasek, around ?
[20:19] <mvo> jibel: oh, interessting
[20:20] <mvo> jibel: are you working on the "-" problem?
[20:23] <jibel> yes, finally I search for an exact match on the package name with the hyphen, replace the '-' by a space to search in the description.
[20:24] <jibel> It's working because the package name is indexed by word in the term list
[20:25] <jibel> mvo, the code is there http://pastebin.com/f36HKtas
[20:26] <mvo> jibel: sweet, you rock!
[20:28] <jibel> mvo, there are other improvements but apt-xapian-index generates poor metadata
[20:28] <jibel> mvo, an since we search for few terms amongst a large list (the description) the relevancy if not relevant
[20:28] <jibel> s/an/and
[20:30] <mvo> jibel: that makes me wonder if we should not simple eascape "-" to something that can be inxed properly when writing the a-x-i and doing the same escaping in the searches. then we can at least exact match on XPpkgname - or am I missing something?
[20:30] <mvo> (its been a long day)
[20:31] <jibel> the exact match is working.
[20:32] <jibel> even with an hyphen. But you cannot use wildcarding with boolean prefix or search with an hyphen with a probabilistic prefix.
[20:39] <jibel> mvo, we could add a new prefix to the index and split the package name. If the boolean search returns nothing, use this prefix instead ?
[20:41] <jibel> mvo, the order of the resultset would be: exact package name, package name containing the query string and finally document matching the query string.
[20:44] <mvo> jibel: I think that is sensible - best is problably to ask in #xapian for a second opinion just to be sure we are on the right track
[20:46] <jibel> mvo, sure. Enrico is not inclined to change the way the index is generated.
[20:46] <mvo> jibel: we could add this as a additional plugin I guess
[20:46] <jibel> mvo, anyhow the result is not that bad and there are ways to improve it a bit.
[20:46] <mvo> but why not?
[20:46] <mvo> ok
[20:47] <jibel> mvo, I'm currently adding the plugin.
[20:48] <jibel> mvo, I'll see if it gives positive result.
[20:48] <jibel> or not.
[20:48] <mvo> ok, thanks
[20:52] <sebner> slangasek: around?
[21:05] <slangasek> smoser: contentless pong
[21:05] <slangasek> sebner: contentless pong :)
[21:05] <smoser> i'm begging for help for bug 531494 (and also, now that i've pinged you, mail i sent thursday PM named "531494")
[21:05] <smoser> oops... mail was subject "questions from today" not 531494
[21:06]  * slangasek nods
[21:06] <sebner> slangasek: ;), Do you (by any chance) know why you introducted "* Demote fckeditor from Recommends to Suggests; the code was
[21:06] <sebner>     previously embedded in moin, but it was also disabled, so there's no
[21:06] <sebner>     reason for us to pull this in by default currently.
[21:06] <sebner> " in moin 1.8.2-2ubuntu2 , a year ago? Upstream told me that fckeditor was *never* disabled by default
[21:07] <slangasek> sebner: because someone told me that was the case, and I was avoiding having to do a run of MIRs
[21:08] <sebner> slangasek: Ic, well, I guess for now it's fine if we keep that change and tackle the MIR stuff for lucid+1?
[21:09] <slangasek> sebner: it was maxb who said this
[21:09]  * sebner summons maxb *hehehehe*
[21:09] <slangasek> if you prefer to do an MIR sooner, that's your choice
[21:10] <sebner> slangasek: well, I didn't want to work on the package (python + cdbs) but I somehow slipped into it so I'm happy if you agree to postpone it (I'll leave a note in changelog)
[21:11] <slangasek> smoser: have you tried downgrading just the upstart package in your build, to see if that fixes the problem?
[21:12] <slangasek> smoser: and I don't have any good ideas how to debug this, if it is an upstart problem but turning on debugging makes it disappear :/
[21:12] <smoser> slangasek, oh comon... suggesting logical steps to reducing scope of problem is not fair!
[21:12] <smoser> no i've not done it.
[21:13] <smoser> slangasek, i did reproduce with debugging on (the attached log shows that), but it does sometimes make it go away.
[21:14] <slangasek> oh, you got one with debug, ok
[21:22] <slangasek> smoser: have posted some analysis of the logs; I think you're going to need Keybuk for further debugging, because I really don't have a clue there
[21:23] <sebner> jdstrand: debdiff is up
[21:51] <micahg> kees: which greasemonkey, upstream or from archvie?
[22:00] <kees> micahg: upstream
[22:00] <micahg> kees: is it the latest (2010 release)?
[22:01] <kees> 0.8.20100211.5
[22:01] <micahg> ugh
[22:04] <cjwatson> Keybuk: so blacklist=fbcon i915.nomodeset=0 blacklist=vga16fb didn't do it - but making sure FRAMEBUFFER was disabled in /usr/share/initramfs-tools/conf-hooks.d/* and booting with init=/bin/bash did. :-)
[22:04] <cjwatson> Keybuk: incidentally, init=/bin/bash is not friends with FRAMEBUFFER=y
[22:04] <micahg> kees: I'll have to look more tonight...seems other users are affected on Arch and Red Hat so probably not an ubuntu issue, but either GM or FF, I'll update the bug with what I find
[22:04] <cjwatson> you get plymouth starting and then nothing ever stops it
[22:05] <kees> micahg: cool, thanks.
[22:05] <cjwatson> we could probably do with an initramfs option to avoid starting plymouth just in case it's built into the initramfs, or something
[22:05] <kees> cjwatson: +1
[22:06] <cjwatson> in any case, I have discovered that my kernel is buggered - it blanks the font entirely on tty switches - so more work required
[22:09] <cjwatson> pitti: https://launchpad.net/ubuntu/+source/grub2/1.98~20100128-1ubuntu4/+build/1541925/+files/buildlog_ubuntu-lucid-powerpc.grub2_1.98~20100128-1ubuntu4_FAILEDTOBUILD.txt.gz - do I remember something vaguely about this being a pkgbinarymangler bug, by any chance?  grub2 doesn't create the control directory manually so it's very odd for it to have wrong permissions
[23:02] <pitti> cjwatson: hm, does the buildd have a bad umask or so? LP seems to be down ATM, but I'll have a look tomorrow
[23:10] <kees> any idea what's going on here?  I can't convince apt-get to install a recommended package: http://paste.ubuntu.com/387905/
[23:13] <superm1> kees, did you try whispering sweet nothings in it's ear? :)
[23:14] <kees> superm1: I even specified --install-recommends.  :P
[23:15] <micahg> kees: try installing smbclient in aptitude and manually add samba-common-bin and see what it says or use whatever -o option tells you package compatability
[23:16] <crimsun> or, aptitude why-not samba-common-bin
[23:16] <kees> micahg: hrm?  it'll install samba-common-bin if I tell it to, but I'm expecting it to install samba-common-bin _without_ me specifying it.
[23:16] <micahg> kees: k, just was thinking there might be an unspoken conflict
[23:16] <micahg> crimsun: that's a cool option :)
[23:17] <kees> yeah, no conflict
[23:24] <kees> oh, is it because it's a recommend of samba-common that is already installed (but is being upgraded?)
[23:25] <cjwatson> pitti: not sure - I couldn't see anything in the build that would be setting umask
[23:26] <ebroder> Is the Librarian supposed to be actually down, or just r/o?
[23:26] <cjwatson> pitti: and indeed my local build looks fine
[23:27] <kees> cjwatson: I'm baffled by apt-get -- it lists "Recommended packages" yet it does not install them even if I use --install-recommends
[23:31] <cjwatson> kees: not a behaviour I'm familiar with ... doesn't do that here
[23:34]  * kees attempts to reproduce in chroots
[23:36] <ScottK> cjwatson: I had the same failure for quassel on powerpc (and only powerpc).
[23:36] <ScottK> So it's not specific to one package.
[23:37] <cjwatson> ScottK: oh good, I thought I was going mad
[23:38]  * ScottK too
[23:41] <cjwatson> I'm sure I saw this problem go by on #u-d a while back though.  I wonder if powerpc is using an out-of-date version of pkgbinarymangler or something
[23:42] <ScottK> In my case it said it was skipping pkgbinarymangler as requested.
[23:42] <ScottK> I thought that was odd.
[23:42] <cjwatson> I don't see anything in the changelog though
[23:47] <kees> are recommends only installed on package install and not package upgrade?
[23:50] <cjwatson> kees: new recommends are installed on upgrade (but not 'apt-get upgrade' as opposed to dist-upgrade, since it never installs new packages)
[23:50] <cjwatson> kees: but if the previous version of the package recommended the package too, apt will assume that you meant not to install it the last time
[23:50] <persia> kees: My understanding is that apt-get ... tries to make the minimum changes required to fulfill the stated requirements.
[23:50] <cjwatson> I'm not sure about 'apt-get install' of an individual package as an upgrade
[23:51] <kees> cjwatson: aaah, so if the prior version also recommended, then it's not a change, so it does nothing.
[23:51] <kees> apt-get install output matches the apt-get dist-upgrade output
[23:51] <kees> here's the state and example: http://paste.ubuntu.com/387921/
[23:52] <kees> it just means that taking a system with install-recommends=false to =true means things will kind of stay not installing recommends.
[23:53] <cjwatson> yeah, you need something a bit more sophisticated than apt-get I imagine
[23:53] <cjwatson> grr, I hate wasting time accidentally building a kernel for the wrong architecture
[23:53] <kees> ugh, that sucks
[23:54] <kees> (building time-waste)
[23:54] <kees> I'll write something to look at all Recommends: for currently installed packages and install those.  :)
[23:54] <lifeless> kees: aptitude
[23:54] <lifeless> kees: has a list at the bottom, of uninstalled but recommended packages
[23:54] <ion> kees: aptitude → View → Audit Recommendations
[23:55] <lifeless> kees: so running that up, go down to recommendations, install at that level - done.
[23:55] <kees> oh my, I see perhaps why I turned this off originally now.  :P
[23:57] <kees> lifeless: cool; this is exactly what I needed.  :)
[23:58] <lifeless> de nada