| infinity | zequence: Your upload had a single bit-flip. The git repo on github is fine, but there was a single bitflip on your hard drive (or in RAM when building the package). | 01:29 |
|---|---|---|
| infinity | zequence: I'm going to re-upload directly to the kernel PPA from git once I've tested it builds locally. You might want to check your hardware. | 01:29 |
| shadeslayer | apw: I see, follow up question, would linux and linux-meta be enough if I upload a saucy kernel to the raring pocket of a PPA? | 02:56 |
| shadeslayer | or do I need to backport more things? | 02:56 |
| shadeslayer | ( I've test built both those packages in a pbuilder, they built fine ) | 02:56 |
| infinity | zequence: All fixed up now. | 03:56 |
| zequence | infinity: ok, thanks. I don't think I mentioned to anyone I had moved the git repos to a project on github, but I guess you found out on your own. | 03:59 |
| zequence | this HD is only about 2 years old. I've only twice had problems with git repos on another HD, but never on this one. But, I guess one bit is all that it takes to screw it up. | 03:59 |
| zequence | not that it was a problem with the git repo, only that is how I've noticed corruption in the past | 04:00 |
| zequence | might be smart to test locally before uploading I guess | 04:01 |
| shadeslayer | odd, I can't even get debuild to spit out the right files :S | 04:06 |
| infinity | zequence: If you're doing it on a consumer-grade PC or laptop without ECC RAM, the bitflip could just be a normal consequence of using a computer, it might not be dying hardware. | 05:21 |
| infinity | zequence: Still worth a check, though. | 05:21 |
| infinity | zequence: (And if that file's corrupt in your local checkout, you'll want to re-clone, or at least replace the corrupt file) | 05:21 |
| === tjaalton_ is now known as tjaalton | ||
| infinity | zequence: Anyhow, it's all in -proposed now, and ready for the binaries to be tested whenever. | 05:22 |
| ohsix | if it managed to make it to software, dmesg and smart should show something, too | 05:22 |
| zequence | infinity: right. ECC. Well, I'm not running server hardware here, but I should probably look at enhancing security a bit :) | 05:38 |
| zequence | ohsix: dmesg didn't show anything. | 05:43 |
| zequence | I just realized these are the same memory sticks though. I should probably check them | 05:43 |
| zequence | (..the same sticks as when I had problems on another machine) | 05:44 |
| infinity | ohsix: How would dmesg know about a bit flip in non-ECC RAM? | 05:44 |
| ohsix | it wouldn't, nor a miswrite to the disk, but there are a lot more likely things to have happened than a random bit flip | 05:45 |
| ohsix | unless you're at 40000 feet ;] | 05:45 |
| infinity | Random bitflips are more common than people think. | 05:45 |
| ohsix | or near an alpha source | 05:45 |
| infinity | If only cking was around to cite the source he quoted last time this came up. | 05:45 |
| infinity | But background radiation leads to a lore more flips than people assume. | 05:46 |
| ohsix | http://www.jedec.org/sites/default/files/docs/jesd89a.pdf probably way more than you want to know about what jedec has to say about testing for soft errors | 05:47 |
| ohsix | even if they were 1000x more likely than people think, it'd still be less than other sources of errors that you can check first :p | 05:48 |
| infinity | Well, I did point out that failing RAM or a failing disk were worth checking for. | 05:48 |
| infinity | But it's not worth tearing one's hair out looking for failing hardware that isn't, either. Cosmic rays happen. | 05:49 |
| ohsix | heh | 05:49 |
| ohsix | consumer hard drive uncorrectable bit error rates are only 10e-14, you can check the smart test logs and the status for raw read error rate/reallocated ector count and be pretty confident that it's not it | 05:52 |
| ohsix | there's a paper somewhere where google gathered statistics on soft errors in all the ECC/registered dram they used | 05:53 |
| ohsix | if you look to see specifically what DRAM is on your memory widgets you can get the jedec measured numbers for the geometry from the vendor ;D | 05:54 |
| infinity | ohsix: Ahh, yes, it was Google's study I was thinking of. | 06:02 |
| infinity | "Our first observation is that memory errors are not rare | 06:02 |
| infinity | events. About a third of all machines in the fleet experience | 06:02 |
| infinity | at least one memory error per year (see column CE Incid. | 06:02 |
| infinity | %) and the average number of correctable errors per year | 06:02 |
| infinity | is over 22,000" | 06:02 |
| ohsix | yup | 06:03 |
| ohsix | in the aggregate, they leave all the details about what you could infer from a single module out, pretty much; aside from the table that shows a breakdown between ddr1/2/3 | 06:04 |
| infinity | Now, to be fair, on a non-ECC machine, the most common results of a bit-flip will be either "you don't notice", "you get a segfault", or "your system crashes", but an unlucky write it possible. | 06:04 |
| infinity | s/it/is/ | 06:04 |
| ohsix | if you have a petabyte of ram and you average it across the number of dimms you have ;] | 06:05 |
| infinity | Given how little of what gets shuffled around in RAM ever ends up on disk, "you don't notice" (or, you notice, but it's some random character corrupted on screen, etc) is probably the most common result. | 06:06 |
| infinity | And most people would forget seeing such a thing once a year, if they saw it at all. | 06:06 |
| ohsix | you can't really ignore the die size and sheer quantity of them when assessing if it's likely to happen to you, like i said; you need to get the specific DRAM datasheet to look for the soft error rate, they're all 'jedec' standard parts, but they have very different ratings for soft error rates depending on geometry and layout | 06:06 |
| ohsix | lets not forget that a harddrive has dram in it | 06:06 |
| ohsix | so you get the double whammy! :p | 06:07 |
| ohsix | though with new ssd's and the scsi stuff for end to end integrity you can know a lot about even that, if you need to (*cough* commercial) | 06:08 |
| === fmasi_afk is now known as fmasi | ||
| shadeslayer | anyone around to help out a bit? if I do pull-lp-source linux , modify the changelog to build against raring and then run debuild -S -sd , there is no .dsc file to sign | 08:09 |
| shadeslayer | and hence dput fails | 08:09 |
| shadeslayer | I don't quite understand what's going wrong | 08:09 |
| hyperair | read the error messages | 08:10 |
| apw | shadeslayer, well presumably the build fails, so can you pastebin the whole debuild -S output | 08:10 |
| shadeslayer | apw: huh? the build works fine pbuilder | 08:10 |
| apw | shadeslayer, probabally it is probabally because you have not said -nc and do not have the build-deps installed | 08:11 |
| shadeslayer | hyperair: but a .changes file is generated | 08:11 |
| shadeslayer | hm | 08:11 |
| apw | shadeslayer, just because debuild is dumb, doesn't mean it worked | 08:11 |
| shadeslayer | heh, okay | 08:11 |
| * shadeslayer will try with -nc | 08:11 | |
| hyperair | odd, i didn't think that .changes would be generated. | 08:13 |
| shadeslayer | apw: and I just need linux and linx-meta | 08:13 |
| shadeslayer | roght? | 08:13 |
| shadeslayer | *right | 08:13 |
| apw | shadeslayer, 'need' is a difficult word, some releases have lbm as well depending | 08:14 |
| hyperair | wasn't there some script that automatically installs the build-deps of a source package? | 08:14 |
| hyperair | i keep forgetting, since i just throw the entire thing into sbuild | 08:14 |
| shadeslayer | -nc seems to have done the trick | 08:15 |
| shadeslayer | apw: lbm? | 08:18 |
| shadeslayer | ah | 08:18 |
| shadeslayer | linux-backports-modules | 08:18 |
| shadeslayer | apw: anything else? | 08:20 |
| apw | shadeslayer, not that i can think of right now | 08:23 |
| shadeslayer | ok | 08:23 |
| shadeslayer | thx | 08:24 |
| apw | shadeslayer, though can't you just pocket copy the source if all you are doing is rebuilding it | 08:24 |
| shadeslayer | oh | 08:24 |
| shadeslayer | I don't see a LP option to do that | 08:24 |
| apw | shadeslayer, cirtainly it can be done, it is possible you cannot pull from the main archive without using the archive tools thingy | 08:26 |
| shadeslayer | well, yeah, I know it can be done, I just don't see a way to do it from the web interface :) | 08:27 |
| apw | shadeslayer, i think you might have to use copy-package | 08:30 |
| shadeslayer | yep, looking at that | 08:31 |
| shadeslayer | though .. does it do a no rebuild copy | 08:31 |
| shadeslayer | ah no, there's a separate option for that | 08:32 |
| shadeslayer | odd | 08:39 |
| shadeslayer | apw: gives me a key error on 'saucy' http://paste.kde.org/757184/ | 08:39 |
| infinity | shadeslayer: You want "-s saucy", not "-d"... Distribution in that context is "ubuntu" or "debian". | 08:42 |
| infinity | shadeslayer: And --to-suite instead of --to-distribution, too. | 08:43 |
| shadeslayer | oh | 08:43 |
| infinity | shadeslayer: And no need to mention component at all, since PPAs have no concept of them anyway. | 08:43 |
| shadeslayer | yeah | 08:43 |
| shadeslayer | hurray, thanks alot :) | 08:44 |
| infinity | (And do you really want to rebuild it? A copy-with-binaries would be much friendlier on the buildds, if the goal is just to have the saucy kernel in a raring PPA) | 08:44 |
| shadeslayer | infinity: too late :( | 08:47 |
| shadeslayer | plus buildds seem pretty empty | 08:47 |
| infinity | shadeslayer: Not too late if it isn't building. You could delete it and re-copy. But, you can always copy better next time. :) | 08:47 |
| shadeslayer | infinity: newb question, but won't different gcc versions affect the build? | 08:48 |
| infinity | shadeslayer: In theory. In practice, upstream tries really hard to make that not true. | 08:48 |
| infinity | shadeslayer: But since the kernel we build in the primary archive is the one that gets heavily QAed, it's generally in your best interest not to rebuild your own, IMO. | 08:48 |
| infinity | Better to share the bugs that millions of people have than share a weird new bug with 20 PPA users. | 08:49 |
| shadeslayer | infinity: yeah, I can understand, however a derivative *really really* wants the 3.9 kernel since the 3.8 one is causing kernel panics for them | 08:51 |
| infinity | shadeslayer: Sure, just arguing against rebuilding, that's all. But, as you say, a bit too late, since it's already building. | 08:52 |
| infinity | shadeslayer: Are their panics reproducible in a way that one could bisect with them? | 08:52 |
| infinity | (And is there a bug filed?) | 08:52 |
| shadeslayer | well, they said that their issues go away on 3.9 | 08:53 |
| shadeslayer | but I'll ask if it's possible for them to file a bug | 08:53 |
| infinity | Sure, and that's cool for them, but we're still supporting 3.8 for 8 months, would be nice to fix it. ;) | 08:53 |
| shadeslayer | *nod* | 08:54 |
| shadeslayer | I also haven't heard back on bug 1171940 even though I supplied all the info :( | 08:57 |
| ubot2 | Launchpad bug 1171940 in linux (Ubuntu) "vgaswitcheroo on the Macbook Pro 8,2" [Medium,Confirmed] https://launchpad.net/bugs/1171940 | 08:57 |
| shadeslayer | patch wasn't there on 3.9.1 ... haven't checked after that | 08:57 |
| apw | shadeslayer, have you any idea just how many open bugs we have on the kernel? | 09:09 |
| apw | shadeslayer, have you tested that patch and confirmed it fixes the issue ? | 09:12 |
| apw | ie are you going by more than the description of the patch | 09:13 |
| shadeslayer | apw: yes, I've tested it and it does indeed fix the issue | 10:28 |
| apw | shadeslayer, it would be helpful to put that in the bug, as it was not clear to me | 10:29 |
| shadeslayer | can do | 10:29 |
| === fmasi is now known as fmasi_afk | ||
| * ppisati -> out for lunch | 11:32 | |
| === fmasi_afk is now known as fmasi | ||
| apw | henrix, sconklin, bjf[afk], i am just playing with the cve-autotriager to sort out the issues with "-proposed kernels which never released" versions begin included | 12:03 |
| apw | so you may want to ignore it for a bit, as i suspect it will be slapping things about for a bit | 12:03 |
| henrix | apw: ack, thanks | 12:03 |
| === ara_ is now known as ara | ||
| * henrix will be out for a bit | 13:41 | |
| === bjf[afk] is now known as bjf | ||
| === ogra_ is now known as ogra | ||
| * ppisati goes out for a bit | 16:50 | |
| ogra | hmm, where do i find the git tree for linux-grouper ? | 16:55 |
| ogra | seatching on kernel.u.c doesnt reveal anything regarding grouper | 16:55 |
| ogra | (same for maguro) | 16:55 |
| cking | ogra, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=shortlog;h=refs/heads/grouper perhaps is what you want? | 17:12 |
| ogra | perfect, thanks | 17:12 |
| * ogra tries to find out why that one doesnt boot with flipped container (natively into an ubuntu rootfs) | 17:13 | |
| ogra | maguro works flawless ... i'm wondering if its a kernel config issue | 17:13 |
| apw | ogra, they are all in saucy | 18:49 |
| apw | ogra, most likley, it is very hard to get them the same with them all being random versions | 18:50 |
| ogra | apw, i only want to see the config, not start a download orgy | 18:50 |
| ogra | :P | 18:50 |
| apw | it is in /boot on the device | 18:50 |
| ogra | it isnt | 18:51 |
| ogra | we dont have the package installe on the images | 18:51 |
| ogra | *installed | 18:51 |
| apw | ogra, then you'll need either the binary package which has it in, or your'll need the source | 18:54 |
| ogra | yes | 18:54 |
| ogra | or just look at git with a browser | 18:54 |
| === fmasi is now known as fmasi_afk | ||
| jono | ogasawara, hey | 21:39 |
| jono | I just saw on G+ that someone got bitten by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/798086 | 21:39 |
| ubot2 | Ubuntu bug 798086 in linux (Ubuntu) "Occasional "The disk drive for /dev/mapper/cryptswap1 is not ready yet or not present" on system startup" [Medium,Confirmed] | 21:39 |
| jono | it seems to be a few years old, would you folks mind taking a look into it?\ | 21:39 |
| ogasawara | jono: sure, I'll ask jsalisbury to follow up | 21:43 |
| jono | thanks ogasawara | 21:43 |
| === bjf is now known as bjf[afk] | ||
| === kentb is now known as kentb-out | ||
| jsalisbury | jono, ogasawara I'll take a look at that bug | 23:42 |
| jono | thanks jsalisbury | 23:48 |
| jsalisbury | jono, np. If possible, can you also email me the g+ link | 23:49 |
| jono | jsalisbury, https://plus.google.com/u/1/117353980479250980339/posts/TFneH4qPrik | 23:49 |
| jsalisbury | jono, thanks | 23:49 |
| jono | if you could hop on that thread and follow up that would be great | 23:49 |
| jono | just shows we care :-) | 23:49 |
| jsalisbury | jono, done. and we do care ;-) | 23:53 |
| jono | thanks jsalisbury :-) | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!