| === zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel | ||
| zul | heylo | 12:06 |
|---|---|---|
| jbailey | Zool. | 12:06 |
| zul | hey jeff, i told you i would start tonight | 12:07 |
| makx | jeff i know almost zero about alpha asm. | 12:07 |
| zul | alpha...bleah...weirdos | 12:09 |
| makx | hehe | 12:10 |
| === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel | ||
| === doko [n=doko@dslb-084-059-072-095.pools.arcor-ip.net] has joined #ubuntu-kernel | ||
| BenC | lamont-away: ping | 02:21 |
| jbailey | makx: Alpha asm isn't that hard, really. | 03:14 |
| jbailey | ia64 asm confuses the !@#$ out of me. | 03:15 |
| === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel | ||
| mgalvin | just noticed that the linux-kernel-headers-2.6.15-8-686 has a small typo, it is... | 03:21 |
| mgalvin | Linux kernel headers 2.6.15 on PPro/Celeron/PII/PIII/PIV SMPP | 03:21 |
| mgalvin | and i think it should be | 03:21 |
| mgalvin | Linux kernel headers 2.6.15 on PPro/Celeron/PII/PIII/PIV SMP/UP | 03:21 |
| mgalvin | in the package description | 03:22 |
| mgalvin | or maybe its just that there is an extra "P" | 03:22 |
| === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel | ||
| lamont-away | BenC: ack | 04:02 |
| zul | well that was a good movie | 05:06 |
| infinity | Which movie? | 05:14 |
| BenC | lamont-away: hey, you know anything about ia64 interp loading? :) | 05:29 |
| lamont-away | no. | 05:31 |
| BenC | klibc bins work when they are static | 05:32 |
| BenC | but dynamic is broken | 05:32 |
| fabbione | morning guys | 05:32 |
| BenC | hey fabio | 05:32 |
| BenC | lamont-away: I booted an initramfs on the i2k today with static bins :) | 05:33 |
| infinity | Well, that's sort of progress. | 05:35 |
| infinity | I'm still this --><-- close to just dumping klibc entirely, building the one or two helper binaries it provides aginst glibc instead, and calling it a day. | 05:35 |
| lamont-away | so why didn't my hppa machine running breezy autodetect the SCA SCSI drive when it got plugged into the hot-swap bay> | 05:36 |
| lamont-away | crw-rw---- 1 root tape 9, 0 Dec 15 20:41 /dev/st0 | 05:41 |
| lamont-away | wonder if we can drive that beast... | 05:41 |
| fabbione | lamont-away: pretty sure we can | 05:43 |
| fabbione | tar is your friend : | 05:43 |
| fabbione | :) | 05:43 |
| lamont-away | fabbione: not when the machine is 20 miles away, with no tape in the mech. | 05:46 |
| fabbione | well.. that really doesn't help :) | 05:46 |
| fabbione | how old is that thing? | 05:46 |
| fabbione | i had one for a while (scsi tape, that's it) | 05:46 |
| fabbione | but i had to force a bunch of options to tar, like block size and such | 05:46 |
| jbailey | infinity: It would certainly be the simpler solution, with the downside that then we'd never get silly small initramfs' | 05:47 |
| fabbione | otherwise the device was just answering back: GET A LIFE. KTHXBYE | 05:47 |
| jbailey | infinity: But klibc is really an undertested piece of shit. | 05:47 |
| jbailey | As amusing as it's been to hack on it. | 05:47 |
| lamont-away | st: Version 20050312, fixed bufsize 32768, s/g segs 256 | 05:48 |
| lamont-away | Attached scsi tape st0 at scsi0, channel 0, id 3, lun 0 | 05:48 |
| lamont-away | st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 917504 | 05:48 |
| lamont-away | these machines were selling in 2000 | 05:49 |
| fabbione | it should be new enough to autoset block size :) | 05:49 |
| fabbione | mine was older than that | 05:49 |
| infinity | jbailey : I don't suppose there's a hope in hell of building a slightly reduced glibc in some hackish way? | 05:58 |
| infinity | jbailey : Still, even without said possibility, I think what we gain from klibc isn't worth the pain. | 05:58 |
| jbailey | infinity: Well, if you'd like I can fork off the utilities into a separate package, or we can try to get them integrated into busybox. | 05:59 |
| jbailey | I don't know the BB folks at all. | 06:00 |
| jbailey | It does crush my dream of the 100k initramfs, though. =) | 06:00 |
| Mithrandir | jbailey: dude, casper alone is 50k. :-) | 06:01 |
| Mithrandir | I should reduce the number of files it consists of | 06:01 |
| Mithrandir | it's 10.6k of text | 06:01 |
| infinity | jbailey : We can revisit your dream another day, but I think glibc is the saner way to go for now. | 06:02 |
| infinity | jbailey : It will actually reduce the size of our initramfs in the short term (since glibc keeps ending up in there anyway right now) | 06:02 |
| infinity | jbailey : And it'll allow more widespread adoption in Debian, which is a Good Thing. | 06:02 |
| jbailey | Mithrandir: I think my first boot-use initramfs was like 20k. =) | 06:03 |
| jbailey | infinity: 'kay. I'll look at that tomorrow then. | 06:03 |
| jbailey | infinity: Hopefully it's anoher slow day on the support side like today was. | 06:03 |
| jbailey | (And unlike today, hopefully tomorrow I'l even be alert) | 06:04 |
| === lamont-away reboots just to find another harddrive. stupid hotplug | ||
| === lamont [n=lamont@mix.mmjgroup.com] has joined #ubuntu-kernel | ||
| Mithrandir | BenC: any reason why SMP is not enabled in the amd64-generic kernel? | 09:50 |
| === crispin [n=crispin@cpc1-cmbg8-4-0-cust246.cmbg.cable.ntl.com] has left #ubuntu-kernel [] | ||
| BenC | Mithrandir: because there's amd64-k8-smp? | 01:17 |
| Mithrandir | BenC: not on the live cd | 01:18 |
| BenC | amd64-generic is like -386, which is not SMP either | 01:18 |
| Mithrandir | can we change that? | 01:19 |
| BenC | SMP is a performance hit | 01:19 |
| Mithrandir | I thought you had the lock rewriting patch in place? | 01:19 |
| BenC | for x86 | 01:19 |
| Mithrandir | can you port it to amd64 and apply it there too? :-) | 01:19 |
| Mithrandir | smp is fairly common on amd64 and will be more so with dualcores | 01:20 |
| BenC | I couldn't but I've no way to test it easily | 01:21 |
| BenC | could | 01:21 |
| Mithrandir | what's the easiest way to test it? Boot and see if it blows up? | 01:21 |
| BenC | pretty much | 01:21 |
| Mithrandir | I could test it easily enough for you, then | 01:21 |
| BenC | ok, it wont be in -9.11, but I'll see if I can get it ready for the next one | 01:22 |
| Mithrandir | cool, thanks. | 01:23 |
| Mithrandir | I'm on vacation from Wednesday until Jan 1st, so no hurry. | 01:23 |
| jbailey | BenC: I have an amd64 here as well, UP though. | 01:27 |
| BenC | nm, that was easier than I thought | 01:30 |
| BenC | it will be in -9.11 | 01:30 |
| BenC | which means that there wont be a -k8-smp | 01:30 |
| Mithrandir | coolie. Any ETA on that? | 01:32 |
| Mithrandir | or, when can I test it? | 01:33 |
| BenC | I can try doing a build on concordia later | 01:34 |
| Mithrandir | great, thanks. | 01:34 |
| BenC | jbailey: well UP is what I want tested, the patch is pretty much a nop on real SMP | 01:34 |
| fabbione | hey Ben | 01:35 |
| fabbione | i also have UP amd64 | 01:35 |
| fabbione | so /me can test | 01:35 |
| jbailey | BenC: Cool lemme know. | 01:36 |
| BenC | cool, thanks | 01:36 |
| jbailey | BenC: Especially if all these lazy sods go on holidays sooner than you're ready. | 01:36 |
| BenC | hehe | 01:36 |
| fabbione | i will have holidays... around the house.. *FUN* | 01:37 |
| BenC | yeah, that's what my holidays look like | 01:37 |
| BenC | fabbione: get used to that, with kids :) | 01:37 |
| fabbione | BenC: yeah i know.. | 01:38 |
| fabbione | this time is more like because my wife needs to work | 01:38 |
| fabbione | she doesn't have holidays | 01:38 |
| === lbm [n=lbm@x1-6-00-13-10-7a-d1-e4.k233.webspeed.dk] has joined #ubuntu-kernel | ||
| infinity | BenC : While we're talking SMP/UP hacks, why does -386 not do SMP, now that you have the crazy hack in there? | 01:58 |
| BenC | because some drivers are not SMP safe | 01:59 |
| BenC | legacy things | 01:59 |
| BenC | they wont even compile when CONFIG_SMP is enabled, or if they do, they wont load because they use things like cli() that is not exported with SMP builds | 01:59 |
| infinity | Ahh, shame. | 01:59 |
| infinity | Since we use -386 on the LiveCD, SMP could be a win there. | 02:00 |
| BenC | with amd64 it's not so bad, since we don't have to worry about ISA slot ethernet and scsi cards | 02:00 |
| infinity | (That's why Mithrandir was whining about amd64-generic, it's the LiveCD kernel, and he has SMP machines) | 02:00 |
| BenC | yeah, I can't really do that without killing a whole lot of hw support...the sorts of things people really whine about | 02:01 |
| infinity | Oh well. | 02:01 |
| infinity | Will this patch eventually find its way into powerpc as well? | 02:02 |
| Mithrandir | can we switch to 586 or 686 kernels for the live i386 CD? | 02:03 |
| Mithrandir | it's not like the live cd will work well on a 486 anyway.. | 02:03 |
| Mithrandir | it will work, albeit slowly, on the last machine I had with ISA, at least | 02:03 |
| infinity | The last machine I had with ISA was still pretty fast, but I'll admit I didn't have any ISA cards in there that would use scary SMP-unsafe drivers. | 02:04 |
| Mithrandir | I'm sure you could come up with contrived cases, but they would be that, contrived. Especially if you can do something like "nosmp" on the kernel command line to force UP | 02:05 |
| BenC | ppc is a bigger animal | 02:05 |
| BenC | mithrandir: nosmp doesn't fix the drivers not loading, and is generally moot now with smp2up kernels | 02:06 |
| jbailey | Mithrandir: One of the TODO items in the ToolchainRoadmapNg is to figure out if we can drop pre-686 | 02:07 |
| BenC | well, nosmp isn't useless I guess on SMP machines | 02:07 |
| jbailey | Mithrandir: So far noone has said no. | 02:07 |
| Mithrandir | BenC: that's not fixable, I presume? | 02:07 |
| Mithrandir | jbailey: buntu? | 02:07 |
| jbailey | Mithrandir: Right. Per-i686 can use buntu instead. | 02:07 |
| jbailey | No need to have the whole distro ready for them. | 02:07 |
| BenC | Mithrandir: not without fixing a driver that has been limping in the kernel source tree with no maintainer for 7+ years :) | 02:07 |
| Mithrandir | BenC: which one is that, and why do we care? :-) | 02:07 |
| BenC | actually we could just have a 686 kernel with generic code for non-686 | 02:08 |
| BenC | Mithrandir: there's a few dozen of them | 02:08 |
| BenC | and the users care | 02:08 |
| Mithrandir | bah, stupid users. It's probably easier just to ship them newer hardware | 02:09 |
| BenC | I'm getting bug reports for dapper about old ass scsi cards | 02:09 |
| BenC | jbailey: we could have a 686 optimized kernel that could still run on 486 | 02:09 |
| Mithrandir | I don't envy you. :-) | 02:09 |
| jbailey | BenC: Don't you lose superpages and CMOV then, though? | 02:10 |
| jbailey | BenC: And the point is really, why do we care? | 02:10 |
| BenC | me personally, I was happy saying you needed PPro or better, but others said "no" :) | 02:11 |
| jbailey | In practice we don't actually support pre-i686 when you look at us not supporting isa-pnp, EISA, VLB. We provide openoffice, a pile of heavy screensavers, require 2GB to install, etc... | 02:11 |
| Mithrandir | jbailey: I had 2GB drives fifteen years ago. | 02:11 |
| jbailey | Someone who wants a smaller system than that (say, for an edge router) can use buntu | 02:11 |
| jbailey | Mithrandir: Right. It would've been *full* | 02:11 |
| Mithrandir | a few years later I had 486 machines without ISA or EISA. | 02:12 |
| === BenC had an 80Meg hd for his first win95 machine | ||
| BenC | just barely fit | 02:12 |
| jbailey | Mithrandir: Nice, so those machines would at least boot. | 02:12 |
| jbailey | Mithrandir: As long as you did a minimum install. | 02:12 |
| BenC | that 80meg hd became my first debian install | 02:12 |
| Mithrandir | jbailey: do we support MCA? :-) | 02:13 |
| jbailey | Mithrandir: You're still not arguing why it needs a full Ubuntu setup. | 02:13 |
| jbailey | Mithrandir: I don't think so. | 02:13 |
| BenC | personally, I think it's too late in the game for dapper to do anything about 386 install CD | 02:13 |
| Mithrandir | oh, then it's not supported after all. | 02:13 |
| jbailey | I'm not sure that code is even still in the Kernel. | 02:13 |
| BenC | we really need more testing on it | 02:13 |
| === jbailey hates the old PS/2 | ||
| BenC | post dapper i have two huge specs I'm writing | 02:13 |
| jbailey | Half a computer, designed to run half an operating system. | 02:13 |
| BenC | will change the way kernels are maintained for distros...FOREVER!!! | 02:13 |
| BenC | muhahaha | 02:13 |
| fabbione | BenC: are we going to use that bootloader that builds the kernel at boot | 02:14 |
| fabbione | ? | 02:14 |
| fabbione | ehehhe | 02:14 |
| BenC | hehe | 02:23 |
| BenC | nah, just all these people complaing about their drivers being fixed in dapper, but not working in breezy has me thinking | 02:24 |
| BenC | not sure how, but I want a better way to handle that | 02:24 |
| infinity | A package for each driver, so you can do selective driver updates! YAY! | 02:29 |
| infinity | Cause that's "intuitive" to Windows users... Or something. | 02:29 |
| fabbione | infinity: you won't be the first one suggesting that | 02:29 |
| === zul_ [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel | ||
| BenC | looking more along the lines of MacOSX | 02:29 |
| === zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel | ||
| zul | heylo | 02:29 |
| fabbione | hi zul | 02:30 |
| BenC | like driver groups: USB Subsystem, SCSI, IDE, ATA, Sound, etc, etc | 02:30 |
| zul | hey fabbione how is it going? | 02:30 |
| fabbione | BenC: how do you plan to cope with ABI's? | 02:30 |
| fabbione | zul: not too bad.. my teeth are still hurting, but i will survive | 02:30 |
| zul | hmmm...whats going on? | 02:30 |
| BenC | fabbione: this is mainly for released systems | 02:30 |
| zul | fabbione: oh that sucks.. | 02:30 |
| zul | we are suppose to be getting 25cm of snow today | 02:30 |
| fabbione | zul: had a couple of extra holes without anestesia..(or whatever is spelled) | 02:31 |
| zul | ouchie | 02:31 |
| BenC | fabbione: but handling an ABI bump post release like we had for breezy is an issue that needs to be addressed | 02:31 |
| BenC | fabbione: dentists suck :( | 02:31 |
| === slushpupie [i=jay@slushpupie.com] has joined #ubuntu-kernel | ||
| fabbione | BenC: well it's an issue.. but i don't think we have any other solution | 02:31 |
| fabbione | BenC: speaking of extra drivers people compiles on top of our kernels | 02:32 |
| BenC | fabbione: one thing is maybe being able to pinpoint which driver groups are affected by the ABI bump | 02:32 |
| zul | whats happeing with ABI? | 02:32 |
| BenC | for example, and ABI change in skbuff shouldn't affect sound | 02:32 |
| === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel | ||
| BenC | an ABI chance in ACPI may not affect most drivers directly | 02:32 |
| fabbione | BenC: well the point is you can only check what's in the stock kernel | 02:32 |
| fabbione | BenC: but like we had last time, there was a new entry in a struct that did look innocent | 02:33 |
| zul | *sigh* ill go read the logs then | 02:33 |
| fabbione | but it did trash ABI all over | 02:33 |
| BenC | zul: sorry, talks about post-dapper handling of released kernels | 02:33 |
| zul | ah ok | 02:33 |
| BenC | fabbione: but we have diffs of affected symbols, which can be cross checked with symbols that the drivers need | 02:34 |
| BenC | so it's easy to take the abi chances and flag the drivers affected | 02:34 |
| BenC | changes | 02:34 |
| === BenC hasn't finished a cup of coffee yet this morning | ||
| BenC | fabbione: it's sort of like doing it for libraries | 02:35 |
| BenC | hacking up some of the module-init-tools code should make it easy to show a chain of affected drivers from the breaking build to the next | 02:36 |
| BenC | s/next/previous/ | 02:36 |
| BenC | fabbione: for example, if the kernel security fixes don't change ABI, and no driver code is touched, then the security upload really only needs vmlinuz, not the whole 57 megs of modules | 02:38 |
| BenC | if the security fix only touches netfilter, with no ABI change, then no reason to install a whole new kernel | 02:38 |
| infinity | While it's all well and good to limit the amount of stuff we force users to download, it also does seem to make the whole process a bit harder to handle. | 02:55 |
| infinity | Not tracking ABIs, that can be automated, but tracking package versions in general starts making it harder for people doing support, etc. | 02:56 |
| BenC | making it easy to handle is my goal | 02:56 |
| infinity | Right now, I can say "do you have kernel X.XX installed?" | 02:56 |
| infinity | Later, it'll be "do you have kernel X.XX, and scsi-modules Y.YY, and blah blah?" | 02:56 |
| infinity | And unless we just assume everyone's always up-to-date, the package combinations get much scarier. | 02:57 |
| BenC | but doing full kernel builds for upgrades post release limits us to what we can update | 02:57 |
| BenC | infinity: then we just make a tool that spits all that information out | 02:57 |
| infinity | I assume your real end goal here is to be able to push driver updates? | 02:57 |
| BenC | updates in general, but yes, that's the main goal | 02:58 |
| BenC | the problem is, it will require a whole new build system (for the buildd's) | 02:59 |
| BenC | you wont be able to build it like we do now, unless we start splitting up the source, which is a big no-no | 02:59 |
| jbailey | BenC: Given the length of time it's taking to get Soyuz even basically online, much less actually meeting everyone's needs, I suspect you won't see much in the way of build structure changes even through dapper+1 | 03:04 |
| infinity | I think he meant a whole rethink to the linux-source package structure and debian/rules, but maybe I'm wrong. | 03:06 |
| infinity | ie: shipping a source package, build-depending on it, building modules from it, or something like that. | 03:06 |
| jbailey | Ah, okay. =) | 03:08 |
| === crimsun [n=crimsun@pdpc/supporter/silver/crimsun] has joined #ubuntu-kernel | ||
| zul | so scsi-modules-x.x.x.y or something? | 03:09 |
| BenC | infinity: basically yes, but we need to not rebuilt parts that haven't changed from the last release | 03:25 |
| BenC | or atleast not repackage it | 03:25 |
| BenC | but that idea conflicts with the whole source+bin versioning scheme that we currently have | 03:26 |
| === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel | ||
| fabbione | BenC: i am pretty sure if the idea is valid, there is no reason to stick with the schema we have | 03:29 |
| BenC | fabbione: when I say "source+bin version scheme", I mean the one that katie expects | 03:33 |
| BenC | like if we do a full build of 2.6.15-8.10, and get all the .deb's from that, and then build 2.6.15-8.11, and only scsi-modules.deb is changed, katie wouldn't like getting a .changes for linux-source-2.6.15 with just that package | 03:34 |
| fabbione | right | 03:38 |
| fabbione | there is no way to solve that easily afaict | 03:38 |
| BenC | I can think of a way, but it's way too evil :) | 03:39 |
| BenC | elmo would probably kill me | 03:40 |
| fabbione | such as? | 03:40 |
| BenC | creating somewhat fake .tar.gz sources for each component, and build-dep on the real kernel source | 03:41 |
| fabbione | ahahah | 03:41 |
| fabbione | i did that for fake modular X | 03:41 |
| fabbione | nothing new about it | 03:41 |
| fabbione | you will end up in a mess to port patches around | 03:41 |
| BenC | doesn't make it any less evil :) | 03:41 |
| BenC | well the main kernel-source tree would spit out the seperate sources, so it all comes from the same place | 03:42 |
| jbailey | BenC: When we were talking about doing almost-free Java, there were some things that couldn't be built with the free java compiler, but could were free themselves and ran on free software. | 03:43 |
| BenC | sounds like a hack though, I'd rather come up with something that isn't trying to work around katie | 03:43 |
| fabbione | that would kill the idea of building everything from the same source | 03:43 |
| jbailey | BenC: I had proposed a binary package with some .o's in multiverse that could just be installed as needed, so the rest of the package was ready to move to universe as soon as those were resolved. =) | 03:43 |
| BenC | jbailey: hehe, nice | 03:43 |
| fabbione | BenC: probably the ideal situation would be the concept of source source | 03:44 |
| fabbione | super source | 03:44 |
| BenC | wasn't there a way to upload rebuilt binaries without source? I seem to recall doing that a lot for the sparc buildd | 03:44 |
| fabbione | you upload source1 that generates new sources .tar.gz, diff.gz and .dsc -> autoreupload -> process again till you get only binaries | 03:44 |
| jbailey | We only have source uploads in Ubuntu. | 03:44 |
| === Traxer|off [i=traxer@shell6.powershells.de] has joined #ubuntu-kernel | ||
| fabbione | BenC: that'd be binNMU, but we don't do them here | 03:45 |
| BenC | like of foo-1.1-0 was built with the wrong compiler, instead of waiting for foo-1.1-0.1, just rebuild it somehow with no change in source package | 03:45 |
| fabbione | BenC: yeps.. binNMU | 03:45 |
| BenC | jbailey: but maybe a source upload that gets built wont build all the binaries everytime | 03:46 |
| BenC | that's basically what I need to happen to make this work | 03:46 |
| fabbione | BenC: that would make other katie's sisters crazy to keep the pool clean of old junk | 03:46 |
| BenC | interdepencies handled on the fly at build-time based on ABI changes and such | 03:46 |
| BenC | fabbione: right | 03:46 |
| fabbione | because you lose relation ship between source and binary versions | 03:47 |
| BenC | basically it would need to track if the new source superseded a certain binary, but not mark the old debs that didn't change as "obsolete" | 03:47 |
| zul | brb...my terminals are all screwy | 03:48 |
| BenC | would be nice if the debs that didn't change could have their relationship changed to the new source | 03:48 |
| BenC | since they didn't change, then the new source would build them just the same anyway | 03:48 |
| jbailey | Mmm, right. | 03:48 |
| BenC | basically the same way that the .dsc refers to a .orig.tar.gz that is already in the dist, but not uploaded | 03:49 |
| BenC | could add the md5sums of the original packages to reroute to the new source, and mark them as "existing" somehow | 03:50 |
| === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel | ||
| infinity | BenC : The archive scemantics won't change anytime soon, but the "build-dep on a master source package" thing has been done many times before. | 04:33 |
| infinity | BenC : Then you just package the modules as tiny debian-native packages that build-dep on the kernel source, and build the right subset of modules. | 04:33 |
| fabbione | infinity: i don't think we want to go there | 04:34 |
| BenC | infinity: not sure it would work though | 04:34 |
| fabbione | that's the whole point of why we build everything from one source | 04:34 |
| infinity | It works well enough. It's ugly, though. | 04:34 |
| BenC | MODPOST embeds info in each module about it's deps, but all modules have to be built in order to do that | 04:34 |
| BenC | fabbione: it would still be one source, just meta-source packages to make the archive happy | 04:35 |
| infinity | Nowhere near as ugly as a source package that only occasionally builds binary packages, and leaves packages with out-of-sync versions. | 04:35 |
| BenC | but it wont work for this case | 04:35 |
| BenC | infinity: that can be fixed with changes to the source+archive system | 04:35 |
| infinity | Like I said. Not gonna change anytime soon. | 04:35 |
| BenC | probably not, but that doesn't mean it wont ever change...the whole goal is probably a dapper+2 thing anyway | 04:36 |
| infinity | The problem is that binaries are tied to the source that BUILT them, not the source you uploaded later. | 04:36 |
| infinity | ie: nic-modules_1.2.3 -> linux-source_4.5.6, but scsi-modules_1.2.3 -> linux-source_9.8.7 | 04:37 |
| BenC | that's why it would need archive changes, to reassociate older version debs to newer version source (source that still builds that same deb) | 04:37 |
| infinity | Since we can't regenerate nic-modules to say "no wait, we actually came from the newer source package, even though we didn't!", we either have to keep all the source revisions around, or we've broken the world. | 04:37 |
| infinity | No guarantees that the old deb would build from the new source without actually building it. | 04:38 |
| infinity | Some say that's a GPL violation. | 04:38 |
| BenC | of course there is | 04:38 |
| infinity | Others just call it problematic in general. | 04:38 |
| BenC | because the build system checks that | 04:38 |
| BenC | if it wasn't the same, it would upload the new version | 04:38 |
| infinity | And the binary->source relationship is actually in DEBIAN/control in the binary package. So you're altering the .deb to fix it. | 04:38 |
| BenC | the whole point being that it only uploads when the build is different from the previous | 04:39 |
| infinity | And whe nyou alter the .deb, people have to download it again, cause the md5 differs. | 04:39 |
| BenC | infinity: I was just thinking of Packages.gz overrides | 04:39 |
| BenC | anyway the package only refers to the source package by name, not version | 04:39 |
| infinity | Nope, does both, if the versions don't match. | 04:39 |
| === BenC points to breezy lrm for examples of debs with different versions than the source | ||
| infinity | apt-cache show php4-imap | 04:40 |
| infinity | Source: php-imap (5.0.5-1) | 04:40 |
| infinity | Version: 4:5.0.5-1 | 04:40 |
| BenC | it will always show just linux-source-2.6.15 though | 04:40 |
| infinity | If binary version != source version, we include source version in the metainfo so we can tie them. | 04:40 |
| BenC | and apt-cache source linux-source-2.6.15 will always pull the latest | 04:40 |
| BenC | and the latest is assumed to build it, otherwise there would be a new deb | 04:41 |
| BenC | infinity: that's just for the archive management | 04:41 |
| infinity | yes... Which is what we're talking about. | 04:41 |
| BenC | yeah, but it's a different case than this | 04:41 |
| BenC | and very hard to explain non-verbal like | 04:42 |
| infinity | No. If scsi-modules.deb gets uploaded, but nic-modules.deb doesn't, then nic-modules.deb now refers to obsolete source. | 04:42 |
| BenC | infinity: that's where the archive changes come in | 04:42 |
| BenC | the new upload would reference the old nic-modules, so the archive could internally associate it to the new source | 04:42 |
| BenC | and hence keep things sane | 04:43 |
| infinity | We're pretty anal about GPL binary/source compliance (specifically because we don't provide the n-year offer) | 04:43 |
| BenC | the archive would say "ok, old nic-modules can be built with this new source, so treat it like such" | 04:43 |
| BenC | infinity: you miss the point | 04:43 |
| infinity | So, how do we KNOW that the old nic-modules will build the same from the new linux-source? | 04:44 |
| BenC | infinity: if nic-modules DOES NOT get uploaded, the new source builds it the same | 04:44 |
| infinity | (not how do YOU know in your debian/rules, but how do WE (the archive) know?) | 04:44 |
| BenC | otherwise the build system would upload it aswell | 04:44 |
| BenC | uh, because that's the way it will work? | 04:44 |
| BenC | if the source for a module changes, the binary gets rebuilt | 04:44 |
| infinity | And if there's an error in your rules file where a package just doesn't get built? :) | 04:44 |
| BenC | and a new package is uploaded for it | 04:44 |
| BenC | infinity: now you're being pedantic :) | 04:45 |
| BenC | the bug would obviously have to be fixed, but assuming it all works as expected, then there is no violation | 04:45 |
| infinity | I dunno. You're welcome to pitch it to Kinnison/elmo for launchpad candy, but I think it's pretty sketchy, personally. | 04:45 |
| infinity | And for very little gain. Kernel updates aren't THAT big. | 04:45 |
| BenC | 22megs isn't that big? | 04:46 |
| infinity | Not these days. | 04:46 |
| BenC | when someone wants to update breezy just to fix their usb card reader, 22megs is a lot | 04:46 |
| BenC | I have a shit load of bugs that I cannot get verified because people are on dialup | 04:46 |
| infinity | Which is solved just by splitting out the subsystems into packages, and allowing people to download just some. | 04:47 |
| infinity | No one's forcing them to grab all of them to test a bugfix. | 04:47 |
| jbailey | I AM, ROAR! | 04:47 |
| jbailey | err | 04:47 |
| jbailey | inside voice, jeff. | 04:47 |
| infinity | <laugh> | 04:47 |
| BenC | IMO, the source hackery is just working around limitations int he archive | 04:47 |
| BenC | the whole reason we have ABI in the kernel now is for this exact reason | 04:48 |
| BenC | and we use it with things like lrm | 04:48 |
| BenC | what I'm talking about is extending that, but without having to split up into half a dozen source packages | 04:49 |
| infinity | And splitting into source packages is bad.. Why? | 04:49 |
| infinity | Either way, you're proposing you rebuild the whole kernel, but only upload a few modules. One way works, the other requires a fundamental rethink of how the whole archive works. | 04:49 |
| BenC | because the kernel is not split upstream? | 04:50 |
| BenC | makes maintaining it harder | 04:50 |
| BenC | and plus we cannot do partial module build | 04:50 |
| infinity | So, don't split the source. Distribute the patched source as a package. | 04:50 |
| BenC | they have to be all built at once | 04:50 |
| BenC | and I don't want to do full builds for scsi/ide/nic/acpi/usb/etc | 04:50 |
| infinity | (Any valid reason they all have to be built together?) | 04:51 |
| BenC | MODPOST scans all the modules and saves the inter-module dependencies in the .ko | 04:51 |
| infinity | That seems to happen anyway. | 04:52 |
| BenC | we can do without that because of depmod, but then we can't make usb-nic depend on ieee80211 without manual checking | 04:52 |
| infinity | Note, for instance, modinfo nvidia shows a dependency on agpgart. | 04:52 |
| BenC | infinity: if I only builds drivers/scsi/, it wont happen | 04:52 |
| BenC | infinity: that's because the symvers are in the linux-headers file | 04:53 |
| BenC | brb, smoke | 04:53 |
| infinity | I think I'll have to ^z this argument until another day. It's 3am and I'm passing out. | 04:54 |
| zul | BenC: but the modinfo is not always uptodate because some of the nic drivers dont export all of their information | 04:56 |
| BenC | zul: we're not talking about that part of modinfo | 04:58 |
| BenC | just inter-module deps | 04:58 |
| BenC | the symbols it needs are always know (they have to be) | 04:59 |
| BenC | same with any symbols that are exported | 04:59 |
| BenC | but connecting them to the module that needs it, or provides it, requires those modules to be around, or the symvers file | 04:59 |
| zul | heh...i guess i shouldnt have jumped in | 05:05 |
| zul | BenC: couldnt you write a helper script like whe do with kernel-headers, ie: this deb depends on this blah blah | 05:11 |
| === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-kernel | ||
| === mjg59 [n=mjg59@cavan.codon.org.uk] has joined #ubuntu-kernel | ||
| lucasvo | 25.594 /w 12 | 06:01 |
| === lamont [n=lamont@mib.fc.hp.com] has joined #ubuntu-kernel | ||
| zul | bleah.. | 07:18 |
| === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel | ||
| zul | BenC: hey BenC | 07:44 |
| BenC | hey | 07:44 |
| === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-kernel | ||
| === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel | ||
| zul | BenC: you might want to post your idea to the kernel mailing list but i know all the cool people hang out here | 07:47 |
| BenC | this is way off, I don't want to take focus off things that need to be done for dapper | 07:47 |
| zul | ah ok | 07:47 |
| BenC | once dapper is near release, I'll have a full spec, some code and testing setup | 07:47 |
| fabbione | BenC: i just got ia64 and hppa :) | 07:53 |
| BenC | sweet | 07:54 |
| zul | so how many is that you have now? | 08:02 |
| fabbione | zul: 7 different arches.. | 08:06 |
| fabbione | about hmm.... | 08:06 |
| fabbione | 6 i386 active, 1 amd64, 1 ppc, 1 hppa, 2 sparcs, 1 ia64, 2 m68k | 08:07 |
| zul | hmm...my wife would kill me if i had that many | 08:07 |
| zul | powered on at the same time? | 08:07 |
| fabbione | and i think i have at least 2/3 i386 that i could mount from spare parts | 08:07 |
| fabbione | zul: rarely | 08:08 |
| zul | ah.. | 08:08 |
| zul | 3 x86, 2 sparcs is it for me | 08:08 |
| fabbione | brb | 08:11 |
| === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-kernel | ||
| fabbione | it's food time | 08:12 |
| dilinger | o/~ stop! hammer time o/~ | 08:20 |
| dilinger | i haven't heard from davem since he got the sunfire | 08:22 |
| dilinger | i hope it didn't fall over and crush him or something ;p | 08:22 |
| fabbione | dilinger: he got it | 08:23 |
| fabbione | but it was half smashed | 08:23 |
| fabbione | it still works tho | 08:23 |
| === ispiked [n=ispiked@unaffiliated/ispiked] has joined #ubuntu-kernel | ||
| dilinger | yea, i know | 08:23 |
| fabbione | it looks like that either it was hitten or you didn't put enough foam on the front side | 08:23 |
| fabbione | but he got it to boot again | 08:23 |
| dilinger | i spent $20 on foam :( | 08:24 |
| dilinger | it was hard to get around it, though, due to the weight | 08:24 |
| fabbione | well it's not too bad.. at least it is not completely broken | 08:24 |
| fabbione | food time for me | 08:25 |
| fabbione | later | 08:25 |
| === crimsun [n=crimsun@pdpc/supporter/silver/crimsun] has joined #ubuntu-kernel | ||
| zul | wohoo...i dont have to shovel when i get home | 08:46 |
| jbailey | zul: You know, they have stores that sell those sorts of things. | 08:51 |
| zul | jbailey: :P im talking snow...sicko | 08:57 |
| jbailey | Oh! Whups. I thought you said "I don't have *a* shovel" | 08:58 |
| zul | yeah then i would have to bend over...nah... | 09:00 |
| === slushpupie [i=jay@slushpupie.com] has left #ubuntu-kernel [] | ||
| === slushpupie [i=jay@slushpupie.com] has joined #ubuntu-kernel | ||
| zul | later | 09:54 |
| === crimsun [n=crimsun@pdpc/supporter/silver/crimsun] has joined #ubuntu-kernel | ||
| makx | jbailey: vorlon's patches are verified by another succesfull boot on alpha | 10:07 |
| makx | would be cool if his alpha statfs64 fix could be tested on another 64 bit arch to exclude regressions | 10:10 |
| makx | http://aipc50.ai.wu-wien.ac.at/~attems/klibc-342931-statvfs.diff | 10:10 |
| dilinger | hrmph | 10:13 |
| dilinger | PGP/GnuPG signature check failed on mysql++_2.0.7-1_i386.changes | 10:13 |
| dilinger | gpg: Signature made Fri Dec 16 13:02:46 2005 PST using DSA key ID CFD42F26 | 10:13 |
| dilinger | gpg: Can't check signature: public key not found | 10:13 |
| dilinger | (Exit status 2) | 10:13 |
| dilinger | mysql++_2.0.7-1_i386.changes has bad PGP/GnuPG signature! | 10:13 |
| dilinger | Removing mysql++_2.0.7-1_i386.changes, but keeping its associated files for now. | 10:13 |
| === dilinger contemplates just going through the ubuntu uploader process and just uploading there | ||
| === Tonio_ [n=tonio@tonio.planetemu.net] has joined #ubuntu-kernel | ||
| Tonio_ | hi everyone | 10:51 |
| Tonio_ | little problem with latest kernel update..... | 10:51 |
| Tonio_ | tun device doesn't seem to work anymore | 10:51 |
| Tonio_ | sudo modprobe tun && ifconfig -a | 10:51 |
| Tonio_ | that gives me nothing | 10:51 |
| Tonio_ | was tun/tap option activated in the latest kernel ? | 10:52 |
| fabbione | yes | 10:56 |
| fabbione | you need to create the tunnels first | 10:56 |
| fabbione | iptunnel or ip are your friends | 10:56 |
| === fabbione heads for bed | ||
| fabbione | good night | 10:57 |
| lucasvo | is there any bot here? | 10:59 |
| Tonio_ | fabbione: you mean creating the tun device ? | 11:17 |
| Tonio_ | already done.... | 11:17 |
| Tonio_ | mkdir /dev/net && mknod /dev/net/tun c 10 200 | 11:17 |
| Tonio_ | doesn't change anything..... | 11:18 |
| Tonio_ | and it was working 2 days ago...... | 11:18 |
| Tonio_ | damn gone ;) | 11:18 |
| BenC | Tonio_: I have vtun working on my box, so I know tun works | 11:46 |
| Tonio_ | BenC: hum............... | 11:49 |
| Tonio_ | I have no error message when loading module tun | 11:49 |
| Tonio_ | so I'm okay that it works | 11:50 |
| BenC | how to get it to work is beyond my knowledge, vtun did everything for me | 11:50 |
| Tonio_ | but what sounds strange is that something changed with the last kernel upgrade.... | 11:50 |
| Tonio_ | BenC: do you have a tun0 device or tunl0 ? | 11:50 |
| Tonio_ | not the same thing.... | 11:50 |
| Tonio_ | tunl0 is create by the ipip module | 11:51 |
| Tonio_ | ifconfig -a will tell you.... | 11:51 |
| BenC | tun1 | 11:51 |
| Tonio_ | no tun0 ? | 11:51 |
| BenC | it's all the same | 11:51 |
| Tonio_ | hum....... | 11:52 |
| Tonio_ | if you have a tun1, it means that you have a tun0 that does not appear maybe.... | 11:52 |
| Tonio_ | which shows there is a kind of issue with that device... | 11:52 |
| BenC | it doesn't really matter | 11:52 |
| BenC | no, it doesn't | 11:52 |
| Tonio_ | BenC: with openvpn it does lol | 11:52 |
| BenC | it's only because vtun was restarted | 11:52 |
| Tonio_ | okay.... | 11:52 |
| BenC | tun0 was taken down before it started a new one, which became tun1 | 11:53 |
| BenC | was taken down after I mean | 11:53 |
| Tonio_ | in any case openvpn doesn't work anymore on my three machines.... | 11:53 |
| BenC | /dev/net/tun exists for me | 11:54 |
| BenC | udev probably created it | 11:54 |
| BenC | did you do a partial upgrade? | 11:54 |
| BenC | it's 10/200, 0660, root:root | 11:55 |
| Tonio_ | same for me........ | 11:56 |
| BenC | I suggest a google search for openvpn vs. 2.6.15, and maybe emailing them | 11:58 |
| Tonio_ | yep maybe ;) | 11:58 |
| BenC | emailing openvpn that is | 11:58 |
| Tonio_ | the strange thing is that it was working 3 days ago......... | 11:59 |
| Tonio_ | I'll have a look, thanks ;) | 12:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!