| nick_schembri | Can anyone point me to the status of aufs and it's replacement? | 00:47 |
|---|---|---|
| dtchen | ubuntu status and/or upstream status? | 00:48 |
| dtchen | as far as ubuntu is concerned, it's gone from karmic | 00:48 |
| dtchen | it was turned down from upstream recently, too | 00:48 |
| nick_schembri | that is sad. :( can you point me to the replacement? | 00:49 |
| dtchen | nick_schembri: whatever Fedora/Red Hat is using | 00:56 |
| nick_schembri | peter graner talked about dm-snapshot. I'm just trying to make sure I get the correct project. | 00:59 |
| dtchen | that's correct | 01:00 |
| nick_schembri | dtchen: thanks for the help. | 01:00 |
| dtchen | nick_schembri: yw | 01:02 |
| cwillu | question: the mainline daily ppa hasn't had an i386 build show up in nearly a week | 04:19 |
| cwillu | is that known? | 04:19 |
| johanbr | cwillu: what happened with your kernel lockups? | 04:20 |
| cwillu | johanbr, nothing yet really | 04:21 |
| cwillu | johanbr, although kms screws up suspend even quicker :p | 04:22 |
| johanbr | :) | 04:22 |
| johanbr | did you try the older kernel with newer userspace? | 04:22 |
| cwillu | ya, that seemed to work fine, although I didn't run it for more than an hour or two, and I've had the newer kernel work that long once in a while | 04:23 |
| cwillu | I'll try that again tomorrow for work | 04:24 |
| johanbr | alright | 04:25 |
| cwillu | latest daily that has an i86 panics on boot with a allocation of page_cgroup was failed | 04:33 |
| johanbr | oh | 04:36 |
| * cwillu boots a mainline-ppa 2.6.29 | 04:37 | |
| cwillu | oh right, I remember why I hadn't tried 2.6.28 during a full work day | 04:39 |
| cwillu | ext4 delete crasher :) | 04:39 |
| cwillu | although that didn't exist in the mainline 2.6.28, so I'll grab one of those | 04:39 |
| cwillu | 2.6.29-020629 looks good so far | 04:45 |
| solarion | So I have in my hands at least partial docs for programming a programmable HD DSP/Amp from AMD's HTPC platform. Where should I start looking for coding up a driver for it? | 04:53 |
| solarion | is there any sort of ALSA interface for programming a programmable dsp? | 04:54 |
| solarion | looks like it's controlled over the HD Audio bus; where do I find docs on using it? | 04:57 |
| cwillu | johanbr, 2.6.29 seems to be working, I'm going to try that one tomorrow unless it gives me some trouble tonight | 05:00 |
| johanbr | alright | 05:00 |
| johanbr | good luck | 05:00 |
| cwillu | johanbr, quick question (I'm on my way out, but I'll read when I'm back), if this 2.6.29 works, am I in bisect-land, and if so, should I be bisecting between 2.6.29 and an early 2.6.30, or is there a better starting point? (I remember you saying something about big suspend changes landing early on) | 05:32 |
| zeroprog | hey guys when trying to write a driver for an undocumented piece of hardware where should i begin in the reversing process | 07:26 |
| AceLan | zeroprog: what kind of driver? and what's its interface? | 10:06 |
| * apw wonders how Keybuk's machine is ... | 10:12 | |
| apw | there must be communities who specialise in the reverse engineering process. i think nouveau was whole reverse engineered from the hardware. they may be a good group to approach | 10:13 |
| Keybuk | apw: still trying to work out why these renames fail | 10:21 |
| apw | Keybuk, which renames, i thought all should fail pretty much | 10:26 |
| Keybuk | since it should be a rename of something on cow to something else on the cow | 10:26 |
| Keybuk | well you should be able to create a new file, then rename it elsewhere, no | 10:26 |
| apw | yeah that is true, and those don't work either? | 10:27 |
| Keybuk | that's what I'm investigating | 10:30 |
| Keybuk | it seems not | 10:30 |
| apw | t | 10:31 |
| apw | that would be limiting indeed | 10:31 |
| Keybuk | apw: of course, this could be an APT bug, arguably | 10:49 |
| apw | you would think that apt would have hit this issue before | 10:50 |
| Keybuk | dunno, I can't work out what it's doing at the moment ;) | 10:51 |
| Keybuk | the syscalls don't make much sense | 10:51 |
| apw | heheh .... if you can't figure it out we are in a lot of trouble :) | 10:51 |
| Keybuk | Invalid cross-device link (/var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_karmic-security_Release -> /var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_karmic-security_Release). | 10:52 |
| Keybuk | now | 10:52 |
| Keybuk | correct me if I'm wrong | 10:52 |
| Keybuk | but aren't those the same path? | 10:52 |
| soren | Their md5sum is identical, at least. | 10:52 |
| apw | to my eye yes | 10:52 |
| mvo | interessting behaviour | 10:53 |
| * Keybuk clears out partial and tries again | 10:54 | |
| Keybuk | ok, I get a different error now | 10:54 |
| Keybuk | apt clearly has a bug there, it's just one you can only hit if you first experience the failure mode of a union mount <g> | 10:54 |
| Keybuk | I clearly need a smaller test case than apt | 10:56 |
| Keybuk | haha | 11:04 |
| Keybuk | strace strace ... | 11:04 |
| Keybuk | gives unexpected output ;) | 11:04 |
| Keybuk | iiiiiinteresting | 11:05 |
| Keybuk | I think they just didn't bother to implement rename at all ;) | 11:06 |
| Keybuk | root@union:/# echo "foo" > a_file_in_the_cow | 11:06 |
| Keybuk | root@union:/# ./overwrite a_file_in_the_cow | 11:06 |
| Keybuk | rename: Invalid cross-device link | 11:06 |
| === smb is now known as smb_afk | ||
| Keybuk | apw: see my mail ;) | 11:12 |
| Keybuk | it shouldn't be a problem for rename ("some_path", "some_path.bak") to fail | 11:14 |
| Keybuk | because apps doing that should | 11:14 |
| Keybuk | a) check the return value and cope | 11:14 |
| Keybuk | b) not do that | 11:14 |
| Keybuk | but the other three rename()s I highlighted there should work, because they're not doing much cross-device | 11:15 |
| apw | yeah i think the first one they lilley don't support, but it sounds like a sane description in tha tyou can do it all at the top level only ever looking at the toplevel | 11:16 |
| apw | the other two sound like bugs, but i think there is rename code in there | 11:17 |
| apw | so it must be broke | 11:17 |
| Keybuk | yeah | 11:18 |
| Keybuk | it should be easy enough to do | 11:18 |
| Keybuk | if source is on the top layer, the rename() should always be permitted | 11:19 |
| apw | yeah that i think makes sense | 11:19 |
| Keybuk | if source is on a lower layer, the rename() should return EXDEV | 11:19 |
| Keybuk | if the source is on the top layer, and there's something of the same name on a lower layer, the rename() should be permitted and leave a whiteout in the old location | 11:19 |
| Keybuk | (otherwise you could overwrite a file on the top layer, rename() it, and suddenly the old file comes back) | 11:20 |
| apw | its likely you could _always_ leave a whiteout, so you don't have to check the lower level | 11:20 |
| Keybuk | true | 11:20 |
| apw | though i think once the names are copied up the first time, they directory becomes opaque anyhow | 11:20 |
| apw | there is some mind bending optimisation in there | 11:20 |
| Keybuk | rename(src-on-lower, dest-on-upper) can't work because you need to copy up | 11:21 |
| Keybuk | but that's ok | 11:21 |
| apw | sounds like we might be able to live with that | 11:21 |
| apw | that the critical erm atomics are top to top only | 11:21 |
| Keybuk | right | 11:22 |
| Keybuk | I'd be interested if anything is actually trying the other form of rename() | 11:22 |
| Keybuk | since it shouldn't | 11:22 |
| apw | right other than mv | 11:22 |
| Keybuk | you shouldn't rename() files to ".bak" because you end up with the permissions round the wrong way | 11:22 |
| apw | and it really should cope | 11:22 |
| Keybuk | you should create .bak and copy into it before trunc()ing the original | 11:22 |
| Keybuk | and if you have a genuine reason to rename() a file, you should at least cope with EXDEV ;) | 11:23 |
| cwillu | Keybuk, I'm curious: how does that interact with the ext4 delayed allocation semantic workaround? | 11:24 |
| cwillu | i.e., does it still trigger an implicit fsync, or does that end up looking like something else? | 11:24 |
| Keybuk | cwillu: ? | 11:25 |
| Keybuk | -ECONTEXT | 11:25 |
| apw | + /* renaming on unions is done by the user-space */ | 11:26 |
| apw | + error = -EXDEV; | 11:26 |
| apw | + if (is_unionized(oldnd.path.dentry, oldnd.path.mnt)) | 11:26 |
| apw | + goto exit5; | 11:26 |
| apw | + if (is_unionized(newnd.path.dentry, newnd.path.mnt)) | 11:26 |
| apw | goto exit5; | 11:26 |
| apw | 11:26 | |
| apw | Keybuk, dispite the commentry in the patches saying that this is supported it appears that rename is simply not supported at all, fail. | 11:26 |
| cwillu | Keybuk, currently with ext4, if you rename over top an existing file, you get an implied fsync of the new contents. This 'fixes' the empty-file-after-a-crash bug that people complained about | 11:26 |
| apw | ext4 does not support union | 11:27 |
| Keybuk | cwillu: this is all done at the VFS level | 11:27 |
| apw | its ext2 and tmpfs only right | 11:27 |
| cwillu | sorry, I didn't read enough scrollback. I thought you were discussing application behaviour, not unions | 11:27 |
| Keybuk | cwillu: if you were using an ext4 top layer, and both the source and destination were on that, its semantics would apply | 11:27 |
| Keybuk | apw: I didn't think the patches were ext2 specific | 11:28 |
| apw | the upper level fs has to have the ability to support whiteout entries | 11:28 |
| apw | and i only see patches for tmpfs and ext2 for that | 11:28 |
| Keybuk | ext4 is based off that ext2 code though, right? | 11:28 |
| apw | i don't think it is in this context | 11:29 |
| apw | but we should ask. for our use cases i don't think we care | 11:29 |
| apw | as any volatile and any non-volatile upper layer is fine | 11:29 |
| Keybuk | right | 11:30 |
| Keybuk | yeah looks like it's ext2 only - but relatively trivial to patch to ext3 and ext4 later | 11:31 |
| apw | yeah and for the two uses we absolutly need for this work for karmic i think tmpfs and ext2 would be fine right? | 11:31 |
| Keybuk | yes | 11:32 |
| Keybuk | though I think the existing COW is ext3 | 11:33 |
| Keybuk | which briefly surprised me | 11:33 |
| * Keybuk tries to remember whether USB and journalling filesystems are friends or enemies | 11:33 | |
| apw | its all very perplexing | 11:34 |
| Keybuk | Eurasia! | 11:35 |
| Keybuk | Subject: Re: [PATCH 15/32] union-mount: Documentation | 11:36 |
| Keybuk | Message-ID: <20090618190558.GB22206@shell> | 11:36 |
| Keybuk | apw: val posted the old rename() patch to lkml | 11:36 |
| Keybuk | might be worth looking at | 11:37 |
| Keybuk | see if it's possible to keep rename() on top layers without the copy-up | 11:37 |
| apw | yeah i think your minor exceptions would be implementable as they occur in one layer only | 11:37 |
| apw | Keybuk, well it still seems to apply to the current stack, i'll apply it and get a kernel building and we can see what happens | 11:46 |
| StevenK | apw: I was curious if it has been accepted upstream | 11:47 |
| apw | vfs union-mounts ? | 11:47 |
| apw | not yet, they are still being developed, i think they were given the nod as the right approach | 11:47 |
| StevenK | apw: Yup | 11:47 |
| apw | which is more than half the battle | 11:47 |
| apw | they seem much less invasive than the alternatives to my eye | 11:48 |
| Keybuk | plus aside from a few minor issues, they work | 11:48 |
| StevenK | Well, so did aufs :-P | 11:48 |
| apw | yeah that they are this close to working so soon is always a good sign | 11:48 |
| apw | cirtainly worth us spending a few man days playing with anyhow | 11:49 |
| apw | Keybuk, i do wish .deb's were rsyncable | 11:59 |
| Keybuk | you can make them rsyncable | 11:59 |
| apw | i can? how? | 12:00 |
| * apw slobbers at the thought | 12:00 | |
| Keybuk | there's a patch to add it directly to dpkg | 12:03 |
| apw | oh hrm. so not just a simple option then | 12:03 |
| Keybuk | you can manually recompress a .deb after making it with gzip --rsyncable as well | 12:03 |
| apw | oh now that i would be happy to do | 12:04 |
| apw | is that documented anywhere/so obvious i should know | 12:04 |
| StevenK | apw: ar x .deb | 12:06 |
| StevenK | gunzip *.tar.gz | 12:06 |
| Keybuk | ar p THINGY.deb | gunzip -c | gzip --rsyncable > data.tar.gz | 12:06 |
| StevenK | gzip --rsyncable ... | 12:06 |
| Keybuk | ar r THINGY.deb data.tar.gz | 12:06 |
| Keybuk | err | 12:06 |
| Keybuk | ar p THINGY.deb data.tar.gz | gunzip -c | gzip --rsyncable > data.tar.gz | 12:06 |
| Keybuk | obv | 12:06 |
| apw | heh thanks both, will give it a go | 12:07 |
| apw | these 28 min uploads are killing me | 12:07 |
| === smb_afk is now known as smb | ||
| ivoks | anyone around? | 15:19 |
| ivoks | i'm looking at linux/connector.h in karmic | 15:19 |
| ivoks | shouldn't connector unique ids be uniq? | 15:20 |
| ivoks | i remember having problems with drbd when it had the same cn_idx as v86d | 15:21 |
| ivoks | both modules couldn't be loaded at the same time | 15:21 |
| ivoks | actually, they could, but only the first one loaded worked, and the other didn't | 15:22 |
| ivoks | by bad, they are unique :) | 15:23 |
| apw | Keybuk, ok finally got that rename patch to build at least, so i've uploaded it to the same PPA. should be there in an hour ish | 16:04 |
| Keybuk | apw: tvm | 16:05 |
| apw | its taken me an hour to get the PPA to accept it, what a waste of time | 16:06 |
| apw | Keybuk, actually waht arch are you testing | 16:08 |
| Keybuk | i386 | 16:09 |
| apw | i'll get you a dirty binary from my build farm ... much quicker | 16:10 |
| apw | getting overly into PPAs and actually they are slowing me down | 16:10 |
| rtg | apw: just sent you a note about GEM/PAE. Have you any test results from your patch set? | 16:21 |
| apw | not seen anything will poke them | 16:21 |
| mdz | is the kernel packaging (debian/ dir) kept in git as well? | 16:32 |
| rtg | mdz: yes | 16:32 |
| mdz | rtg: thanks. so if I have a packaging patch to submit, I should do it the same way as one would a kernel code patch? | 16:33 |
| rtg | mdz: exactly | 16:33 |
| lionel | Hi all. Digging with a collegue of mine today on bug #243393, we found that a one line fix (removing a warning) could fix it. Do you think this low risk fix could be integrated in the next hardy SRU kernel upload? | 16:33 |
| ubot3 | Malone bug 243393 in linux "dmesg is flooded with warnings in kvm/mmu.c" [Low,Fix released] https://launchpad.net/bugs/243393 | 16:33 |
| rtg | mdz: as an example, see how Luke has done it for the ports config changes: 'git://kernel.ubuntu.com/themuso/ubuntu-karmic.git master' | 16:34 |
| smb | lionel, In general it could. But as this is a WARN_ON it needs to be made clear this is not just shutting the eyes in the face of some evil... | 16:39 |
| lionel | smb: agreed, but considering that it is now what's is done on newer kernel | 16:39 |
| lionel | smb: the problem is that is fill partitions (10GB of logs here for this :() | 16:40 |
| mvo | for me the crashkernel functionatlity is not work (bug #389449 and possible #364414) - is that a known issue? | 16:41 |
| ubot3 | Malone bug 389449 in linux "linux-crashdump not working: "crashkernel reservation failed - memory is in use" " [Undecided,New] https://launchpad.net/bugs/389449 | 16:41 |
| smb | lionel, Well in that case, if you can provide that patch from upstream with an explanation on why and send it to the kernel-team mailing list. | 16:41 |
| lionel | smb: Ok, will do, thanks ! | 16:41 |
| Araneidae | Wondering where my RAM has got to: have 3GB installed, but Linux (and Memtest) only recognises 2.5G! | 16:46 |
| Araneidae | /proc/iomem tells a curious tale, not really sure how to interpret it... | 16:47 |
| apw | Keybuk, ok ... http://people.ubuntu.com/~apw/vfs_union10-karmic/ | 16:53 |
| Keybuk | apw: if my computer burns, you owe me a new one :p | 16:55 |
| Keybuk | which reminds me, wonder what happened to the one pgraner was supposed to have sent me | 16:55 |
| apw | Araneidae, look at the e820 section of the dmesg output, tells you where your ram is | 16:56 |
| pgraner | Keybuk: I haven't sent it yet. My wife packed it my mistake (we are moving houses) and I will get it next week. Once that happens I'll drop it in FedEx. | 16:56 |
| pgraner | Keybuk: Sorry I forgot to mention it to you earlier | 16:56 |
| Araneidae | apw, it's a bit all over the place -- and it's not all there! | 16:56 |
| Keybuk | ahh, no worries | 16:56 |
| Keybuk | not in any rush, just wondered whether the postman had stolen it ;P | 16:56 |
| Keybuk | or customs | 16:56 |
| apw | Araneidae, paste the e820 in a pastebin | 16:56 |
| Araneidae | http://pastebin.com/d24698a24 | 16:56 |
| Araneidae | That's the first page of dmesg | 16:57 |
| Araneidae | I was kind of hoping 00000000 - bfffffff, but I guess that was too simple minded of me | 16:58 |
| sbeattie | smb|ogasawara: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/330824/comments/191 should probably get on your radar (as a separate bug) | 16:59 |
| ubot3 | Malone bug 330824 in linux "Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28" [Medium,In progress] | 16:59 |
| ogasawara | sbeattie: thanks | 16:59 |
| Araneidae | apw, am I just at the mercy of my BIOS here? | 17:00 |
| apw | Araneidae, uless some of the ram has been shifted over 4GB cause of the other stuff | 17:00 |
| apw | you might try booting with a pae kernel (like the server one) and see if its there | 17:00 |
| smb | sbeattie, Thanks. Yeah should be there | 17:01 |
| Araneidae | Well, there's something funning going on -- when I tried Memtest86+ it also showed 2.5G; if I tried reconfiguring memory it crashed! | 17:02 |
| Araneidae | Probe => black screen; All BIOS => many memory error messages then hang | 17:03 |
| apw | define reconfiguring memory | 17:03 |
| Araneidae | On the Memtest86+ screen it offers a couple of menu options, one is "c" => "Configure Memory" | 17:04 |
| Araneidae | This then offers a menu with a number of options, including "All BIOS" and "Probe" as well as the subset it had selected. | 17:05 |
| Araneidae | Unfortunately I'm wholly unfamiliar with this tool! | 17:05 |
| Araneidae | and with the BIOS interface it's using | 17:05 |
| mdz | is linux-meta in git as well? or just in the archive? | 17:06 |
| apw | mdz, in git as well, in the ubuntu/ubuntu-series-meta.git | 17:06 |
| smb | mdz, it is in git | 17:06 |
| Araneidae | I'm guessing my motherboard is messing me about; don't know if the kernel can do any better with what it's being told. | 17:07 |
| mdz | apw: can you translate that to a URL for me? I tried git://kernel.ubuntu.com/ubuntu/ubuntu-series-meta.git but that fails | 17:07 |
| apw | if the memory is mapped high, and that happens often when you get abover 3GB then the kernle won't see it unless its PAE enabled | 17:07 |
| mdz | apw: oh, series=karmic | 17:08 |
| apw | mdz s/series/karmic/ etc | 17:08 |
| apw | i should have said -<series>- | 17:08 |
| Araneidae | Is the Ubuntu stock kernel not PAE enabled by default? | 17:08 |
| smb | only the server kernel | 17:08 |
| * Araneidae is running Ubuntu 9.04 "out of the box" | 17:08 | |
| apw | no, we will have it avilable in karmic | 17:09 |
| Araneidae | Ahhh | 17:09 |
| Araneidae | Is there a simple package to switch to PAE? Not that keen on maintaining a separate kernel build on this machine... | 17:09 |
| ogasawara | sbeattie: just fyi I created - https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/389555. also posted a comment to 330824 | 17:09 |
| ubot3 | Malone bug 389555 in linux "[PATCH] ext4 filesystem corruption" [Undecided,Fix released] | 17:09 |
| apw | you can install the server kernel | 17:09 |
| Araneidae | Package linux-server ? | 17:11 |
| apw | linux-image-server | 17:11 |
| mdz | apw: so I have an ubuntu-karmic tree and an ubuntu-karmic-meta tree containing local changes which I would like to submit to the kernel team for review. what's the best way to do it? | 17:12 |
| mdz | commit and then format-patch? | 17:12 |
| Araneidae | Guess linux-server is a meta-package, it depends on linux-image-server and linux-restricted-modules-server | 17:12 |
| apw | yeah thats the simplest | 17:12 |
| rtg | mdz: the simplest is 'git format-patch -1 <SHA1>', then email it | 17:13 |
| apw | Araneidae, that will do the trick then | 17:13 |
| Araneidae | Ach: "There can be issues with third party drivers and the server kernel (specifically, nvidia drivers)". I'll have to suck it and see, I guess... | 17:14 |
| Araneidae | Can anybody here run `cat /proc/uptime` on a 2.6.30 kernel and tell me what it says? | 17:16 |
| apw | apw@dm$ cat /proc/uptime | 17:16 |
| apw | 270380.70 254.39 | 17:16 |
| Araneidae | Is that second, very small number, a likely measure of idle time on that machine? | 17:17 |
| Araneidae | If not, /proc/uptime is *still* broken | 17:17 |
| Araneidae | My patch didn't make it in... | 17:17 |
| apw | i'd say its a load average | 17:17 |
| Araneidae | No, it's meant to be cumulative idle time. | 17:17 |
| apw | but i don't know | 17:17 |
| Araneidae | Always was up to .28 | 17:17 |
| apw | then its broken | 17:18 |
| Araneidae | Well, damn. I'll have to try prodding everyone who was cc'd before on this. Dammit, I thought it went in. | 17:18 |
| apw | Araneidae, what was the title of the bug | 17:18 |
| apw | patch eve | 17:18 |
| apw | even | 17:18 |
| Araneidae | hang on, I'll try and hunt out the thread | 17:19 |
| apw | smb, dunno if you watching the release meeting, they are on hardy .03 | 17:19 |
| smb | apw, thanks missed it | 17:20 |
| smb | apw, Thought after kernel team it is done... :-P | 17:20 |
| apw | heh me too | 17:20 |
| apw | just luck its in another window so i saw it | 17:21 |
| Araneidae | This was my repost of the patch: http://marc.info/?l=linux-kernel&m=124265309620490&w=2 | 17:22 |
| Araneidae | There was quite a lot of traffic with titles: "linux-next: cputime tree build warning" and "[GIT PULL] cputime patch for 2.6.30-rc6" | 17:24 |
| mdz | apw: I've attached two nearly-trivial patches to bug 382115 which fix it (and bug 247517) | 17:25 |
| ubot3 | Malone bug 382115 in linux "Consider building unversioned linux-doc package" [Wishlist,Triaged] https://launchpad.net/bugs/382115 | 17:25 |
| ubot3 | Malone bug 247517 in linux "linux-doc-2.6.26 unnecessarily conflicts with other linux-doc packages" [Medium,Triaged] https://launchpad.net/bugs/247517 | 17:25 |
| Araneidae | The build warning was an annoying accident, which probably didn't help it. | 17:25 |
| apw | mdz, thanks for those | 17:26 |
| mdz | apw: is it sufficient to attach them to the bug, or would it help if I sent them to the mailing list? | 17:26 |
| apw | if you have time to send them to the mainling list then they'll get sorted sooner | 17:28 |
| mdz | apw: done | 17:30 |
| apw | thanks | 17:31 |
| rtg | apw: one of the things mdz's patch reminded me of is that we were considering the removal of generated files from the git repo, e.g., debian/control, debian/control.stub, debian/d-i/kernel, etc | 17:32 |
| rtg | that would make some of these patches a bit simpler | 17:33 |
| mdz | rtg: yeah, I was unsure about whether I should commit the autogenerated stuff or not | 17:33 |
| apw | yeah i tend to send the patches without the generated stuff and let them come in automatically for that reason | 17:33 |
| mdz | different packages handle this differently | 17:33 |
| rtg | mdz: I usually strip that stuff out when I'm integrating the patch anyways | 17:33 |
| mdz | if you want me to strip it out, that's easy enough | 17:33 |
| rtg | mdz: thats ok, we can deal | 17:33 |
| mdz | ok, thanks | 17:33 |
| rtg | apw: so, lets try it for awhile. I'll go ahead and delete those generated files. OK ? | 17:34 |
| rtg | that would also help a common packaging mistake where debian/control doesn't get regenerated correctly | 17:35 |
| apw | yeah i am down with that. | 17:35 |
| apw | as long as the packaging will clean things before making the source package we will be ok i think | 17:38 |
| apw | there was something about control needing to be there before building the src pckg which would need testing | 17:38 |
| rtg | apw: it does 'cause everything is dependent on debian/control | 17:38 |
| apw | yep, so as long as dpkg-thingy doesn't need a control to exist before it hits clean we are good, and clean is the first thing in src generation | 17:39 |
| rtg | apw: it always does a clean first | 17:40 |
| rtg | I'll practice it to make sure | 17:41 |
| apw | dpkg-buildpackage: source changed by Andy Whitcroft <apw@canonical.com> | 17:41 |
| apw | dpkg-checkbuilddeps: failure: cannot read debian/control: No such file or directory | 17:41 |
| apw | dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting. | 17:41 |
| apw | dpkg-buildpackage: warning: (Use -d flag to override.) | 17:41 |
| apw | dpkg-buildpackage: warning: This is currently a non-fatal warning with -S, but | 17:41 |
| apw | dpkg-buildpackage: warning: will probably become fatal in the future. | 17:41 |
| apw | fakeroot debian/rules clean | 17:41 |
| apw | so control may need to be there still, | 17:41 |
| rtg | I'll work on it. | 17:41 |
| === thegodfather is now known as fabbione | ||
| rtg | apw: so, I think I like the side effects of removing the auto-generated files. It pretty much forces you to generate them before you can package or build. | 17:57 |
| apw | i can live with that, the instructions need to be 'fdr clean; debuild -s .... -sa' sort of thing i guess | 17:58 |
| rtg | If we go forward with this patch, then we'd better mention it on the maintenance wiki | 17:58 |
| Keybuk | apw: err, that one panic'd on boot | 17:58 |
| apw | hrm i did what? | 17:59 |
| apw | it even? | 17:59 |
| Keybuk | apw: panic, on boot | 17:59 |
| Keybuk | somewhere in populate_rootfs | 17:59 |
| apw | before you did anything with unions ? | 17:59 |
| Keybuk | right, before it even got as far as the initramfs ;) | 17:59 |
| apw | well heck what did i do wrong there | 18:00 |
| Keybuk | no idea | 18:00 |
| Keybuk | even "ls" produces wacky output | 18:00 |
| Keybuk | d??????? ? ?? ?? grub | 18:00 |
| apw | there was a lot of porting forward for that patch, so i must have bust it | 18:00 |
| Keybuk | ls: cannot access grub: File exists | 18:00 |
| Keybuk | it looks like you screwed the VFS <g> | 18:01 |
| apw | gurgle | 18:01 |
| Keybuk | clearly it's that special time of the week that we call "Friday" | 18:02 |
| apw | yeah ... clearly | 18:02 |
| Keybuk | so I can't tell you whether the rename patch works | 18:04 |
| Keybuk | because I can't access my filesystem <g> | 18:04 |
| apw | Keybuk, any stack info for me from it? | 18:09 |
| Keybuk | apw: only that it's somewhere in populate_rootfs() | 18:11 |
| Keybuk | annoyingly someone thought the top of the stacktrace should be off the top of the screen without the ability to scroll up ;) | 18:11 |
| apw | yeah i know ... bloody thing | 18:12 |
| apw | its inevitably rename | 18:12 |
| === thegodfather is now known as fabbione | ||
| zeroprog_ | if something has a usb-ttl converter(pl2303) does that mean i can use serial i/o instead of having to write a driver? | 20:35 |
| cr3 | anyone happen to have a moment to help me understand overcommitting memory? I heard that it's possible to allocate gigabytes of memory, more than what seems to fit in the void* address space. is that right? | 20:59 |
| mjg59 | cr3: No | 21:03 |
| mjg59 | Overcommit relates to whether allocated pages are backed by real memory or swap, not whether you can have more than 3GB of address space on a 32-bit CPU | 21:04 |
| cr3 | mjg59: ok, I understand the first part but not the latter part | 21:04 |
| cr3 | mjg59: to have more than 3GB, is the address still allocated on the heap somehow? | 21:05 |
| mjg59 | You can't allocate more than 3GB on a 32-bit CPU | 21:06 |
| cr3 | mjg59: my bad, I misread "not whether" as "or whether". heh, maybe it was wishful thinking :) | 21:07 |
| mjg59 | PAE means you can have more than 4GB of RAM for the platform | 21:08 |
| mjg59 | But each process can only have 3GB in its address space | 21:08 |
| mjg59 | What you /can/ do is use shared memory segments (backed by RAM) as if they're files | 21:08 |
| mjg59 | Oracle does that | 21:08 |
| cr3 | mjg59: gotcha, all makes sense again. I was given a false impression of what overcommitting really is. thanks! | 21:09 |
| cwillu | johanbr, 2.6.29's suspend was working fine for me today under karmic's userspace | 22:08 |
| johanbr | alright :) | 22:09 |
| johanbr | so it's a problem with 2.6.30... | 22:09 |
| cwillu | surprise surprise :p | 22:16 |
| johanbr | you'd filed a bug, right? | 22:18 |
| johanbr | did you add that information to the bug? | 22:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!