[00:04] <kees> fta, asac: is is possible to build thunderbird with FORTIFY now?
[00:17] <asac> kees: most likely lacks the patch
[00:18] <asac> kees: is this blocking something?
[00:19] <kees> asac: nope, just noticed it is all.
[00:19] <kees> asac: should I re-open the bug?
[00:19] <asac> kees: i am too tired right now, but maybe we should add a tracker bug for all mozilla apps :)
[00:20] <kees> asac: okay, I'll ping you about it tomorrow.  thanks!
[00:47] <NCommander> Wooooo, MIPS based laptop
[00:48]  * NCommander figured out how to order one and port Ubuntu to it
[00:54] <NCommander> http://mobile.slashdot.org/article.pl?sid=08/09/04/2232225
[01:00] <NCommander> kees, poke
[01:03] <kees> NCommander: yo
[01:03] <NCommander> kees, what options do you want me to embed into GCC
[01:04] <NCommander> I want to deprieate harden-wrapper on amd64 if possible by simply having GCC have those options ON by default
[01:04] <NCommander> *hardening
[01:04] <NCommander> I can add any flag that GCC recongizes as well as FORTIFY_SOURCE
[01:06] <kees> NCommander: there's already all in there: https://wiki.ubuntu.com/CompilerFlags
[01:06] <NCommander> HLFS recommends: -fstack-protector -fstack-protector-all fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,-z,combreloc
[01:06] <kees> -z now by default is a bad idea.
[01:06] <NCommander> With the behavior turning off on -D_KERNEL_
[01:06] <NCommander> Ok
[01:06] <kees> haven't seen combreloc before
[01:07] <NCommander> (fortify source will also be set on by default)
[01:07] <kees> see that wiki page
[01:07] <NCommander> Yes my lord and master
[01:08]  * NCommander will have patchs for doko that will make him scream
[01:08] <kees> NCommander: I feel like you're not hearing me: I have already patched gcc for all those options.
[01:09] <NCommander> I thought hardening-wrapper did it
[01:09] <NCommander> Oh
[01:09] <NCommander> Sweet :-)
[01:09] <NCommander> That just means I need to add the PIE flags to the spec file, and we're in business
[01:10] <kees> I have implemented these options in about 3 ways now.  :)
[01:10] <kees> hardening-wrapper _also_ does it.
[01:10] <NCommander> I guess some confusion on my end is understandable
[01:10] <NCommander> I didn't know that
[01:10] <kees> note that there isn't technically a "spec" file.
[01:10] <NCommander> spec strings
[01:10] <NCommander> Fine :-P
[01:10] <kees> check out my existing patches in gcc-4.3 for some hints on the insanity needed.  :)
[01:11] <NCommander> 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] <NCommander> ^?
[01:12] <kees> 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] <NCommander> he's going to eventually read this backlog, and a high pitched scream is going to deafen us all
[02:26] <bryce> pitti: ping
[02:46] <bryce> 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] <bryce> 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] <ion_> echo... echo... echo...
[02:47] <bryce> ion_: sorry, xchat is not displaying anything
[02:48] <bryce> 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] <NCommander> ScottK, you floating around?
[04:38] <NCommander> Riddell, you around?
[04:41] <NCommander> Hobbsee, you around?
[04:43] <ScottK> NCommander: Here now.
[04:56] <GomoX> Hey
[04:58] <GomoX> 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] <GomoX> Also i'm not sure how it works on other laptops but i guess it should toggle NetworkManager.getWirelessEnabled via DBUS
[05:00] <NCommander> GomoX, this is for Ubuntu development, not Ubuntu debugging, please try #ubuntu
[05:00] <NCommander> (or support)
[05:01] <GomoX> Well technically this should be interesting to the corresponding developer
[05:01] <GomoX> I can get it working with a script, the question is how does one go about telling the corresponding dev about it
[05:03] <NCommander> GomoX, file a bug on Launchpad
[05:32] <android6011> is there an alpha 5 install iso yet?
[05:33] <philwyett> Not yet going by cdimage.ubuntu.com
[05:40] <android6011> so its been delayed then?
[05:50]  * NCommander waits on the passage of time.
[05:58] <Hobbsee> NCommander: contentless ping.
[05:59] <NCommander> Hobbsee, interesting in commenting on my UDC application?
[06:04] <Hobbsee> hmmm....
[07:04] <NCommander> Riddell, I got koffice2 fixed, waiting on a confirmation build
[07:06] <pitti> Good morning
[07:06] <NCommander> morning pitti
[07:07] <Hobbsee> pitti!
[07:07] <NCommander> pitti, mind if I pick your mind on an archive question?
[07:07] <pitti> NCommander: not at all
[07:07] <pitti> Hello Hobbsee, hey NCommander
[07:08] <pitti> bryce: post-alpha 5 is ok, thank yuo
[07:08] <NCommander> pitti, ok, have you been following the PIE experiment?
[07:10] <pitti> NCommander: not too closely, the uploads were done during my holidays
[07:11] <NCommander> 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] <NCommander> pitti, if something non-PIE remains, builds would explode in a shower of sparks
[07:12] <NCommander> 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] <NCommander> 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] <NCommander> pitti, so here comes the archive part
[07:13] <dholbach> gooood morning
[07:14] <pitti> hey dholbach
[07:14] <dholbach> hiya pitti
[07:14] <NCommander> 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] <pitti> 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] <NCommander> pitti, when transitional time comes, its just a matter of changing every deb from amd64-pie to amd64
[07:15] <NCommander> pitti, the other choice is keep it in a different distribution such as intrepid-pie, intrepid+1-pie, etc.
[07:15] <pitti> NCommander: well, this wouldn't be a thing we'd keep indefinitively, it's an one-time transition, right?
[07:15] <NCommander> pitti, once per architecture
[07:16] <NCommander> (once AMD64 goes, powerpc will go, and so forth expect lpia/x86)
[07:16] <NCommander> 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] <pitti> 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] <NCommander> pitti, well, we could just do a rebuild, but we need the archive tracking with PIE
[07:17] <pitti> 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] <NCommander> 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] <pitti> that should happen at the opening of a cycle, when it doesn't matter so much to have a mostly broken archive
[07:18] <NCommander> pitti, extactly. I suspect pie will hit AMD64 intrepid+2
[07:18] <NCommander> (we can probably add amd64-pie to Launchpad towards the end of intrepid+1)
[07:19] <pitti> 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] <pitti> or can you build PIE programs against non-PIE libs?
[07:19] <NCommander> pitti, correct. It would be the equivent of rebootstrapping amd64 from scratch
[07:19] <NCommander> pitti, no, the linker explodes
[07:20] <pitti> well, hang on, aren't libs PIE already anyway?
[07:20] <NCommander> Only shared
[07:20] <pitti> or was that just "PIC"?
[07:20] <NCommander> Static libs need to be rebuilt
[07:20] <pitti> NCommander: right, but who cares about static libs? there should be very few cases actually
[07:20] <NCommander> You'd be suprised
[07:20] <wgrant> How many static libs are there?
[07:20] <NCommander> wgrant, enough
[07:20] <wgrant> Can't they just be rebuilt?
[07:20] <pitti> NCommander: in fact, that would be a good opportunity to get rid of them altogether
[07:20] <wgrant> Grr.
[07:21] <NCommander> pitti, every executable still needs a rebuild, and the shared libraries still need -fPIE AFAIK
[07:21] <NCommander> (I haven't tried mixing and matching flags just yet :-))
[07:21] <slangasek> no, the shared libs shouldn't need -fPIE
[07:21] <NCommander> There is a good Gentoo page
[07:21] <pitti> NCommander: IIRC it is Debian Policy to build shlibs with PIE
[07:21] <NCommander> But let me put it like this
[07:21] <slangasek> 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] <NCommander> dpkg is compiled against a static libselinux
[07:22] <pitti> sorry, -fPIC
[07:22] <NCommander> That's a core package, and I bet there are loads more all over the place
[07:22] <slangasek> there should certainly not be /loads/ more
[07:22] <pitti> NCommander: dpkg is also quite a special case
[07:22] <slangasek> there should be a few dozen at most
[07:22] <pitti> NCommander: dpkg must not link against a lot of shlibs, because it almost always have to work
[07:22] <NCommander> slangasek, 15% of main alone FTBFS due to PIE/non-PIE linkages
[07:23] <slangasek> erm
[07:23] <pitti> NCommander: there's things like bash-static, but I really thing we shuoldn't have more than a handful of static linkages
[07:23] <NCommander> (kees has been experimenting with this more)
[07:23] <NCommander> Well, the experiment to see quite how bad the situation is
[07:24] <NCommander> 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] <NCommander> This is the best time to do it
[07:25] <NCommander> I expect getting main to be PIE (with a few exceptions) should be relatively straightfoward. I'm more worried about universe
[07:25] <pitti> seriously, do we really need to waste so much archive space for building static libs all the time
[07:25] <pitti> especially since I expect that 95% of them are not policy compliant anyway?
[07:25] <slangasek> hrm?  policy for a static lib is pretty easy
[07:25] <NCommander> pitti, how do you suggest we remove them?
[07:25] <pitti> (static libs must not be built with -fPIC, but I seldomly see a package which actually builds twice)
[07:25] <slangasek> pitti: anything that uses libtool builds twice
[07:26] <NCommander> pitti, that's only completely true for x86. amd64 and other architectures can have static libs as PIC safely with some benefits
[07:26] <slangasek> and I'm not sure that's a 'must'; consulting the policy
[07:26] <slangasek> ah, it is a must, with exceptions
[07:26] <NCommander> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3 - the Gentoo packaging page
[07:27] <NCommander> Which explains the usual PIE related FTBFS
[07:27] <slangasek> I don't see any explanations of PIE failures on that page
[07:27] <NCommander> Go straight down to the bottom
[07:28] <NCommander> The four problems with PIE and how to correct
[07:28] <slangasek> those all say "PIC"
[07:28] <NCommander> PIE is just a PIC executable
[07:29] <slangasek> 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] <NCommander> slangasek, no, I'm not saying that. The static libraries either must be rebuilt or removed
[07:30] <NCommander> Or any resulting binaries that links statically will fail once PIE is default
[07:30] <slangasek> ok, but things aren't supposed to be linking to static libs /anyway/ aside from exceptional cases.
[07:32] <NCommander> slangasek, at least you confirmed for me the -fPIE issues weren't quite so bad as kees made them sound to be
[07:32] <NCommander> or should I say clarified
[07:32] <pitti> at least I don't think we need a particular order in rebuilding the archive, which makes things much easier
[07:33] <pitti> at least not for shlibs
[07:33] <slangasek> well, I don't know what this 15% figure is based on
[07:33] <slangasek> 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] <NCommander> slangasek, that was simply the percent of packages that failed
[07:33] <NCommander> slangasek, well, yes. I'll have to ask kees when he floats online
[07:34] <NCommander> (its quite possible there were other FTBFS issues related to PIE)
[07:34] <pitti> 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] <NCommander> I figure if killing static libraries as best as possible is desirable, might as will kill two birds with one stone
[07:34] <NCommander> The question is how to do it
[07:34] <pitti> even things like cdebootstrap-static are not warranted IMHO
[07:34] <slangasek> pitti: there are some libs that get linked statically because they don't have stable ABIs
[07:34] <slangasek> (libbfd)
[07:34] <pitti> (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] <pitti> slangasek: right, those too
[07:35] <pitti> slangasek: ffmpeg or something similar was such a case
[07:35] <NCommander> so there are enough static libs that rebuilding the archive is justified
[07:35] <slangasek> well, ffmpeg's case isn't all that similar :)
[07:35] <NCommander> (and probably not a bad idea to make sure everything got built with the new hardening flags from intrepid)
[07:35] <wgrant> Rebuilding the entire archive would be a nightmare.
[07:36] <slangasek> 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] <NCommander> slangasek, every executable still needs to be rebuilt with -fPIE
[07:37] <slangasek> "needs" - that's not a strong argument for an archive event, IMHO
[07:37] <wgrant> Not immediately.
[07:37] <wgrant> We haven't had an archive event for a while now.
[07:41] <NCommander> 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
[08:13] <NCommander> 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] <NCommander> slangasek, would you agree?
[08:14] <pitti> 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] <NCommander> No it won't
[08:14] <pitti> (for the test rebuild)
[08:15] <NCommander> No, I wasn't doing the rebuild on SOyuz ;-)
[08:15] <NCommander> ubuntuwire already has the infrastructer doing it
[08:16] <NCommander> 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] <NCommander> THe binaries of course shouldn't break anything
[08:17] <NCommander> 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] <slangasek> it shouldn't be that difficult, the static libs that need to be built should be identifiable by visual inspection
[08:18] <NCommander> slangasek, once the build system is rebuilt, the FTBFS will find the rest
[08:18] <slangasek> then everything else should be rebuildable without fiddling
[08:18] <NCommander> s/build/base
[08:19] <NCommander> then its just a matter of making sure the important packages get retouched
[08:20] <NCommander> slangasek, I'm glad your experienced in such matters, you saved me quite a bit of work in testing this ;-)
[08:40] <nemesis> hi, when will alpha 5 be released?
[08:44] <amitk> pitti: cjwatson: what would convince you to move kerneloops package to the default install?
[08:44] <pitti> amitk: hm, don't we have the kernel crash dump infrastructure for that now?
[08:45] <pitti> amitk: apport picks up the dump, and offers the user to send it to LP as a bug report
[08:45] <amitk> pitti: kerneloops is unrelated
[08:45] <pitti> right, I know
[08:45] <pitti> we shoudn't have two different systems for the same purpose
[08:45] <amitk> pitti: it sends the bug reports the kerneloops.org so that upstream sees what bugs are most frequently encountered
[08:46] <amitk> 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] <pitti> amitk: can we discuss that on ubuntu-devel@ first?
[08:47] <amitk> pitti: sure. I will send email.
[08:47] <pitti> amitk: would they actually appreciate getting reports from a heavily ubuntu-modified kernel?
[08:48] <pitti> amitk: what kind of GUI does it offer, BTW? it depends on gtk, but how does it integrate into the desktop?
[08:50] <pitti> 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] <pitti> such things aren't appropriate to enable on production systems, in stable releases, but very useful for devlopment releases indeed
[08:51] <amitk> pitti: there is a kerneloops-applet that pops up when it notices an oops. It seems well intregrated into gtk/gnome.
[08:52] <nemesis> are there any information online about what you talk right now? so a user can use this? :)
[08:52] <NCommander> pitti & slangasek, roughly speaking, who is in charge of the buildd chroot and upgrades? (I just want to compare notes with them)
[08:56] <amitk> pitti: 'apt-cache depends kerneloops' shows dbus, glib, gtk, libnotify
[08:56] <pitti> NCommander: infinity and lamont
[08:56] <pitti> amitk: ok, thanks; let's discuss this on the ML to get some more input, shall we?
[08:57] <amitk> pitti: ack
[09:33] <pitti> soren: EBW == evil, bad, and wrong
[09:38] <soren> pitti: Heh :) Ok.
[09:52] <tseliot> 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] <pitti> tseliot: no, that should be fine
[09:54] <tseliot> pitti: ok
[10:01] <\sh> pitti: moins....any update on the MIRs?
[10:01] <pitti> \sh: I processed almost all of them yesterday, but was sidetracked with doing some high-urgency stuff
[10:01] <pitti> \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] <mdz> 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] <mdz> 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] <mdz> \sh: sounds different
[10:06] <asac> 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] <asac> \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] <asac> 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] <asac> \sh: what does: dpkg -S libflashplayer.so
[10:10] <asac> give you ?
[10:11] <asac> \sh: obviously your libflashplayer.so is installed in a wrong fashion
[10:11] <asac> but afaik our package doesnt do that
[10:11] <mdz> 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] <pitti> mdz: it first checks your preferred browser in System -> Preferences -> Applications
[10:12] <pitti> (might be "Preferred applications" or so)
[10:12] <lucky711x> wow everyone quits as soon as I ask a question :)
[10:12] <lucky711x> wow everyone joins at the same time
[10:12] <cjwatson> lucky711x: http://wiki.ubuntu.com/ContributeToUbuntu may help you get started
[10:12] <mdz> asac: I don't see anything particularly scary in there
[10:12] <asac> \sh: think for a minute why you have /usr/lib/firefox-addons/plugins/libflashplayer.so
[10:13] <asac> \sh: if you dont find an explanation, just remove that file
[10:13] <lucky711x> cjwatson, yeah Ive read through almost everything on the wiki
[10:13] <asac> \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] <lifeless> 19:07 < lifeless> mdz: try removing your extensions
[10:13] <lifeless> 19:08 < lifeless> mdz: apparently the 'chrome' folder should contain them, they might be per-user or packaged
[10:14] <lucky711x> 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] <lifeless> 19:10 < lifeless> mdz: also try passing --safe-mode
[10:14] <lifeless> 19:10 < lifeless> e.g. firefox --safe-mode
[10:14] <cjwatson> 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] <lucky711x> ahh
[10:14] <\sh> asac: will reinstall the package (remove --purge + --reinstall install )
[10:14] <dholbach> kees: I fixed the harvest problem you ran into
[10:15] <mdz> asac,lifeless: aha, there is still a firefox process running but no windows
[10:15] <asac> mdz: yeah
[10:15] <asac> mdz: that explains it.
[10:15] <mdz> asac: it seemed to shut down cleanly
[10:16] <cjwatson> 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] <lucky711x> cjwatson, ok cool thanks
[10:16] <\sh> asac: that was it
[10:17] <asac> \sh: i am a bit scared why the plugin is in that directory. did you run adobes installer?
[10:17] <cjwatson> 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] <lucky711x> cjwatson, thanks alot Im really excited to help out with Ubuntu
[10:22] <NCommander> cjwatson, I think you need to stop me right now
[10:22] <NCommander> 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] <asac> hmm ... is alpha5 stuck?
[10:29] <cjwatson> the only problem I heard of was the Edubuntu add-on CD one
[10:30] <cjwatson> _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] <cjwatson> slangasek: anything other than Edubuntu holding things up?
[10:34] <pitti> 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] <ogra> pitti, i think i can drop it
[10:35] <pitti> ogra: want a bug report?
[10:35] <ogra> though ltsp has the oportunity to use xdebconfigurator
[10:36] <ogra> 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] <ogra> *hardlocks
[10:37] <ogra> pitti, i have to think about that, ltsp relies on xorg.conf for the custom setups ...
[10:37] <pitti> ogra: ok, thanks
[10:38] <ogra> 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] <ogra> but i'm note sure the current design of Xorg even remotely offers that
[10:38] <slangasek> cjwatson: if I see some progress on UbuntuStudio testing I might delay the push to let that finish; otherwise, not AFAIK
[10:39] <stefanlsd> 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] <cjwatson> slangasek: I couldn't reproduce the bug that got filed about debootstrap failing
[10:40] <cjwatson> (bug 264804)
[10:42] <mdz> asac: killing that process fixed it, but I can't say what went wrong
[10:43] <slangasek> 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] <asac> 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] <asac> which then might have a better chance to completely tear down the old firefox
[10:46] <slangasek> updated edubuntu CDs posted now; syncing the amd64 one here
[10:48] <tseliot> ogra: why do you need a a sed'able xorg.conf?
[10:50] <ogra> tseliot, to adjust a ton of values ...
[10:51] <cjwatson> slangasek: hmm, no (I stopped after failing to reproduce the bug, foolishly), but I could get there in not too long
[10:51] <ogra> ltsp is often used with HW thats really ancient
[10:51] <tseliot> ogra:  you can use X-Kit to do it
[10:52] <tseliot> ogra: it only depends on python
[10:52] <ogra> tseliot, is that supported by fedora, gentoo and debian ?
[10:52] <tseliot> ogra: not yet but it would be trivial to install it there
[10:52] <ogra> 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] <ogra> note also that ltsp in 80% of the cases runs on HW that is to old to be properly detected
[10:53] <tseliot> ogra: ok I see. Maybe when X-Kit is supported by those distributions then
[10:53] <cjwatson> slangasek: I'm jigdoing it back down now
[10:54] <ogra> i.e no DCC info from monitors and people ending up with 640x480
[10:54] <tseliot> ogra: with X-Kit you decide what you want to change. It's just a parser/writer and a validator
[10:54] <ogra> 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] <ogra> ltsp has scripts for that since yeras but these only work on a basic xorg.conf
[10:56] <tseliot> 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] <ogra> oh, and forget about python on a 48M thin client
[10:56] <tseliot> ogra: ouch
[10:57] <ogra> 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] <ogra> compcache mght help there, but i dont have enough time to even do all the ltsp packaging
[10:58] <ogra> so changing big chunks of the X detection mechnanism is something i wont manage before release
[10:59] <mdz> asac: neat
[10:59] <ogra> getting hl-input proper there for the default set without xorg.conf was hard enough
[10:59] <ogra> *hal
[10:59] <ogra> and it still has its rough edges
[10:59] <ogra> and is fedora/ubuntu only as of now ... which isnt really great
[11:00] <tseliot> ogra: maybe we can talk about this at the next UDS then
[11:00] <ogra> yeah, happy to
[11:00] <ogra> for now i just dont want to tell users with very old HW that they are screwed
[11:01] <tseliot> yes, I understand ;)
[11:01] <ogra> for these parsing a generic xorg.conf is the only solution
[11:01] <NCommander> ogra, trying to resolve the old vsync issue?
[11:01] <NCommander> hsync/vsync
[11:02] <ogra> 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] <ogra> or "barely/badly" supported
[11:02] <NCommander> Like my old thinkpad
[11:02] <NCommander> er, Toshiba
[11:02] <NCommander> the thinkpad just didn't like X period
[11:02] <ogra> we even have still users with serial mice that run the input through gpm
[11:03] <NCommander> I know people who still use XT keyboards
[11:03] <NCommander> Hell, I have a real old AT Dvorak I keep around
[11:03] <NCommander> ogra, the problem is even the newer VIA cards lie about their capabilities
[11:03] <ogra> 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] <ogra> *mice
[11:03] <NCommander> I had to handwrite at least 20 lines of xorg to get my laptop to at least SYNC to the right resolution
[11:04] <NCommander> and this was an '05
[11:05] <NCommander> ogra, BTW, has anyone worked at implementing the GNOME exit box?
[11:05] <ogra> hsync/vrefresh is a DCC value coming from the monitor
[11:05] <ogra> *DDC
[11:05] <ogra> ?
[11:05] <ogra> hmm
[11:05] <NCommander> I did it for Xfce 4.6
[11:05] <ogra> well, a monitor value ...
[11:06] <ogra> most old tube monitors dont report that properly
[11:06] <NCommander> ogra, most VIA laptops just report the card, with no monitor P&P
[11:06] <NCommander> ogra, this is an LCD :-)
[11:06] <ogra> 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] <NCommander> And if you screw up
[11:07] <NCommander> Those old monitor burn up nice
[11:07] <NCommander> What I would kill for is a program that could get the right ranges out of the windows drivers
[11:07] <wgrant> Didn't displayconfig-gtk do that?
[11:07] <NCommander> Nope
[11:07] <NCommander> displayconfig-gtk won't give me the right sync ranges
[11:08] <kelemengabor> mvo: ping
[11:08] <kelemengabor> any progress on bug 254628 ?
[11:08] <NCommander> er, refresh
[11:08] <NCommander> (I needed a refresh of 60, resolution of 1024x768, and some insanely high vsync)
[11:08] <NCommander> bed time for me
[11:09] <NCommander> I sleep beyond the reachs of time itself ;-)
[11:09] <wgrant> NCommander: You sleep?
[11:10] <ogra> heh
[11:10] <NCommander> wgrant, 6-12 hours a night
[11:10] <NCommander> Makes you wonder when I do Ubuntu magic
[11:11]  * NCommander takes the 50 spot on the stats
[11:11] <NCommander> w00
[11:11] <NCommander> bed now
[11:12] <mvo> kelemengabor: not yet, but the archive is still in (soft) freeze, so I can not upload
[11:15] <cjwatson> slangasek: does an uninstallable virt-manager on the server CDs justify rerolling those?
[11:17] <slangasek> cjwatson: is that in one of the tasks?
[11:20] <slangasek> 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] <tkamppeter> 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] <cjwatson> slangasek: it's not in one of the tasks AFAICS
[11:28] <lemming> Hi!
[11:29] <lemming> I have a small question
[11:29] <lemming> Over make repository with gpg
[11:34] <slangasek> 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] <slangasek> so I'm going to go get a bit of sleep
[11:37] <persia> tkamppeter: I don't have such an email address.
[11:39] <doko> sleep well
[11:40] <cjwatson> lemming: I'm not sure I can figure out what your question is
[11:45] <lemming> cjwatson, i'm making an oficial repository for Galician packages
[11:45] <lemming> i'm using reprepro for this, but i don't know if this is the better option
[11:47] <lemming> because i want do that one valid user upload a package in a specific folder this package go "automagically" to unstable repository
[11:47] <lemming> but to do this i have to make a gpg key without password
[11:47] <cjwatson> yes, you do
[11:48] <cjwatson> 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] <cjwatson> I'd recommend not allowing particularly widespread shell access to the machine in question
[11:48] <lemming> ok
[11:49] <lemming> i suposed it
[11:49] <lemming> ;)
[11:59] <liw> 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] <cjwatson> liw: no, I think there's a bug for that
[12:05] <liw> cjwatson, ack, then I won't file a new one
[12:08] <lore20> hi
[12:08] <lore20> does latest intrepid updates fix #233787 bug?
[12:09] <lamont> 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] <cjwatson> that's not the installer, it's something random in some random unknown package
[12:13] <liw> er, yeah, I knew that
[12:13] <liw> syslog is shouting at me
[12:14] <liw> but that's ok, it will work anyway
[12:14] <cjwatson> you could be the one to figure out what's at fault! :)
[12:14] <liw> cjwatson, I could, once I have a wokring machine again, and some time
[12:15] <liw> t+5 hours 45 minutes until my UDW session, which I need to prepare, and that would greatly benefit from a working machine to run a VM on
[12:16] <Mithrandir> liw: if it's t+, you're a bit late for preparing.  ITYM t-5:45. :-)
[12:16] <liw> Mithrandir, t as in "now" :)
[12:16]  * liw is confused, and therefore confusing
[12:17] <cjwatson> liw: partitioner> bug 89093
[12:17] <liw> cjwatson, ack
[12:32] <pitti> seb128: seahorse-plugins will get a reverse dependency by something (seahorse?) or should it get seeded?
[12:34] <pitti> seb128: binary NEWed
[12:34] <kwwii> pitti: I have package to fix the human theme bug...
[12:35] <kwwii> http://sinecera.de/human-theme_0.23.dsc
[12:35] <kwwii> http://sinecera.de/human-theme_0.23_source.build
[12:35] <kwwii> http://sinecera.de/human-theme_0.23_source.changes
[12:35] <kwwii> http://sinecera.de/human-theme_0.23.tar.gz
[12:35] <kwwii> http://sinecera.de/ubuntu-artwork_44.dsc
[12:35] <kwwii> http://sinecera.de/ubuntu-artwork_44_source.build
[12:35] <kwwii> http://sinecera.de/ubuntu-artwork_44_source.changes
[12:35] <pitti> kwwii: nice! thanks, will sponsor them
[12:37] <pitti> kwwii: hm, ubuntu-artwork is already at 44 in intrepid
[12:37] <pitti> kwwii: did you actually change something in there? If so, you probably need to reapply them to the existing 44 and reupload as 45
[12:38] <fta> seb128, i just opened bug 265029 against gdm, not sure about the package, could be xorg or evdev
[12:38] <pitti> kwwii: human-theme change doesn't mention an LP #, doesn't it fix that milestoned bug?
[12:38] <seb128> fta: I doubt it's gdm or will get a reply there but thanks
[12:38] <pitti> kwwii: oh, BTW, human-theme-0.23/Human/gtk-2.0/gtkrc: "# Kenneth Wimar <kwwii@ubuntu.com>" -> you might want to fix your name :-)
[12:38] <seb128> fta: you might have a better chance reassigning it to xorg
[12:38] <seb128> pitti: thanks
[12:39] <fta> seb128, the thing is it's just with autologin, so i started from there
[12:40] <seb128> that's weird
[12:41] <fta> seb128, it means when i reboot, i see my desktop fully loaded but i can't use it
[13:01] <BenC> This is obviously off-topic, but is there a way to push a line back into a file stream in perl?
[13:02] <kwwii> pitti: freaky, I wonder how that came about
[13:02] <kwwii> thanks for noticing it :-)
[13:04] <Treenaks> BenC: there's ungetc in IO::Handle objects.. but not much else
[13:05] <kwwii> pitti: human-theme itself doesn't fix the bug, the ubuntu-artwork package fixes the bug
[13:05] <superm1> slangasek, if the intent is just to describe DKMS and not how it's used for 8.10, then good
[13:05] <cjwatson> there's an Unread method in the PerlIO C API, but I'm not sure if it's exposed at the Perl layer
[13:05] <kwwii> pitti: although I guess it is how you look at it, because without the changes to human-theme the -artwork package wouldn't fix the bug either
[13:05] <cjwatson> personally I think I might be inclined to use PerlIO::via
[13:06] <pitti> kwwii: ok, as long as it is mentioned in either changelog, all is well
[13:06] <pitti> kwwii: so you are prep'ing version 45?
[13:06] <cjwatson> (unread does seem to be exposed in perlio::via)
[13:06] <kwwii> pitti: it seems that my local copy was old...I can make a new source package with the correct version number, one second
[13:07] <kwwii> pitti: in fact, I will fix the spelling error in human-theme and then give you new urls for both
[13:07] <pitti> kwwii: alright :)
[13:07] <kwwii> pitti: I'll send you an email to avoid posting more crap here
[13:27] <pitti> kwwii: replied, u-artwork is still wrong
[13:33] <BenC> Treenaks: looks like redo does what I want
[13:36] <Treenaks> BenC: that restarts a loop block, it doesn't to things with filehandles
[13:36] <BenC> Treenaks: while (<STDIN>) { ...; redo if foo }
[13:37] <Treenaks> oh like that, yeah, that would work
[13:41] <seb128> kees: could you look at bug #264229? the libtiff 7.10 security update has an issue apparently
[13:42] <seb128> oh, that one is hardy
[13:42] <seb128> #264875 is a similar issue on gutsy
[13:44] <kwwii> pitti: no worries, i just noticed that it won't build because of po problems
[13:44] <kwwii> :-(
[13:44] <kwwii> I have absolutely no idea how to do the PO stuff
[13:46] <kwwii> boah, I take that back...sometimes I hate packaging
[13:51] <RAOF_> pitti: Yay!  No more Xgl!  Thanks :)
[13:51] <wgrant> It has finally died?
[13:51] <RAOF_> It's no longer in Intrepid, at least.
[13:52] <seb128> going to close all the bugs now? ;-)
[13:53] <RAOF_> Hm. Should I?
[13:53] <ogra> RAOF_, i thought you were so unhappy about that ?
[13:54] <seb128> would be nice to close all those bugs yes, maybe ask on #launchpad if they can do that
[13:54] <RAOF_> ogra: No?  Not really.  I was unhappy about the work needed to make it build again, but it's not really useful anymore.
[13:54] <ogra> yeah
[13:55] <RAOF_> (I would have had to bundle an old snapshot of the mesa source into the tarball, among other things.  Not pretty)
[13:55] <RAOF_> But all that's solved by merely not trying to build it at all! :)
[14:03] <pitti> kwwii: replied
[14:04] <pitti> seb128: wow, new *blows the dust off* esound?
[14:04] <seb128> pitti: yeah ;-)
[14:04] <seb128> pitti: oh, forgot to reply to your question, nothing depends on seahorse-plugins, but maybe seahorse should Recommends it?
[14:05] <pitti> seb128: yes, that's what I figured
[14:06] <pitti> seb128: btw, for the spellcheckers, new lang-support packages are up; what was the tbird problem again?
[14:07] <seb128> pitti: hunspell-* conflicts on thunderbird
[14:08] <pitti> seb128: for -en-us only? others have a versioned conflicts thunderbird (<< 2.0.0.1+0dfsg-0)
[14:09]  * pitti -> lunch
[14:10] <seb128> pitti: hunspell-fr has the issue too, didn't look at all the variants
[14:10] <seb128> pitti: enjoy
[14:10] <seb128> hum, I've to run for a bit too, see you later
[14:12] <seb128> dholbach: how busy are you? ;-) could you sponsor the gnome-themes and gcalctool updates? I've cleaned everything else on my sponsoring list but I've to run for a bit and I've other things to finish today and there is a new GNOME on monday, will try to do those later otherwise
[14:13] <dholbach> seb128: will do
[14:13] <seb128> lool: could you also look at the GNOME sponsoring request assigned to you? new GNOME is due on monday and they will be outdated before being uploaded otherwise ;-)
[14:13] <seb128> dholbach: thanks
[14:13]  * seb128 hugs dholbach
[14:13] <seb128> anyway I've to run, be back later
[14:13]  * dholbach hugs seb128 back
[14:13] <dholbach> see you
[14:14] <lool> seb128: I know it's a bad excuse for not spending time on sponsoring, but I spent too much time on GNOME tasks this week that this sponsoring should happen after some mobile work
[14:15] <lool> ideally, I would tend to everything immediately, but I can't really spend the whole week doing GNOME stuff
[14:18] <seb128> lool: understood, thank you for the GNOME work on did ;-)
[14:32] <fta> seb128, regression with nautilus. custom icons on directories (on the desktop) are replaced by a white/gray page (instead of the picture)
[14:38] <lool> seb128: I reviewed vino's proposed upload, it was a bit disappointing
[14:41] <lool> seb128: pushed libwnck 2.23.91
[15:00] <pitti> seb128: yay seahorse gpg agent \o/
[15:04] <alex-weej> i've a question
[15:04] <alex-weej> who is the "kernel team"?
[15:04] <alex-weej> actually, launchpad!
[15:07]  * RainCT remembers mvo that his branch is ready for merging (I finished the "another update manager is running" stuff which I still wanted to do yesterday) :)
[15:08] <mvo> RainCT: great, thanks! but we are still in archive freeze :)
[15:19] <robertj> hello all, can someone point me to any info on Canonical's hardware regression testing?
[15:51] <thvdburgt> I have a question, I'm testing intrepid right now and when I open something I downloaded via the firefox download-dialog it does not respect my 'Open With' settings. Why isn't gnome-open or something similar used for this (I understand this opens it with the preferred operation)?
[15:52] <ScottK> thvdburgt: You might have more luck with that question in #ubuntu-mozillateam
[15:53] <thvdburgt> Thank tou ScottK, I'll ask there?
[15:53] <asdasdas> hi, when the iso for alha 5 willl be available?
[15:55] <asdasdas> I mean alpha 5
[16:13] <ScottK> jdstrand: Do we want to recommend apparmor in clamav or suggest it?  Since we ship it by default, if a user has removed it, I think it's a little unfriendly to bring it back when they install clamav.
[16:16] <jdstrand> ScottK: that could be said of any software with Recommends. I believe that it would be highly unusual to have an Ubuntu system without apparmor installed. That said, the ApparmorProfileMigration was developed before Recommends were turned on by default, and I don't have a particularly strong opinion about Suggests vs Recommends
[16:16] <pitti> ScottK: personally I'd Suggests: it
[16:16] <pitti> ScottK: Recommends: is very strong nowadays, and clamav works perfectly fine without AA
[16:17] <jdstrand> ScottK: btw, after more than a month of use, of course *today* (right after uploading the debdiff), my production server compalined and needed an adjustment
[16:17] <ScottK> jdstrand: I think suggests because apparmor or no apparmor is a global system decision.  It's not specific to clamav.
[16:17] <ScottK> jdstrand: OK.  I'm just reviewing the patch now.
[16:17] <jdstrand> both you and pitti make a good point-- I'll adjust the wiki
[16:17] <ScottK> jdstrand: Does /tmp need to be in the profile?  I thought we patched clamav to not use it.
[16:18] <jdstrand> ScottK: is that new to Intrepid?
[16:18] <ScottK> No.
[16:18] <jdstrand> (cause hardy certainly needs it-- it was a file in /tmp that cause AA to complain)
[16:18] <ScottK> The upstream code uses /tmp, but I thought we had patches to use /var for everything.
[16:18] <ScottK> OK.
[16:19] <ScottK> jdstrand: Do you know what file?  It may be updating the patch to not use /tmp is what's needed.
[16:19] <jdstrand> ScottK: can you use the files on a production hardy server somewhere in complain mode, and forward me any complaints?
[16:19] <lool> seb128: pushed vino 2.23.91
[16:19] <ScottK> jdstrand: I can.  How about you send me your update first?
[16:19] <jdstrand> kernel: [1349877.940962] audit(1220610317.840:79): type=1503 operation="file_lock" requested_mask="k::" denied_mask="k::" name="/tmp/clamav-45625f80857577367ff15bc472e13446/.dbLock" pid=4903 profile="/usr/sbin/clamd" namespace="default"
[16:20] <jdstrand> ScottK: the change is simply:
[16:20] <jdstrand> /tmp/** krw,
[16:20] <jdstrand> (it was 'rw')
[16:22] <mpt> pitti, I'm resuming work on the Hardware Drivers design now
[16:22] <pitti> mpt: good morning; great!
[16:23] <ScottK> jdstrand: Looks like that one's not settable in the conf file, so we'll need /tmp.
[16:24] <Riddell> cjwatson: I think I've got oem-config sorted for KDE 4 now, shall I upload or do you want to look at it?
[16:24] <ScottK> jdstrand: OK.  Got it.  I'll try to do some testing and get back to you.
[16:25] <jdstrand> ScottK: great!
[16:25] <mpt> pitti, what's the maximum number of drivers likely to be shown in this window?
[16:25] <mpt> at one time, I mean
[16:25] <jdstrand> ScottK: my little production server isn't too busy (and doesn't use amavisd-new), so the testing is much appreciated
[16:25] <pitti> mpt: hard to tell, but I guess you'd not have more than ten
[16:26] <jdstrand> (and I really just smoke-tested amavisd-new, as you know_
[16:26] <pitti> mpt: usually maybe two or three (graphics card, wifi, printer)
[16:26] <mpt> ok
[16:26] <ScottK> jdstrand: Right.  Well I think for amavisd-new it would either be just fine or not work at all.
[16:30] <cjwatson> Riddell: feel free to commit it; best not to upload yet, though, as technically we're still in milestone freeze
[16:34] <pitti> Riddell: hm, your jockey kde4 merge apparently broke the test suite for run-kde4 heavily; did you patch that out of do-release or so?
[16:34] <pitti> Riddell: anyway, fixing now
[16:35] <mpt> pitti, is it true that drivers will sometimes be installed via this window, but never uninstalled?
[16:36] <pitti> mpt: no, you can uninstall them there, too; the "Enable" button will turn into "Disable" for installed drivers
[16:36] <mpt> or are drivers uninstalled if you deactivate them?
[16:36] <pitti> mpt: well, "depends"
[16:36] <pitti> mpt: if enabling a driver entailed installing a package, disabling will uninstall that package again
[16:36] <mpt> ah
[16:37] <pitti> mpt: if we already ship the driver in our kernel, and the user disables it, it just gets blacklisted
[16:37] <pitti> (e. g. because the user doesn't want non-free drivers)
[16:37] <pitti> mpt: in general, disabling in jockey will undo all effects that enabling did
[16:37] <mpt> So, activating a driver will sometimes require Internet access because it needs installing from there
[16:37] <mkrufky> where can i find the licenses for the firmware images shipped in /lib/firmware/`uname -r`/ ?
[16:38] <alex-weej> anyone know what needs to be fixed in order for "coretemp" to be automatically loaded on my system (to get sensors)?
[16:38] <pitti> mpt: right
[16:38] <alex-weej> i've a bug open against linux, doesn't seem to be going anywhere though
[16:38] <pitti> mpt: or an Ubuntu CD, any apt package source; but in general this will be the internet
[16:51] <pitti> Riddell: is there a pyqt/pykde equivalence for: gobject.timeout_add(1000, self.ui.on_quit)
[16:51] <pitti> Riddell: i. e. the passed function will be called after one second?
[17:00] <cody-somerville> How do I add a new e-mail address to an existing gpg key?
[17:01] <pitti> cody-somerville: gpg --edit-key, then adduid
[17:02] <pitti> cody-somerville: seahorse has a nice UI for this -- "Add Name"
[17:02] <geser> cody-somerville: don't forget to send the key to the keyservers afterwards
[17:03] <pitti> have a nice weekend everyone!
[17:03] <cody-somerville> \o_
[17:03] <Riddell> pitti: yes
[17:03] <geser> pitti: you too
[17:04] <Riddell> QTimer.singleShot(1000, self.foo)
[17:04] <pitti> Riddell: rock, thanks
[17:04] <vinu76jsr> new on this
[17:04] <vinu76jsr> where to start
[17:05] <pitti> Riddell: that's not from PyKDE4.kde{core,ui} (I'm working on jockey tests/run-kde)
[17:05] <tseliot> pitti: that's qt4 not kde4
[17:06] <pitti> Riddell: right, but from PyQt4 import QTimer doesn't work either
[17:06] <pitti> ah, PyQt4.Qt.QTimer
[17:06] <vinu76jsr> not a place to ask ! sorry developers!!!
[17:07] <tseliot> pitti: PyQt4.QtCore.QTimer I guess
[17:07] <pitti> Riddell: rocking, that works, and fixes the segfault I'm getting when using gobject's timer
[17:07] <pitti> tseliot: yep, thanks
[17:07] <Riddell> yay
[17:08] <tseliot> Riddell: doesn't KDE4 have a suspend button?
[17:08] <Riddell> tseliot: how do you mean?
[17:08] <pitti> ok, really off now, I'm late
[17:08] <tseliot> Riddell: so as to suspend my laptop (as in suspend/resume)
[17:09] <tseliot> I can see log out, shutdown but no suspend button
[17:09] <Riddell> tseliot: either right click on the battery icon (guidance-power-manager) or on the logout dialogue the confusingly hidden hold mouse button on Turn Off
[17:10] <Riddell> it was in our intrepid plan to tidy up the logout dialogue but it hasn't happened thus far
[17:10] <tseliot> Riddell: ah, ok, thanks
[17:12] <cjwatson> vinu76jsr: see http://wiki.ubuntu.com/ContributeToUbuntu
[17:16] <vinu76jsr> thanx
[17:28] <calc> how is alpha 5 going?
[17:28]  * calc is waiting to upload new OOo 2.4.1 w/ openjdk until its safe
[17:44] <seb128> lool: thanks
[17:47] <mpt> pitti, e-mailed you a new mockup
[17:59] <kees> seb128: thanks for the heads-up, I will investigate.
[18:00] <seb128> kees: thanks
[18:01]  * kees wonders if there is still some bug sneaking around in the troublesome libxml2 update.
[18:10] <kees> seb128: I cannot reproduce the issue.  Additionally, the 2nd comment seems to indicate it wasn't libtiff4 (and I see no new bugs for libxml2)
[18:10] <kees> I wonder if something else is going on?  I will try again on 64bit...
[18:11] <seb128> kees: it's obviously not happening to everybody or we would have received lot of bugs, but 2 bugs mentionning libtiff just after the update seems a weird coincidence so I prefer to point it
[18:11] <seb128> kees: could be trigger by some applet used or something dunno
[18:12] <seb128> the bugs don't have so many details
[18:13] <kees> seb128: yeah, it makes me worry a bit too.  I'll try to get more details
[18:47] <jdstrand> kirkland: so I'm sure you've probably heard all kinds of arguments for and against auto-umount
[18:48] <jdstrand> kirkland: one thing I might point out that may influence your decision is that I had my ~/Private directory auto-umounted
[18:48] <jdstrand> then I tried to start firefox (I moved the .mozilla dir to ~/Private and symlinked it)
[18:49] <jdstrand> this totally made ff not start at all
[18:49] <jdstrand> apparently, firefox checks for .mozilla, but gets confused cause it's a broken symlink
[18:50] <jdstrand> kirkland: if we start recommended ecryptfs for things like .mozilla, .ssh and .gnupg, then this will at the very least need to be documented
[18:51] <jdstrand> kirkland: or somehow make it smarter so that it only auto-umounts when logging out from the session that was used to auto-mount it
[18:52] <jdstrand> kirkland: eg, login via gdm, logout of gdm auto-umounts it...
[18:52] <jdstrand> kirkland: what do you think?
[18:53] <jdstrand> (and by not start at all, I mean there was no feedback as to what happened-- I had to strace ff)
[18:58] <kirkland> jdstrand: actually, i'd like to use a trigger, like inotify or some such to auto-mount on demand, when necessary
[18:58] <kirkland> jdstrand: but I don't know inotify well enough to hack that just yet
[18:58] <jdstrand> kirkland: assuming that can be done safely and reliably, that would be cool too
[18:59] <kirkland> jdstrand: as for the documentation, i absolutely agree
[18:59] <kirkland> jdstrand: i will create an Encrypted Private "Best Practices" wiki page prior to Intrepid release
[18:59] <kirkland> jdstrand: with some do's and don'ts
[19:00] <kirkland> jdstrand: one really nasty gotcha is moving .ecryptfs into Private
[19:00] <jdstrand> kirkland: sounds good-- you might mention the caveats/workarounds for things like the firefox issue I had
[19:00] <kirkland> jdstrand: that's VERY BAD NEWS
[19:00] <kirkland> jdstrand: true, i'll sign you up for review of that documentaiton
[19:00] <jdstrand> sure
[19:01] <calc> slangasek: ping
[19:05] <slangasek> calc: pong
[19:05] <calc> slangasek: how's the a5 freeze coming? :)
[19:05] <calc> i didn't see the announcement go out yet so i assume its still frozen anyway
[19:08] <calc> "Options
[19:08] <calc> * More About Barton * Less About Barton
[19:08] <calc> * More Status Stories * Fewer Status Stories
[19:08] <calc> Options
[19:09] <calc> Barton George | After 13yrs, today is Barton's last day at Sun. Its been a blast! (taking Sat & Sun off before I start the new job on Monday :)."
[19:09] <calc> hmm copy & paste on facebook embeds stuff you don't see (garg)
[19:09] <calc> sorry about the several lines of crap
[19:11] <Treenaks> calc: some PDFs do that as well (from evince)
[19:12] <Treenaks> I've gotten into the habit of test-pasting in a spare terminal
[19:12] <calc> Treenaks: yea :-\
[19:18] <slangasek> calc: I haven't seen anything blowing up, so I think you're ok to upload now; a5 should be out very shortly
[19:19] <Treenaks> hm, I think some timer is going bad on my box:
[19:19] <Treenaks> 28161 martijn   20   0  781m  97m  25m S    1  2.5  1708779h rhythmbox
[19:20] <calc> slangasek: ok thanks! :-)
[19:28] <emgent`nl> heya
[19:40]  * calc uploading OOo 2.4.1-8ubuntu1 now
[19:45] <slangasek> superm1|away: "describe how it's used" - you mean from a developer's perspective?  I think we want this to be end-user-oriented, so yeah
[19:46] <jdong> calc: so that means the rest of us (tm) can't build anything for a few days, right? :)
[19:54] <toresbe> Hello. I have what appears to be a kernel bug where the kernel fails to see my PATA disks. I will report it to Launchpad, but is there anything anyone would suggest I do, either to address the problem, or to supply meaningful additional info to the bug report?
[19:54] <toresbe> I've already got dmesg, lspci -vvv and fdisk -l in.
[19:55] <calc> jdong: there are three buildds per arch iirc
[20:10] <tseliot> slangasek: if you're referring to DKMS, can I have a look at what you prepared for the release notes?
[20:11] <mvo> RainCT: hello, are you around?
[20:13] <slangasek> tseliot: https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview#DKMS
[20:14] <slangasek> tseliot: s/release notes/technical overview/
[20:15] <tseliot> slangasek: it looks good to me
[20:16] <tseliot> slangasek: are you going to add a warning about the NVIDIA and ATI drivers in the Known Issues section?
[20:17] <slangasek> tseliot: I'm not writing anything up for alpha-5; that's on the list of things to document for the release notes for final, if it remains unresolved
[20:17] <tseliot> slangasek: ok, it makes sense. Let's wait until the final release
[20:23] <mvo> RainCT: I merged your apturl changes, many thanks, excellent work! please re-merge, there is a minor correction I did
[20:34] <slangasek> _MMA_: there still don't appear to have been any successfully completed tests of UbuntuStudio for alpha-5; I'm going to release the others, and if Studio gets some testing, it can be pushed out after
[20:56]  * calc fixed his upload problems :)
[20:58] <slangasek> you shrank the OOo code to < 5MB?
[21:00] <jdong> slangasek: mv abiword openoffice.org? :)
[21:01] <ion_> LyX! :-)
[21:02] <jdong> vi!
[21:04] <tech404> Does anyone know if/why util-linux is still using volid? The change log suggests that the maintainers plan to move to blkid for intrepid but I can't find much more info on it. Is there a reason we have decided not to stay with debian on this one?
[21:55] <slangasek> superm1: mythbuntu also not included in alpha-5 yet, but I'm holding the cronjob if you want to test it and let me know it's ok to release
[21:56] <superm1> slangasek, yeah one of our people should be pulling it to test
[21:56] <superm1> i'll let you know
[22:07] <cjwatson> slangasek: I did a very basic but successful ubuntustudio test, fyi
[22:07] <cjwatson> only just had a chance to tell iso.qa about it
[22:08] <_MMA_> cjwatson: Ill be doing one in about an hour. I had to scrounge some real HW to use 'cause of Vbox issues.
[22:09] <cjwatson> hey, the ubuntustudio gdm screen is pretty classy
[22:09] <_MMA_> :P
[22:09] <cjwatson> not sure I like the desktop theme as much, never been much of a metal kind of guy
[22:10] <cjwatson> err, I meant to say brushed-metal, damned lag
[22:10] <slangasek> cjwatson: ah, ok, great
[22:10] <slangasek> (.oO brushed-hiphop)
[22:11] <_MMA_> Well, it's more in line with pro multimedia apps (the dark theme). That's our target audience. :) Brushed metal? The wallpaper has a hex pattern to it atm. :)
[22:13] <cjwatson> I'm not sure I'm using the right term, it's just what it reminds me of. :)
[22:13] <_MMA_> :)
[22:13] <cjwatson> anyway, I'm not so much your target audience
[22:15] <_MMA_> Sure. ;)
[22:16] <_MMA_> cjwatson: Thanx for the test btw.
[22:16]  * NCommander has found MIPS hardware
[22:16] <NCommander> Wooo
[22:22] <calc> doko: is openjdk-6 known to work properly on sparc?
[22:22] <calc> doko: OOo failed to build using default-jre due to:
[22:22] <calc> Checking DLL ../../unxlngs.pro/lib/check_libofficebean.so ...: ERROR: libmawt.so: cannot open shared object file: No such file or directory
[22:22] <calc> not sure what caused that error though
[22:22]  * calc will see how the other buildds react over the next few hours
[22:26] <kees> pitti, slangasek, NCommander: I seem to have been missing from an important conversation.
[22:27] <kees> through the magic of backlog temporal shift...
[22:27] <kees> 06:22 < NCommander> slangasek, 15% of main alone FTBFS due to PIE/non-PIE linkages
[22:27] <kees> I don't believe that to be true at all.
[22:27] <kees> there are tons of reasons things don't compile with PIE.
[22:27] <kees> 06:32 < NCommander> slangasek, at least you confirmed for me the -fPIE issues weren't quite so bad as kees made them sound to be
[22:27] <kees> I'm not sure I ever said it was "so bad".  I just said we needed to carefully examine the .a file usage.
[22:28] <kees> 06:36 < NCommander> slangasek, every executable still needs to be rebuilt with -fPIE
[22:28] <kees> no need for "needs".  It'll all happen naturally.
[22:28] <kees> 07:14 < pitti> do we actually need that new arch in soyuz? that's a quite expensive operation; wouldn't a local archive do as well?
[22:28] <kees> a separate arch would be massive overkill
[22:28] <doko> calc: please check that the correct pathes are used. it's likekey that OOo hardcodes something. this file lives in an arch specific dir
[22:28] <NCommander> kees, we decided that :-)
[22:28] <kees> 07:18 < slangasek> it shouldn't be that difficult, the static libs that need to be built should be identifiable by visual inspection
[22:28] <kees> and, yeah, that's what I said.  :P
[22:29] <NCommander> Can I say that this conversation happened early this morning when I should have been alseep?
[22:30] <kees> haha
[22:31] <kees> well, it happened while I _was_ asleep.  I just want to speak for myself is all.
[22:56] <ion_> pitti, tkamppeter: http://heh.fi/patches/cups/01-pstopdf-ppd-settings
[22:58] <ion_> pitti, tkamppeter: Updated
[23:09] <tkamppeter> ion_, looks OK for me. pitti has probably already left for today.
[23:11] <tkamppeter> ion_, for the question you asked me in private, CUPS does not have a PPD parser to be used from scripts.
[23:12] <ion_> Yeah, i noticed the answer, thanks
[23:12] <ion_> It works with the sed hack, it’s just ugly. :-)
[23:20] <cameronh> i need to restart avahi-daemon every few minutes or else it stops working (ping blah.local elsewhere won't respond, broadcast shares won't pick up)
[23:42] <lool> Kudos to the release team for the a5 release
[23:49] <mdke> yes, intrepid is looking pretty nice already
[23:51] <ion_> tkamppeter: I’m not sure any changes are needed in testprint.ps. If someone *really* wants the printer to run the code, she’s free to nc printer 9100 <testprint.ps