[00:03] Is the new volume control applet an Ubuntu-originated thing or an upstream thing? [00:03] (or both) [00:05] I was under the impression there was a new upstream for it that had so far only been adopted in Ubuntu. [00:18] YokoZar: The new volume control is a DX team thing afaik. === bladernr_ is now known as bladernr-away === sconklin is now known as sconklin-gone === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [02:11] hello. [03:58] *scratches head* [03:58] what are the new lucid compiz bindings? [03:58] I just noticed super-a seems to do what alt-shift-up used to do [04:02] never mind, ccsm answered that question [04:18] jdong, shoudl bug 530945 stay as backport or should be a SRU ? [04:18] Launchpad bug 530945 in keepalived "Please backport keepalived 1.1.17-2 to Karmic from Lucid" [Medium,Confirmed] https://launchpad.net/bugs/530945 [04:19] RoAkSoAx: if the debdiff in #5 on the orig bug is correct, then SRU [04:19] or something equally trivial [04:20] jdong, ok thanks. I'll change the bug report then :) [04:27] 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] arose: X Strike Force [04:40] Seems it finally has been merged... Would be nice to know not to waste time reporting bugs in launchpad in the future... [05:26] 7/c [06:07] TheMuso, are you familiar with the new package process to add a package to Universe? [06:07] growlf (one of the developers of gdm2setup) is working on getting that into Universe (bug #531138) [06:07] Launchpad bug 531138 in ubuntu "[needs-packaging] python-gdm2setup" [Wishlist,Triaged] https://launchpad.net/bugs/531138 [06:09] growlf, it should be called "gdm2setup" not "python-gdm2setup". The "python-" prefix is only required for libraries [06:10] Ahh. ty. Shall I change that in the bug? [06:10] Also we're past feature freeze for Lucid, so it'll need a compelling justification for getting in now. [06:11] Do you want that here and now - or in an email? [06:11] In the bug. It needs to get made into a feature freeze exception request [06:11] ScottK, does that apply for packages in Universe? [06:12] robert_ancell: Absolutely. [06:12] ok [06:12] Ah. ok. [06:12] Thank you. Once I have that in - what is the next step I should take? [06:13] growlf, So my guess is that this wouldn't be included in Lucid (as it is easily installable from the PPA) [06:13] 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] Subscribe ubuntu-release. Look for general feature freeze exception information. [06:15] ScottK, and if it wasn't in feature freeze? [06:15] New packages get reviewed on REVU [06:15] !REVU [06:15] REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU [06:24] growlf, ok, next step upload to revu as in the above comment [06:30] linux-backports-modules-nouveau-2.6.32-15-generic still in NEW ? [06:31] yep seems so :( and now nouveau is broken because of it : [06:31] :( [06:31] I'm working on it [06:34] how about the other php-* ? [06:34] [06:39] dupondje: Accepted. It will take around 90 minutes, at best, to hit archive.u.c [06:41] 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] I suggest replacing archive admins with a small cron script. [06:43] ejat: No php-* packages are in NEW, the only one I can find is mapserver [06:43] 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] persia: indeed [06:44] StevenK: but it will remove some other package rite? [06:44] (but there's 3 bugs that need be sorted before the python script can be deployed) [06:44] ejat: I'm not sure I understand what you mean. [06:45] StevenK: http://paste.ubuntu.com/387442/ [06:46] ejat: I have no idea why that is. [06:46] ejat: Those packages need porting. That needs a developer, not an archive-admin. [06:46] (or else your archive is out of date) [06:46] StevenK + persia .. ok thanks for the acknowledgement .. [07:13] pitti: could you accept the most recent eucalyptus package for karmic-proposed? [07:15] StevenK: thanks :) [07:24] innocent question here, where to learn modern methods for adding Ubuntu package generation from a project source code? [07:24] #ubuntu-motu is a good place to chat about that === lucent_ is now known as lucent [07:25] thanks! [07:32] lifeless: it's kind of quiet in -motu [07:33] I wonder if the process is any different than http://www.debian.org/doc/maint-guide/ [07:35] highvoltage: stgraber: thanks :) [07:40] Good morning [07:41] sebner: in that generality, no; please file a bug with "ubuntu-bug storage" [07:41] kirkland`: will do SRUs soon again [08:20] good morning [08:22] Good Night here in NY === tkamppeter_ is now known as tkamppeter [10:05] ArneGoetje, Riddell: I was having a look at bug 463181 - seems like kde-i18n-zhcn is not in lucid any more? [10:05] Launchpad bug 463181 in ubuntu-translations "wrong dependency on language-pack-kde-zh" [Medium,Fix committed] https://launchpad.net/bugs/463181 [10:27] * cjwatson speeds up grub-probe filesystem queries by a factor of >10 [10:28] I like lots-of-bang-for-your-buck work [10:37] nice! [10:54] mvo: I think bug #467490 is really bug #459829 which should be fixed, at least in theory. Any ideas? [10:54] Launchpad bug 467490 in nvidia-common "nvidia drivers don't work due to -Q in obsolete /etc/modprobe.d/lrm-video" [High,In progress] https://launchpad.net/bugs/467490 [10:54] Launchpad bug 459829 in nvidia-common "Upgrade from hardy to Karmic didn't remove lrm-video" [Medium,Fix released] https://launchpad.net/bugs/459829 [10:55] dholbach: yes kde-i18n-zhtw isn't in lucid, it was translations for KDE 3 [10:56] ArneGoetje: ^ [10:56] thanks Riddell [11:00] cjwatson: is it ok to perform other operations after doing a db_stop in postinst scripts? [11:00] what kind of operations? [11:01] you should, in general, not use db_stop at all unless you are absolutely sure you know what it does [11:01] cjwatson: even things such as rm -f some_file [11:01] it's a workaround for things better handled in other ways [11:01] rm -f is fine [11:01] cjwatson: oh, it's that much "not recommended"? [11:01] but db_stop can break things you really don't expect [11:01] pitti: yes [11:01] cjwatson: I usually do it after I know I'm done with it, since later stderr output used to confuse it [11:02] please don't - I can advise on other, better approaches [11:02] it doesn't even really help much with that [11:02] 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] 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] 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] basically it's nothing but trouble :) [11:03] 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] that's completely wrong [11:04] just delete the db_stop, what's it for anyway! [11:05] I don't think it would cause the script not to remove the file, though [11:08] cjwatson: so if I remove db_stop will debconf require user interaction and execute my .config script? (just to be sure) [11:12] tseliot: after calling db_stop, any following debconf commands may *break*. it's not a clean shutdown [11:12] 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] 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] 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] (this is in nvidia-common) [11:14] it seemed to make sense when I read the documentation (a long time ago) [11:14] it's almost always wrong to call db_stop at all [11:14] yes, it's wrong there [11:15] cjwatson: ok, thanks [11:15] just remove it from both your config and postinst, and things will probably work better with no downside :) [11:15] sure [11:37] cjwatson: I get no debconf prompt if I remove db_stop [11:38] run with DEBCONF_DEBUG=developer to see what it's doing [11:38] the question's probably just marked as seen from a previous run, or something [11:40] cjwatson: do you mean export DEBCONF_DEBUG=developer and install the package? [11:40] as it doesn't show anything this way [11:41] or is it something that I have to put in either the .config script or in the postinst script? [11:42] 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] ah, ok [11:45] cjwatson: yes, that worked: http://pastebin.ubuntu.com/387559/ [11:47] cjwatson: I guess it's my fault. Thanks for your suggestion [11:47] tseliot: right, so by the looks of things either /usr/bin/nvidia-detector doesn't exist or nvidia-detector returns none [11:48] the latter [11:48] tseliot: that config script has another serious bug right now [11:48] cjwatson: oh, what is it? [11:48] tseliot: config scripts may only use things on the filesystem that are in Essential packages, plus debconf itself [11:48] because they're run at preconfiguration time [11:48] oh [11:49] 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] 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] cjwatson: what do you mean? I'm already sourcing /usr/share/debconf/confmodule in the postinst [11:50] nvidia-detector is a python script which relies on a library included in the same package [11:53] tseliot: but when the config script is executed, your package may not have been unpacked yet [11:53] /usr/share/debconf/confmodule is safe because it's in debconf; config scripts may rely on Essential packages *plus debconf* [11:54] cjwatson: right. Is there a way to call the config script in the postinst? [11:55] tseliot: if you want that, just move the contents of the config script into the postinst, and delete the config script [11:55] I need to warn users about the fact that they're using an obsolete driver with a UI [11:56] 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] 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] that said I suppose you're testing whether the binary exists [11:57] cjwatson: yes, this shouldn't interrupt upgrades with update manager as u-m deals with these things first (right mvo?) [11:57] but what happens if this is a new installation? [11:57] tseliot: er, no! [11:57] tseliot: update-manager isn't special in this regard [11:58] it doesn't magically reach in and run config scripts in a screwy way [11:58] cjwatson: I think update-manager includes part of nvidia-common already [11:58] that is done by debconf, in the manner I described [11:58] tseliot: we can't have correctness depend on people using update-manager [11:59] cjwatson: so the debconf UI will be used only for example if users dist-upgrade from the command line [11:59] 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] 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] mvo: the thing is that it will get the logic wrong ... it'll use the previous version of nvidia-detector, etc. [11:59] right [11:59] or maybe no version at all [12:00] cjwatson: oh, sorry. I missed that bit of the discussion [12:00] so it really needs to be moved into the postinst [12:00] 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] yes, I assume that's the way it works now [12:01] 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] mvo: is this correct? [12:02] so in that case, the correct fix is indeed to move the config script contents into the postinst [12:02] yes, definitely, that's a bug [12:02] 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] I have not tested if its still working, but if the interfaces have not changed it should [12:03] the code around it in u-m has not changed [12:04] 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] tseliot: I'm happy to look at the u-m integration/test it after UI freeze [12:05] 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] tseliot: ok, cool [12:05] 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] cjwatson: yes I forgot to paste the line that sources debconf [12:07] ok, let me try again [12:12] cjwatson: it works great now. Thanks for your help [12:12] np === yofel_ is now known as yofel [12:30] 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] morning [12:39] pitti: can you also approve php-interbase as well? [12:44] * dholbach hugs pedro_!!! [12:44] * pedro_ hugs dholbach back [12:48] ok you guys can let go now === MacSlow is now known as MacSlow|lunch === bfox__ is now known as bfox [13:07] zul: what's the bug#? I didn't get mail about it apparently [13:07] pitti: 530932 [13:08] zul: done [13:08] 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] pitti: did you get my message about my external harddrive? if not I'd be glad to remessage [13:08] sebner: I answered with "please ubuntu-bug storage" [13:09] sebner: without further information there's nothign I can do, I'm afraid (it seems to work well for most people) [13:09] pitti: ok ill do that in the future with regards to php [13:09] pitti: didn't get that :), running that while the exterinal drive is attached right? [13:10] sebner: not quite; it'll tell you [13:10] it's an interactive process [13:12] pitti: grr, before you waste your time and energy on me: It's magically working now [13:12] pitti: just tried it, 2 days ago it wasn't and wasn't workingit :( [13:12] :) [13:14] pitti: I'm really sorry [13:14] * pitti isn't sorry about things working :) [13:17] pitti: sure but wasting time is not nice, next time I'll try again right before contacting you :) [13:17] sebner: no prob, didn't take any time [13:18] * sebner hugs pitti :) [13:18] and wasting time with success messages cant be that bad :) [13:21] heh [13:28] 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] apw: I think it's OK these days; I haven't noticed any problems at the NEW-queue stage for a while [13:32] cjwatson, thanks, i think that covers all the items [13:33] 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] apw: didn't we already work this out? [13:34] 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] "the manuals" ? [13:34] man perf stat ... manuals [13:34] yeah they just say "perf" [13:34] because we said we'd put a /usr/bin/perf that had [13:35] #!/bin/sh [13:35] exec $0-$(uname -r) [13:35] in it :p [13:35] right ... so happy with that ... looking for advice as to how to package the manuals for it [13:35] whatever ships that can ship the man page :) [13:35] I doubt it'll change much [13:35] after all, the kernel package doesn't actually include its own manuals either [13:36] well t [13:36] the manuals are pretty estensive for perf [13:36] i guess i could include the perf script in the main kernel source package and package that too l ike t [13:36] the linux-doc package which seems to be self-replacing [13:37] Keybuk, ok will try that than [13:51] where do the u1ms people live on irc? [13:52] directhex: /j #ubuntuone [13:59] mvo: Have you seen bug #530632? ttx suggested I made you aware. [13:59] Launchpad bug 530632 in initramfs-tools "Upgrading from 8.04 to 10.04 fails on update-initramfs" [Undecided,New] https://launchpad.net/bugs/530632 [14:01] Omahn: I haven't, let me check [14:01] 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] mvo: It's during the upgrade. [14:02] mvo: I'll upload the contents of /var/log/dist-upgrade/* shortly. [14:04] Omahn: thanks! [14:13] mvo: Uploaded. === kirkland` is now known as kirkland [14:13] $ cat /etc/default/locale [14:13] LANG="de_DE.UTF-8" [14:13] $ echo $LANG [14:13] de_DE.utf8 === sconklin-gone is now known as sconklin [14:13] so, does anybody know what magic rewrites $LANG on login? [14:14] gdm ? [14:14] (guessing) [14:14] yes, gdm does [14:14] better question: why does anything care about the difference, given that they're aliases [14:14] hm, on a VT it's not rewritten [14:15] cjwatson: oh, I have a bug to fix in gnome-menus, which cares [14:15] ArneGoetje, ogra: thanks === MacSlow|lunch is now known as MacSlow [14:18] pitti: I'm almost happy that gdm is doing this, because it's shaking out bugs like that [14:18] 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] I'm going to make the gnome-menus cache robust against that, I was just curious [14:19] .utf8 is glibc's canonical internal form; .UTF-8 is the form it advertises in SUPPORTED [14:19] (.utf8 is what you always got from 'locale -a') [14:19] pitti: anyways, .utf8 and .UTF-8 work both [14:19] so I don't know exactly why it changed but I can imagine things like something trying to canonicalise the name [14:20] 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] ArneGoetje, many scripts and tools blindly rely on UTF-8 [14:21] ogra: they're buggy and always needed to be fixed anyway [14:21] ogra: yep, it was the common way to write the locale codes until recently [14:21] cjwatson, i didnt say they dont need fixing :) === dendrobates is now known as dendro-afk [14:21] (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] mvo: On a different note, is it possible to get my application for the sru-verification team from 2008 approved? :-) [14:23] Omahn: probably :) bdmurray is now in charge I think [14:23] 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] yes [14:23] that's just one tool though :) [14:24] well, a quite essential one [14:24] sure [14:24] :) [14:24] 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] true [14:30] mvo: Your automatic build system appears to have already replicated my initramfs upgrade issue [14:31] http://people.ubuntu.com/~mvo/automatic-upgrade-testing/2010-03-01-09:08:07/dapper-hardy-lucid-ubuntu/apt-term.log === Lutin is now known as Guest49002 [14:33] Omahn: thanks, I targeted the bug now [14:34] Omahn: just there? or in the normal lts-ubuntu profile as well? [14:34] Omahn: was your upgrade a dapper install before ?or is it just coincidence? [14:35] 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] mvo: Conincidence. Our machines are all hardy originally. [14:35] ArneGoetje, what happens when you try to log in exactly? [14:36] 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] Omahn: oh yes - its in the auto-upgrade-tester package, and in bzr under lp:update-manager (in the AutoUpgradeTester subdir) [14:39] Omahn: its pretty flexible, but not well documented, I'm happy to help you if you have specific questions [14:39] mvo: Thanks, I'll check it out. [14:39] 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] weird [14:40] do you have anything special for your account like protected userdir? [14:40] seb128: no [14:41] seb128: I have one suspicion... [14:41] ArneGoetje, which is? [14:43] 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] ArneGoetje, /var/cache/gdm [14:44] s/dies/does/ [14:44] it does store the .dmrc there to handle protected userdirs [14:44] so it can read the config before asking the password [14:44] seb128: thanks! Yes, it still has the buggy file there. [14:44] np [14:45] please open a bug saying that gdm breaks when you break that file content [14:45] seb128: ok, will do [14:45] thanks [14:46] seb128: yay, works again! :) [14:46] good! [15:01] mvo: re http://lists.debian.org/debian-devel/2010/02/msg00424.html, is the new API going to land in lucid (soon)? [15:01] or indeed [15:01] juliank: ^- [15:02] 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] In the end, it depends on whether a freeze exception is granted for it [15:03] 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] since then I won't have so much skew to deal with [15:04] cjwatson: its the goal, it will make the next lts upgrade much simpler as well [15:04] right [15:04] lots of balls to juggle currently, I want to look at it tomorrow (when UI freeze is over) [15:05] I looked last week and it was 98% there, some compat issues with the progress (as juliank said) [15:05] but nothing that looks like a real blocker [15:06] 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] juliank: thanks, please let me know and I have another look [15:08] poo. I got rid of "GRUB loading" and left the dot and newline in [15:09] more tedious boot testing ... === dendro-afk is now known as dendrobates [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] either that or my machine is toast [15:20] apw: this sounds more like aptitude, apt just informs about autoremovalbles [15:20] ahh crap so it is, damn a typeo on my behalf, why is aptitude installed anyhow [15:23] aptitude is in ubuntu-minimal because tasksel needs it if you select manual package selection in the server installer [15:24] it's not ideal but the cost is tolerable [15:24] might sort that out one day [15:24] the alternate and desktop CDs could live without it [15:27] seb128: How can the CSD patch for Gtk be tested? I take it there’s a theme that uses the functionality. [15:28] ion, GtkWindow::client-side-decorated = 1 in your gtkrc [15:28] but it will not look correct without a specific theme [15:28] Thanks [15:29] I think people are working on making a theme using it [15:29] Alright [15:29] wait a few extra days I would say [15:29] I will try to check and let you know [15:29] Thanks [15:44] bah, gtk is still building on armel [15:45] bloat ! 3h buildtime are to much for a toolkit ! [15:48] ogra: gtk doesn't take that long to build [15:48] it's just built several times [15:48] ah [15:48] static, udeb, directfb [15:48] + normal [15:49] (i wasnt seriously ranting :) ) [15:49] it's something which annoys me too [15:49] I would like to drop the static build at least [15:50] for what is that ? d-i in debian ? [15:50] no, udeb is for d-i [15:50] and directfb somewhat [15:50] and directfb i guess [15:50] yeah [15:51] we should probably just switch the whole distro to fltk :) [15:51] would also prevent all kde vs gnome discussions :) [15:51] lol [15:55] 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] juliank: great [16:00] seb128: sounds like directfb is going to go away in the not too distant future [16:01] at least the d-i uses of it === jamie is now known as Guest65472 [16:01] yeah, I've read some blog posts about that [16:05] 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] lol [16:06] it was apparently written to roughly match what they thought the X code assumed BSD/SVR did at the time [16:06] 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] 16:12 cjwatson: will it matter whether the VT is in VT_AUTO or VT_PROCESS ? [16:13] Keybuk: moo [16:14] (dunno yet) [16:14] I don't think so, but I could be missing something [16:14] the confusion I had was whether there was a font-per-VC [16:15] or whether the font applied to every console [16:18] the code appears confused on this issue too ;-) [16:20] Riddell: we have backported the av_lockmgr stuff to 0.5 because we were asked by the geexbox guys at fosdem [16:21] Riddell: it is included in the 0.5.1 release, which we published yesterday [16:21] Riddell: I'm currently working on the package, and will upload it to lucid shortly [16:21] Riddell: as for that specific question, it was decided to bump MICRO instead of MINOR in libavcodec for that feature backport [16:22] Riddell: does this answer your question? [16:23] siretart: so this AVLockOp enum will appear in your upload today? [16:23] Keybuk: "depends" [16:24] Keybuk: vgacon is one-font-to-rule-them-all, currently; fbcon is font-per-VC [16:24] Riddell: today I'm not sure, I don't feel very well today. But I should manage it this week [16:24] Keybuk: BTW what's the current best way to blacklist fbcon so that I can test this properly [16:24] ? [16:24] cjwatson: blacklist=fbcon ? [16:24] though you'd need .modeset=0 and blacklist=vga16fb I guess too [16:24] 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] Keybuk: ok, thanks [16:25] siretart: lovely thanks === MacSlow is now known as MacSlow|afk [16:26] 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] juliank: right, just clarifying whether there'll be a Breaks even if squeeze has >= v+1 [16:26] I think there should be [16:26] cjwatson: all the current ioctl()s seem to ignore whatever tty you use [16:26] and just fiddle with vc_cons[fg_console] [16:26] which is somewhat scary [16:28] * Keybuk thinking what if you do that ioctl mid-vt-switch for example [16:28] cjwatson: Do you want a package with Breaks: against more than 20 other packages? [16:29] juliank: I don't see why not, if it's accurate [16:29] I don't subscribe to the theory that upgrade compatibility should be dropped after each release :-) [16:30] 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] shtylman: seen my conversation with siretart above? [16:30] Keybuk: I was sort of hoping there was a VT lock somewhere, but haven't looked too hard ... [16:30] cjwatson: HAHAHAHA [16:31] no such thing [16:31] there's vga_lock at least [16:31] but I think that's for the VGA hardware [16:31] it may not matter [16:31]