[00:00] <YokoZar> kees: Do you remember that initial memory access stuff we talked about at UDS-boston?
[00:01] <YokoZar> kees: I think you looked over my shoulder and saw a bug report ~ Wine and being unable to nab the early memory range (https://bugs.edge.launchpad.net/ubuntu/+source/wine/+bug/114025)
[00:02] <YokoZar> Well, now that the kernel change is in Hardy...it's breaking Wine (namely 16 bit apps).  I'm still trying to figure out a good way to fix it without disabling the setting entirely when Wine is installed (I just put out an email to ubuntu-devel) about it.
[00:02] <YokoZar> kees: Forgive me if I'm confusing you with someone else, by the way ;)
[00:03] <kees> YokoZar: you've got the right person.
[00:03] <kees> YokoZar: basically, 16bit apps shouldn't all need that memory space.
[00:04] <sistpoty> heh, I just wanted to write that this sounds like the crack kees is into ;)
[00:04] <kees> :)
[00:06] <YokoZar> kees: I'm not exactly sure how Wine handles that memory space, or if there's some sort of virtual memory workaround upstream could eventually do
[00:06] <kees> YokoZar: and 32bit apps should almost never need it
[00:06] <YokoZar> kees: yes, even without the setting running 32 bit apps still works in Wine just fine
[00:06] <kees> YokoZar: I think it can be worked around, but it's a little painful.  My thought has been that if someone needs to run a 16bit app that actually needs that memory area, just turn off the protections.
[00:07] <YokoZar> kees: I believe the trouble is Windows never made a proper separation in some instances, and a lot of 32 bit programs will invoke 16 bit instances of things, causing a potential crash in the middle rather than refusal to run outright.
[00:08] <sistpoty> kees: are we talking about virtual addresses there? if so, any pointer why it's disable in the first place?
[00:08] <YokoZar> kees: The other trouble, of course, is that it's still hard to turn off protections and we have no easy way of doing it (or, for that matter, figuring out if it will be needed before running the application)
[00:09] <kees> sistpoty: unfortunately while it is technically virtual (i.e. not mapped to physical location), the kernel and userspace tools use the same memory address space.
[00:09] <kees> YokoZar: I'm not aopposed to turning it off if someone install wine in general.  Just finding a good way to manage it I think is the key.
[00:10] <sistpoty> kees: ah thanks
[00:10] <kees> YokoZar: I think newer procps (the package that does /etc/sysctl.conf) has an /etc/sysctl.d directory now, so maybe we can do something with that.
[00:10] <YokoZar> kees: Yeah.  my thought was to have an (optional) "turn-it-off" package that turns it back on when removed
[00:10] <kees> sistpoty: yeah, I find it confusing and slightly alarming, but that's how it is.  :(
[00:10] <YokoZar> And then have Wine depend (or I guess recommend that)
[00:11] <sistpoty> kees: I always though kernel would use quite a high address space, but tbh I never looked nor cared *g*
[00:11] <kees> sistpoty: it does, it uses (on i386) the range from 3 to 4G
[00:11] <kees> YokoZar: yeah, let me check on procps and get back to you about how we might best approach it.
[00:12] <YokoZar> kees: Thanks a lot :)
[00:12] <kees> YokoZar: np, thanks for poking me about it.  :)
[00:12] <sistpoty> kees: oh, but where is it shared then?
[00:13] <kees> sistpoty: it's the address space that's shared.  i.e. memory address 0x0 is visible to the kernel.
[00:13] <kees> so if it gets mapped by a userspace process, the kernel may access it on a NULL deref.
[00:14] <sistpoty> kees: I, I see, thanks for the insihgt
[00:14] <sistpoty> (h<->g)
[00:15]  * kees nods
[02:33] <emgent> hello people
[03:06] <tiglionabbit> with python-xml moved, I can't use Gogh.  The workaround isn't working for me
[03:07] <LaserJock> tiglionabbit: what package is that from?
[03:08] <tiglionabbit> python-xml
[03:08] <tiglionabbit> is the package I want to use
[03:08] <tiglionabbit> Gogh is not in the repositories
[03:08] <tiglionabbit> https://bugs.launchpad.net/ubuntu/+source/python-xml/+bug/215723
[03:08] <LaserJock> ah, that's why I couldn't find it
[03:08] <LaserJock> :-)
[03:09] <tiglionabbit> http://www.goghproject.com/
[03:10] <tiglionabbit> I tried the workaround in the terminal, but I still can't import xml.dom.ext.  What am I to do?
[03:12] <LaserJock> tiglionabbit: hmm, maybe you could email the gogh author?
[03:12] <LaserJock> unless some smart Python person has any better ideas
[03:12] <LaserJock> ScottK: you around?
[03:13] <tiglionabbit> well, considering it works on any other distribution...
[03:13] <tiglionabbit> I was hoping there would be a solution to this
[03:14] <tiglionabbit> I asked in #python and they thought ubuntu was silly for doing this
[03:14] <LaserJock> hehe
[03:15] <LaserJock> I don't have any specific knowledge of the python-xml stuff
[03:16] <LaserJock> but my guess would be that the gogh author might have some idea of what specifically is going on
[03:17] <cody-somerville> Hey
[03:19] <tiglionabbit> urk, how do I import this
[03:19] <pwnguin> well, languages are in motion; if you dont tread water, the project will drown
[03:19] <pwnguin> drownd
[03:19] <tiglionabbit> you don't have to throw away code just because it's old
[03:20] <pwnguin> sure, you can port it forward
[03:20] <pwnguin> assuming it wasnt built on a philosophy the language depricates
[03:20] <tiglionabbit> I just want to know how to import it on ubuntu
[03:21] <pwnguin> i have no specific python knowledge, but often times development stuff is stored in -dev packages?
[03:22] <cody-somerville> tiglionabbit, If you send me an e-mail I promise to look into the issue for you.
[03:22]  * cody-somerville has to jet atm.
[03:22] <tiglionabbit> what's your email?
[03:22] <pwnguin> somerville32@ubuntu.com?
[03:23] <cody-somerville> cody-somerville@ubuntu.com
[03:44] <grandy> hello, has anyone written upstart config for a custom daemon?  just looking for some advice
[03:47] <pwnguin> Is there a way to query the HW database or ubuntu.com weblogs for information on display sizes and DPI?
[03:59] <emgent> slangasek: ping
[03:59] <slangasek> moo
[03:59] <emgent> slangasek: take a look Bug #247612
[04:03] <slangasek> emgent: seen it
[04:05] <emgent> slangasek: thanks.
[04:06] <slangasek> emgent: given that all the relevant folks are already gone for the weekend (some of them traveling), I think this will probably wait until Monday
[04:08] <emgent> i think so
[04:10]  * emgent love mod-security
[07:55] <cjwatson> (pp Steve, at least as far as I can tell :-) )
[08:07] <slangasek> oops, yes :)
[08:32] <halex> win 25
[08:32] <halex> Oh, grrr.
[09:05] <jpds> halex: /script exec for (1 .. 200) { Irssi::command("/alias $_ window goto $_") }
[09:06] <halex> jpds: oh, neat. Danke.
[09:06] <jpds> halex: Bitte.
[11:07] <gnomefreak> tseliot: if you are around, why does the new nvidia-glx-173 (im sure not only that version) once modules are built system plays the gnome login sound but never restarts gnome session? is this a bug or a feature?
[11:08] <tseliot> ﻿gnomefreak: it's a bug but not in the driver or in the package
[11:08] <tseliot> and it's not supposed to restart anything
[11:08] <gnomefreak> tseliot: oh ok thanks. i only notice it after friver update thats why i thought it was nvidia drivers
[11:09] <gnomefreak> it doesnt restart it but it plays the sound as if you loged in
[11:09] <tseliot> yes, I know. It would be interesting to find the cause of the problem.
[11:09] <gnomefreak> tseliot: agreed
[11:11] <gnomefreak> if i knew what package triggers it than i might beablet to track down the cause but finding the package is hardest part
[11:51] <bigon> shoudn't v86d be installed by default as it seems to be needed by the uvesa driver?
[12:05] <cjwatson> bigon: yes, there's a bug on (I think) linux-meta about it
[12:05] <bigon> oh ok
[12:11] <cody-somerville> cjwatson, I'm having some trouble regenerating the xubuntu meta package.
[12:11] <cody-somerville> cjwatson, for some reason it seems to be skipping i386 and amd64, lol
[12:18] <cjwatson> cody-somerville: can you send me mail describing the problem? I'll certainly look at it
[12:21] <cody-somerville> cjwatson, thanks
[12:30] <cody-somerville> cjwatson, odd, I've seemed to have managed to fix it but I'm not sure what I did, lol
[12:36] <sjoerd> 89/topic
[12:42] <sjoerd>        
[12:47] <emgent> good morning
[14:35] <savvas> if I want to create i386 package using a ubuntu amd64 I just use debuild -us -uc -a ?
[14:36] <savvas> -ai386 *
[14:36] <savvas> ?
[14:54] <cjwatson> savvas: no, not reliably and not without some other setup (32-bit development libraries etc.). It would be better to create an i386 chroot.
[14:54]  * ogra sighs about ubuntu-users 
[14:54] <cjwatson> savvas: debootstrap --arch=i386, or pbuilder --debootstrapopts --arch=i386
[14:55] <wgrant> ogra: Anybody installed XFree86 lately?
[14:55] <cjwatson> (in the latter case, just at the create step)
[14:55] <savvas> thanks cjwatson
[14:56] <ogra> wgrant, nah, a guy who doesnt manage to stop insulting people ... he triggered https://lists.ubuntu.com/archives/ubuntu-users/2008-February/137100.html in feburary and just starts over to call people assholes, wankers and tells then STFU
[14:56] <ogra> s/then/them/
[14:56] <wgrant> Oh dear.
[16:13] <alex-weej> any ideas how i've managed to get a "(now)" available version for a package in synaptic when it isn't even installed?
[16:13] <alex-weej> i've a feeling something has broken in my dpkg database
[16:34] <cody-somerville> lovely, the new flash likes to crash my firefox
[16:35] <laga> how is that different from the old flash?
[16:36] <cody-somerville> laga, it just rendered transparency as opaque
[16:36] <cody-somerville> now it crashes
[16:36] <laga> heh :)
[16:36]  * highvoltage can't wait for free flash to mature
[16:36] <alex-weej> it won't happen
[16:37] <alex-weej> both gnash and swfdec have like 0.1 developers
[16:37] <laga> adobe needs to.. oh, is this channel logged?
[16:37] <laga> ;)
[16:37] <highvoltage> alex-weej: gnash actually has quite a few full-time, paid developers
[16:38] <alex-weej> but it's GNU
[16:38] <highvoltage> alex-weej: and recently Adobe has released a substantial amount of free-flash specs
[16:38] <highvoltage> alex-weej: and?
[16:40] <alex-weej> and... like... they have beards
[17:18] <IntuitiveNipple> When versioning for a PPA package upload, should the version number increment? E.g. with package-1.2.3 should it be package.1.2.3~ppa1 or package.1.2.4+ppa1. I ask this because a while back I found that Update was offering to replace installed package-1.2.3~ppa1 with package-1.2.3 but the docs I read at the time didn't make it clear
[17:30] <tormod> IntuitiveNipple: 1 < 2~ppa < 2 < 2+ppa
[17:30] <cjwatson> IntuitiveNipple: well, at the risk of stating the obvious, it depends whether you want the PPA to supersede what's in the regular archive or not :-)
[17:32] <cjwatson> IntuitiveNipple: usually you'd want it to be newer than anything in the release it's targeted for - so if 1.2.3 is in hardy and you're uploading to a hardy PPA, you'd want to use 1.2.3+ppa1, whereas if 1.2.3 is in intrepid and you're uploading to a hardy PPA, you'd want to use 1.2.3~ppa1
[17:32] <IntuitiveNipple> Thanks... I just found the answer in my launchpad-users mail folder from an email by Martin Schwenke on May 17th... his suggestions now added to the PPAQuickStart guide which, last time I'd looked this up, didn't have his updates
[17:32] <cjwatson> IntuitiveNipple: try to avoid making it greater than the expected next version in the normal archive
[17:32] <cjwatson> (hence 1.2.3+ppa1 rather than 1.2.4+ppa1)
[17:32] <IntuitiveNipple> cjwatson: I was mostly confused because logic seemed to say 1.2.3 < 1.2.3ppa lexically at least
[17:33] <cjwatson> and you can use dpkg --compare-versions to ask "is this version greater than that version?"-type questions
[17:33] <cjwatson> IntuitiveNipple: it is - "~" is magic though
[17:33] <cjwatson> $ dpkg --compare-versions 1.2.3 lt 1.2.3ppa && echo yes
[17:33] <cjwatson> yes
[17:34] <IntuitiveNipple> cjwatson: Yeah... hence the confusion... but my main reason for asking is, I'm trying to figure out how to do a custom kernel build on the PPA and get the versioning correct... the prepare-ppa-source does its own thing with the versioning specific for the 'main' kernel PPA
[17:34] <cjwatson> ah, now, the kernel is kinda weird with versioning
[17:35] <IntuitiveNipple> Yes, you see now why I'm trying to understand it!
[17:35] <cjwatson> although bear in mind that prepare-ppa-source may be partially intended for use by Ubuntu kernel team members who are preparing preview versions of the next kernel version along
[17:35] <cjwatson> personally, unless it was a backport from a later release, I'd just append "ppa1" or "+ppa1" and not worry about it too much
[17:35] <IntuitiveNipple> Yes, it is, I'm trying to figure out how others have managed to upload and build kernels correctly
[17:36] <cjwatson> the only real weirdness in the kernel versioning scheme is that it's UPSTREAM-ABI.REVISION
[17:36] <IntuitiveNipple> the entire kernel source preparation process is different to a regular package
[17:36] <cjwatson> so as long as you don't screw up ABI then it shouldn't make too much difference
[17:36] <IntuitiveNipple> yeah.. breaking the ABI is something I'm trying to avoid
[17:37] <IntuitiveNipple> The bug-fix works! I'm just trying to find a 'nice' way to make it available for testing
[17:37] <cjwatson> how to seriously confuse yourself by mistake: go to https://launchpad.net/ubuntu/+source/python-gtk2 rather than https://launchpad.net/ubuntu/+source/pygtk
[17:37] <cjwatson> "uh, hoary? what?"
[17:38] <IntuitiveNipple> lol yeah... there's a lot of 'legacy' stuff that often confuses me too
[17:38] <cjwatson> infinity: http://launchpadlibrarian.net/15978774/buildlog_ubuntu-intrepid-hppa.pygtk_2.12.1-6ubuntu1_FAILEDTOBUILD.txt.gz - is xvfb known-broken on hppa?
[17:38] <savvas> cjwatson: thanks for the pbuilder tip, building with it is increbidly easy and wonderful to manage cleaning up :)
[17:38] <cjwatson> you're welcome
[17:40] <savvas> one tiny problem though, could be neglected, but i used "--buildplace ." and it still made the resulting .deb packages in /var/cache/pbuilder/result/
[17:41] <cjwatson> afraid I don't know, I was just quoting the pbuilder equivalent to what I knew to work for debootstrap
[17:41] <cjwatson> if you think it's a bug, file it
[17:43] <savvas> I'll try it again a bit later, thanks
[17:44] <cjwatson> (I don't actually use pbuilder myself)
[17:45] <savvas> it's good for a playground :)
[18:03] <wattazoum> hello everyone
[18:04] <wattazoum> I am trying to use apport for non Ubuntu package (the project is hosted on Launchpad but not registered on the Ubuntu Distribution) . Is it possible ?
[18:07]  * bluefoxicy grabs alpha 2 to see if it's got compcache in it, and if it works.
[18:08] <cody-somerville> bluefoxicy, let me know what you find out
[18:08] <bluefoxicy> cody-somerville:  have you looked at the code?
[18:08] <cody-somerville> bluefoxicy, not since UDS
[18:08] <bluefoxicy> Coming from someone who could never read kernel code like this, it looks like a vanilla block device that self-initializes to swap space but doesn't enforce that.
[18:08] <bluefoxicy> so, I'll tinker with it.  Then swapoff and put a file system on it :p
[18:09] <bluefoxicy> also, imagine suspending with this thing active... XD
 resuming ................... wtf?

[18:13] <bluefoxicy> (actually in theory it would store the kernel memory for the device somewhere; however, it might realize it's SOMEHOW out of swap space during the suspend process)
[18:38] <cjwatson> bluefoxicy: ogra tested it and found that suspending with compcache active worked fine
[18:39] <cjwatson> I assume for hibernate there are the usual constraints of requiring a big enough swap partition
[18:39] <bluefoxicy> yeah
[18:41] <bluefoxicy> anyway trying to not kill myself while feeling around for voltage levels inside live high-voltage vacuum tube power amps, ttyl
[18:44] <ScottK> LaserJock: I'm around for a few minutes now.  More later today.
[18:44] <bluefoxicy> kernel panic - not syncing, attempt to kill the idle task!
[18:58]  * bluefoxicy rolls back to -17 in Hardy in virtual box so he has vboxadd.ko, because without it the damn thing locks up X on the host as soon as he starts playing a video.
[19:30] <cody-somerville> Can someone block the flash update? Firefox is crashing like crazy :/
[19:31] <savvas> in backports?
[19:32] <savvas> looks like i'm the only one not using backports :)
[19:32] <cody-somerville> savvas, seems like it :P
[19:33] <savvas> cody-somerville: sudo aptitude forbid-version flashplugin-nonfree :P
[19:35] <savvas> a person in ubuntuforums said that he was having problems with a flash site, and claimed backports were great and ok, when he reverted back to version 9 i had a good laugh when he said it was fixed :)
[19:35] <LaserJock> ScottK: nvm, it was a python-xml question somebody had last night
[19:39] <cody-somerville> There doesn't seem to be a regression policy for backports
[19:39] <cody-somerville> Should I just e-mail the TB like I would an SRU?
[19:42] <LaserJock> cody-somerville: I'd just talk to jdong or another backporter
[19:42] <cody-somerville> jdong, hey you :P
[20:16] <cody-somerville> Ugh... the phone calls have started :(
[20:19] <LaserJock> cody-somerville: dude, it's backports, it's expected to not work much of the time :-)
[20:20] <cody-somerville> LaserJock, Thats absolutely untrue
[20:20] <cody-somerville> On the wiki page it says:
[20:20] <cody-somerville> "A great deal of work goes into testing backports and it's highly unlikely for a backport to be a severe regression from the version it replaces."
[20:21] <cody-somerville> And I'm looking at the bug report for the backport (haven't read it all yet) but even before it was uploaded there were reports of the crashing.
[20:21] <LaserJock> right, well, that's why I don't run it
[20:21] <cody-somerville> Furthermore, the status of the bug doesn't indicate it was approved but I should know what happened in a second - lots of comments to go through
[20:22] <LaserJock> my understanding is that when you run development release packages on the stable release you should expect it to run roughly like the development release
[20:22] <tritium> cody-somerville: /etc/apt/sources.list words it differently
[20:23] <cody-somerville> tritium, what are you trying to say?
[20:24] <tritium> cody-somerville: what you pasted said a great deal of work goes into testing, whereas /etc/apt/sources.list contradicts that.  I'm not trying to say anything.  I'm pointing out the difference.
[20:26] <cody-somerville> tritium, Well, it almost seemed like you were suggesting that the comments in /etc/apt/sources.list would be common knowledge
[20:26] <tritium> cody-somerville: nope, I wasn't suggesting anything
[20:26] <LaserJock> well, presumabely they should be
[20:29] <cody-somerville> LaserJock, why would a user (for the common use case) read the contents of /etc/apt/sources.list over /user/include/getopt.h ?
[20:29] <LaserJock> I'm not saying they should read it
[20:29] <LaserJock> but *presumably* what is in sources.list should be common knowledge and consistent with what people are documenting
[20:30] <cjwatson> so is the problem that libflashsupport is in -backports?
[20:30] <LaserJock> i.e. sources.list should represent a fairly canonical source of information on the repos
[20:30] <cjwatson> seems to be what bug 235135 suggests
[20:30] <cody-somerville> cjwatson, no, I don't think so
[20:30] <cjwatson> cody-somerville: so is Alexander wrong in that bug?
[20:31] <cjwatson> hmm, seems to be inconsistent between users
[20:31]  * cody-somerville nods.
[20:32] <cjwatson> ScottK: should I remove flashplugin-nonfree and libflashsupport from -backports? I've only skimmed the bug and would like your say-so
[20:32] <cjwatson> ScottK: note that the only way to deal with users who have already upgraded is to upload a higher version, though
[20:33] <cjwatson> so this is purely prophylactic
[20:38] <cody-somerville> cjwatson, In his e-mail to -devel he says yes
[20:38] <cody-somerville> "I am aware (I approved the backport) and as soon as I get somwhere that
[20:38] <cody-somerville> lends itslef to a stable IRC presence (less than an hour) I intend to hunt
[20:38] <cody-somerville> down an archive admin and deal with it."
[20:39] <cody-somerville> Well... I suppose thats not exactly what he says, heh.
[20:41]  * cody-somerville is off to take a nap.
[20:42] <cody-somerville> Oh, luckily it appears Firefox already has a patch :)
[20:42] <YokoZar> cjwatson: can I trouble you to take a peak at https://bugs.launchpad.net/bugs/246118  ?  It got tagged verification-done but hasn't hit the archive yet
[21:27] <ScottK-laptop> Is there an archive admin in the house?
[21:39] <cjwatson> ScottK: hi
[21:39] <cjwatson> ScottK-laptop: you too
[21:40] <cjwatson> ScottK-laptop: so what should be done with flash?
[21:41] <ScottK-laptop> Hello
[21:42] <ScottK-laptop> My intent (if you agree) is to upload the hardy release versions to backports with a higher number so users naturally upgrade back to where they were.
[21:43] <ScottK-laptop> i.e. libflashsupport-1.9-0ubuntu2~hardy2~really1.9-0ubuntu1
[21:43] <cjwatson> ScottK-laptop: I think that's theoretically the best action, although the version number is going to be truly unfortunate
[21:43] <ScottK-laptop> Yes.
[21:43] <ScottK-laptop> I need a little time for testing.
[21:43] <cjwatson> just libflashsupport, or flashplugin-nonfree too?
[21:43] <ScottK-laptop> Both
[21:43] <cjwatson> more confusing for the latter, really
[21:43] <ScottK-laptop> nixternal reported that removing libflashsupport was not sufficient
[21:43] <cjwatson> 10.0.1.218+10.0.0.525ubuntu1~hardy2~9.0.124.0ubuntu2? oh man
[21:44] <ScottK-laptop> Yep.
[21:44] <ScottK-laptop> I don't see a better option though.
[21:44] <cjwatson> can we do hardy1+really, at least?
[21:44] <ScottK-laptop> OK.
[21:44] <cjwatson> just to reduce ~-confusion
[21:44] <ScottK-laptop> Fair enough.
[21:44] <cjwatson> no, I don't see a better option either - I said something similar above, but you may have been offline
[21:44] <cjwatson> 20:32 <cjwatson> ScottK: should I remove flashplugin-nonfree and libflashsupport from -backports? I've only skimmed the bug and would like your say-so
[21:44] <cjwatson> 20:32 <cjwatson> ScottK: note that the only way to deal with users who have already upgraded is to upload a higher version, though
[21:45] <cjwatson> 20:33 <cjwatson> so this is purely prophylactic
[21:45] <ScottK-laptop> Will you be around for a bit so I can ping you after I've tested.
[21:45] <cjwatson> ScottK-laptop: so, I'm about to be away for a week, so I'd like to go spend some time with my wife
[21:45] <cjwatson> ScottK-laptop: estimated time?
[21:45] <ScottK-laptop> ~30 minutes?
[21:45] <cjwatson> ok, I can check back in then
[21:45] <ScottK-laptop> Great.  Thanks.
[21:45]  * ScottK-laptop gets to work...
[21:48] <cjwatson> YokoZar: done
[22:04] <YokoZar> cjwatson: *hugs*
[22:11] <ScottK-laptop> cjwatson: They are both waiting for approval.
[22:12] <ScottK-laptop> 27 minutes instead of 30.
[22:16]  * ScottK-laptop tries to remember what he had planned to do with this free time with a laptop and wifi.
[22:23] <cjwatson> ScottK-laptop: accepted, thanks
[22:23] <cjwatson> if they build before :55, they'll be published by about 90 minutes from now
[22:24] <ScottK-laptop> cjwatson: Thank you.  Have some good time with your wife.  I'll keep an eye on them.