[00:15] cjwatson: cool :) [00:15] yipee i managed to get OOo to properly build under intrepid now [01:09] * milli applauds calc [01:54] slangasek: I'm about to upload the openldap merge from debian - considering that the package has been renamed from openldap2.3 to openldap, is there anything to special to do in LP ? [01:54] mathiaz: hum, the QA folks might have a better idea in that regard than I do; I think they dealt with the similar case of the linux package renames [01:55] mathiaz: I imagine that all the bugs with open intrepid/openldap2.3 tasks should also have tasks opened for openldap/intrepid, but the doing is tedious without some script help :) [01:55] slangasek: I was planning to move all bugs related to openldap2.X package to openldap [01:55] right, then that's the only special thing I can think of [01:55] slangasek: well - there aren't so many of them [01:55] ok [01:55] slangasek: I was more thinking about soyuz [01:56] nah, we just need to be sure to remove the package as obsolete after openldap has gone through source NEW [01:56] feel free to file a bug to that effect and subscribe ubuntu-archive [02:06] how do you properly branch from bzr.d.o to launchpad? [02:07] do i just go into a bzr.d.o checkout and push it to lp? [02:10] calc: sounds right to me... [02:11] ok thanks [02:11] i get this error: [02:11] bzr: ERROR: Transport operation not possible: http does not support mkdir() [02:12] should i be doing something special other than "bzr push lp:~openoffice-pkgs/openoffice/3.0-intrepid" [02:13] hmm, is your launchpad user ID configured? [02:13] 'bzr launchpad-login' [02:13] (I don't know if that makes a difference in how lp: uris are parsed, but it's worth a try) [02:14] it seems that using the bzr+ssh bit works but not sure if i have launchpad-login setup right [02:14] my local username and lp match though [02:34] Lrrr: debian/changelog entries would be appreciated [02:35] Lrrr: also would prefer newline-indent after colon as a general rule, rather than packing onto one line [02:37] Lrrr: the ".It Fl o Fl Fl output-directory" bit in the man page is wrong formatting - see germinate.1 for examples of how to do that properly (search for .It Xo) [02:38] Lrrr: expect I'd be happy to merge after those fixes [02:44] cjwatson: noted, I'll fix that tomorrow. [03:26] hmm, anyone know of bug #'s for USB HID devices not working in initramfs [03:26] my macbook internal keyboard is USB, and it's annoying that it doesn't work in initramfs [03:26] i.e. where my encryption passphrase needs to be entered [03:27] Oh, awkward. [03:27] after udev starts post-rootmount it works, and also one of 3 boots work [03:27] I think it must be a race condition where upon activating the USB bus the keyboard doesn't connect for a second or two [03:27] just enough to miss the point that udevsettle is done during initramfs [03:27] *considers hacking some sleep calls* [03:28] is there a way to inject a premount command rather than dropping to a prompt? break=premount does me no good if I can't actually type anything :D [03:29] Hack /usr/share/initramfs-tools/scripts/init-premount and update-initramfs -u [03:29] well.... that actually requires a livecd so I can have a working keyboard AND a decrypted / :D [03:30] oh well, weekend project [03:31] So, a prompt is shown, but for some reason the keyboard doesn’t become available because it’s discovered after udevsettle? That sounds a bit strange. You’d still expect udev to load the module and the keyboard to start working. [03:31] Are the necessary modules installed to the initramfs for sure? [03:31] right, the symptoms are exactly as you state [03:32] except one of every 3 or so boots, it actually works [03:32] Huh. [03:32] something racy seems t be taking place [03:32] whether that's because of initramfs, or by luck legacy peripheral emulation is still active by apple BIOS emulator... [03:33] the HID modules are definitely in initramfs [04:04] jdong: I guess the best way to track that one down is to boot into the initramfs with debugging enabled. [04:38] BenC: hey [04:40] I guess Alpha 2 isn't out yet [04:41] * bluefoxicy found some flaws with the current implementation of compcache, but isn't sure the exact impact; thinks it's still overall positive [04:42] What kind of flaws? [04:42] Other than that the newest version (the one that is in the Ubuntu kernel) seems to like to crash on my box. :-) [04:42] ion_: Well I haven't been in ANY code for a while, much less kernel code; but at a glance I don't like the memory eviction policy, mainly. [04:42] 0.3 didn’t. [04:44] lemme get the current code [04:44] bluefoxicy: hey [04:44] Hi BenC :) [04:44] (isn't this particular issue assigned to you?) [04:45] http://code.google.com/p/compcache/source/browse/trunk/compcache.c is what I'm looking at. [04:46] Lines 185-193 seem to handle freeing a page... which basically entails, "If the kernel just wrote a NEW memory page to that spot in the swap device, then the old one was probably gotten rid of ages ago, so we can safely free it from memory now" [04:47] so, let's say you kill -9 a process that uses, say, 1000 pages (4MB) of the compcache device for swap? Those pages will remain in memory, compressed, until something else swaps out overtop of them [04:48] It makes sense for disk based swap devices: when you free a page you just note it's no longer used in kernel memory. The disk doesn't know or need to know about this. Compressed cache does need to know, but doesn't. [04:50] I'm GUESSING the impact is going to be that long term usage will cause a chunk of memory to get tied up needlessly; but that it will still be an improvement over not having it. There's a "worst case" that just simply fills up the compcache device and doesn't use it ever again; I think this WILL occur if the compcache device doesn't have the highest priority (i.e. if you favor filling up a disk-based swap device first, and e [04:50] nd up spilling over into compcache) [04:52] Doesn't the very nature or compcache encourage using it as highest-priority swap? "disk" i/o is likely to be slower, even when the "disk" is in fact SDRAM. [04:52] persia: yes it does. [04:53] persia: the very nature of compcache actually encourages it to be an intermediary cache though, i.e. CPU registers > L1 > L2 > L3+ > RAM > compcache > disk swap [04:54] however, it's lumped in as a disk swap; you'll fill up compcache and then start putting further pages on disk, instead of pushing them out of compcache under the observation that they really haven't been used in a long time (LRU policy on compcache would be more optimal) [04:54] Hmm. Makes sense. Might be a slot for VRAM swap in there at some point, but that's not heavily used (and compiz discourages it). [04:55] As far as I'm aware, any form of graphics acceleration discourages it (at least the naieve implementation I've seen on the gentoo wiki) [04:55] I've actually got a small list that I sent to Nitin; but the eviction issue seems important to me just because you could seriously bone yourself by adding compcache as lowest priority swap [04:56] other issues included it not being an intermediary cache; compressing one page at a time (the sweet spot, based on tests I did years ago, was groups of between 4 and 8 pages); and not compressing page cache (which effectively "swaps" against the on-disk copy of the data) [04:58] The initramfs stuff for compcache uses -p 100, as well as the compcache-setup package waiting in REVU. I’m not sure users are going to manually swapon it, forgetting to use a high priority. That doesn’t mean the issue is not there, of course. [04:58] RAOF: I thought there were some better implementations sorted, but it does require that you've lots more VRAM than you need, and most graphics accelleration wants local textures. [04:58] am i crazy, or is this arizona package manager vuln wrong on the details? [04:59] ion_: nods. With it being the first device used, it's a gain over not having it; however, do note that when you fill it up and then "empty" it, it's still holding a chunk of RAM as used, so you'll start swapping to it earlier than you need to. [04:59] Yeah [04:59] IN THEORY this is PROBABLY not an issue, since that particular operation is cheap. [05:00] aside from effectively decreasing the amount of physical ram available to things like page cache, which aren't swapped out [05:03] Question: does HTTPS really matter for the official -security repo? [05:04] freeflying, Hi! [05:04] pwnguin: you can MiM stuff and replace packages, but they're signed. [05:04] foka: hi [05:04] so I don't really think so :P [05:04] freeflying, I think I'm a REVU now. So, I can already upload packages directly? What's the procedure? [05:04] thats what i was thinking; you dont need an https cert when the metadata and packages are gpg signed themselves by the repo [05:05] foka: #ubuntu-motu [05:06] unless you think https itself is safe but apt-get or gpg is not... [05:06] freeflying, Go there? :-) [05:06] foka: yes [05:06] granted, the author does point out that apt will happily fill your filesystem if the other end just sends you /dev/random [05:09] well, at least the paper is intelligent [05:43] does ubuntu releases point releases in a fixed schedule, or when updates get big enough (or the min of those)? [05:44] point releases for LTS releases are scheduled in advance [05:45] for 8.04, they're planned at 6-month intervals [05:45] I thought it was strage that https://wiki.ubuntu.com/HardyReleaseSchedule ends at the just release .1 [05:46] so the next is due Jan09, right? [05:49] approximately, yes [05:49] it hasn't been scheduled precisely yet [05:50] fair enough, thanks for the info [05:53] yesterday's Intrepid Alpha 2 release is also approximate [05:54] was it released? [05:54] not as of a couple hours ago <_<; [05:54] or if it was I sure as hell can't find it [05:58] * persia comments that the definition of "yesterday" is geographically variable [05:59] Someone in UTC +10 and someone in UTC -8 might have very different views of when Thursday happens. [06:00] it's not released yet because we haven't been getting ISO tests in [06:00] so it's slipping a day; email to u-d-a will be sent soon [06:01] * bluefoxicy somehow tempted to use compcache for a file system, since it doesn't have any code that prevents it from being used as a plain old block device. [06:02] persia: where is sabdfl? [06:03] and is it still thursday there :) [06:13] bluefoxicy: Unfortunately, it appears that shoes have been changed since I last emplaced a microdot transmitter: I can't answer that with any confidence. [06:13] lol [06:15] i guess X is still having issues after i installed nvidia-glx-173 and now i cant get a X session after using nvidia-config [06:22] nevermind its fixed so far [06:35] good morning === MenschenFleisch is now known as soylentgrun === soylentgrun is now known as SoylentGrun [07:10] hi ara [07:10] hey dholbach [07:34] Good morning === thekorn_ is now known as thekorn [09:21] pitti: ffox 3.0.1 / xul 1.9.0.1 require your approval ;) (hardy-proposed) [09:21] noted [09:22] security-updates through -proposed, yay! [09:28] thekorn: hm, p-lp-bugs broken again, on BugReport.__nickname parsing; known already? [09:29] pitti: yup, working on it, bug 247498 [09:29] Launchpad bug 247498 in python-launchpad-bugs "Recent rollout of edge.launchpad.net broke py-lp-bugs" [High,In progress] https://launchpad.net/bugs/247498 [09:29] thekorn: great, thanks [09:30] Who broke my fglrx ? :) [09:30] cjwatson, thekorn: btw, any idea about the difference of the main and intrepid.merge branches? someone flipped the default branch to intrepid.merge on drescher [09:30] I had to spend half an hour and 3 hard reboot to get a working X server again :) [09:30] stgraber: hardy or intrepid? [09:30] intrepid [09:30] *phew* [09:31] don't worry, Hardy works fine (including suspend to ram) :) [09:31] thekorn: oh, nice, that looks like test suite output [09:32] thekorn: ok, then I'll just wait with sync processing until it is fixed [09:32] pitti: yes, py-lp-bugs now has some unittests [09:35] hi ppl, while it's fine that you removed edgy from mirrors (hmm, what about announcement?), there should be a way how to download update-manager-core for edgy, so people can upgrade long forgotten servers. [09:36] ondrej: old-releases.ubuntu.com [09:36] ondrej: edgy and others are still on old-releases.ubuntu.com [09:37] ondrej: also, why do you need u-m for edgy? you certainly don't want to upgrade a dapper to edgy, you want to upgrade it to hardy... [09:37] pitti: I have server on edgy and it's stuck because I cannot download d-r-u [09:37] d-r-u? [09:38] do-release-upgrade [09:38] ie. update-manager-core [09:38] hm, weird; I had always thought that update-manager would download the tarball for the target release [09:39] it propably would, but since it was minimal install I don't have update-manager{,-core} installed at all [09:40] ondrej: http://old-releases.ubuntu.com/ubuntu/pool/main/u/update-manager/ (I don't think -core was split out back then) [09:41] persia: sure, thanks... I can handle it from now... I was just trying to explain problem in more detail (and I will update FeistyUpgrades wiki page to mention that) [09:41] ondrej: Thanks for updating the documentation [09:46] persia: just FYI: update-manager-core is available for edgy [09:49] Odd. I wonder why it wasn't in the same pool directory. Maybe something special about that package. === dholbach_ is now known as dholbach [09:54] persia: I think it wasn't part of the same source back then... anyway this upgrade is non-trivial, you have to change old-releases to archive in sources.lists in the middle of do-release-upgrade script. [10:02] ok, done, upgraded to feisty, thanks to all [10:03] wonderful [10:03] oh, gone already [10:10] Can any archive admin please clear xml-commons-external from new queue? An update to batik is dependent on it. [10:12] I'll get to NEW processing in a bit [10:13] pitti: thanks. :-) [10:14] why does compiz suddenly think it would be a good idea to map my mouse wheel to switching workspaces? [10:20] mdz: Compiz does it on Hardy too, when you have the mouse cursor on an empty area of the desktop and use the mouse wheel. [10:22] tseliot: this was on top of firefox [10:22] but I can't seem to reproduce it now [10:22] it was very surprising though [10:23] mdz, sure you didn't hover the workspace switcher? [10:23] thorwil: yes [10:23] hovering over the switcher doesn't seem to do that when I try it [10:23] ^ that WFM in metacity [10:23] ahh, the keypad state on my keyboard was activated [10:24] (compiz doesn't want to start on -intel apparently ATM) [10:24] s/start/be useful/? [10:24] mdz, maybe some modifier-key -weel combo? [10:25] well, whatever it thinks; I just get metacity [10:25] ah; I thought you meant the bug that I'm seeing here, which is that compiz doesn't fall back to metacity, I just get a blank screen in intrepid [10:25] (installer testing) [10:26] does anyone know why so many linux-{,headers,image,restricted-modules}-$FLAVOR metapacakges are NBS? [10:26] linux-meta only builds a small subset of the former hardy set [10:26] because the kernel team has split everything out of the main package [10:26] is that on purpose? [10:26] tseliot: just wondering, there is currently no fglrx driver working with 7.4 right ? [10:27] it's on purpose, though I still wonder about the wisdom of it seeing how none of those other packages have gotten done yet [10:27] stgraber: no, the xserver broke the ABI compatibility [10:27] slangasek: ATM I'm not sure whether I should kill those NBS or not; I left them last week, and I'm inclined to leave them today, too [10:27] pitti: yes, I was about to say I think they should be left where they are as a pointed reminder [10:28] and perhaps we should schedule some time next week to sync up with the kernel team about exactly whose responsibility it is to recover those other packages, so we know who to bug [10:28] tseliot: ok, so that'll be radeonhd and hoping ATI's next driver will include Xorg 7.4 support :) [10:29] stgraber: you can try something like this but success is not guaranteed http://www.linuxinsight.com/running-nvidia-display-drivers-with-xorg-7.3.html [10:29] (to ignore the ABI, I mean) [10:29] slangasek, pitti: At least amitk and myself will be taking care of getting the virtual and lpia builds going. I imagine we'll have our own meta packages as well. [10:29] Next week, that is. [10:29] ah, next week, that's good to know [10:29] slangasek: let's, yes [10:30] whoops, I forgot to actually cron the NBS script, doing [10:30] oh, interesting option I'll give it a try and see how broken it'll be :) [10:30] thanks tseliot === jscinoz_ is now known as jscinoz [10:33] soren: virt-viewer wants to pull xen-3.1 into main, but main already has xen-3.2; I hope that can be fixed? [10:38] tjaalton, bryce: xserver-xorg-video-via source is in main, binary is in universe, -all depends on it; shall I promote the binary, or does -all need to be fixed? [10:38] thorwil: my keyboard is a kinesis and has a keypad lock (the numeric pad shares keys with the alphabetic keys) [10:38] thorwil: when that is activated, the mouse wheel switches workspaces [10:39] pitti: nvidia-glx-173 works fine for me, modulo bug 247523 and bug 247527 [10:39] Launchpad bug 247523 in dkms "Fails silently if kernel headers are not available" [Undecided,New] https://launchpad.net/bugs/247523 [10:39] Launchpad bug 247527 in nvidia-graphics-drivers-173 "Kernel headers dependency could be more specific" [Undecided,New] https://launchpad.net/bugs/247527 [10:40] pitti: Certainly. [10:45] pitti: I switched it to intrepid.merge because at the time that was what worked [10:46] Riddelll, nixternal: FYI, I removed the python-kde4 source, because it seems to be superseded by kde4bindings; however, python-kde4 is still in Debian; what's the plan for this? [10:46] pitti,slangasek: agreed, I've been avoiding removing those NBS packages too [10:46] pitti: py-lp-bugs should be fixed now [10:46] thekorn: yay you [10:49] cjwatson: ok, I updated the main branch for this ^ and flipped back, since main works ATM (for syncbugbot anyway) [10:52] bryce, tjaalton: also, xserver-xorg-video-vga wants to go to universe; are we exclusively using -vesa as a fallback now? i. e. is this deliberate? [10:52] * pitti tries to reduce the insane size of component-mismatches a bit [10:53] pitti: ok, cool [10:55] pitti: -all should not depend on it anymore [10:55] and vga is dead [10:55] it's not included in X7.4 katamari [10:55] tjaalton: ok, so I demote vga, and wait with the -via demotion until -all gets fixed? [10:56] pitti: actually, you could just remove via, since it's deprecated upstream, and openchrome is the default anyway [10:56] there should be a bug about it too.. [10:56] tjaalton: I just don't want to break installability of -all at this point (alpha 2 tomorrow) [10:56] via doesn't build against 1.5 [10:56] unless you want to fix -all right now [10:57] it doesn't break it [10:57] openchrome | via [10:57] ah :) [10:57] :) [10:57] it will be removed completely in the next upload, but that shouldn't be necessary for alpha2 [10:57] tjaalton: it's still in Debian, though; will someone file a removal bug there as well, or shoall I blacklist it? [10:58] pitti: kdesudo-kde4 is missing from the kubuntu desktop images because it's a recommends and has yet to be promoted to main [10:58] pitti: could we do a quick main promotion of it? [10:58] pitti: yes, they don't have the new stuff available yet [10:58] (breaks ubiquity rather badly) [10:58] slangasek: yep, will do right now [10:58] pitti: so it'll get removed when 1.5 hits unstable [10:59] tjaalton: ok, removed; thanks [10:59] slangasek: kdesudo is already in main, so I guess the package should eventually just be renamed [11:00] perhaps [11:00] hrm, but kdesudo-kde4 installs its binary under /usr/lib/kde4/bin, what good is that supposed to do? :/ [11:01] and kdesudo is still KDE 3 AFAICS [11:01] yes [11:01] anyway, kdesudo-kde4 is the one that's seeded, so I guess we should at least get that fixed for now [11:01] slangasek: kdesudo-kde4 hasn't been uploaded in intrepid yet, so I guess that simply needs some work [11:02] pitti: well, I wonder how burying the binary in /usr/lib was ever supposed to work... it won't work for ubiquity, AFAICS [11:02] is there an equivalent in some other package? a lot of the -kde4 packages got replaced [11:03] Tonio_: do you have some insight wrt. kdesudo? [11:03] I think the equivalent would be kdesudo, but that's the KDE3 version [11:05] how did it work in alpha1? or didn't that have kde CDs? [11:06] slangasek: so, kdesudo-kde4 is derived from kdesudo (one upload) with porting to kde4; I have no problem to quickly promote it at this point, but I have doubts that it will fix the problem? [11:06] we didn't have desktop CDs [11:06] pitti: correct, that alone won't fix the problem [11:06] we need a ubiquity upload anyway; I'm happy to do a quick path tweak [11:06] though I won't be able to test it [11:07] cjwatson: /usr/lib/kde4/bin, then [11:08] promoted [11:11] lool, StevenK: hm, why does hildon-control-panel{,-l10n} want to go back to universe? [11:12] slangasek: ah, and rightfully kdesudo wants to go to universe; demoting that [11:13] StevenK: and libhildonhelp, too [11:14] in fact, half of the mobile stack is there [11:16] pitti: mobile has moved to separate seeds which LP isn't yet taking into account, which probably influences that [11:17] oh, I see [11:17] cjwatson: so component-mismatches is very misleading ATM then [11:17] I guess some of the demotions I just did were wrong them (some were correct, though) [11:17] yes, sorry :-/ [11:17] s/them/then/ [11:17] well, eventually they will pop back [11:17] just be careful about mobile things [11:17] Hmm [11:17] yes, I didn't demote the obvious ones [11:17] dont we build mobile with universe enabled anyway atm ? [11:18] * ogra thought we did [11:18] ogra: Ultimately we'd like to change this [11:18] ogra: the target is for that stuff to move to main [11:18] right, but for alpha2 it should be ok :) [11:18] I'll sort out a bug report about this in a bit - I'm knee-deep in ubiquity at the moment [11:18] pitti: (StevenK is in holidays this week BTW° [11:18] * lool launches a rope to pull cjwatson out [11:19] asac, could you take a look at https://bugs.launchpad.net/cmpc/+bug/247478 [11:19] Launchpad bug 247478 in cmpc "Classmate PC fails to connect a wired LAN." [Undecided,New] [11:19] i'm not sure what i should tell them === rraphink is now known as raphink [11:20] what they do there (playing with roaming mode on a wired connection) seems very weird [11:23] ogra: err, if he turns of "roaming mode", then its not network manager anymore [11:23] turns off [11:31] gar, crash on switch to vt [11:36] ogra: the bug is quite hard to read. is that china? [11:37] yep [11:39] ogra: what are they trying to achieve? static IP configuration? [11:40] ogra: i dont understand why they "check roaming off" in step 2. and do the same in step 3. again :/ [11:40] i think either 2 or 3 should be "check roaming on" [11:40] hmm [11:42] now that i read it again i dont even understand point 1 [11:42] yeah ... what is a wired AP? [11:42] a hub/router? [11:42] 1. Keep roaming mode enabled and plug in a network cable connected to an AP. [11:42] heh [11:42] they dont say *wired* [11:43] ogra: does "click.Click unlock" mean: double click? [11:43] maybe ask them for clarification? [11:44] asac, no, the dot ends the forst sentence :) [11:44] *first [11:44] ah ;) [11:44] ogra: i think they should make more steps out of it: [11:44] could you comment ? [11:45] so they see that its valuable to use LP :) [11:45] istead of sending spreadsheets around :) [11:45] ogra: valuable like: "i mark your bug as invalid" ;) [11:45] no, ask for more or vclearer info [11:51] ogra: whats the name of the gnome network admin package again? [11:53] network-admin iirc [11:53] ogra: usb-imagewriter> why not add an option for an alternative output file? -o /tmp/test.img [11:53] ogra: hardcoding that upstream isn't nice either [11:53] ogra: also, please don't use shell=True, just split the args into components (trivial here); better for weird file names [11:55] pitti, ergh, that was fixed upstrem indeed it picks the device from the pulldown menu [11:55] ogra: I have to reject it anyway, I'll mail you [11:55] pitti, plan is to make dd go away completely [11:55] ok [11:57] (sent) [11:58] pitti, there is only one actual application file in there and that has a GPL header ... i thought that suffices [11:58] * ogra adds a general license ... [11:58] ogra: thanks [11:59] pitti, and i suspect debian wouldnt be happy about the branding ;) [11:59] http://people.ubuntu.com/~ogra/ImageWriter/main.png [12:00] ogra: That's loaded at runtime, no? A sufficiently imaginative debian/rules ought be able to allocate the right branding :) [12:00] ogra: nice :) [12:06] pitti, dont wait for it ... just had a discussion with persia, we'll look at it next week at the sprint and rip out dd as well [12:06] ogra: what's the replacement for dd? [12:06] python magic? [12:07] no idea, persia has one we didnt discuss yet (next week) .... but i would assume python, yes [12:07] <_MMA_> ogra: That branding there actually needs a little help. :P I'll help if you want or tap kwwii. Unless he did that one. Then I'll have to have a word with him. ;) [12:07] it should be interesting whether a read()-write() Python loop is significantly slower than dd [12:07] so, is it just me, or is klibc's chroot.c on crack? [12:07] it does chroot() then execve(), rather than chroot() chdir() execve() [12:08] pitti, speed doesnt really matter ... i took dd because i know for sure it DTRT and isnt buggy :) [12:08] unlike every other chroot in existence [12:08] saftey first [12:08] cjwatson: the chroot(2) manpage claims the same (chdir necessary) [12:08] ogra: well, for copying 700 MB speed should matter a bit... [12:09] yay, NEW empty [12:09] right, this is why the crackful PATH=/root/stuff was added to casper, I think [12:09] I have a solution for dd? [12:10] _MMA_, i wrote that app (including the branding) in less than 8h its only a first shot and was more a fingertraining weekend project .... https://code.launchpad.net/usb-imagewriter has the xcf in the source feel free to do what you like with it :) [12:10] i'll happily merge branches and patches [12:11] pitti, really, doe it mater if it takes 4 or 5 mins ? its slow in any case :) [12:11] *does [12:11] ogra: no, but it would if it takes 4 vs. 20, that's why I'm curious [12:11] ah, yeah, indeed [12:12] of course, we could just rip out klibc chroot and use busybox for that instead [12:12] since busybox also correctly uses execvp rather than execve [12:13] pitti: still writing the code.... should be done this WE... [12:13] <_MMA_> ogra: Sure. Ill have a go at it.:) Mind if I mention it on the art list? [12:13] i not at all :) [12:13] <_MMA_> Cool [12:14] pitti: I don't know te whole reasoning behind separating pykde4 from the kde4bindings in the past [12:14] Tonio_: so is it the right thing to use kdesudo-kde4 for alpha-2? [12:14] _MMA_, my personal plan was to have fun with it, produce something minimally usable and then throw it at the community ;) [12:14] Tonio_: do you know why pykde4 was separated from kdebindings? [12:14] (it's still in Debian, apparently) [12:15] it could have been due to the rest of the bindings not being ready in the past [12:16] <_MMA_> ogra: Cool. Maybe Ill ask for one with Debian branding also. Maybe it will make it easier to go to them as well. [12:16] feel free ... we should really make more use of the art team for non desktop art [12:17] (that struck me yesterday when we were discussing presentations in the mobile meeting) [12:18] there is so much enthusiasm and so many other areas than the desktop where good artwrok makes sense ... but i only see theme discussions on the artwork ML [12:32] nixternal: no idea concerning pykde4.... I still didn't do much on the kde4 side... [12:32] pitti: yeah we can make use of it right now, except it has a few bugs fixed in the kde3 version, that I have to fix in the kde4 one [12:32] Tonio_: ok, thanks [12:32] pitti: but as kdesu in kde4 is built without sudo support, we have to use kdesudo in any case [12:37] Tonio_: is it going to be moved to a more sensible filesystem location? [12:41] cjwatson: yeah kde4 will go in /usr afaik [12:42] cjwatson: Riddelll would know more on that point, but moving to /usr was decided uring the UDS [12:42] s/uring/during === ogra_ is now known as ogra [12:44] hello === asac_ is now known as asac === _MMA1 is now known as _MMA_ [13:07] is the startup splash graphics stored in the initrd on the livecd? [13:07] Karnaugh: Yes they are. [13:12] TheMuso: I see usplash has something to do with it, wandering through the docs for that atm [13:12] Karnaugh: Thats correct. [13:24] cool that seems quite trival [13:24] *trivial === hefe_bia_ is now known as hefe_bia [13:25] pitti, I think syncs from bug 247481 and bug 247482 were not processed. Packages left incoming this morning and probably didn't reach mirrors in time. [13:25] Launchpad bug 247481 in helpviewer.app "Please sync helpviewer.app 0.3-6 (universe) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/247481 [13:25] Launchpad bug 247482 in lusernet.app "Please sync lusernet.app 0.4.2-4 (universe) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/247482 [13:26] can we make syncbugbot not close bugs when that happens? === ember_ is now known as ember [13:41] pitti: so did you promote kdesudo-kde4 in the end? I just made ubiquity depend on it ... [13:41] (I don't seem to have much option) [13:47] cjwatson, seeing all this effort above, do you actually try to get a desktop CD ready for alpha2 ? (i refrained from adding the compcache stuff to casper because we seemed to have none) [14:00] ogra: Steve seems to want to try, anyway [14:00] and I think it would be good if we could === LucidFox is now known as TSLRPFox [14:10] pitti, kirkland: how much functionality is going away from ecryptfs-utils when removing the two build-deps? [14:11] doko: hey, we were just talking about this with zul on #ubuntu-server [14:11] zul: -> move over here [14:12] doko: libltspi is a library with support for TPM chips on modern motherboards [14:12] at least we should document that in the MIR [14:12] doko: pitti: how about I do that, and ping back here once it's in writing? [14:13] doko: pitti: on the other hand, shall I just file the MIR for the other build deps, and only remove the deps if there's a problem moving them to Main? [14:14] yes, at least libltspi doesn't sound like a problem [14:15] doko: opencryptoki contains support for some cryptographic accelerator hardware [14:15] doko: mostly IBM stuff, I think [14:15] doko: might be nice to have on the server [14:16] doko: I've already written the MIR for libltspi: https://wiki.ubuntu.com/MainInclusionReportTrousers [14:16] doko: no bug filed yet [14:16] doko: see the top of that... we need library out of trousers, but not necessarily the daemons and such (trousers) [14:17] hmm, I don't see a b-d on trousers ..., but on libopencryptoki-dev [14:18] trousers provides libltspi-dev [14:18] isn't this chip in the thinkpad notebooks as well? [14:18] doko: the TPM (libltspi, trousers) -- yes. opencryptoki stuff -- no. [14:19] doko: although we don't have userspace to exploit it, ecryptfs could use a TPM to cryptographically lock a mounted filesystem to a TPM chip (ie, a particular motherboard/machine) [14:19] doko: or using a keyring, a set of machines [14:21] cjwatson: I did promote kdesudo-kde4, yes [14:21] doko: also, it looks to me like opencryptoki would also mean an MIR for freetype1 [14:22] DktrKranz: sorry, reopened [14:22] pitti: ok, cool, thanks [14:22] cjwatson: kdesudo could be demoted, so that seemed like an adequate deal :) [14:23]