=== rickspencer3 is now known as rickspencer3-afk === savvas_ is now known as savvas [06:41] good morning [07:03] Good morning [07:04] LordKow: try enabling UXA and KMS :) [07:11] Hey pitti! [07:15] pitti: well, FUSA isn't working properly here :) [07:15] tjaalton: at least something! :-) what's wrong with it? [07:15] it doesn't present the options to shutdown/suspend etc [07:16] those work from the gdm login screen [07:16] interesting === herb__ is now known as herb [07:16] also, seems like FUSA is making Xorg eat the cpu [07:16] since removing it from the session and logging back in makes that go away [07:24] KMS = 100% brightness :/ === tkamppeter_ is now known as tkamppeter [08:55] What is the difference between Xserver and Xorg? I believed that Ubuntu 9.04 uses Xorg 7.4, now I'm reading it's using Xserver 1.6. What is Xserver 1.6? [08:57] Xorg is an x server [08:57] xfree86 is another one, now mostly obsolete [09:00] highvoltage, i know about xfree86, but, that's in version 4.something.... I have no idea what is Xserver 1.6 [09:00] i tought that xserver is 'type' of sofware... xorg is xserver ,xfree is xserver.... (much like mysql is rdbms, postgres is rdbms) [09:09] MmikeNekud: "Xserver" is a name for a particular (important) component released by the X.org Foundation (actually, they normally call it xorg-server but both names are in use colloquially); see e.g. http://www.x.org/wiki/Releases/7.4 [09:10] MmikeNekud: the name "X.org" or "Xorg" is sometimes used to refer to the whole suite of software released as various modules by the X.org Foundation [09:10] cjwatson, so, xserrver 1.6 is one of the xorg 7.4 components? [09:11] cjwatson, is it that xserver means a spec to which xorg and xfree86 conform? [09:11] since xorg replaces xfree86 as the default xserver in a lot of distros [09:17] MmikeNekud: actually, no, X11R7.4 included xorg-server 1.5.1 (as you would see if you'd gone to the wiki page I quoted above); Ubuntu 7.04 went a bit ahead of X11R7.4 for the server [09:17] maco: err, "spec" is putting it a bit strongly. Obviously both XFree86 and X.org need to include an X server or they'd be a bit pointless. [09:18] cjwatson, is there some sort of API or something? [09:18] there's a wire protocol, yes [09:18] XFree86 was monolithic - the server wasn't released separately, X was just one giant lump [09:19] StevenK: hey, will you do syncs today? [09:19] cjwatson, yes, i see that now.... Ok, thnx, you clarified quite a bit for me here.... :) I'm trying to set up my friends laptop, he has FireGL 5200, and that one doesn't seem to be working with ubuntu :( [09:19] so it's only with X.org that the server has started having independent versioning [09:19] seb128: I was thinking about it :-P [09:20] StevenK: that would be nice, would clean the sponsoring and merge lists ;-) [09:20] splitting xorg from one big fatty fat fat into actually distinct parts was one of the headline items that differentiated xorg 7.0 from xorg 6.9's xfree86-like build system [09:21] And it moved to autofoo [09:22] everyone loves autofoo [09:23] it's like cotton candy for the soul [09:29] cjwatson: I was reading yesterdays backlog, and I wonder what mksquashfs -sort actually does/how it works [09:30] do you keep a list of filenames or block numbers? [09:34] pitti: how do I stop the retracer from marking installer bugs as duplicates of bug 260001 when they aren't? they just happen to have the same backtrace because the backtrace isn't detailed enough. Can I change the bug description to stop it doing that? [09:34] Launchpad bug 260001 in ubiquity "ubiquity crashed with InstallStepError in configure_bootloader()" [Undecided,New] https://launchpad.net/bugs/260001 [09:34] Chipzz: actually currently we give an empty file to mksquashfs -sort while building our live CDs :-) [09:34] (which is largely by accident, but) [09:35] cjwatson: but that doesn't actually explain what that option does :) [09:35] Chipzz: read the source, you know as much as I [09:35] or the manual page [09:36] I was just going to say, I'm too lazy to install a package just for reading the man-page ;) [09:36] but anyway [09:36] what I was thinking [09:36] would something along these lines help for ext3: [09:37] find /temporary/path | sort | cpio -pumdv /path/to/loop/ext3 [09:37] which would copy the files to the ext3 images in some sort of sorted fashion [09:38] cjwatson: I could delete that one from the dup db, but the next time such a report comes in, it would be auto-dup'ed again [09:38] also, something you may want to consider may be fragmentation of the image - in which case ext4 extents could help? [09:39] cjwatson: I can do a quick cowboy-hack to not dup to 260001, if that helps [09:39] cjwatson: fixing that properly will require some deeper thinking [09:40] cjwatson: anyway, just some idle braindumps I got when reading that backlog; you probably thought of those already, but just trying to contribute some ideas ;) [09:44] pitti: would changing the bug description make any difference, or does it look at the original description or some cache? [09:44] cjwatson: no, just bug numbers and stack traces [09:44] Chipzz: we used to do that sort of thing but it was hopelessly awkward to maintain and we don't want to go back to it [09:44] and package names [09:45] pitti: ah. In that case, yes, I'd appreciate it if you could blacklist 260001 from auto-duplication [09:45] the traceback just says "installing the bootloader failed for some reason" [09:46] cjwatson: done [09:46] thanks! [09:47] (oh god, now I'm going to have to go through the 66 dups - oh well) [09:47] cjwatson: well, untested, but worst that can happen is that it crashes now, and then I'll fix it [09:47] cjwatson: sorry [09:47] cjwatson: but I guess without auto-duplication you also had to go through them [09:48] yeah [09:48] not your fault :) [09:49] hm. it seems i still suck at Closes: [09:53] cjwatson: the installer again? [09:55] lifeless: ? [09:57] cjwatson: bug duplication detection [human and bot] [09:57] cjwatson: we have similar issues in bzr where users think things are the same, that aren't, fairly regularly [09:58] lifeless: in this case it's essentially because the traceback is too general [09:58] I can't really blame them, you have to look into the syslog to stell [09:58] tell [09:58] I wonder if we could hack the backtrace to be more useful [09:59] clearly, but not retrospectively for old versions of the installer burned onto physical media [09:59] of course :) [10:00] though it does irritate me when users deliberately report duplicates of their own bugs - but not much to be done about that [10:03] slangasek: hi, you know about samba and pam, could you have a look to bug #375569 and reassign where it would make sense? [10:03] Launchpad bug 375569 in gnome-screensaver "gnome-screensaver failure - can't access samba password database - not running as root " [Undecided,New] https://launchpad.net/bugs/375569 === Tonio__ is now known as Tonio_ [10:06] TheMuso: is anyone testing the ubuntustudio alpha-1 images? [10:06] seb128: FYI, slangasek is on holiday this week [10:07] pitti: oh right ;-) [10:07] pitti, seb128: doesn't mean I'm not queuing it, though :) [10:08] slangasek: thanks [10:08] probably a not-a-bug, in any case [10:09] slangasek: hush, back to gardening! :-) [10:09] oh well, would ba fairly dark outside, I figure [10:09] yeah, it rained all day today too :P [10:09] good gardeners can mow their lawn in the dark ! [10:09] I don't claim to be a good gardener [10:09] :) [10:09] ogra: to the great amusement of their neighbours [10:09] yeah [10:10] mine use to start around six on a good day :/ [10:10] (AM) === korn_ is now known as c_korn [10:54] cjwatson, Ok, so the thing for the kernel package post-installation would be to only claim /vmlinux if the version is more recent that the current. So this relates to the kernel with the higest version number and not to the one which happened to be installed last [10:55] smb: it's not especially clear to me what should happen if you previously had 2.6.28-6-386 installed and then install 2.6.28-11-generic [10:57] Right, that was the reason that lead me to that timestamp idea. From purely looking at the installation viewpoint I deducted -u should always update all initrds that have been touched during that round of installation. [10:58] no, that isn't true [10:58] what is the criteria for a rebuild [10:58] update-initramfs -u means "update the most current initramfs", which may be because one of the userspace packages that form part of the initramfs has been updated, not just because the kernel has been updated [10:59] apw: what sort of rebuild? [10:59] sorry for an initramfs rebuilt, it seems that update-initramfs -u is run whenever any possible contents are change [11:00] i presume we don't rebuild all kernels as that could break your old ones [11:01] And the whole problem arises because when the kernel installation itself builds an initrd, udev was somehow in an inconsistent state, so all builds done between that are broken and when udev finally gets into the correctly configured state, it will only update the mos recently build initrd [11:01] apw, that would be my thinking [11:02] cjwatson, how do the delayed triggers work for other things [11:02] There's several factors involved though. [11:02] it almost sounds like we should rebuild kernels at the end of things [11:02] rebuild _initrds_ at the end [11:02] If I install something *other* than a kernel that affects initramfs, I'd expect I'd want all my initramfs's updated. [11:02] apw: please see the docs for dpkg triggers [11:02] it's a lot quicker than me reciting them [11:02] persia, should that update be broken though then we would break _all_ your kernels, bad [11:03] cjwatson, thanks for the pointer [11:03] persia: we've always said that we should only update the most current one, in order to increase the likelihood of having something older you can boot into if things go wrong [11:03] I have no interest in changing that [11:03] persia, But in theory you could have a shared /boot and have older kernels there. Which you do not want to touch [11:03] but I do think we should update the most current one *for each kernel flavour* [11:03] cjwatson, i think that is very reasonable to do [11:04] cjwatson, Hrm. I was unaware of that, but it does explain some behaviour I encountered in the past. [11:04] * apw thinks he has a box with that situation [11:05] apw, So we have to make sure update-initramfs can get the most recent kernel version [11:05] apw: largely we do build initramfses at the end, but not for the kernel - there's no way to pass data to triggers, so the trigger can only say "update most current initramfses" [11:05] look, I can fix the update-initramfs thing [11:05] I know exactly what the problem is there [11:05] what I don't know is how to deal with the *other* problem Steve identified [11:05] cjwatson, Ok, and I fix up the other thing [11:06] the kernel postinst unconditionally claims the /vmlinuz symlink === Tonio__ is now known as Tonio_ [11:06] smb: how? it's not at all clear what the correct semantics are [11:06] what does the vmlinuz link officially even mean [11:06] it's the default thing you boot into [11:07] cjwatson, Ok, to me it sounded as that link always is set to the most recently *installed* kernel [11:07] smb: it is, right now; it is not clear that this is correct [11:07] does anything use it at all? [11:07] apw: update-grub [11:07] cjwatson, You actually boot into the kernel defined in grub. I don't think /vmlinz has any meaning to that [11:07] smb: update-grub is smarter than you think it is [11:08] or at any rate is supposed to be :-) [11:08] cjwatson, Maybe smarter than I fear it is .:) [11:08] also there are still people using lilo for various reasons and I'm pretty certain that lilo.conf refers to /vmlinuz [11:08] cjwatson, So that is the "saved" magic? [11:08] (legitimate reasons; the installer still defaults to lilo in some circumstances) [11:08] so our behaviour currently is to say that the latest kernel is your default kerenl [11:09] apw, If I parse unconditionally claiming correctly it set the link whenever you install a kernel... But maybe not... [11:10] well, how about looking at it this way for something that's *obviously* wrong [11:11] let's say you have both 2.6.28-10-generic and 2.6.28-11-generic installed, and for whatever reason (let's say filesystem corruption) you decide to reinstall the 2.6.28-10-generic package [11:11] right now, it's my belief that doing that will change /vmlinuz to point to 2.6.28-10-generic when it was previously 2.6.28-11-generic [11:11] can we agree that this is wrong? [11:12] cjwatson, I would agree [11:12] if the user has no other way to change the default, that might be a reasonable way to say i want this one to be the default [11:12] they have other ways [11:12] if they have a way to select it is wrong [11:12] so we should only update the link if the kernel is 'newer' in some sense [11:12] now, what should happen if they have 2.6.28-6-386 installed and then install 2.6.28-11-generic? [11:12] those ABI versions aren't comparable [11:13] and, while we generally prefer -generic, the user might have a reason to use -386 [11:13] (substitute -server if you prefer) [11:13] i would tend to say stay at the latest of the current flavour [11:13] and if the users wants to change they can use the changer [11:13] let's say that they have both the linux-386 and the linux-generic metapackages installed, so if they keep upgrading, right now the link flip-flops over time [11:14] I think I agree, mostly, that it should stay pinned to a flavour, with one exception [11:14] Right, so the post install would have to look at the current current flavour adn only update if newer. [11:14] for that reason i think we should only move the link to a later version of the current flavor [11:14] if you *remove* a kernel, it needs to switch that link to a different flavour if there are none left of the current flavour [11:15] but really the exact rules need to be written down in policy style [11:15] cjwatson, good point ... and yes we should document them somewhere [11:15] smb, you gonna do that. cjwatson do we have a place for that kind of thing? [11:16] if not we should make a KernelTeam/Policy thing and put it there [11:16] a big comment in the postinst would be fine, or a wiki page [11:16] probably ought to be commented in the postinst anyway [11:16] Probably remove would dec the abi version as long as there is one with the same flavour and go to generic or anything left if not [11:16] can anyone please test the current Kubuntu alternates? it becomes urgent now [11:16] stay in flavour if at all possible [11:16] apw, Maybe we get togehter later to think of that [11:17] I don't think I'd mind it being essentially random if you remove a kernel, as long as it says on stdout what it's doing [11:17] smb, sure. i think the rules are pretty sensible and implementing them sounds relativly straight forward [11:17] i think some awk magic can work it out [11:17] apw, Yes, I think the hardest part is to think of all the cases [11:18] and what should be the sensible approch there [11:18] pitti, I could do a bit but only start in around an hour? [11:18] pitti, something special to have tested? [11:19] smb: just whether they install in general [11:19] smb: the previous 5 didn't [11:19] smb: if you can get through a standard "entire disk" VM install and can login and get a desktop, that's enough [11:19] pitti, ok, so kubuntu alternate in general or 64 or 32 specifically [11:19] smb: we need to test both [11:20] pitti, Ok, let me start getting the immages [11:22] pitti, rsyncing, I'l do the installs when I am back [11:23] smb: thanks [11:25] smb,apw: If you haven't already, I'd recommend familiarising yourself with the chapter of the Ubuntu policy manual that describes the valid state transitions for packages [11:25] cjwatson, ok thanks [11:25] smb,apw: it's something like "how maintainer scripts are called" [11:25] cjwatson, Good idea. Thanks [11:27] http://women.debian.org/wiki/English/MaintainerScripts has some nice graphs for the simpler cases. [11:39] pitti: I tried testing them today but the RT kernel we are using + new karmic bits + desktop are all a little wacked out, so since nobody else has done anything at this point, I am enclined to say that we'll skip alpha 1. [11:39] TheMuso: okay, understood [11:40] ogra: did anyone test the edubuntu addon alpha-1 CDs? [12:00] pitti, no idea [12:00] pitti, i havent touched edubuntu since hardy [12:00] ogra: want me to release edubuntu alpha-1 CDs? [12:00] oh, who is the primary contact nowadays? [12:01] LaserJock is the last guy taking care from a technical side [12:01] probably highvoltage too [12:01] highvoltage: did you happen to test the edubuntu alpha-1 addons? [12:02] i guess if nobody tested it wont do harm to skip A1 [12:03] *nod* === fta_ is now known as fta [12:46] doko, hi, any plan to add binutils-gold to karmic? [12:47] fta: yes, should be reenabled [12:48] * ogra thought thats still experimental [12:49] that's why we remove it before the releases [12:49] ah [12:49] ok, thanks [12:50] i want to start experimenting with it on some big packages [12:51] cjwatson, did you notice that upstream is two versions ahead wrt unionfs-fuse ? [12:56] pitti: I agree with ogra that it's probably safe to skip A1, but if it won't be too late I'll be happy to test it tonight [12:56] ogra: no, but not exactly top of my agenda right now [13:00] Packaging Training session in #ubuntu-classroom now! [13:00] ogra: (don't get me wrong, thanks, just doing a lot of stuff right now) [13:01] cjwatson, yeah, i just noticed there were two upstream releases, one of tehm with a cryptic message wrt com filesystems [13:01] 0.22 [13:01] - Fix a bug reported by Jens Hoelldampf , in 0.21 cow [13:01] didn't work for pathes. [13:02] s/com/cow/ [13:05] ogra: at the moment I think it might be easiest to identify the problem I can see right now, and make decisions based on that [13:06] but right now I'm looking through grub-installer bugs and worrying about my allhands talk, so ... [13:07] yep, i just noted that there are a bunch of upstream commits in their mercurial that arent released and that we are two releases behind, i simply thought i'd give you a heads up about that fact no need for any action here :) [13:08] pitti, Kubuntu alternate i386 installed. My favourite testcase (playing mp3 with amarok) fails. No codecs installation offered. [13:16] smb: thanks. audio may well not work at all that's not unexpected [13:17] Riddell, actually it makes sound. :) [13:17] amd64 next [13:17] smb: when does it make sound? [13:18] Riddell, Login and logout (just before jockey crashes on logout. heh) [13:20] ok, that's good [13:20] hi people, is there any plans to replace or extend gnome-bluetooth functionality with blueman? It has integration with NM .7 so it is possible to use Bluebooth modems as mobile broandband connections === keffie_jayx is now known as effie_jayx [13:38] smb: thanks; if you got this far, it's about as much as we can expect for a1 [13:40] pitti, Yeah, its not too bad. amd64 is about to reboot after installation [13:43] pitti, Riddell, Ok amd64: basic installation ok, too [13:43] smb: cheers! [13:43] smb: mouse working? [13:43] Riddell, yep [13:43] better than I get :) [13:43] Riddell, All "old" hw. Ps/2 mouse and keyboard [13:48] is there a formal way to request that someone not act like an arse by treating launchpad bugs like youtube comments? === rickspencer3-afk is now known as rickspencer3 === asac_ is now known as asac === Lure_ is now known as Lure [14:38] kirkland: Didn't try it out, but I see that /usr/bin/ecryptfs-setup-swap uses vol_id and it was dropped; you might have to move to blkid instead [14:38] * lool goes filing a bug [14:38] 376486 [15:09] lool: ah, good catch, thanks. [15:09] lool: any chance you can file a bug to keep that from getting lost? [15:09] kirkland: I think he did * lool goes filing a bug 376486 [15:09] i'm doing my first steps with packaging and am trying to cook up my own tracker 0.6.94 package, starting from the jaunty 0.6.93 package. turns out the patch 99_autotools.patch needs to be updated - how do I do that? [15:09] diverse_izzue__: you can move the patch out of the way, cdbs-edit-patch 99_autotools.patch; autoreconf; remove cache dir; exit [15:09] kirkland: like seb128 said :) [15:09] lool: seb128: gotcha, thanks! === pitti changed the topic of #ubuntu-devel to: Archive: Open for development | Karmic alpha 1 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [15:11] voila [15:11] seb128: by "moving the patch out of the way" you mean delete the patch file and remove the according line from the file "series"? [15:11] oh, that's a quilt package? [15:11] diverse_izzue__: try #ubuntu-motu for packaging questions [15:11] seb128: sorry, thanks. [15:19] <\sh> oh nice...I hope my new bl7000c equipment arrives in time to test karmic on it :) === Tonio__ is now known as Tonio_ [15:34] doko: You around by any chance? Do you know what is up with the Debian Java team? [15:36] bddebian: persia or ttx would be good people to ask about that. They just finished a team meeting in #uubntu-meeting. [15:36] bddebian: Nevermind. I misread which distro's team you asked about. [15:37] ScottK: Is Persia on an ubuntu-java team? [15:37] (and the highlighted person is in #debian-java anyway) [15:37] bddebian, Yes. I run the meetings. [15:38] No one ever responds in #debian-java :) [15:38] * hyperair would love to see eclipse updated. [15:39] * bddebian would love to see Java removed.. ;-P [15:39] * bddebian hides [15:40] * hyperair brandishes a knife [15:40] * ScottK reminds hyperair he has to clean up the mess after, so consider carefully. [15:40] * persia points hyperair at https://blueprints.launchpad.net/ubuntu/+spec/foundations-karmic-eclipse-update [15:42] bddebian: I'm not the nanny of debian-java ... so I just see what you seem to see. [15:42] doko: Is Python 2.6 coming to unstable anytime soon? [15:42] persia: hot air (or call it it hyperair) [15:42] ScottK: wrong channel [15:42] Well it would help us with pushing stuff back and getting syncs if the Python 2.6 bugs went from wishlist to RC [15:42] doko: I didn't mean to imply that you were I'm just trying to find a warm body that will respond. :) Response from Arnaud was that he is too busy and Michael Koch seems MIA :( [15:42] pah. hot air indeed [15:42] lol [15:42] soon, but not real soon [15:42] OK [15:43] doko: BTW, any chance of updating python2.4/2.5 libdb to 4.6 or 4.7? [15:43] bddebian: yes, I couldn't contact Michael for some months [15:44] persia: i've seen that before. unfortunately, 5 minutes after staring at eclipse's packaging, i decided against trying my luck [15:44] bddebian: I'm going to guess that comes with 2.6 [15:44] bddebian: not really. will get rid of 2.4 hopefully soonish (ScottK: not real soonish) [15:44] * ScottK did some fixing of Eclipse back in the Feisty timeframe (IIRC). Learned better. [15:44] persia: also the debian-java guys have 3.3 in svn last i checked. for some reason, it's sitting there rotting away without anyone to tend for it. [15:47] asac: How usable are the packages in the mozilla daily build team ppa? [15:47] ScottK: Sure but I'm trying to RM: any libdb < 4.6 [15:47] hyperair: Most of the debian-java packages seem to be bitrotting :( [15:49] bddebian: indeed. what happened to them? have they all died or something? [15:49] them meaning the members of that team [15:50] mterry: in general they are very much usable [15:50] I'm trying to find that out. As I said Arnaud is busy and Michael Koch is missing, the rest, I have no idea. [15:50] The set of people who are 1) active, 2) DD, and 3) have access to pkg-java SVN has become small. [15:50] mterry: firefox-3.5 is mostly frozen upstream, so you only get baked patches there [15:50] I'm tempted to NMU jamvm without jikes but I hate to do that [15:50] mterry: i run firefox-3.6 trunk and even there i usually dont get issues - probably because all extensions are incompatible/disabled ;) [15:50] asac: Heh, OK. Thanks [15:50] asac: haven't you heard of nightly tester tools? =P [15:50] hyperair: heh. i am quite happy without extensions ;) [15:50] persia: So hurry up and get your DD and join the team.. ;-P [15:50] * persia waffles harder [15:50] heh [16:00] cjwatson: I added a section to https://wiki.ubuntu.com/KernelTeam/Specs/KarmicKernelFlavours regarding unsupported architectures. Feel free to add your thoughts. === thunderstruck is now known as gnomefreak [16:15] bryce: I couldn't get an R500 chipset in the end :( So I had to go with an R600 chipset instead. I'm having massive issues with it in Karmic. I'm assuming it is trying to use the highest setting of the card rather than the highest setting of the monitor if I set it to safe graphics it works round this but the system seems to be working at double speed including the internal clock in 4 minutes it had done 7. Other [16:18] rtg: thanks [16:18] np [16:23] how do I figure out which component a package belongs to? [16:23] al-maisan: rmadison packagename will tell you (if it doesn't specify it's in Main) [16:23] ScottK: great, thanks! [16:26] al-maisan: I believe it's also in the Soyuz UI ;-) [16:26] cjwatson :) [16:27] https://launchpad.net/ubuntu/karmic/+source/man-db "Component: main" for example [16:28] or https://launchpad.net/ubuntu/karmic/+source/man-db/2.5.5-1build1 which is what you can get to from the main source-package page also shows that [16:28] I don't think you can get binary specific component that way though. [16:28] ScottK: you can. e.g. https://launchpad.net/ubuntu/karmic/i386/linux-rt has a Component column [16:28] cjwatson: thanks for the pointer but command line tools are typically much handier. [16:28] it's just very cumbersome to find because the links aren't very good [16:30] al-maisan: well, personally I couldn't agree more, just thought somebody used to Launchpad might prefer the web UI ;-) [16:30] but certainly I always use rmadison myself - unfortunately it doesn't handle ports yet [16:30] I think we have all the pieces in the LP API necessary to write lpmadison now mind you ... [16:30] I am an "old dog", love the command line :) [16:30] cjwatson: Thanks. I didn't know about that one. [17:06] cjwatson, when using ubuntu-cdimage, is there an easy way to replace the ubuntu-keyring package in main to include a new ubuntu-keyring package on the fly? (I tried putting one in the LOCALDEBS folder, and it ends up on the CD, but not in the dists) [17:16] hi all [17:16] Is LVM and cryptsetup support planned for the Karmic desktop installer? [17:17] Fedora 11 has this already while I guess the changes couldn't be adapted so easily or are the installer projects compatible? [17:21] you can use the alternate installer if you want LVM === kenvandine1 is now known as kenvandine [17:38] Chipzz: it is even possible with the desktop if you install the lvm2 package but it is no real option imho [17:39] At least LVM should be possible because it is becoming more and more important. Afaik the Alternate uses LVM per default. [17:54] * pitti does an autosync run and gives the buildds something to do [18:00] doko: thanks for fixing ooo-l10n, I'm not sure what happened to break my merge :\ [18:15] cjwatson: doing a full archive rebuild on PPAs? [18:15] i386 12969 builds waiting in queue [18:15] https://edge.launchpad.net/builders/ [18:15] or is that huge number a bug? [18:18] So many PPA builders, as opposed to official archive builders? I’d have expected the PPA load to be lower than the main archive load. [18:19] hello [18:19] ion_: archive builders is real hardware, while ppa builders are VM instances afaik [18:19] Ah [18:19] Ubuntu 9.10 Alpha 1 was compiled with -fgraphite Cflag ??? [18:24] hi [18:25] That was quick. [18:26] so the silence means NO [18:27] If you say so. [18:42] bah [19:05] NCommander: there's a local directory that should work, see bin/update-local-indices; haven't used it in production since pre-warty though so it might have bitrotted, but that would be the place to start [19:05] asac: yes, testing out a new LP feature [19:06] cjwatson, yeah, that's what I tried. The debs ended up on the CD, but not in the main Packages file, so debootstrap self-destructs since the normal keyring package goes MIA :-/ === rickspencer3 is now known as rickspencer3-afk [19:15] NCommander: right, certainly not claiming it works, just that you can probably debug it into existence from there ... it's where I'd start [19:15] it may put things into dists/karmic/local/ or some such which might not work for debootstrap [19:15] I honestly forget, it's been nearly five years :) [19:15] cjwatson, well, its ... weird :-/ [19:16] cjwatson, I'll provide a branch for merging once I get it fixed; its handy for building unofficial images for ports :-) [19:16] anyone with a ThinkPad or Sony Vaio or Asus laptop here? [19:16] * ion_ [19:16] Thinkpad T23 [19:17] cjwatson, Sony VAIO VGN-660N [19:17] er [19:17] pitti, [19:17] ion_: does this show one device for you: [19:17] udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='ThinkPad Extra Buttons' [19:17] NCommander: does this show one device for you: [19:17] udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='Sony Vaio Keys' [19:18] pitti: It prints /sys/devices/virtual/input/input7 [19:18] running as user should work [19:18] ion_: cool; does this directory have a 'dev'? [19:18] pitti: capabilities event7 id modalias name phys power subsystem uevent uniq [19:19] ion_: aha, I want the event7/ sub dir then, I guess [19:19] pitti, /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:3b/SNY6001:00/input/input5 [19:19] pitti, the media keys on this laptop work on and off depending on the phase of the moon [19:19] pitti: Ah, it has the dev. dev device power subsystem uevent [19:20] mcasadevall: I suppose that dir has an "event5" subdir, and that has a "dev"? [19:21] pitti, huh? [19:22] mcasadevall: ls /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:3b/SNY6001:00/input/input5/event5/dev [19:22] mcasadevall: does that exist? [19:22] pitti, yes [19:22] mcasadevall: cool, thanks [19:22] ion_: thanks as well [19:22] np [19:22] mcasadevall, ion_: do you get the same output with this unified command: [19:22] udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='*Extra Buttons|Sony Vaio Keys' [19:23] * pitti tries to write a debugging tool to make debugging and fixing wrong keymaps much much easier [19:24] pitti: '*Extra Buttons|Sony Vaio Keys' doesn’t print anything, '*Extra Buttons' prints the path. [19:24] pitti, no output [19:24] pitti, that being said, I only have working brightness, no sound, but that might be because my sound setup is funny, or because I'm running Xfce :-) [19:24] ok, need to check them separately then [19:24] pitti: If it’s a plain fnmatch(), | won’t work. [19:24] ion_: | works in udev rules, but apparently not here [19:25] Ok [19:30] mcasadevall, ion_: could you now please try to run http://people.ubuntu.com/~pitti/tmp/keymap-debug ? [19:30] ion_: for you it should say "input/event7" [19:30] mcasadevall: for you it should say "input/event5" [19:30] pitti, I got input/event3 back [19:30] and probably another one which is your real keyboard [19:31] NCommander: can you pastebin sh -ex output? [19:32] pitti, http://paste.ubuntu.com/172528/ [19:32] pitti: evdev=$m/input* fails, i.e. it seems to behave as if evdev="$m/input*". I’ll edit the script to make it work and post a revised version for you. [19:34] ion_: already done and uploaded [19:34] Ok [19:34] mcasadevall: please get the current one [19:34] ah, crap [19:34] updated again [19:34] input/event3 [19:34]