[00:36] <isamar> hi folks
[00:36] <isamar> needing a hand with custom install cd and ubuntu installer..
[00:36] <isamar> it's freezing when loading bash package.
[00:36] <isamar> no sure but looks like libncurses is not being loaded for some reason...
[00:37] <isamar> anyone?
[01:10] <DPic> Can somebody help move Empathy dependencies to main and change the desktop seed? https://bugs.launchpad.net/ubuntu/+source/telepathy-farsight/+bug/388898
[01:13] <Caesar> dtchen: ping?
[01:13] <Caesar> Why did you mark bug 192590 as "Fix Released"?
[01:13] <Caesar> I see no evidence of this being the case for Hardy
[01:17] <Ampelbein> Caesar: it is "Fix Released" because it is fixed in the development version, karmic koala. See https://wiki.ubuntu.com/StableReleaseUpdates for info on how to request an update for previous versions of ubuntu.
[01:18] <Caesar> Ampelbein: did you look at the bug in question?
[01:19] <ScottK> Caesar: What bug it is doesn't change the fact that Hardy isn't relevant for marking a bug fix released.
[01:19] <Caesar> ScottK: I suspect we're in violent agreement here
[01:20] <Caesar> Basically it looks like someone was preparing an SRU, possibly went dark, and then in the meantime someone marked the bug as Fixed
[01:20] <Caesar> Meanwhile, down on the Hardy ranch, the bug is still very much alive and well
[01:25] <Ampelbein> Caesar: the debdiff was submitted when hardy was still in development, there were some problems with it and the patch submitter didn't bother to do the changes requested. So now it's still broken in hardy, there you are right. If you want it fixed, I'm afraid you'll have to request a SRU.
[01:26] <Caesar> Right then
[01:26]  * Caesar digs out his SRU-making pants
[01:27] <Ampelbein> Caesar: you can check with one of the team members on irc first to see If they are likely to approve it: https://edge.launchpad.net/~ubuntu-sru/+members
[01:28] <billybigrig> does anyone know why the nvidia module won't build in dkms? i compiled the daily kernel from linus's tree...and installed the headers, source, and image, but dkms won't build the nvidia module
[01:28] <Ampelbein> billybigrig: any error message?
[01:28] <billybigrig> yeah
[01:28] <Ampelbein> billybigrig: care to share it?
[01:28] <billybigrig> sudo dkms add -m nvidia -v 185.18.14 -k 2.6.31-rc2-billybigrigger-07.13
[01:29] <billybigrig> err whoops
[01:29] <billybigrig> sorry
[01:29] <billybigrig> :(\
[01:29] <Ampelbein> ;-)
[01:29] <billybigrig> ya i care to share gimme a sec :P
[01:29] <billybigrig> Error! Bad return status for module build on kernel: 2.6.31-rc2-billybigrigger-07.13 (x86_64)
[01:29] <billybigrig> and then says consult make.log
[01:29] <billybigrig> so it says...
[01:30] <billybigrig> *** Unable to determine the target kernel version. *** make: *** [select_makefile] Error 1
[01:30] <billybigrig> sudo dkms build -m nvidia -v 185.18.14 -k 2.6.31-rc2-billybigrigger-07.13
[01:30] <billybigrig> that is the command i tried
[01:30] <TheMuso> billybigrig: How did you install the kernel headers, and where did you put them?
[01:31] <billybigrig> linux-headers-2.6.31-rc2-billybigrigger-07.13_2.6.31-rc2-billybigrigger-07.13-10.00.Custom_amd64.deb
[01:31] <TheMuso> billybigrig: How did you build the kernel?
[01:31] <billybigrig> CONCURRENCY_LEVEL=3 time fakeroot make-kpkg --initrd -append-to-version=-billybigrigger-07.13 kernel_image kernel_headers kernel_source > ~/make.log 2>&1 && git reset --hard origin/master && git clean -xdf && git pull
[01:32] <billybigrig> from a git clone of linus's tree
[01:32] <TheMuso> And you only had one headers package get built? Did that package create a build symbolic link in /lib/modules/kernelversion?
[01:33] <billybigrig> billybigrigger@cabo:/lib/modules/2.6.31-rc2-billybigrigger-07.13/build$ ls
[01:34] <billybigrig> you want to see the list?
[01:34] <TheMuso> Is there a symbolic link called build there?
[01:35] <TheMuso> If not, create a symbolic link called build, which links back to the headers directory for the kernel in /usr/src
[01:35] <billybigrig> im in build
[01:36] <billybigrig> billybigrigger@cabo:/lib/modules/2.6.31-rc2-billybigrigger-07.13$ ls
[01:36] <billybigrig> build is cyan colored when i ls
[01:36] <billybigrig> im pretty sure thats a symlink isn't it?
[01:36] <billybigrig> lrwxrwxrwx 1 root root     30 2009-07-13 16:40 build -> /home/billybigrigger/linux-2.6
[01:36] <billybigrig> yeah so thats right
[01:37] <TheMuso> Ok. Where did the headers package install the header files? In /usr/src?
[01:38] <billybigrig> yes
[01:38] <TheMuso> I suggest changing the build symlink to point to that directory where the headers are instead.
[01:45] <billybigrig> sudo rm build && sudo ln -s /usr/src/linux-headers-2.6.31-rc2-billybigrigger-07.13/ build
[01:45] <billybigrig> ?
[01:45] <billybigrig> or is it build /usr/src/linux-headers-2.6.31-rc2-billybigrigger-07.13/
[01:46] <billybigrig> and i guess it would be build/ right?
[01:46] <TheMuso> no the former is correct
[01:46] <TheMuso> The /  is not needed
[01:48] <billybigrig> so /usr/src/xxxxx build
[01:48] <TheMuso> yep
[01:48] <billybigrig> lrwxrwxrwx 1 root root     55 2009-07-13 18:48 build -> /usr/src/linux-headers-2.6.31-rc2-billybigrigger-07.13/
[01:48] <TheMuso> man ln for more info
[01:48] <billybigrig> k
[01:48] <TheMuso> yep that looks fine
[01:48] <TheMuso> now try and run the dkms command again
[01:53] <billybigrig> nice
[01:53] <billybigrig> thanks TheMuso
[01:53] <billybigrig> nvidia, 185.18.14, 2.6.31-rc2-billybigrigger-07.13, x86_64: installed
[01:53] <billybigrig> is there a way to re-build all dkms modules?
[01:53] <billybigrig> i have a few and would rather not do them manually
[01:54] <billybigrig> a bunch of vbox stuff
[01:54] <billybigrig> like how dkms does its post-inst stuff after a kernel image install, where is that script located?
[01:54] <billybigrig> can't i just run that?
[02:00] <TheMuso> billybigrig: I don't know how thats done sorry.
[02:00] <TheMuso> man dkms may tell you however.
[02:01] <billybigrig> still cant boot that kernel
[02:02] <TheMuso> billybigrig: ah "sudo /etc/init.d/dkms_autoinstaller start kernelversion"
[02:03] <TheMuso> should do it
[03:50] <sleepster> I just need a kernel with CONFIG_HZ = 1000... I am using ubuntu server and the default kernel is set to CONFIG_HZ = 100... is there a pre-built kernel I could use with this option?
[03:51] <sleepster> or is there a way to use ubuntu server with the desktop kernel installed?
[03:51] <ScottK> You can install the desktop kernel and use it, but that's a support question and not a development question.
[03:53] <sleepster> ScottK: ah.. okaythanks
[04:06] <ScottK> Lovely.  Reliable and repeatable OOo crash in a document that has business sensitive stuff in it so I can't use it for a bug report ....
[04:07] <lifeless> \o/
[04:09] <StevenK> ScottK: But that's how it always happens ...
[04:10] <ScottK> Right.  It's not like I'm suprised.
[04:11] <ScottK> It's one of these fill-in the form and you can't change all these parts and it must be just so work document that is exactly the kind of thing that would be bugged.
[04:11] <ScottK> work/word
[04:11] <lifeless> morale of the story, don't use Oo. for anything you care about?
[04:11] <ScottK> What's your alternative that handles MS Office file formats?
[04:12] <ScottK> Everything else I know of sucks even more.
[04:12] <StevenK> I didn't think abiword or gnumeric handled the embedded stuff?
[04:12] <ScottK> I don't think so.
[04:13] <ScottK> Kwrite neither.
[04:13] <vanz> hi
[04:18] <ScottK> For a while I tried including an ODF copy with the MS Office copy of stuff I sent to customers to raise awareness.  Then $LARGE_CORPORATION's spam filter decided ODF was dangerous and must be blocked.
[04:19] <TheMuso> ouch
[04:19] <ScottK> I had a nice chat with their mail admins, but their spam filtering software was proprietary so all they could do is file a bug with the vendor.
[04:19] <ScottK> So then I decided not getting fired for not sending stuff was more important than raising awareness.
[04:51] <\sh> moins
[05:30] <pam> Does anyone know where is the official ISO build described? I need to test some changes to isolinux (assuming the karmic iso uses karmic's isolinux).
[06:49] <dholbach> good morning
[06:51] <JonDoe297> dholbach: good morning :)
[06:51] <dholbach> hey JonDoe297
[07:07] <pitti> Good morning
[07:07] <pitti> NCommander: retracer> just launchpadlib crashing with HTTP 500 errors a lot
[07:08] <StevenK> pitti: UNR (and Ubuntu) livefs builds are broken due to brasero and nautilus-cd-burner Conflict'ing, halp?
[07:11] <pitti> slangasek: re-added; hm
[07:12] <pitti> StevenK: hm, drop n-c-d?
[07:13] <pitti> StevenK: I think it was done as an upgrade cleanup
[07:14] <StevenK> pitti: We don't seed n-c-d
[07:15] <StevenK> piA nautilus             Recommends nautilus-cd-burner | brasero (>= 2.26)
[07:15] <StevenK> And I think germinate will always jump for the first
[07:16] <pitti> StevenK: ah, I guess the ubuntu desktop seeds seed brasero earlier than nautilus or so
[07:17] <pitti> StevenK: where did you see this, BTW?
[07:17] <pitti> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/latest/livecd-20090713-i386.out is differntly broken
[07:17] <StevenK> 0714
[07:17] <pitti> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/latest/livecd-20090714-armel.out is an evolution thingy
[07:18] <pitti> any/all desync, as it looks?
[07:18] <pitti> interesting, _all_ arches have a different failure
[07:18] <StevenK> Yeah, Ubuntu i386 hasn't tried yet
[07:18] <StevenK> Anyway:
[07:18] <StevenK> pi  ubuntu-netbook-remix Recommends rhythmbox
[07:18] <StevenK> pi  rhythmbox            Depends    libbrasero-media0 (>= 0.9.1)
[07:18] <StevenK> piA libbrasero-media0    Recommends brasero
[07:18] <pitti> so is this since yesterday then?
[07:19] <pitti> brasero was added ages ago
[07:19] <StevenK> Right, so UNR should seed brasero, too?
[07:19] <StevenK> I don't think that makes sense.
[07:20] <pitti> StevenK: oh, did you already NBS out libsgutils{1,2}?
[07:20] <StevenK> pitti: I've not done NBS in a week or so
[07:20] <pitti> I did the transition yesterday, but no NBSing yet
[07:20] <pitti> StevenK: we could just flip around the nautilus dep
[07:21] <StevenK> pitti: That works
[07:21]  * pitti uploads
[07:39]  * \sh should write a rant about klibc's ipconfig dhcp crap inside initramfs while using real network switches and not soho cheap table switches from netgear
[07:47] <pitti> kirkland: thanks muchly, this is so much better now
[07:51]  * mneptok is about to fly to Armonk and set IBM on fire
[07:52] <maco> question: if i have a debdiff for a package waiting for sponsorship to close one bug and i have another bug in that package that i want to fix, should i do the debdiff for this bug against the currently-in-karmic version or against the one that's waiting for sponsorship?
[07:52] <mneptok> and not happy, warming Yule log fire. ANGRY BALROG MOUTH FIRE!
[07:53] <maco> or just put one debdiff to do both?
[07:55] <\sh> maco: do one debdiff to do both...add both (LP: #<bugno>) to the changelog in the debdiff
[07:55] <maco> ok. ive been told before one bug per upload so wasnt sure
[07:57] <\sh> maco: TBH i don't think there is a policy or rule...but could be wrong..
[07:58] <maco> im gonna guess it was just a housekeeping thing. and with quilt, youve got plenty of housekeeping
[07:59] <maco> :( lp timing out
[07:59] <\sh> maco: btw...I added some links about the cult of virgin mary to mdzs blog .. just waiting until he moderates his comment area
[08:00] <dholbach> robert_ancell: you writing a gdm replacement? pitti said so! :)
[08:01] <pitti> ... configuration :)
[08:01] <dholbach> that's going to be headline news tomorrow
[08:01]  * robert_ancell feels thrown to the wolves :)
[08:02] <\sh> it's all about marketing ;)
[08:02] <robert_ancell> I've got the GUI mocked up and know the config to change.  The difficulty is navigating the policykit/dbus/... in between
[08:06] <maco> i didnt break quilt this time :D
[08:09]  * TheMuso kicks speech-dispatcher's autotools files where it hurts most, and leaves it for tomorrow. :)
[08:10] <StevenK> maco: Are you sure?
[08:11] <maco> StevenK, yes. quilt informed me that my patch level was wrong (forgot to add little a/ and b/ to --- and +++ lines) and then i push -a'd and it was happy
[08:11] <maco> i even remembered the QUILT_PATCHES env var
[08:11] <StevenK> quilt always curls up into a little ball when I mistreat it
[08:13] <maco> ive been actively using quilt for the last 2 weeks, so its soaking in
[08:14] <maco> though ive only got the routine down for quilt import so far. havent tried the start quilt, edit things, stop quilt thing yet
[08:14] <StevenK> All this mentioning of quilt is making me want to sob
[08:14] <maco> what if its the kind little amish women sew?
[08:15] <maco> i can go grab my needlecraft stuff to trick your brain...
[08:15] <StevenK> maco: I wasn't aware you were Amish
[08:15]  * StevenK hides
[08:15] <maco> my facebook profile used to list Amish as my religion
[08:16] <StevenK> Hah
[08:16] <maco> a scarily large number of folks believed it
[08:16] <maco> amish...facebook...amish...facebook...
[08:19] <\sh> twitter, facebook, youtube what product comes next to steal important life and working time
[08:20] <maco> is youtube newer than facebook?
[08:20] <maco> wait, twitter too?
[08:20] <\sh> in the beginning there was usenet ,-)
[08:21] <maco> heh
[08:21] <maco> hmm on the hundred papercuts thing. if youre just reporting a bug so youll have something to hang the debdiff on, is it worth marking it as a papercut?
[08:34] <pitti> maco: just subscribe sponsors, FWIW
[08:34] <pitti> maco: the papercut queue is pretty full, and IIRC David asked not to add more
[08:36] <maco> pitti, ok thanks
[08:47] <sbeattie> maco: a friend of mine lists his religion on facebook as chaotic good.
[08:48] <maco> hey mine currently says Church of Vi
[08:48] <maco> one friend asked what about my Pastafarianism. i said "polytheism"
[09:11] <cjwatson> pam: I just keep some canned runes around derived from how the CD image building stuff works ...
[09:11] <cjwatson> sudo mkisofs -r -V 'Ubuntu 9.10 i386' -o karmic-alternate-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-i386
[09:22] <ogra> pitti, my powermanager tends to crash after some time, is there a known bug for this ?
[09:23] <pitti> ogra: not to me, but I'm not regularly following them
[09:23] <ogra> hmm, k
[09:23] <pitti> ogra: yesterday's update fixed a bug which made gpm crash when the battery got full
[09:24] <ogra> ah, that might be it, though i rarely unplug at home and didnt actually monitor when exactly its happening ...
[09:25] <ogra> i have the brightness applet in my panel and notice that it is crossed out in the morning usually until i fire up the power prefs
[09:26] <ogra> nothing intresting in .xsession-errors ...
[09:26] <liw> .xsession-errors is a sucky logging facility...
[09:26] <pitti> ogra: no apport crash either?
[09:26] <ogra> (it would reallly help to have timestamps in that file)
[09:27] <ogra> nope, no apport
[09:27] <pitti> ogra: but perhaps it's fixed with yesterday's update
[09:27] <liw> ogra, http://blog.liw.fi/posts/userlog/ :)
[09:28]  * ogra runs an upgrade and will watch if it occurs again tomorrow morning
[09:28] <svqyqb> http://tinyurl.com/nkypfa
[09:28] <ogra> liw, :)
[09:29] <ogra> liw, sounds like something to spec next UDS to me
[09:29] <ogra> though i would be happy already if we had timestamps
[09:32] <maco> pitti, where does jockey get the text it displays explaining the driver it's offering?
[09:34] <maco> (i see you in (C) line)
[09:41] <maco> nevermind. i figured it out.
[09:54] <pitti> maco: ok :)
[10:22] <ogra> seb128, did you upload gtk and the apps out of order again ?
[10:22] <ogra> The following packages have unmet dependencies:
[10:22] <ogra>   gnome-icon-theme: Depends: libgtk2.0-bin but it is not going to be installed
[10:22] <seb128> ?
[10:22] <ogra> is what i see on armel
[10:22] <seb128> there is no order, gtk didn't change abi or soname or anything
[10:22] <ogra> hmm, strange
[10:22] <seb128> well that probably means that gtk didn't build on armel
[10:23] <ogra> i'll try a give back of evo and friends
[10:23] <pitti> arch all/any desync
[10:23] <seb128> and arch any and all binaries are out of sync
[10:23] <ogra> it isnt on the ftbfs list, i think its just a timing issue
[10:23]  * ogra gives back gtkhtml
[10:47]  * ogra grumbles at whoever gave back mesa on armel 
[10:56] <dholbach> james_w: did you say you have a fix for the harvest-django filter problem?
[11:02] <james_w> dholbach: a partial one
[11:02] <james_w> I have a better idea though
[11:02] <Keybuk> heh, I can't seem to edit bug titles in LP today
[11:04] <dholbach> james_w: I was just thinking "having the fix/workaround in trunk already would make testing and playing with it more interesting" :)
[11:04] <james_w> ok, ok :-)
[11:12] <ogra> hmm, why is pbuilder attempted to be built on the ports arches ?
[11:12] <ogra> Package: pbuilder
[11:12] <ogra> Architecture: all
[11:12] <ogra> weird
[11:14] <Quintasan> How should I deal with package that uses a src directory? When you untar the package there is only install.sh src/ and README. Pbuilder complains about missing CMakeLists.txt.
[11:16] <cjwatson> err that depends on what's in src/ :-)
[11:16] <cjwatson> basically your debian/rules build needs to do whatever the package says needs to be done to build its source code
[11:16] <cjwatson> there are no fixed rules
[11:16] <ogra> oh, hmm
[11:17] <ogra> Package: pbuilder-uml
[11:17] <ogra> Architecture: i386 amd64
[11:17] <Quintasan> cjwatson: it's a plasmoid, I use pkg-kde-tools for compiling it. I think DEB_SRCDIR = src might solve it
[11:20]  * ogra wonders why armel isnt respecting "Architecture: i386 amd64" in the control file
[11:21] <cjwatson> ogra: Packages-arch-specific controls what is *attempted*. if debian/control forbids it then of course it will fail
[11:21] <ogra> cjwatson, well, it even attempts to build pbuilder-uml in a local build
[11:21] <ogra> (on armel)
[11:22] <ogra> "Architecture: i386 amd64" should prevent that, shouldnt it ?
[11:23] <cjwatson> ogra: should it?
[11:23] <ogra> i would expect it to :)
[11:23] <cjwatson> you expect wrong :)
[11:23] <ogra> seemingly
[11:24] <cjwatson> ogra: whether a source package attempts to build one of its binary packages is controlled entirely by debian/rules, not by debian/control
[11:24] <cjwatson> after all it's just what debian/rules build / binary depend on
[11:24] <ogra> well, all pbuilder-uml stiff is in binary-arch
[11:24] <ogra> while all the rest is in binary-indep
[11:25] <ogra> doesnt seem wrong to me
[11:25] <cjwatson> so why should it magically not get built then?
[11:25] <cjwatson> a -B build basically just does debian/rules build && fakeroot debian/rules binary-arch
[11:26] <cjwatson> if the package wants to do things only on certain architectures, it needs to conditionalise that in debian/rules
[11:26] <ogra> hmm, wouldnt it make more sense to check the control file ?
[11:27] <cjwatson> maybe if we were doing it from scratch; but it's not done that way now
[11:27] <ogra> if its not Architecture all or any at least
[11:37] <ogra>        -s, --same-arch
[11:37] <ogra>            This is a smarter version of the -a flag, that is used in some rare circumstances. It understands that if the control file lists "Architecture: i386" for the
[11:37] <ogra>            package, the package should not be acted on on other architectures. So this flag makes the command act on all "Architecture: any" packages, as well as on any
[11:37] <ogra>            packages that have the current architecture explicitly specified.  Contrast to the -a flag, which makes the command work on all packages that are not architecture
[11:37] <ogra>            independent.
[11:37] <ogra> cjwatson, ^^^
[11:37] <ogra> then i dont understand the debhelper manpage
[11:38] <ogra> (pbuilder uses "dh_builddeb -s" for binary-arch
[11:38] <ogra> )
[11:40] <ogra> (well, it uses -s not only for builddeb but for all commands)
[11:42] <ogra> i wonder if that flag not doing what is described is a fallout of the --dpkg-print-architecture change in dpkg
[11:42] <ogra> *--print-architecture
[11:57] <cjwatson> ogra: that causes *those specific debhelper commands* to act on the named packages
[11:57] <cjwatson> ogra: why don't you use DH_VERBOSE=1 so you can see exactly what's going on?
[11:57] <cjwatson> you seem to be blaming the tools, which IME is usually a mistake
[11:57]  * ogra does so ... but the code didnt change, the tools did though
[11:57] <cjwatson> they aren't perfect but it's not usually a good bet for a first guess
[11:59] <cjwatson> BTW, why is it a problem for pbuilder to harmlessly fail to build on non-x86 architectures?
[11:59] <cjwatson> you can just ignore it
[11:59] <ogra> it fills up my ftbfs list ...
[11:59] <cjwatson> you can still just ignore it :)
[11:59] <ogra> just sense of cleanness :)
[12:01] <cjwatson> pbuilder-uml is listed in Packages-arch-specific, so it's probably a Soyuz bug that it's tried
[12:02] <ogra> wel, my local system doesnt have PAS
[12:03] <cjwatson> then it'll fail on your local system. big deal :)
[12:03] <ogra> if i want to roll pbuilder here from source it fails
[12:03] <ogra> well, it actually doesnt because it calls arch-indep first if built locally, so i get my pbuilder deb ...
[12:04] <ogra> *build
[12:05] <cjwatson> BTW it can't possibly be fallout from the dpkg change you mention
[12:06] <cjwatson> 1) debhelper uses dpkg-architecture not dpkg --print-installation-architecture 2) dpkg --print-installation-architecture just prints a warning to stderr and calls through to --print-architecture
[12:06] <ogra> yep, i just looked at Dh_Lib.pm
[12:07] <cjwatson> debuild -b -aarmel works here
[12:07] <cjwatson> bunch of whining from dh_* -s but that's all
[12:07] <cjwatson> you aren't using -B are you?
[12:09] <ogra> no, and debuild -b -aarmel fails here on my amel machine
[12:12] <ogra> oh, wait, it fails on signing not due to -s
[12:13] <ogra> ok, now i'm completely confused
[12:42] <ogra> Keybuk, ...
[12:42] <ogra>  * Starting kernel event manager...                                                                                                                                                 error getting signalfd
[12:42] <ogra>                                                                                                                                                                              [fail]
[12:42] <ogra> invoke-rc.d: initscript udev, action "restart" failed.
[12:42] <ogra> Keybuk, thats what i get on armel with a dist-upgrade
[12:44] <Keybuk> next time we announce a new port of Ubuntu, let's find an architecture that the kernel really supports
[12:45] <Keybuk> like m68k or something
[12:45] <ogra> haha
[12:45] <Keybuk> I assume that ARM has "forgotten" to implement signalfd() or something
[12:45] <ogra> well, the boards i have all only have a 2.6.26 binary kernel atm
[12:46] <Keybuk> ah
[12:46] <ogra> no source ... whats the kernel option that creates signalfd ?
[12:46] <Keybuk> yeah that probably won't work anyway
[12:46] <Keybuk> I think the syscall changed in 2.6.27
[12:46] <ogra> gah
[12:46] <ogra> i though it changed post .25
[12:46] <Keybuk> there's no kernel config
[12:46] <ogra> oh, k
[12:46]  * ogra just saw bug 397187
[12:47] <Keybuk> oh, heh
[12:47] <Keybuk> yeah see my comment there too
[12:47] <ogra> so i'm not alone
[12:47] <ogra> yep
[12:47] <ogra> does upstart *already* use it in 0.6 ?
[12:47] <Keybuk> yes, but not for anything critical
[12:47] <ogra> ok
[12:48] <ogra> i'll try to downgrade udev then until we finally get something usable from the kernel team
[12:48] <Keybuk> a bug fix going into 0.6.1 makes it use it for critical things though
[12:48] <ogra> though i bet that will cause other issues
[12:56] <ogra> grmbl, why isnt signalfd mentioned anywhere in the udev changelog
[12:57] <ogra> how am i supposed to find out which is the last version i can use :(
[12:57] <ogra> bah
[13:02] <ogra> pitti, oh ... Jul 14 13:55:41 osiris kernel: [98748.268006] <6>gnome-power-man[23647]: segfault at 838b0c24 ip 004b0701 sp bfc7ba60 error 6 in libc-2.9.so[43f000+15c000]
[13:02] <ogra> just found that by accident in my /var/log/messages
[13:02] <seb128> ogra, use apport to send a bug?
[13:02] <seb128> ogra, just mentionning a crash on IRC without any detail is of no real use
[13:03] <ogra> seb128, i'm not up to date with my system yet, i was following up on an earlier conversation
[13:26] <ogra> bah i was to fast giving back evolution-exchange ...
[13:40] <mterry> evand, again thanks for the catch.  No summary is normal for me, coming from oem-config land.  :)  I merged your patch
[13:42] <Keybuk> james_w: how would I make lp:~ubuntu-core-dev/upstart/ubuntu be the "Ubuntu" branch (lp:ubuntu/karmic/upstart) ?
[13:42] <james_w> Keybuk: I can do that for you
[13:43] <james_w> however, I'm wary to make *that* branch the one to use given a couple of LP bugs we have at the moment
[13:44] <james_w> I can push it to another location and make that lp:ubuntu/karmic/upstart
[13:44] <evand> mterry:  great!  I think given cjwatson's recent comment on the merge page, we're ready.
[13:44] <james_w> or we can wait for LP to be fixed instead
[13:44] <evand> I've added you to the installer team, so you'll be able to commit directly to trunk now
[13:45]  * mterry is nervous anyway
[13:45] <james_w> also, would we be able to resurrect branches for < karmic?
[13:45] <mterry> evand, is there a test suite for the installer that the branch has been run through, or can be run through?
[13:45] <evand> nope, but patches welcome for that
[13:45] <mterry> evand, oh, thanks for the team add
[13:45] <mterry> evand, heh
[13:45] <evand> it is something we have on the horizon, but neither Colin nor myself have found time to write it
[13:46] <mterry> evand, maybe I could look into that.  I have some experience with ldtp
[13:46] <evand> mterry: any effort you can make on that would be hugely appreciated
[13:47] <mterry> evand, OK, well, I'll merge this branch, and keep an eye out for bugs reported, I guess
[13:58] <pitti> ogra: can you please enable apport then (/etc/default/apport) and send a crash report? thanks!
[13:59] <ogra> pitti, will do if it turns up with the upgrade, sorry i'm to busy today to donate time to that atm
[13:59] <pitti> ogra: no prob, just enable apport and let it sort out itself :)
[13:59] <ogra> yep
[14:13] <Keybuk> james_w: don't mind if you need to move the branch, the lp:ubuntu/... URL is better ;)
[14:14] <Keybuk> james_w: there's no real ubuntu/jaunty branches - while there was something in bzr, it actually was buggered up and missing all the changes
[14:14] <Keybuk> just the changelog entries
[14:20] <james_w> Keybuk: ok, I could do that
[14:20] <james_w> not having the branches available is a bit of an annoyance
[14:21] <Keybuk> james_w: they never really existed properly - you could do an auto-import of them if you liked
[14:22] <james_w> plus, it would currently take away your ability to write to the branch
[14:22] <james_w> which I imagine would be a pain for you?
[14:24] <Keybuk> james_w: err
[14:24] <Keybuk> it would be kinda helpful to write to the branch :p
[14:24] <Keybuk> why wouldn't I be able to?
[14:25] <james_w> because the move would be out of the namespace of a team that you are a member of
[14:25] <Keybuk> so who can commit to lp:ubuntu/... branches?
[14:25] <Keybuk> shouldn't that be developers?
[14:25] <Keybuk> *confused*
[14:25] <james_w> we are waiting on LP to make the permissions for official branches match the uploaders
[14:25] <james_w> yes, it should be
[14:25] <james_w> it is not currently
[14:26] <Keybuk> oh, who is it currently?
[14:26] <james_w> and due to the other LP bug I mentioned, the branches can only be owned by the team we are using for "special" privileges
[14:26] <james_w> it's a team called ~ubuntu-branches
[14:26] <james_w> it's members are me and jml IIRC
[14:26] <Keybuk> err
[14:26] <Keybuk> so
[14:26] <james_w> and Colin actually
[14:27] <Keybuk> the lp:ubuntu/ namespace is really just read-only right now?
[14:27] <james_w> yeah
[14:27] <james_w> but that will be changing real soon now
[14:27] <cjwatson> what's the schedule for that bugfix anyway? it's been on the cards for ages
[14:27] <Keybuk> so I don't want to move the upstart/ubuntu branch there, because the whole point is people commit to it? :P
[14:27] <james_w> I'm not sure, it doesn't have a milestone yet IIRC
[14:27] <cjwatson> we need to sit on jml about that
[14:27] <cjwatson> or possibly thumper
[14:27] <james_w> Keybuk: yeah, but we can move it once that is fixed
[14:27] <Keybuk> ok
[14:28] <Keybuk> when that bug is fixed, does it just become an alias?
[14:28] <Keybuk> or will it still involve "moving" the branch?
[14:29] <james_w> bug 347768
[14:29] <james_w> the lp:ubuntu/... thing is an alias
[14:30] <james_w> however, you can't currently ask which branch that points to using the API without it crashing
[14:30] <james_w> so there is currently a hard-coded assumption that it is the branches owned by ~ubuntu-branches with a particular name
[14:31] <james_w> so once that is fixed we can just make the alias point to the ~ubuntu-core-dev branch if we like
[14:31] <Keybuk> would the same work for lp:debian/
[14:31] <Keybuk> it might be nice for mbiebl to be able to have br branch lp:debian/sid/upstart for the Debian branch he maintains
[14:31] <james_w> however, we may want to move it anyway, so that it is a "package branch"
[14:31] <james_w> it will work for Debian
[14:34] <cjwatson> james_w: where would LP get information about who can upload to the Debian branches?
[14:34] <cjwatson> I suppose we could import the Debian keyring but I wasn't aware that we were doing that
[14:34] <james_w> ah
[14:34] <james_w> I assume it will have "branch owner, plus those able to upload to the Debian archive through LP"
[14:34]  * cjwatson comments on 347768
[14:34] <james_w> which will be no-one
[14:35] <cjwatson> uploading to the Debian archive through LP would be a pretty odd thing to do :)
[14:35] <james_w> so only the owner will have write access
[14:35] <james_w> which I think is ok
[14:58] <Keybuk> that's kinda boring
[14:58] <Keybuk> bzr commit --fixes=lp:NNNNNN
[14:58] <Keybuk> doesn't mark the bug as "Fix Committed"
[14:58] <Keybuk> and links to the branch, not the revision
[15:00] <kirkland> Keybuk: yeah, i've been disappoitned with --fixes too
[15:00] <kirkland> Keybuk: i filed a bug asking bzr/lp to scan the contents of the commit message for "fixes LP: #NNNNNN", because I always mention it there, but always forget it at --fixes
[15:01] <cjwatson> FWIW debcommit does scan the changelog for LP: so in cases where you use that it works
[15:04] <Ng> what handles mounting USB devices these days (in karmic, i.e. what should I call ubuntu-bug on?)
[15:08] <pitti> Ng: hm, nautilus, gvfs, and devicekit-disks, depending on what kind of operation
[15:09] <Ng> hrm. my phone presents a PTP interface and each time I plug it in I get asked if I want to run f-spot (which is fine). If I don't click Unmount in that dialog and just hit cancel and later unplug the phone nautilus still thinks it has a "Digital Camera (usb:000,007)" device attached. Over the course of the day I end up with about 10 in there
[15:10] <pitti> Ng: sounds like gvfs then
[15:11] <Ng> ok
[15:11] <pitti> could be my bug, I recently did the porting to gudev; can you please assign it to me?
[15:15] <Ng> pitti: sure, thanks
[15:15] <Ng> pitti: bug #399320
[16:01] <slytherin> Can any of the archive admins clear excalibur-logkit (source) from queue?
[16:02] <james_w> slytherin: review or reject?
[16:02] <slytherin> james_w: review
[16:03] <slytherin> clear as in 'give go ahead'.
[16:06] <james_w> slytherin: has it been in before as avalon?
[16:06] <slytherin> james_w: it was in as liblogkit-java
[16:06] <james_w> ok
[16:08] <slytherin> james_w: I intend to eventually migrate all r-deps of liblogkit-java to this package because this is the last stable version of the library.
[16:09] <james_w> slytherin: accepted
[16:10] <james_w> slytherin: note that debian/copyright doesn't conform to dep-5 by my reading
[16:12] <slytherin> james_w: really? I thought it ddid. I wrote it from scratch.
[16:12] <james_w> just small things
[16:12] <james_w> e.g. it specifies Apache, you used Apache-2.0
[16:13] <james_w> and a strict reading would suggest your Files: * stanza needs to duplicate the statement about common-licenses
[16:13] <james_w> or use a standalone license section
[16:13] <slytherin> oh, ok. I will correct it if I need to upload again.
[16:14] <james_w> thanks
[16:22] <slytherin> james_w: Do you mind reviewing the binary as well? It's arch:all package.
[16:22] <james_w> is it through already?
[16:23] <james_w> oh yeah
[16:23] <slytherin> james_w: yes, even I was surprised.
[16:35] <slytherin> james_w: Got to go. See you later. Thanks for quick review.
[16:52] <mrec> Hi, does anyone know why I cannot use LD_PRELOAD to intercept stat()?
[16:52] <Keybuk> mrec: because it's morally wrong
[16:53] <Keybuk> and are you sure it's stat() you want to intercept, not stat64(), fstat(), lstat(),e tc.
[16:53] <mrec> Keybuk: why should it be wrong?
[16:54] <mrec> strace says stat .. although I'll check
[16:55] <Keybuk> strace tells you underlying syscalls
[16:55] <mrec> I think almost everything works except stat on ubuntu for some reason
[16:55] <Keybuk> LD_PRELOAD intercepts glbc library calls
[16:57] <ion> glbc – is that a fork of glbt?
[16:58] <mrec> the reason why I need to intercept stat() is I have a usb TV driver written in userspace working across all systems the only reason why it doesn't work with some legacy applications is that they use some kind of stat()
[16:58] <mrec> the performance is quite good 21 mbyte/second
[16:59] <mrec> the driver also includes a reimplementation of the linuxdvb and video4linux API so it's compatible with legacy apps
[16:59] <mrec> tvtime works without any problem
[17:03] <mrec> without the need of a kerneldriver
[17:18] <Keybuk> cjwatson: I don't have a GIT branch for your util-linux changes? :)
[17:21] <vadi2> Hi. In regards to the openjdk news for 9.04, is the certified package already in?
[17:22] <cjwatson> Keybuk: I sent a patch, and IIRC you said on IRC at the time you would be happy to wrangle it into git for me
[17:22] <Keybuk> cjwatson: did I?  ok :)
[17:22] <Keybuk> we're friends, I won't make you use GIT unnecessarily
[17:23] <Keybuk> cjwatson: unrelated question
[17:23] <Keybuk> debian/util-linux-udeb.dirs
[17:24] <Keybuk> contains "sbin"
[17:24] <Keybuk> but isn't in GIT, is that necessary?
[17:24] <Keybuk> hmm
[17:25] <Keybuk> apparently Lamont uploaded to fix that
[17:25] <Keybuk> but doesn't appear to has pushed
[17:25] <Keybuk> lamont: ?
[17:25] <cjwatson> Keybuk: yeah, it is
[17:25] <Keybuk> oh, no
[17:25] <Keybuk> "git fetch lamont"
[17:25] <Keybuk> *sigh*
[17:25] <Keybuk> HATE HATE HATE
[17:25] <cjwatson> I certainly remember that coming up ...
[17:25] <cjwatson> and I think that's why the ln in debian/rules now has a trailing slash
[17:25] <Keybuk> hmm
[17:25] <Keybuk> no, that didn't do it
[17:25] <Keybuk> *confused*
[17:25] <cjwatson> because if that isn't there, then you get an executable called "/sbin" ...
[17:26] <Keybuk> oh, no, I see
[17:26] <cjwatson> if you can point me to the right branch, I can do a git format-patch for you
[17:26] <Keybuk> git checkout lamont/ubuntu/stable/v2.15
[17:26] <Keybuk> git checkout -b ubuntu/stable/v2.15
[17:26] <Keybuk> *sigh*
[17:26] <cjwatson> I imagine the changelog in the bug is out of date
[17:27] <cjwatson> I have no lamont/ubuntu/stable/v2.15 branch here ...
[17:27] <cjwatson> branches should have URLs, damnit. hate
[17:28]  * cjwatson tries re-cloning
[17:28] <Keybuk> http://kernel.ubuntu.com/git?p=scott/util-linux.git;a=shortlog;h=refs/heads/ubuntu/stable/v2.15
[17:29] <Keybuk> right
[17:29] <Keybuk> I've pushed that
[17:29] <cjwatson> what's the rune to set up automatic tracking for your branch, given a clone of git://git.debian.org/users/lamont/util-linux.git ?
[17:29] <Keybuk> git remote add lamont git://...
[17:29] <Keybuk> though it's not automatic
[17:29] <Keybuk> you have to "fetch"
[18:04] <ion> Ah, high-resolution versions. Awesome. http://videos.ubuntu.com/uds/karmic/plenary_1/
[18:06] <pitti> bazaar.launchpad.net, where are you?
[18:10] <cjwatson> Keybuk: I'm thoroughly confused about what branch that is
[18:10] <cjwatson> Keybuk: it claims to be an Ubuntu branch, but the differences between the version I uploaded and it look like this: http://paste.ubuntu.com/218119/
[18:11] <cjwatson> Keybuk: am I being stupid?
[18:13] <Keybuk> that looks like you've diffed Ubuntu and Debian
[18:13] <Keybuk> so..
[18:13] <Keybuk> there are three GIT repos
[18:13] <Keybuk> origin - this is Karel's upstream repo
[18:13] <Keybuk> lamont - this is Lamont's repo on git.debian.org
[18:13] <Keybuk> keybuk - this is my repo on kernel.ubuntu.com
[18:13] <Keybuk> each contains many branches
[18:13] <Keybuk> master - trunk line of development
[18:14] <Keybuk> stable/v2.XX - stable release line
[18:14] <Keybuk> and there's a waterfall between them
[18:14] <Keybuk> so origin/master is merged into lamont/master to form the Debian package
[18:14] <Keybuk> and that is merged into keybuk/master to form my copy of the Debian package
[18:14] <Keybuk> and then merged into keybuk/ubuntu/master to form the Ubuntu package
[18:15] <Keybuk> ie. keybuk/master is Debian, not Ubuntu
[18:15] <Keybuk> likewise
[18:15] <Keybuk> origin/stable/v2.15 -> lamont/stable/v2.15 -> keybuk/stable/v2.15 -> keybuk/ubuntu/stable/v2.15
[18:15] <Keybuk> and you'll find there's a lamont/ubuntu/stable/v2.15 as well
[18:15] <Keybuk> so basically, depending who did the last upload
[18:15] <Keybuk> lamont/* or keybuk/* may actually contain the current Debian and/or Ubuntu packages
[18:16] <Keybuk> I wish to note that this madness WAS NOT MY IDEA
[18:21] <cjwatson> Keybuk: I'm diffing the last upload with ubuntu/stable/v2.15 in your repo
[18:22] <Keybuk> cjwatson: the HEAD of my repo, or the release tag?
[18:22] <cjwatson> 'git checkout keybuk/ubuntu/stable/v2.15'
[18:22] <Keybuk> ahh
[18:22] <Keybuk> right
[18:22] <Keybuk> that makes sense
[18:22] <cjwatson> 'git checkout -b ubuntu/stable/v2.15'
[18:22] <Keybuk> I'm updating to 2.15.1
[18:22] <Keybuk> along with merging back the hwclock stuff into Debian
[18:24] <Keybuk> http://kernel.ubuntu.com/git?p=scott/util-linux.git;a=commitdiff;h=a1b46c1ff070feaab2387f7b1b1ac5a87389bd5b
[18:24] <Keybuk> that's the patch I applied from you
[18:25] <cjwatson> right, that looked correct for the Ubuntu branch
[18:25] <cjwatson> FSVO "the"
[18:26] <Keybuk> so what you're seeing is just me resolving some differences between Ubuntu and Debian
[18:26] <Keybuk> ie. trailing / on dirs and such
[18:34] <Sarvatt> yuck, timeout increase on arm wasnt enough for mesa
[18:34] <Sarvatt> Session terminated, killing shell...make: *** [binary-arch] Terminated  ...killed. Build killed with signal 15 after 600 minutes of inactivity
[18:35] <ogra> Sarvatt, pleasedont give it back, it hogs a buildd for 10h :)
[18:36] <ogra> mcasadevall made that mistake already
[18:36] <Sarvatt> the only change between that one and the previous that worked is in a driver that doesnt build on arm, must be something in the build environment that broke
[18:36] <mcasadevall> Sarvatt, its lzma compression
[18:36] <mcasadevall> Sarvatt, it takes too long and the build times out
[18:37] <mcasadevall> Sarvatt, we're debating on what to do about it, some packages should now build with the longer timeout, mesa non-withstanding
[18:37] <ogra> mcasadevall, can you fire off a local mesa build if you go to bed or something ? so we can see if it actually finishes if there is no timeout (and prefix it with "time" to see how long it took)
[18:38] <mcasadevall> ogra, I run launchpad-buildd to determine it to rule out any issues with translation stripping and friends.
[18:38] <ogra> i would do it here but dont have a trustworthy build system atm
[18:38] <Sarvatt> somewhere between june 30th and july 7th lzma started being a problem then?
[18:38] <mcasadevall> Sarvatt, I'm not sure what caused it initially; but the lzma compresison of large -dbg packages causes huge amounts of issues
[18:38] <mcasadevall> Sarvatt, hence why KDE is completely FTBFS ATM
[18:39] <Sarvatt> Finished: 	2009-06-30 (took 3 hours, 44 minutes, 41.0 seconds)
[18:40] <Sarvatt> nothing changed besides an added patch that only touches a driver that doesnt build on arm
[18:41] <Sarvatt> thats really odd
[18:41] <mcasadevall> Sarvatt, when I did test builds on my local hardware, no issues. Its dying during compression
[18:43] <Sarvatt> did KDE start failing to build on arm at a certain date or has it always?
[18:44] <ogra> .oO( we should probably be on #ubuntu-arm with that conversation )
[18:53] <nelhage> Does anyone have thoughts on bug #399368? In particular, it seems to me the new version pushed today is an example of an issue it's not really worth requesting a reboot for, but I'm wondering if I'm missing something.
[18:56] <ebroder> Do you strictly need a reboot to restart dbus? I don't think you do for, e.g., a gdm-less system
[18:56] <ebroder> (Of course, I don't get popups about needing to reboot my gdm-less systems)
[19:19] <mcasadevall> doko, ping?
[19:24] <doko> mcasadevall: ?
[19:24] <mcasadevall> doko, are we building with VFP by default for GCC?
[19:25] <doko> mcasadevall: no
[19:26] <mcasadevall> doko, I thought we decided to make that change at the start of the cycle
[19:26] <mcasadevall> doko, what compiler flag will get me VFP enabled?
[19:39] <doko> mcasadevall: -mfpu=vfp -mfloat-abi=softfp (and maybe you should add -march=armv7 -mtune=cortex-a8)
[19:48] <slytherin> cjwatson: Does this approach ok to you to workaround build failures on powerpc - http://paste.ubuntu.com/217917/
[19:50] <cjwatson> slytherin: it's being fixed on the buildd side, according to infinity
[19:50] <cjwatson> so no, I don't think that workaround is OK
[19:50] <cjwatson> it'd be a lot of work (a) to do it (b) to revert it later
[19:51] <slytherin> cjwatson: Ok. If it is being worked on then I have no problem.
[19:51] <cjwatson> the bug is apparently that the powerpc buildds are still on a dapper base system, unlike other architectures
[19:51] <slytherin> I thought it was too much work to fix on buildd side.
[19:51] <cjwatson> infinity seemed to reckon it was tractable in sbuild
[19:52] <slytherin> hmm.
[19:53] <cjwatson> he didn't elaborate on how
[19:54] <infinity> The "when" is more important than the "how", really.
[19:54] <infinity> And I tihnk I'm going to have to make time to do it this week.
[19:54] <slytherin> infinity: I wish I could help anyway, but I have no idea about sbuild.
[21:14] <ccheney> cjwatson: ping, germinate 1.16 in bzr is listed as released 2009-06-17 but its not in karmic yet?
[22:16] <jml> cjwatson, I'm going to start working on it today
[22:17] <cjwatson> ccheney: odd, I don't know what happened to it. I've reuploaded it to Debian
[22:17] <cjwatson> jml: thanks
[22:18] <jml> cjwatson, I've wanted to do it earlier, but I've been thwarted at every turn.
[22:18] <jml> mostly by prep for open sourcing Launchpad.
[22:21] <cjwatson> jml: a worthy cause, I'll admit ;)
[22:28] <BUGabundo> is Colin around? wanna ask him about swap on file
[22:29] <BUGabundo> clean install and I'll be testing it on karmic
[22:30] <BUGabundo> cjwatson: ping ^^^^^^^
[22:33] <cjwatson> BUGabundo: no progress on implementation yet
[22:33] <BUGabundo> but will it work?
[22:33] <BUGabundo> it is usable cjwatson?
[22:33] <BUGabundo> will I be able to hibernate?
[22:33] <cjwatson> it is not implemented yet
[22:33] <cjwatson> there has been *no progress*
[22:34] <cjwatson> it's targeted for a later milestone in karmic, not the one currently in preparation
[22:34] <BUGabundo> I know I read it
[22:34] <cjwatson> we are working on other things right now
[22:34] <BUGabundo> but what was/is the current state?
[22:34] <cjwatson> I have no idea
[22:34] <BUGabundo> ohh
[22:34] <cjwatson> I have not looked at it beyond what I did to write up the specification
[22:36] <BUGabundo> ok
[22:36] <BUGabundo> I'll be using
[22:36] <BUGabundo> hope I don't mess it much
[22:36] <BUGabundo> cjwatson: if you need further testing along the cycle ping me on #ubuntu+1 or identica
[22:38] <cjwatson> absolutely everyone with new installs will be using it once implemented
[22:38] <cjwatson> so we should get a fair bit of testing, I'd expect ;-)
[22:39] <BUGabundo> well count on early testing on my side
[22:39] <BUGabundo> but I guess no need to file bugs
[22:39] <BUGabundo> until you start to touch it
[22:41] <cjwatson> the spec isn't even owned by me ...
[22:41] <cjwatson> Assignee:      Scott James Remnant
[22:41] <BUGabundo> eheh
[22:41] <BUGabundo> right
[22:56] <ccheney> cjwatson: thanks
[22:57] <BUGabundo> hey ccheney
[23:19] <billybigrig> can someone in here help me?
[23:19] <billybigrig> i had a problem with the daily kernel and dkms yesterday
[23:19]  * BUGabundo hides
[23:19] <billybigrig> and i forgot the fix for it
[23:19] <BUGabundo> :)
[23:19] <billybigrig> dkms won't build
[23:20] <billybigrig> billybigrigger@cabo:/var/lib/dkms/nvidia/185.18.14/build should be a symlink to /usr/src/linux-headers-2.6.31-rc3-billybigrigger0714
[23:20] <billybigrig> correct? to get my nvidia module to build in dkms?
[23:24] <billybigrig> !logs
[23:26] <cjwatson> ccheney: making its way into karmic now
[23:27] <puff> Hey, I have an odd question that's fairly arcane (I think), where does suspend-to-disk save its data?  Does it use the swap partition?
[23:28] <cjwatson> yes, that's right
[23:28] <puff> cjwatson: Really?  Ah, good... then making my laptop's swap partition extra-large actually was a good idea.
[23:29] <puff> I have been saying, for some time, "I have this feelnig that suspend-to-disk uses swap, so I make it alrge" band I thought, you know, I really should maybe, y'know ASK somebody who might KNOW.
[23:30] <BUGabundo> puff: swap
[23:30] <BUGabundo> Or eventually swap on file
[23:30] <BUGabundo> eheh
[23:30] <bardyr> Hey, where can i find the blueprint/specification template?
[23:30] <puff> Thanks muchly.
[23:30] <BUGabundo> that's what brought me here tonight ahah
[23:30] <cjwatson> bardyr: http://wiki.ubuntu.com/SpecTemplate
[23:30] <bardyr> cjwatson, Thanks
[23:31] <cjwatson> Documentation/power/swsusp-and-swap-files.txt in the kernel source describes how things are meant to work when you're using a swap file
[23:31] <cjwatson> (which is why I'm not worried about it, it's clearly been thought about it so at worst whoever's implementing proper swap file support gets to fix a few bugs)
[23:31] <cjwatson> s/thought about it/thought about/
[23:32] <cjwatson> ... and implement some little helper tool to go in the initramfs, possibly
[23:33] <cjwatson> puff: for suspend-to-disk to work, you do indeed need swap >= RAM
[23:33] <BUGabundo> yeah cjwatson
[23:33] <BUGabundo> I do know that as swap it works very well since gutsy
[23:33] <BUGabundo> but what may break is hibernate (or better, resume)
[23:34] <cjwatson> sure
[23:34] <cjwatson> like I say, it probably needs some work in the initramfs; but the presence of kernel documentation makes me confident that it's possible without too much difficulty
[23:34] <puff> cjwatson: Again, much thanks,a dding that detail to my notes.
[23:34] <BUGabundo> and since I use that a lot, I would like to have it on a working state, even if with _some_ bugs
[23:38] <puff> cjwatson: swsusp-and-swap-files.txt, what would be the normal place an ubuntu user should look for that?  The linux kernel doc website or is there somewhere in a  normal ubuntu install (I don't see it in /usr/share/doc)?
[23:39]  * BUGabundo wanna know too :)
[23:39] <puff> http://www.mjmwired.net/kernel/Documentation/power/swsusp-and-swap-files.txt
[23:40]  * BUGabundo checks
[23:52] <cjwatson> puff: it'll be in the linux-doc(whatever) package
[23:52] <cjwatson> linux-doc-2.6.28 on jaunty, plain old linux-doc from karmic on