=== cpplogger is now known as apachelogger [00:38] hrm.. I'm a bit out of my realm here with all this dbus and gconf stuff, but it looks to me like the cpufreq panel is already broken up into two components where the cpufreq-selector-servervice is supposed to be run as root and called on by the panel [00:40] there's an xml file in here that looks like it's supposed to define some sort of control interface methods at /org/gnome/CPUFreqSelector [00:40] it doesn't look like it's actually getting installed though [00:41] kees: The point of the way mk-sbuild does things is that you don't need to start a VM: just `schroot -c` or `sbuild -d` as usual. Plus what lool said. [00:43] kees: also, both armel and powerpc are known to work (armel works better). I believe the rest of the architectures are untested (but bugs against qemu-kvm-extras-static would be nice if they don't) [01:09] anyone know of a simple code snippet for debian/rules to do patching if it isn't using cdbs? [01:09] or an example package that i can look at for it [01:10] use dpkg-source v3, and then you can just leave the patches applied and not have to worry about junk in debian/rules [01:10] ccheney: there are a bundle of them. What's your debian/rules look like now? [01:11] persia: i'm adding a patch to karmic webkit in particular for backport to hardy [01:12] cjwatson: hmm sounds cool but can't do that for hardy :) [01:12] run what-patch to see what system it's using now [01:12] you should always stay in line with that [01:12] cjwatson: good idea for lucid and neweer though :) [01:12] cjwatson: ok [01:12] if it isn't using any patch system, just apply the patch directly [01:12] cjwatson: as best as i can tell it isn't using any patches at the moment [01:12] * persia avoids repeating the obviously correct advice [01:13] I must get round to finishing that blog post about my experiences with 3.0 (quilt) [01:13] ok so i'll have it applied directly along with a copy of the patches in debian/patches for anyone who wants to pull them out separately (if ever) [01:14] oh, at best semi-relatedly but while I think about it, my current projection is that dh will overtake cdbs in unstable sometime in July [01:14] cjwatson: dh 7? [01:14] the dh command in debhelper 7, yes [01:15] ah i see [01:15] cjwatson: is there a doc on how deb 3.0 works? [01:15] cjwatson: other than man dpkg-source i mean [01:15] that was what I was going to recommend [01:16] so does it automatically create the debian tarball for you or do you do that yourself? [01:16] cjwatson: any chance you can approve thunderbird and ubufox in the queue? [01:16] i didn't notice where it mentioned how that happens, i might have missed it [01:16] it automatically creates it the same way as it automatically creates .diff.gz [01:16] micahg: sorry, I'm just about to go to bed [01:16] cjwatson: k [01:16] micahg: poke on #ubuntu-release if you need to [01:16] cjwatson: ok, so you just need premade other tar.gz's but the debian one is automatically made? [01:16] cjwatson: thanks [01:16] ccheney: yes [01:16] cjwatson: ok thanks that helps a lot :) [01:18] ccheney: oh, there's http://wiki.debian.org/Projects/DebSrc3.0 too [01:18] cjwatson: thanks [01:19] cjwatson: are we going to get xz support anytime soon (lucid/lucid+1 ?) [01:19] lucid+1 [01:19] ok [01:20] I believe anyway, haven't paid terribly close attention but I saw some commits go by [01:20] * ccheney will do the testing for that with OOo for lucid+1, aiui it works better than lzma [01:20] ok [02:02] bug #356208 mentions: The reason appears to be that in order to work, the CPU applet (and a whole bunch of other things) attempt to validate that the "Desktop User" is a user who can perform administration. They look for the user who was setup during installation and not finding that user, they don't do anything. But, they also provide no errors, nor do they they attempt to use the "root" user. [02:02] Launchpad bug 356208 in gnome-applets "CPU Frequency Scaling Monitor Applet does not allow me to change CPU Frequency (Ubuntu 8.10)" [Low,New] https://launchpad.net/bugs/356208 [02:02] how exactly does the policy kit decide who is the admin? or where can I start tracing that process? [02:42] hrm.... here's a question... it seems that the default upstream policy is for the cpufreq applet to admin_auth_keep, so you have to type your password the first time it needs it... [02:43] bug #455694 people are complaining about the password prompt... it seems like no harm can be caused by allowing admin users to set their cpu frequency without entering their password first [02:43] Launchpad bug 455694 in gnome-applets "CPU Frequency Scaling Monitor asks for authentication all the time" [Low,New] https://launchpad.net/bugs/455694 [02:43] if I were to attach a debdiff adding a patch changing it to just be allowed, would this be accepted? [02:44] psusi: How do you detect "admin user" then, if not by authentication? [02:44] persia: group membership ? [02:44] persia, hrm... actually I guess just setting it to yes allows anyone to do it... [02:45] lifeless: Wasn't pitti trying to drop the "admin" group? [02:45] persia: so don't use that group :) [02:45] the policy kit now has auth_admin_keep set... so you have to type your password the first time you try to change the frequency [02:45] personally I'd say the 'local' bit is policy kit should be enough [02:45] some users on the forums have suggested editing it to just yes so it doesn't annoy you [02:45] lifeless: at_console? Yeah, that's what I was thinking. [02:46] eh? at_console? that a group or polkit rule? [02:46] RAOF: yah, if thats what its called. [02:46] psusi: That's the "stick it under the rug" solution. Dig into policykit a bit more, and see if you can't determine whether the current user should be able to do that by other means, and only ask for authentication when this fails. [02:46] (at_console seems reasonable for most use cases) [02:47] hrm... yea, I guess that's the question... is there something between allow_active=auth_admin_keep and yes [02:48] oh wait, no... it sounds like allow_inactive lets anyone do it, and allow_active=yes means anyone on the local console can do it [02:49] "anyone at the local console" breaks the use case of doing something, opening a guest account, and handing it to the person next to you, but I'd hope that's a rare use case. [02:50] persia: for cpu frequency setting [02:50] persia: I don't think it matters [02:50] yes, the guest would also be able to use it, but the most harm they can do is slow down the cpu, so... [02:50] yea, don't think it really matters.... [02:50] persia: because they can also take the machine and walk away :) [02:50] Agreed, hence my contrived use case : we generally don't care if a long-running job takes a little longer when *someone else* is currently at console. [02:51] persia: ok, now I understand. your description was a little opaque [02:51] so I can change it to yes and attach the debdiff to the bug and request a sponsor upload and it should be accepted? [02:52] psusi: None of the folks in this conversation so far can upload it, so the answer is "maybe". [02:52] But if it does something sensible, and is still relatively secure, likely. [02:54] it looks like there is no option to require admin, but NOT require them to enter their password again, shame... [02:55] Maybe it doesn't really require admin. [02:55] I think the lack of behaviour you see is to support things like computer labs, where most active users are *not* admins. [02:58] wait, what was the magic phrase to put in the change log to auto close the lp bug? [02:59] (LP: #nnnnn) [03:01] to allow the interactive user to set the cpu frequency without first authenticating as an admin. Closes (LP: #455694). [03:01] that look good? [03:01] You don't need closes [03:01] psusi: debuild -S -us -uc to get a source.changes : check for the launchpad-fixes-bugs header (or whatever it's called) [03:01] hrm... ok [03:02] so just "authenticating as an admin (LP: #455694)."? [03:02] "Closes: #12345" is Debian BTS syntax [03:03] hrm... seems the existing quilt patches here all start with two digits... how should I choose a number for mine? [03:03] or do I have to even? [03:09] number tells what order they were added to the package, usually [03:16] ohh, it looks like it uses bzr... should I instead create a branch on lp and modify that, then link to the branch in the bug? hrm... [03:18] or what order they need to be applied sometimes [03:19] nm,not for quilt [03:20] I'm confused... why is it using quilt, if it already uses bzr? === sconklin is now known as sconklin-gone [04:09] lool: do we have kernels for anything besides versatileab from the list in qemu-system-arm -M help [04:13] (I actually get _no_ output from qemu-system-arm when booting them) [06:58] Good morning [06:59] kees: What are you trying to do at a higher level. [06:59] persia, lifeless: CPU freq scaling admin group> I'll answer in the bug report; I have a plan for the similar problem in udisks [07:00] pitti: Excellent. Thanks. === MacSlow is now known as MacSlow|afk [07:21] good morning [07:27] TheMuso, crimsun: pitti says you might know about this; karmic + dell vostro + built in mic; any known issues with the mic not actually working? === jelmer_ is now known as jelmer [07:54] kees: No, only versatilepb and ab (I think the kernel is configured for both) [07:54] kees: There's a qemu branch for OMAP3 and an OMAP3 kernel is pending, that might be a new combination in the future [07:54] kees: Make sure you pass -cpu cortex-a8 to qemu-system-arm [07:55] kees: The default for versatile is an older CPU, but our userspace needs armv7+ [07:55] (cortex-a8 is v7; we also patched the versatile Kconfig to select v7) === sabdfl1 is now known as sabdfl === MacSlow|afk is now known as MacSlow === tkamppeter_ is now known as tkamppeter [09:32] mdz: would you be so kind as to file a bug for the usb-creator umount issue you ran into? [09:33] lifeless: I think that's perfectly reasonable as a command line option. If you file a bug, I'll put it on my list for lucid+1. [09:35] ev: ok, I'll double check my facts and put a bug up for you [09:35] much appreciated [09:35] de nada [09:36] Riddell: if you could have a look at #538522 that would be much appreciated [10:21] mvo: where do I look for the error in the test case logs? http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/kubuntu/ [10:21] Riddell: I pasted the relevant bits in the bugreport I think, its in http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/kubuntu/apt-term.log [10:22] Riddell: if you search for "dpkg: error" there [10:22] Riddell: you will find the file overwrite problem [10:22] Riddell: sorry, its not entirely user-friendly yet the output :/ [10:23] oh aye there it is === jelmer_ is now known as jelmer [10:35] pitti, Do you know off your head whether something from userspace already touches /sys/power/disk. I am looking at a bug for one system that requires the "shutdown" instead of the default "platform" method and I am wondering whether this justifies a new quirking method in the kernel or is much simpler done in user-space... [10:37] smb: the only thing I know of is pm-utils' hibernate command, which writes a "hibernate mode" to /sys/power/disk (and then "disk" to /sys/power/state) [10:37] I don't think we touch it anywhere else [10:38] smb: I think this $HIBERNATE_MODE might be what you are looking for [10:38] it can be overridden by hooks, I figure [10:38] pitti, Well mode would probably be what I am looking for. Right [10:38] pm/defaults:# HIBERNATE_MODE="shutdown" [10:39] ah, that's just a comment [10:39] smb: our actual default is "" [10:39] pitti, Ok. But its a place to investigate further [10:39] smb: in other words, we don't write /sys/power/disk by default [10:40] smb: but if a suspend.d script would set it, it should respect it [10:40] pitti, Ok. Thanks. I think thats a starting point [11:08] hm. i guess glxinfo shouldn't segfault, right? [11:10] right [11:10] :) [11:10] directhex: Xorg driver? [11:11] pecisk, intel [11:11] directhex: bug reported? [11:11] pecisk, doing it now [11:16] eh? i appear to have nvidia libglx.so [11:18] wow [11:18] directhex: isn't some kind of new hardware you got there? [11:18] pecisk, dell laptop. [11:18] directhex: brand new? [11:18] pecisk, nope [11:19] worked with karmic. wonder what happened [11:19] directhex: pastebin.ca lspci please [11:22] http://paste.ubuntu.com/396106/ [11:23] directhex: there is no Nvidia. Do you have nvidia-glx installed? Maybe remove it, restart and try again. [11:23] wait a sec, this xorg.0.log is ancient. [11:23] ahh :) [11:24] no, my mistake, was reading the Release Date line [11:25] i really don't get it. md5sums for libglx.so match the xserver-xorg-core.md5sums file, yet Xorg.0.log says vendor="NVIDIA Corporation" on the module [11:26] huh? strings says it's not nvidia's [11:27] wtf is going on -_- [11:27] directhex: 'dpkg -l | grep nvidia' >> pastebin.ca :) [11:28] wait a sec, it's this "nvidia-current". bleh @ constant renaming of nvidia packages. also, wtf did it come from? [11:30] directhex: nvidia-current I think is newest nvidia-glx driver, just so you don't have to remember which version of nvidia driver you have to install [11:30] just remove it and reboot machine [11:30] faulty dependencies I think [11:30] directhex: how did you installed Lucid? [11:30] where is the log from an update-manager upgrade? [11:31] have no idea [11:32] 2010-03-09 14:19:10 install nvidia-current 195.36.08-0ubuntu1 [11:32] came in with my upgrade, i think [11:33] something pulled it in [11:34] wobbly windows are back [11:35] yay \w/ === MacSlow is now known as MacSlow|lunch [12:03] directhex: /var/log/dist-upgrade [12:06] mvo, right. definitely came with the upgrade [12:07] aha! libmyth-0.22-0 [12:07] so if you had mythtv on karmic, upgrading to lucid will break non-nvidia 3d [12:08] that's probably a bug === jcarter is now known as highvoltage === MacSlow|lunch is now known as MacSlow [13:08] hm, I wonder if I did something wrong with bug #535090? It is marked as security vulnerability (although of lower impact). I grabbed it last week, linked branches with fixes from intrepid up to lucid and debdiffs for easier review. I think I subscribed the right groups, but nothing seems to happen about it. [13:08] Launchpad bug 535090 in erlang "CVE-2008-2371 (outer level option with alternatives caused crash)" [Low,Confirmed] https://launchpad.net/bugs/535090 [13:24] has anyone had any weird sudo behavior on the live cds? the first time I use sudo on the edubuntu livecd it kills gdm and shows some weird characters while it's restarting. after that it works fine [13:25] radoe: Everything looks right for that bug. In the most recent secuirty team meeting, there was talk of a backlog: I suspect you've just hit that. [13:26] directhex, mvo i'm not sure why libmyth-0.22-0 was even kept/upgraded during the upgrade though, nothing should be depending on it, and there is a 0.23-0 in the archive that should have pulled in libvdpau1 rather than anything nvidia [13:26] superm1, well, that's the only culprit i can find for why it was there o_o [13:27] persia: well, thx for this info. === doko_ is now known as doko [13:30] pitti: I see you got involved with the cpufreq polkit bug... last night I chanced the source code policy for gnome-applets to fix the policy file, then installed the new package, but the policy file on my system remained unchanged, and it doesn't look like the binary package contains that file... what gives? [13:30] psusi, what file? [13:30] also the package seems to be using both quilt and bzr, so which should I use? make a quilt patch? make a bzr branch? make a quilt patch IN a bzr branch? [13:30] psusi, the later option [13:31] ugh, really? use one vcs to change control another? [13:31] psusi, quilt is used by the packaging, bzr is just where we store the changes [13:31] that just seems.... wrong... [13:31] psusi, quilt is used as a patch system not a vcs [13:31] that seems like saying something is a car, not a vehicle ;) [13:32] psusi: which then gets into a diff.gz, so in practice you have at least three indirection layers for a patch. [13:32] psusi, the policy is in the -data binary btw, not sure if that reply to your question [13:32] what is the purpose of continuing to use quilt IN bzr? bzr should be providing you with everything quilt does and more [13:32] psusi, the usecase we have usually is to drop a git commit from upstream in the patches dir [13:33] psusi, we don't have the full source in bzr just the debian dir [13:33] ohh [13:33] psusi, and we keep upstream changes in the debian dir not in the diff.gz [13:33] upstream -> distro [13:33] I see [13:34] psusi: People who gets the built source package don't necessarily have bzr [13:34] as for what file, it was the polkit file... I can't recall exactly now but it was something like /usr/polkit-1/actions/org.freedesktop.cpufreq-selector [13:35] I found where that file was in the source and changed the auth_admin_keep line to yes, and rebuilt... but that file does not seem to make it into the binary paackage [13:36] psusi, the -data binary has it as said before [13:36] psusi: It would be cool to make a system which uses git/bzr and created quilt patches directly from the commits instead of having yet another indirection layer [13:36] psusi, did you install that one too? [13:37] hrm... I didn't notice an additional .deb in the pbuilder directory... maybe I missed it [13:37] that reminds me, isn't pbuiolder supposed to allow non root users to build packages via fakeroot? so why do I always have to sudo it? [13:39] ohh, and is there something wrong with dpkg these days? it seemed to be taking AGES to install the dep packages last night in pbuilder... I noticed a thread about a massive slowdown on debian-dpkg, but it seems to be talking about a newer version that is in lucid [13:39] psusi: Yes. A fix has been uploaded. [13:40] (for lucid) [13:40] ohh... got a bug #? [13:40] or I can go search for it... [13:40] psusi, #537241 [13:46] ohh, so we DID backport the damn fsync patch to dpkg [13:46] yes, because there was a bug with 200 duplicates fixed by it [13:49] really? what is that? seems like the underlying bug is the default mount options for ext4 are dangerous [13:49] ugh, that reinstall of my laptop took ages; now I mean what cjwatson meant with "dpkg performance regression".. [13:49] yea, it's like a 10-50x slow down [13:49] psusi: hm, I can't say without seeing your changes, I'm afraid [13:50] psusi: ah, seems you already discussed that; but please don't change it in gnome-applets [13:51] pitti: why is that? I seem to be missing something about how that file gets from gnome-applets to /usr/polkit-1/actions.. I don't really understand polkit [13:52] on the dpkg thing, last night when I had pbuilder build gnome-applets, it took like 5-10 minutes to install the dep packages, then only like 20 seconds to actually build gnome-applets... ssd = very nice, that dpkg sync patch = very bad [13:52] psusi: there's no magic; it's just a file put into the .deb, which is built by the source [13:53] pitti: I would have thuoght, but it iddn't get updated when I installed the new package, and when I did a dpkg -L, the file was not listed as belonging to the package... so I did a dpkg -x and sure enoguh, the file was not in there [13:53] $ dpkg -S /usr/share/polkit-1/actions/org.gnome.cpufreqselector.policy [13:53] gnome-applets-data: /usr/share/polkit-1/actions/org.gnome.cpufreqselector.policy [13:53] works here [13:54] ahh... ok, I must have missed the -data binary [13:54] ohh, in fact, I know why I did... I was only looking for amd64, it's probably an _all [13:54] psusi: please see debian-dpkg, I'm not going to repeat myself at that kind of length here :) [13:55] anyway, the relevant small part of the patch has been reverted, so there's no need to continue to rant about how dreadful it is [13:55] now you seem to not want to change it in the source because a server might not want that change? but the change only allows INTERACTIVE users access, so for a server the only interactive user ever there shuold be the admin [13:55] psusi: yes, it's Arch: all (as most of the -data packages, otherwise having them wouldn't make sense) [13:56] psusi: you might also want to not have those policies in a business environment; having a separate package (1) is more flexible, and (2) avoids delta to Debian/upstream [13:57] hrm... why is debconf hardly ever used? it seems like this is the sort of thing that debconf should ask you when yuo install or reconfigure it, at least if you use the correct question priority level [14:01] couldn't you set up debconf to have a low priority question to override it, and otherwise default to auth for server and yes for desktop? [14:02] psusi: you'd have to debconfize many packages then, though [14:02] what do you mean? [14:02] and (1) we don't show debconf by default, and (2) most desktops are installed with the desktop CD, where pacakges don't get "installed" in teh dpkg/debconf sense [14:03] psusi: you'd have to apply this to udisks, gnome-applets, gnome-panel (for the time setting), etc. [14:04] I thought 1) the default was to ask only high priority questions at install, medium at manual instal, and low only get asked when you explicitly say so at install or reconfigure, and 2) since it would be a low priority that wouldn't really matter since they would need to explicitly dpkg-reconfigure and ask for low priority questions [14:04] but if most people don't see it at all, why bother? [14:04] ohh, right, because you're trying to bundle up changes to all of them at once... [14:04] I think we should just configure servers and desktops with sane default permissions [14:05] because isn't this kind of the purpose of debconf? so that when I as a user go, why is this thing not set up the way I want? let me see what debconf options I can tweek... [14:06] debconf has never been really entailed by ubuntu, though [14:06] erm, "adopted" [14:06] yea... I've noticed, and find it kind of disappoiinting [14:07] yes it has, just in contexts other than the default desktop [14:08] well I know there have been a few times I've installed daemons on servers and wondered why I get no configuration options even on low priority debconf ;) [14:08] psusi: on servers you'll see a few, for example mysql [14:08] or web apps asking for an admin password or so [14:08] obviously there are going to be exceptions, but we have not in general ripped out debconf questions that are in place in Debian [14:08] yea, I've seen one or two high priority questiosn, but never medium or low [14:09] psusi: right, our default priority is "high"; everything else below that isn't shown by default [14:09] right, but even if I do a dpkg-reconfigure and ask it to show me low, nothing new shows up [14:10] seems nobody bothers writing medium or low priority questions, probably because they assume nobody will ever see them [14:13] cjwatson: rename() resulting in a file size of 0 after a crash problem that the sync patch seems to try to fix seems to have an ext4 mount option to fix: auto_da_alloc [14:35] siretart`: take a look at bug #539555 [14:35] Launchpad bug 539555 in ogmrip "mencoder crashed with SIGSEGV in x264_nal_encode()" [Undecided,New] https://launchpad.net/bugs/539555 [14:35] siretart`: mplayer in lucid isn't compatible with the x264 version in lucid it appears [14:36] mdeslaur: seems I need to backport more if not all of libmpcodecs/ve_x264.c. thanks for notifying me [14:37] mdeslaur: btw, any news on the ffmpeg patches? [14:38] siretart`: nobody assigned additional CVE numbers for the other issues. There were a couple of those CVEs that didn't seem to have patches associated to them in lucid...I was waiting to see what you thought of that [14:39] siretart`: did you get a chance to look at the CVEs that didn't seem to have patches in my email? [14:39] siretart`: ie: issue 16, 21 and 22? [14:40] oh right, the ball was in my camp. sorry, I didn't find time to look up the CVE numbers. [14:40] that time, I rather focused on roundup issue numbers and svn commits [14:40] now I have to match theses to your issues, which is terribly time consuming :( [14:40] siretart`: yeah, thanks for that [14:41] siretart`: actually, I gave you the list with everything already matched up [14:41] siretart`: the quoted part at the bottom of the email has the upstream commits, and the top part in my email has your corresponding patches in lucid [14:41] that list didn't contain svn commits in trunk, did it? [14:41] siretart`: yes! take a look at the quoted part at the bottom [14:42] siretart`: well, it's from upstream trunk, not your repo [14:43] yes, your mail links to mans git-svn import, that's at least straight forward to map [14:43] yes, I'll see that I can tackle this tonight [14:44] so, if we can decide what to do with the 2-3 missing patches, I'll then release updates for hardy-karmic [14:44] great! [14:44] with the existing list of CVE numbers [14:44] siretart`: again, thanks for your excellent work in pulling out all the patches :) [14:52] psusi, from the tests I've done the auto_da_alloc doesn't prevent the 0 length problem, at least with dpkg [14:54] jibel: really? with data=ordered? [14:57] because the man page specifically says: This provides roughly the same level of guarantees as ext3, and avoids the "zero-length" problem that can happen when a system crashes before the delayed allocation blocks are forced to disk. [14:59] psusi, yes with data=ordered [15:00] hrm... sounds like a kernel bug then... [15:00] psusi, it's written in the man page but it doesn't in the case of dpkg. [15:01] there's no way dpkg can rely on kernel options anyway. [15:01] psusi, no necessarily , you'd better talk with dpkg dev who knows dpkg's code path better than me. [15:01] it should be able to rely on the filesystem not being broken though... [15:02] "broken" is, apparently, a matter of opinion. (yes, I know, and I have *my* opinion, but it apparently isn't shared by e.g. POSIX.) [15:02] this was discussed at enormously tedious length last year ... [15:02] psusi, you'll encounter this problem with all fs supporting delayed allocation. [15:03] I agree that enabling auto_da_alloc by default would be sane, if it isn't already [15:03] but if it doesn't entirely fix things for some arcane reason ... wewll [15:03] *well [15:04] then they are all broken... historically many applications have relied on rename() to provide an atomic replace... hell, even Microsoft wrote NTFS to detect this and make sure it worked properly [15:04] I agree that any filesystem that does not treat rename() this way is *at best* wilfully ignoring 40 years of Unix history [15:05] Willfully ignoring history seems to be the order of the day (thus the KibiByte). [15:05] and is only useful for specially written applications [15:05] noting that e.g. shell scripts can't do the fsync thing [15:05] indeed... and the read only mount flag no longer meaning read ONLY [15:07] anyway, I stated my opinion on debian-dpkg. dpkg should do its best to mitigate these issues up to some point that doesn't kill performance too badly, but there's a point where it becomes a kernel configuration problem. [15:07] indeed [15:07] cjwatson, I totally agree [15:07] but if that mount option does not fix it then it seems it should be reported upstream as a kernel bug since it says it should [15:08] geser: ping, DMB meeting [15:08] sure, somebody who has something more resembling a test case should push it upstream :) [15:08] I just want to make it not suck for lucid [15:08] mmm, i like the bootsplash i'm seeing on the laptop right now. the fsck message is rather more slick than it was in karmic [15:10] I guess the unfortunate thing is that relying on rename() being a barrier is itself just a workaround to the filesystem apis lacking means to control barriers [15:11] directhex: yeah I just ran into a fsck the other day, it's quite lovely [15:21] seb128: http://blogs.gnome.org/alexl/2009/09/21/archer-gdb-macros-for-glib/ are these packaged? [15:22] jcastro, haven't updated today, mind... it's a bit less pretty on the nvidia-based desktop [15:22] doko, no [15:23] directhex: it's a tradeoff, do I want pretty boot or vdpau ... :) [15:23] doko, debian don't install those because they "need an experimental gdb version" [15:23] doko, I can change that in the next upload if we want those now [15:23] seb128: that would be nice [15:24] doko, ok, will do after beta1 [15:30] Keybuk: have you had a change to look at bug 527666? [15:30] Launchpad bug 527666 in lvm2 "LVM Not mounting in Lucid" [High,Confirmed] https://launchpad.net/bugs/527666 [15:30] amitk: I don't look at LVM bugs generally [15:31] Keybuk: it contains mountall with --debug info [15:31] so? [15:31] it's unlikely to be a mountall issue [15:31] it's more likely it's in fstab wrong, or LVM is configured wrong [15:31] Keybuk: errm, you asked for it last time it was reported on ubunt-devel [15:32] usually to prove it's not a mountall issue ;) [15:32] Keybuk: the text plymouth theme is awesome! [15:32] Keybuk: heh, ok. But 3-4 people are seeing this bug consistently. I guess I need to find someone who will look at LVM. [15:33] amitk: sadly, without cloning, I'm just not able to look at all of the bugs that I'm a perfect person to look at [15:33] there are too many bugs, and I'm the perfect person to look at too many different things [15:33] and I'm not sure cloning would help, I'd just end up making out with myself :p === jamie is now known as Guest93964 [15:34] highvoltage: I love how many people it's confusing [15:34] narcissist === beuno is now known as beuno-lunch [15:34] plus every subsequent clone would be worse, so after 3 or 4 you'd start creating more bugs I'd guess [15:34] I actually had someone try and debug why the logo filename wasn't being picked up - they hadn't realised it was entirely faked :) [15:35] Keybuk: hah! so they thought it was like an alt="" in an highvoltage: yes ;) [15:35] awesome. [15:35] exacty that in fact [15:36] I do have the VGA 16 theme working now too [15:36] that looks kinda neat [15:37] though I can't decide whether it looks better with Flloyd-Steinberg or without [15:37] * highvoltage racks brain to remember closest colour in aubergine to VGA16 [15:37] to aubergine, even [15:37] highvoltage: just reprogram the VGA to know about aubergine [15:37] ah, ok. [15:37] though it looks quite fetching in MAGENTA http://twitpic.com/18nmqr [15:38] Keybuk: but that won't work on EGA displays will it!? [15:38] (sorry I shouldn't try to be ironic) [15:38] i get a text-only boot :( [15:39] highvoltage: I don't think they've ever made a 386 with EGA [15:39] Keybuk: I've seen some, but I'm not sure whether they were sold like that [15:39] for a start, I haven't seen any monitor with an old EGA connector in decades [15:41] yes they died out quite quickly. [15:41] well VGA apparently came out in apr 1987 so some really old 386 had them but probably not too many [15:42] Keybuk: maybe you can try with purple? #800080 [15:42] i.e. 128,0,128 [15:43] kirkland: bug 527666 [15:43] Launchpad bug 527666 in lvm2 "LVM Not mounting in Lucid" [High,Confirmed] https://launchpad.net/bugs/527666 [15:43] tseliot: for the vga16 stuff, I just reprogram the palette now [15:43] so it's ubuntu aubergine [15:43] bdrung_: hi. is Eclipse 3.5.2 in the plan for inclusion in lucid? (noticed the merge in git) [15:43] xhaker: yes [15:44] Keybuk: ah, nice. Does the logo look ok now? [15:44] xhaker: we try to release 3.5.2-1 to debian really soon and sync it then [15:44] tseliot: mostly, still fiddling with it [15:44] tseliot: haven't released it yet because there are bugs with text mode I want to fix first ;) [15:45] anyone know how to modify a symbols file to work on multiple architectures? i backported webkit and it builds fine on amd64 but fails on i386 due to missing symbols, can i just add the i386 symbols (i would think it would then complain on amd64)? [15:45] Keybuk: good idea ;) [15:45] ccheney: depends :-) [15:46] you can put architecture tags in the symbols files if that's appropriate. see man dpkg-gensymbols [15:48] cjwatson: thanks, guess i need to look at each arch to see what it complains about to determine what to add to its specific symbol file [15:51] ccheney: for some libs it might be worth first checking if it really only exports symbols that are supposed to be exported [15:52] bdrung_: thanks [15:52] siretart`: ok [15:56] pitti, hi [15:56] rickspencer3, hi [15:57] hi tkamppeter [16:02] hi tkamppeter === seb128_ is now known as seb128 [16:07] directhex: do you know anything about #536925 ? [16:08] pitti, I have seen you have worked on SRUs (moving verified packages to -updates), did you forget bug 293832? [16:08] Launchpad bug 293832 in poppler "printer prints page at wrong position, page cut" [High,Fix committed] https://launchpad.net/bugs/293832 [16:09] bug 536925 ? [16:09] Launchpad bug 536925 in mono "docky gmail checker is unable to connect to gnome-keyring" [Undecided,Confirmed] https://launchpad.net/bugs/536925 [16:10] tseliot, i don't know anything about it. i could take a look. the docky bug report seems entirely unhelpful [16:11] directhex: basically it doesn't seem to be able to access gnome-keyring. Is there anything else that you need to debug it? [16:16] tseliot, running it from a console might help give some diagnostic output, but as i said, the developers seem actively unhelpful. "broken" as a term should be banned from launchpad [16:18] tseliot, i can believe that there's an incompatible change to gnome-keyring, since adobe air apps are broken, but i see no evidence of any commits to g-k-s's svn repo for about a year [16:20] tkamppeter: hm, there is no poppler upload in the queue [16:21] directhex: the console output is here: https://bugs.launchpad.net/docky/+bug/456166/comments/12 [16:21] Launchpad bug 456166 in docky "gmail applet doesn't work" [Low,Fix released] [16:21] directhex: are you sure that libgnome-keyring1.0-cil hasn't changed recently? [16:22] recently = since karmic [16:22] not substantively [16:22] tseliot, only a build fix. [16:23] ok [16:23] http://changelogs.ubuntu.com/changelogs/pool/main/g/gnome-keyring-sharp/gnome-keyring-sharp_1.0.0-2/changelog [16:25]