[00:04] fta, asac: is is possible to build thunderbird with FORTIFY now? [00:17] kees: most likely lacks the patch [00:18] kees: is this blocking something? [00:19] asac: nope, just noticed it is all. [00:19] asac: should I re-open the bug? [00:19] kees: i am too tired right now, but maybe we should add a tracker bug for all mozilla apps :) [00:20] asac: okay, I'll ping you about it tomorrow. thanks! [00:47] Wooooo, MIPS based laptop [00:48] * NCommander figured out how to order one and port Ubuntu to it [00:54] http://mobile.slashdot.org/article.pl?sid=08/09/04/2232225 [01:00] kees, poke [01:03] NCommander: yo [01:03] kees, what options do you want me to embed into GCC [01:04] I want to deprieate harden-wrapper on amd64 if possible by simply having GCC have those options ON by default [01:04] *hardening [01:04] I can add any flag that GCC recongizes as well as FORTIFY_SOURCE [01:06] NCommander: there's already all in there: https://wiki.ubuntu.com/CompilerFlags [01:06] HLFS recommends: -fstack-protector -fstack-protector-all fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,-z,combreloc [01:06] -z now by default is a bad idea. [01:06] With the behavior turning off on -D_KERNEL_ [01:06] Ok [01:06] haven't seen combreloc before [01:07] (fortify source will also be set on by default) [01:07] see that wiki page [01:07] Yes my lord and master [01:08] * NCommander will have patchs for doko that will make him scream [01:08] NCommander: I feel like you're not hearing me: I have already patched gcc for all those options. [01:09] I thought hardening-wrapper did it [01:09] Oh [01:09] Sweet :-) [01:09] That just means I need to add the PIE flags to the spec file, and we're in business [01:10] I have implemented these options in about 3 ways now. :) [01:10] hardening-wrapper _also_ does it. [01:10] I guess some confusion on my end is understandable [01:10] I didn't know that [01:10] note that there isn't technically a "spec" file. [01:10] spec strings [01:10] Fine :-P [01:10] check out my existing patches in gcc-4.3 for some hints on the insanity needed. :) [01:11] You have to modify the linux64.h if you just want it 64-bit specific. Linux.h affects both i386 and amd64, right [01:11] ^? [01:12] NCommander: sounds right, but I don't know for sure. this is a doko area. :) [01:13] * NCommander turns on the doko-light [01:14] he's going to eventually read this backlog, and a high pitched scream is going to deafen us all [02:26] pitti: ping [02:46] pitti: anyway, I've got the debdiff for g-c-c at http://bryceharrington.org/ubuntu/gnome-control-center_2.23.90-0ubuntu5.debdiff [02:46] pitti: anyway, I've got the debdiff for g-c-c at http://bryceharrington.org/ubuntu/gnome-control-center_2.23.90-0ubuntu5.debdiff [02:47] echo... echo... echo... [02:47] ion_: sorry, xchat is not displaying anything [02:48] pitti: I'll plan on uploading that post-alpha-5 unless you or seb128 wish to see it included for alpha-5 (in which case feel free to upload it yourselves) [03:55] ScottK, you floating around? [04:38] Riddell, you around? [04:41] Hobbsee, you around? [04:43] NCommander: Here now. [04:56] Hey [04:58] The wifi toggle key on my laptop doesn't work (i get the setkeycode message on dmesg), how do i go about indicating the right keycode to somehow get it fixed in the next release? [04:58] Also i'm not sure how it works on other laptops but i guess it should toggle NetworkManager.getWirelessEnabled via DBUS [05:00] GomoX, this is for Ubuntu development, not Ubuntu debugging, please try #ubuntu [05:00] (or support) [05:01] Well technically this should be interesting to the corresponding developer [05:01] I can get it working with a script, the question is how does one go about telling the corresponding dev about it [05:03] GomoX, file a bug on Launchpad [05:32] is there an alpha 5 install iso yet? [05:33] Not yet going by cdimage.ubuntu.com [05:40] so its been delayed then? [05:50] * NCommander waits on the passage of time. [05:58] NCommander: contentless ping. [05:59] Hobbsee, interesting in commenting on my UDC application? [06:04] hmmm.... [07:04] Riddell, I got koffice2 fixed, waiting on a confirmation build [07:06] Good morning [07:06] morning pitti [07:07] pitti! [07:07] pitti, mind if I pick your mind on an archive question? [07:07] NCommander: not at all [07:07] Hello Hobbsee, hey NCommander [07:08] bryce: post-alpha 5 is ok, thank yuo [07:08] pitti, ok, have you been following the PIE experiment? [07:10] NCommander: not too closely, the uploads were done during my holidays [07:11] pitti, well, -fPIE wasn't enabled because it causes FTBFS because to make it work, every static library and static built binary needs to be rebuilt in the archive [07:11] pitti, if something non-PIE remains, builds would explode in a shower of sparks [07:12] pitti, right now, with kees's assistance, I'm doing a full manual bootstrap of Ubuntu amd64 with PIE enabled. Now the ABI will remain unchanged, but every library needs to be rebuilt, and I felt that trying to mix PIE and non-PIE libraries was a disaster waiting to happen [07:13] pitti, talking to kees, if it proves that the archive can reasonably be converted to -fPIE/PIC, he's going to push hard to make the change [07:13] pitti, so here comes the archive part [07:13] gooood morning [07:14] hey dholbach [07:14] hiya pitti [07:14] pitti, there will be a transitional period where we will have to pretty much remove the existing binaries and rebuild things from scratch. What I think though might be an easier solution however is treat it as a new architecture, amd64-pie [07:14] NCommander: I expect that there will be some fallout, i. e. a lot of packages which won't build with -fPIE right away; but ICBW, of course (and hope I am :-) ) [07:14] pitti, when transitional time comes, its just a matter of changing every deb from amd64-pie to amd64 [07:15] pitti, the other choice is keep it in a different distribution such as intrepid-pie, intrepid+1-pie, etc. [07:15] NCommander: well, this wouldn't be a thing we'd keep indefinitively, it's an one-time transition, right? [07:15] pitti, once per architecture [07:16] (once AMD64 goes, powerpc will go, and so forth expect lpia/x86) [07:16] Roughly speaking, having it as an architecture allows us to seperately manage those buildds without disrupting amd64's normal port until the very end of the transition [07:16] NCommander: I would assume that having an amd64-pie arch would be feasible (except for the mirror costs maybe), but a mass-renaming of amd64-pie .debs to amd64 sounds hackish and wrong [07:17] pitti, well, we could just do a rebuild, but we need the archive tracking with PIE [07:17] NCommander: TBH I'm not quite sure how to do that transition smoothly; of course the first test build should be entirely separate, but then we more or less need to rebuild the entire archive on soyuz anyway, so we might just as well do it for the right architecture [07:17] pitti, I'm going to be using ubuntuwire and rebuildd to track, but its still not that great since it means only ubuntuwire admins can control the rebuildd daemon, and no bug control intergration, etc. [07:17] that should happen at the opening of a cycle, when it doesn't matter so much to have a mostly broken archive [07:18] pitti, extactly. I suspect pie will hit AMD64 intrepid+2 [07:18] (we can probably add amd64-pie to Launchpad towards the end of intrepid+1) [07:19] NCommander: will still be quite tricky, I expect, since yuo have to rebuild everything in a particular order (upwards the dependency chain), right? [07:19] or can you build PIE programs against non-PIE libs? [07:19] pitti, correct. It would be the equivent of rebootstrapping amd64 from scratch [07:19] pitti, no, the linker explodes [07:20] well, hang on, aren't libs PIE already anyway? [07:20] Only shared [07:20] or was that just "PIC"? [07:20] Static libs need to be rebuilt [07:20] NCommander: right, but who cares about static libs? there should be very few cases actually [07:20] You'd be suprised [07:20] How many static libs are there? [07:20] wgrant, enough [07:20] Can't they just be rebuilt? [07:20] NCommander: in fact, that would be a good opportunity to get rid of them altogether [07:20] Grr. [07:21] pitti, every executable still needs a rebuild, and the shared libraries still need -fPIE AFAIK [07:21] (I haven't tried mixing and matching flags just yet :-)) [07:21] no, the shared libs shouldn't need -fPIE [07:21] There is a good Gentoo page [07:21] NCommander: IIRC it is Debian Policy to build shlibs with PIE [07:21] But let me put it like this [07:21] they should already be position-independent if built with -fPIC; and if that's not sufficient for any reason, that's a bug in the implementation [07:21] dpkg is compiled against a static libselinux [07:22] sorry, -fPIC [07:22] That's a core package, and I bet there are loads more all over the place [07:22] there should certainly not be /loads/ more [07:22] NCommander: dpkg is also quite a special case [07:22] there should be a few dozen at most [07:22] NCommander: dpkg must not link against a lot of shlibs, because it almost always have to work [07:22] slangasek, 15% of main alone FTBFS due to PIE/non-PIE linkages [07:23] erm [07:23] NCommander: there's things like bash-static, but I really thing we shuoldn't have more than a handful of static linkages [07:23] (kees has been experimenting with this more) [07:23] Well, the experiment to see quite how bad the situation is [07:24] If we want to look towards removing or (in my opinion, a better solution would be adding them as a -static-dev package) doing whatever with static libs [07:24] This is the best time to do it [07:25] I expect getting main to be PIE (with a few exceptions) should be relatively straightfoward. I'm more worried about universe [07:25] seriously, do we really need to waste so much archive space for building static libs all the time [07:25] especially since I expect that 95% of them are not policy compliant anyway? [07:25] hrm? policy for a static lib is pretty easy [07:25] pitti, how do you suggest we remove them? [07:25] (static libs must not be built with -fPIC, but I seldomly see a package which actually builds twice) [07:25] pitti: anything that uses libtool builds twice [07:26] pitti, that's only completely true for x86. amd64 and other architectures can have static libs as PIC safely with some benefits [07:26] and I'm not sure that's a 'must'; consulting the policy [07:26] ah, it is a must, with exceptions [07:26] http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3 - the Gentoo packaging page [07:27] Which explains the usual PIE related FTBFS [07:27] I don't see any explanations of PIE failures on that page [07:27] Go straight down to the bottom [07:28] The four problems with PIE and how to correct [07:28] those all say "PIC" [07:28] PIE is just a PIC executable [07:29] I think I know better than you what PIE is, if you're trying to claim that all shared libs need to be rebuilt with an extra option to be compatible with it [07:29] * NCommander runs regression testing on his PIE compiler [07:29] slangasek, no, I'm not saying that. The static libraries either must be rebuilt or removed [07:30] Or any resulting binaries that links statically will fail once PIE is default [07:30] ok, but things aren't supposed to be linking to static libs /anyway/ aside from exceptional cases. [07:32] slangasek, at least you confirmed for me the -fPIE issues weren't quite so bad as kees made them sound to be [07:32] or should I say clarified [07:32] at least I don't think we need a particular order in rebuilding the archive, which makes things much easier [07:33] at least not for shlibs [07:33] well, I don't know what this 15% figure is based on [07:33] but if 15% of main is linking to libs statically, something's wrong, and we should fix that instead of papering over it :) [07:33] slangasek, that was simply the percent of packages that failed [07:33] slangasek, well, yes. I'll have to ask kees when he floats online [07:34] (its quite possible there were other FTBFS issues related to PIE) [07:34] I see the usefulness in static linking for dpkg, bash-static, busybox-static, zsh-static, dar-static, and binutils-static, but that's about it [07:34] I figure if killing static libraries as best as possible is desirable, might as will kill two birds with one stone [07:34] The question is how to do it [07:34] even things like cdebootstrap-static are not warranted IMHO [07:34] pitti: there are some libs that get linked statically because they don't have stable ABIs [07:34] (libbfd) [07:34] (well, at least to me the entire idea of cdebootstrap is hilarious, but *shrug*) [07:35] * NCommander has never gotten it to work [07:35] slangasek: right, those too [07:35] slangasek: ffmpeg or something similar was such a case [07:35] so there are enough static libs that rebuilding the archive is justified [07:35] well, ffmpeg's case isn't all that similar :) [07:35] (and probably not a bad idea to make sure everything got built with the new hardening flags from intrepid) [07:35] Rebuilding the entire archive would be a nightmare. [07:36] NCommander: no, it's not at all justified; just identify and rebuild the packages providing static libs that are linked against by packages [07:36] slangasek, every executable still needs to be rebuilt with -fPIE [07:37] "needs" - that's not a strong argument for an archive event, IMHO [07:37] Not immediately. [07:37] We haven't had an archive event for a while now. [07:41] this is why I'd like to do the staging work as amd64-pie, which make sure everything is going to work, and then can be simply killed once amd64 is fully migrated === thekorn_ is now known as thekorn === tkamppeter_ is now known as tkamppeter [08:13] slangasek, thinking it over, the best solution is to rebuild the base system by hand due to the static libraries with PIE with this rebuild being a new architecture (amd64-pie), and then do a test rebuild with a deb line for the archive and (amd64) added similar to lpia, which would simulate the situation we'll see on the buildds, and catch what packages will need to be touched to properly complete the transition [08:13] slangasek, would you agree? [08:14] do we actually need that new arch in soyuz? that's a quite expensive operation; wouldn't a local archive do as well? [08:14] No it won't [08:14] (for the test rebuild) [08:15] No, I wasn't doing the rebuild on SOyuz ;-) [08:15] ubuntuwire already has the infrastructer doing it [08:16] It just means the chroot on every buildd will need to be manually updated due to the bootstrapping issue (you can't (easily) build the PIE base system from a non-PIE chroot; its extremely difficult to do) [08:16] THe binaries of course shouldn't break anything [08:17] Roughly speaking, it basically becomes the base system needs to be bootstrapped PIE, the buildds need that chroot installed, and then just rebuild the base packages which require static [08:18] it shouldn't be that difficult, the static libs that need to be built should be identifiable by visual inspection [08:18] slangasek, once the build system is rebuilt, the FTBFS will find the rest [08:18] then everything else should be rebuildable without fiddling [08:18] s/build/base [08:19] then its just a matter of making sure the important packages get retouched [08:20] slangasek, I'm glad your experienced in such matters, you saved me quite a bit of work in testing this ;-) [08:40] hi, when will alpha 5 be released? [08:44] pitti: cjwatson: what would convince you to move kerneloops package to the default install? [08:44] amitk: hm, don't we have the kernel crash dump infrastructure for that now? [08:45] amitk: apport picks up the dump, and offers the user to send it to LP as a bug report [08:45] pitti: kerneloops is unrelated [08:45] right, I know [08:45] we shoudn't have two different systems for the same purpose [08:45] pitti: it sends the bug reports the kerneloops.org so that upstream sees what bugs are most frequently encountered [08:46] pitti: in case of the kernel, it would help to push bugs upstreams sooner, than waiting for kernel QA to manually link them upstream through LP [08:47] amitk: can we discuss that on ubuntu-devel@ first? [08:47] pitti: sure. I will send email. [08:47] amitk: would they actually appreciate getting reports from a heavily ubuntu-modified kernel? [08:48] amitk: what kind of GUI does it offer, BTW? it depends on gtk, but how does it integrate into the desktop? [08:50] amitk: so, depending on how it looks and what it does exactly, we could have it similar to apport (enable in the development release, disable in the final release) [08:50] such things aren't appropriate to enable on production systems, in stable releases, but very useful for devlopment releases indeed [08:51] pitti: there is a kerneloops-applet that pops up when it notices an oops. It seems well intregrated into gtk/gnome. [08:52] are there any information online about what you talk right now? so a user can use this? :) [08:52] pitti & slangasek, roughly speaking, who is in charge of the buildd chroot and upgrades? (I just want to compare notes with them) [08:56] pitti: 'apt-cache depends kerneloops' shows dbus, glib, gtk, libnotify [08:56] NCommander: infinity and lamont [08:56] amitk: ok, thanks; let's discuss this on the ML to get some more input, shall we? [08:57] pitti: ack === mvo__ is now known as mvo [09:33] soren: EBW == evil, bad, and wrong [09:38] pitti: Heh :) Ok. [09:52] pitti: will I have to modify the detection and representation of the recommended driver in Jockey for the new interface mpt and you are working on? [09:53] tseliot: no, that should be fine [09:54] pitti: ok === android6011_ is now known as android6011 [10:01] <\sh> pitti: moins....any update on the MIRs? [10:01] \sh: I processed almost all of them yesterday, but was sidetracked with doing some high-urgency stuff [10:01] \sh: oh, right, your's is tslib, right? [10:02] <\sh> pitti: not mine, but I'm waiting for it, because of refresh+update on ia32-libs [10:04] asac: eek, firefox won't start anymore on my current Intrepid system ("Error launching browser window:no XBL binding for browser") is there a known issue? [10:05] I would check myself but my browser doesn't work ;-) [10:05] <\sh> mdz: I have since yesterday some strange "firefox just crashing randomly without leaving any trace" [10:05] \sh: sounds different [10:06] mdz: no ... i didnt hear about that. also there wasnt an upload the last days. [10:08] <\sh> asac: http://paste.ubuntu.com/43585/ <- can you have a look and tell me if it's known to you? [10:08] <\sh> asac: sidenote: it's not on all websides with flash...this is happening e.g. on technorati for me...I wonder why [10:09] \sh: i guess you are on 32-bit? [10:09] <\sh> asac: no ;) [10:09] <\sh> afaik I don't have any i386 anymore in use [10:10] mdz: i think a first start would be to stare at strace -f -eopen firefox ... and see if there are any write permission issues or some files not found [10:10] \sh: what does: dpkg -S libflashplayer.so [10:10] give you ? [10:11] \sh: obviously your libflashplayer.so is installed in a wrong fashion [10:11] but afaik our package doesnt do that [10:11] pitti: I tried to override the browser for apport-cli with $BROWSER but it still launches firefox [10:11] <\sh> asac: hmm..dpkg -S libflashplayer.so doesn't give me anything, dpkg -l|grep flashplugin-nonfree gives me 1.0.1.128+10.0.0.525ubuntu1 [10:11] mdz: it first checks your preferred browser in System -> Preferences -> Applications [10:12] (might be "Preferred applications" or so) [10:12] wow everyone quits as soon as I ask a question :) [10:12] wow everyone joins at the same time [10:12] lucky711x: http://wiki.ubuntu.com/ContributeToUbuntu may help you get started [10:12] asac: I don't see anything particularly scary in there [10:12] \sh: think for a minute why you have /usr/lib/firefox-addons/plugins/libflashplayer.so [10:13] \sh: if you dont find an explanation, just remove that file [10:13] cjwatson, yeah Ive read through almost everything on the wiki [10:13] \sh: maybe look at what uplaods were done for the flashplugin-nonfree package . i dont want to rule out that there was yet another broken upload [10:13] 19:07 < lifeless> mdz: try removing your extensions [10:13] 19:08 < lifeless> mdz: apparently the 'chrome' folder should contain them, they might be per-user or packaged [10:14] cjwatson, I guess what I mean is that what can I apply my Java experience to? Or what would be the best area of development? [10:14] 19:10 < lifeless> mdz: also try passing --safe-mode [10:14] 19:10 < lifeless> e.g. firefox --safe-mode [10:14] lucky711x: quits/joins> those were a netsplit, when two IRC servers in the network forget how to talk to each other for a bit. The better clients know how to filter them all down to one line [10:14] ahh [10:14] <\sh> asac: will reinstall the package (remove --purge + --reinstall install ) [10:14] kees: I fixed the harvest problem you ran into [10:15] asac,lifeless: aha, there is still a firefox process running but no windows [10:15] mdz: yeah [10:15] mdz: that explains it. [10:15] asac: it seemed to shut down cleanly [10:16] lucky711x: we don't have a lot of Java applications installed by default or anything, but we are generally in need of more people to help maintain Java library packages; https://wiki.ubuntu.com/JavaTeam have weekly meetings and you could start by looking over their records [10:16] cjwatson, ok cool thanks [10:16] <\sh> asac: that was it [10:17] \sh: i am a bit scared why the plugin is in that directory. did you run adobes installer? [10:17] lucky711x: also, a good way to get started is often to visit the bug tracker for packages you're interested in (https://bugs.launchpad.net/ubuntu/+source/INSERTSOURCEPACKAGENAMEHERE/+bugs) and start proposing patches [10:17] <\sh> asac: some time ago...but thought I got rid of all cruft of that [10:18] cjwatson, thanks alot Im really excited to help out with Ubuntu [10:22] cjwatson, I think you need to stop me right now [10:22] cjwatson, I'm looking at SGI MIPS machines. If I get one, an Ubuntu port may be born after my current rebuild project [10:25] hmm ... is alpha5 stuck? [10:29] the only problem I heard of was the Edubuntu add-on CD one [10:30] _MMA_: oops, I just noticed that I arranged for ubuntustudio-desktop to be installed by default, but forgot to roll out that debian-cd change to antimony. Sorry about that; should be fixed after alpha-5 [10:32] slangasek: anything other than Edubuntu holding things up? [10:34] ogra: ltsp-client-core is the only thing still needing discover1, and it has been obsoleted by discover and removed in Debian; do you eventually plan to get rid of it? [10:35] pitti, i think i can drop it [10:35] ogra: want a bug report? [10:35] though ltsp has the oportunity to use xdebconfigurator [10:36] and given that Xorg --configure which we used until now hardlicks the system thats probably the only opportunity to get a sed'able xorg.conf [10:36] *hardlocks [10:37] pitti, i have to think about that, ltsp relies on xorg.conf for the custom setups ... [10:37] ogra: ok, thanks [10:38] if bryce can make Xorg -configure work as it used to (and as its documented) i can get around that though and discover can go [10:38] but i'm note sure the current design of Xorg even remotely offers that [10:38] cjwatson: if I see some progress on UbuntuStudio testing I might delay the push to let that finish; otherwise, not AFAIK [10:39] aah. these look cool - think im gonna put off my eee pc purchase - http://www.dell.com/content/products/productdetails.aspx/laptop-inspiron-9?cs=19&s=dhs&ref=homepg [10:40] slangasek: I couldn't reproduce the bug that got filed about debootstrap failing [10:40] (bug 264804) [10:40] Launchpad bug 264804 in debian-installer "[intrepid alpha 5] ubuntu studio i386 install fails at debboostrap" [Undecided,Incomplete] https://launchpad.net/bugs/264804 [10:42] asac: killing that process fixed it, but I can't say what went wrong [10:43] cjwatson: does that mean you have a complete successful test, then? that would seem to be the first reported for US alpha-5, if so [10:46] mdz: most likely xulrunner upgrade underneath a running firefox ... after alpha-5 the new ubufox will hopefully fix this by presenting users with a "restart" button in firefox after upgrade [10:46] which then might have a better chance to completely tear down the old firefox [10:46] updated edubuntu CDs posted now; syncing the amd64 one here [10:48] ogra: why do you need a a sed'able xorg.conf? [10:50] tseliot, to adjust a ton of values ... [10:51] slangasek: hmm, no (I stopped after failing to reproduce the bug, foolishly), but I could get there in not too long [10:51] ltsp is often used with HW thats really ancient [10:51] ogra: you can use X-Kit to do it [10:52] ogra: it only depends on python [10:52] tseliot, is that supported by fedora, gentoo and debian ? [10:52] ogra: not yet but it would be trivial to install it there [10:52] note that ltsp tries to work distro independent, its maintained in a consortium ... all distro specifics i add for ubuntu have to be maintained separately [10:53] note also that ltsp in 80% of the cases runs on HW that is to old to be properly detected [10:53] ogra: ok I see. Maybe when X-Kit is supported by those distributions then [10:53] slangasek: I'm jigdoing it back down now [10:54] i.e no DCC info from monitors and people ending up with 640x480 [10:54] ogra: with X-Kit you decide what you want to change. It's just a parser/writer and a validator [10:54] s3virge cards from 1996 ... for which you hardly find a supported driver but which can got working with a special set of options [10:55] ltsp has scripts for that since yeras but these only work on a basic xorg.conf [10:56] ogra: I feel that the use case is good for X-Kit (which is only 2 files, BTW). Can't you include it in the ltsp packages? [10:56] oh, and forget about python on a 48M thin client [10:56] ogra: ouch [10:57] running the interpreter is already to heavy there (we used to have the display manager in python, tha forced a min req. of 128M on us ... which was the reason to rewrite everything in plain C) [10:58] compcache mght help there, but i dont have enough time to even do all the ltsp packaging [10:58] so changing big chunks of the X detection mechnanism is something i wont manage before release [10:59] asac: neat [10:59] getting hl-input proper there for the default set without xorg.conf was hard enough [10:59] *hal [10:59] and it still has its rough edges [10:59] and is fedora/ubuntu only as of now ... which isnt really great [11:00] ogra: maybe we can talk about this at the next UDS then [11:00] yeah, happy to [11:00] for now i just dont want to tell users with very old HW that they are screwed [11:01] yes, I understand ;) [11:01] for these parsing a generic xorg.conf is the only solution [11:01] ogra, trying to resolve the old vsync issue? [11:01] hsync/vsync [11:02] NCommander, yeah, that and unsupported old cards [11:02] * NCommander notes that anyone who has a laptop with a VIA card has been absolutely raped on that bug [11:02] or "barely/badly" supported [11:02] Like my old thinkpad [11:02] er, Toshiba [11:02] the thinkpad just didn't like X period [11:02] we even have still users with serial mice that run the input through gpm [11:03] I know people who still use XT keyboards [11:03] Hell, I have a real old AT Dvorak I keep around [11:03] ogra, the problem is even the newer VIA cards lie about their capabilities [11:03] now these are the ones i have to tell to say goodbye to their moce, i doubt thats even remotely possible with the new input model [11:03] *mice [11:03] I had to handwrite at least 20 lines of xorg to get my laptop to at least SYNC to the right resolution [11:04] and this was an '05 [11:05] ogra, BTW, has anyone worked at implementing the GNOME exit box? [11:05] hsync/vrefresh is a DCC value coming from the monitor [11:05] *DDC [11:05] ? [11:05] hmm [11:05] I did it for Xfce 4.6 [11:05] well, a monitor value ... [11:06] most old tube monitors dont report that properly [11:06] ogra, most VIA laptops just report the card, with no monitor P&P [11:06] ogra, this is an LCD :-) [11:06] thast the biggest prob we have in ltsp ... which is often used in countries where a tube monitor from 1999 is the latest you can get [11:06] And if you screw up [11:07] Those old monitor burn up nice [11:07] What I would kill for is a program that could get the right ranges out of the windows drivers [11:07] Didn't displayconfig-gtk do that? [11:07] Nope [11:07] displayconfig-gtk won't give me the right sync ranges [11:08] mvo: ping [11:08] any progress on bug 254628 ? [11:08] er, refresh [11:08] Launchpad bug 254628 in app-install-data-ubuntu "Make it possible to translate eg. codec name/description strings" [Undecided,New] https://launchpad.net/bugs/254628 [11:08] (I needed a refresh of 60, resolution of 1024x768, and some insanely high vsync) [11:08] bed time for me [11:09] I sleep beyond the reachs of time itself ;-) [11:09] NCommander: You sleep? [11:10] heh [11:10] wgrant, 6-12 hours a night [11:10] Makes you wonder when I do Ubuntu magic [11:11] * NCommander takes the 50 spot on the stats [11:11] w00 [11:11] bed now [11:12] kelemengabor: not yet, but the archive is still in (soft) freeze, so I can not upload [11:15] slangasek: does an uninstallable virt-manager on the server CDs justify rerolling those? [11:17] cjwatson: is that in one of the tasks? [11:20] cjwatson: if the testing can get done in the next few hours, then I'm ok with rerolling if there's a fix fr virt-manager; if it can't, and virt-manager doesn't generally break the server install, I'd rather not re-roll since that would push the current candidate images off the server unless we fiddled first [11:25] persia, can you give me the e-mail address of balachmar? I need to contact him, he visits the IRC only for some minutes when I am not here. [11:27] slangasek: it's not in one of the tasks AFAICS [11:28] Hi! [11:29] I have a small question [11:29] Over make repository with gpg === dholbach_ is now known as dholbach [11:34] cjwatson: ok; then I think everything's set to push the alpha out tomorrow morning, if someone can test edubuntu/i386 and (optionally) UbuntuStudio amd64 in the meantime [11:35] so I'm going to go get a bit of sleep [11:37] tkamppeter: I don't have such an email address. [11:39] sleep well [11:40] lemming: I'm not sure I can figure out what your question is [11:45] cjwatson, i'm making an oficial repository for Galician packages [11:45] i'm using reprepro for this, but i don't know if this is the better option [11:47] because i want do that one valid user upload a package in a specific folder this package go "automagically" to unstable repository [11:47] but to do this i have to make a gpg key without password [11:47] yes, you do [11:48] archive keys usually need to be usable in an unattended fashion; you just have to keep the key material as secure as you can [11:48] I'd recommend not allowing particularly widespread shell access to the machine in question [11:48] ok [11:49] i suposed it [11:49] ;) [11:59] cjwatson, in the hardy ubiquity installer, when I go back from the final overview page to the partitioner, it forgets what I had told it (I'm having to use manual partitioning for this re-installation); is that known/intentional? [12:04] liw: no, I think there's a bug for that [12:05] cjwatson, ack, then I won't file a new one [12:08] hi [12:08] does latest intrepid updates fix #233787 bug? [12:09] pitti: infinity is in charge of the buildd chroots, not me. [12:13] * liw sees the hardy installer still sets the tty flag to convert everything to upper case, heh [12:13] that's not the installer, it's something random in some random unknown package [12:13]