| Keybuk | Hobbsee: kernel update? | 00:04 |
|---|---|---|
| Keybuk | no, ignore me | 00:04 |
| Keybuk | 2.6.29 is current HEAD and that's where the X-related fun is happening | 00:05 |
| Keybuk | jaunty only has .28 | 00:05 |
| Hobbsee | Keybuk: ah. I have the X log, if anyone's interested in seeing it | 00:05 |
| === rbelem is now known as rbelem-pinhole-g | ||
| === rbelem-pinhole-g is now known as pinhole-glasses | ||
| === pinhole-glasses is now known as rbelem | ||
| bryce | asac: Xorg.0.log and lspci -vvnn, description of symptoms when running EXA. Title it something like, "[rNNN] High CPU when EXA enabled; needs XAA quirk" where rNNN is your chip type, r350, r500 or whatever | 02:06 |
| === asac_ is now known as asac | ||
| bluefoxicy | Is there anything about how to make a repo from source packages? | 03:51 |
| bluefoxicy | i.e. build my own copy of main, from source, into debs | 03:52 |
| Hobbsee | pbuilder with some extensions + a repository thing? reprepo / falcon / etc? | 03:54 |
| bluefoxicy | is there documentation? | 03:54 |
| Hobbsee | i've no idea | 03:55 |
| Hobbsee | but that's how i'd go about doing it | 03:55 |
| bluefoxicy | a friend of mine wants to build some generalized security stuff into Ubuntu (toolchain modifications, hardened kernels, etc) and the best I can come up with is to rebuild the repos | 03:55 |
| ScottK | falcon is broken in Intrepid and later. | 03:55 |
| ScottK | bluefoxicy: I know NCommander has done this recently. | 03:55 |
| Hobbsee | useful. why? | 03:55 |
| bluefoxicy | Hobbsee: was that for me or scottK? | 03:56 |
| Hobbsee | ScottK. | 03:56 |
| ScottK | Hobbsee: Not updated for the Django 1.0 api changes. | 03:56 |
| NCommander | bluefoxicy, rebuilding the archive is a sheer pain in the ass, and not something trivial to do. | 03:56 |
| * bluefoxicy notes to ask NCommander | 03:56 | |
| Hobbsee | ScottK: ah, darn. | 03:56 |
| PovAddict | there you go | 03:56 |
| ScottK | Thus NCommander has done it more than once, just for 'fun'. | 03:57 |
| bluefoxicy | NCommander: dude, there is a build server that does this continuously; and since like Hardy all I've ever heard is "it's really non-trivial" | 03:57 |
| NCommander | ScottK, I like pain, 'nuf said | 03:57 |
| ion_ | scottk: It should depend on the correct version of django then. | 03:57 |
| NCommander | bluefoxicy, I assume your referring to UWSA's archive rebuild setup | 03:57 |
| ScottK | ion_: It should and if I was the maintainer, I'd fix it. | 03:57 |
| bluefoxicy | NCommander: yeah. | 03:58 |
| ScottK | seveas has been going to rename falcon and get it fixed up, real soon now, for most of a year. | 03:58 |
| NCommander | bluefoxicy, That's not what you want, since it depends on currently existing packages to rebuild the archive. If I read you right, you don't want to use th existing packages, which means bootstrapping the archive | 03:58 |
| bluefoxicy | NCommander: what I'm thinking is iterate all of main and get the package source, rebuild every package in main, and stick it in a folder, then generate a packages.gz off it | 03:58 |
| bluefoxicy | i.e. let's say I want to install Ubuntu, but build everything with 'gcc -Os' instead of -O2 | 03:59 |
| bluefoxicy | everything... | 03:59 |
| PovAddict | bluefoxicy: to rebuild certain packages you need to build other packages first, so yes what you want is "bootstrapping" | 03:59 |
| NCommander | Like I said, non-trivial to redo | 03:59 |
| bluefoxicy | yes | 03:59 |
| NCommander | bluefoxicy, there is no mechanism in place for automagic rebootstrapping | 03:59 |
| NCommander | its a long, slow, and UGLY process | 03:59 |
| bluefoxicy | NCommander: hmm. | 03:59 |
| NCommander | bluefoxicy, that being said, if its just -O2 -> -Os, you might be able to cheat by using existing packages | 04:00 |
| bluefoxicy | PovAddict: I don't suppose a host ubuntu system can simply install the existing packages and rebuild... | 04:00 |
| NCommander | bluefoxicy, wgrant is the guy who runs UWSA archive rebuilds | 04:00 |
| bluefoxicy | NCommander: nods. | 04:00 |
| PovAddict | bluefoxicy: if you tell ubuntu to build package X from source, it will get *binaries* for packages Y, Z, and W it depends on | 04:01 |
| PovAddict | so it can build | 04:01 |
| bluefoxicy | NCommander: the actual problem I have in mind is compiling all binaries as PIC, linking executables as PIE, and using a kernel that's patched to load said executables with a randomized executable base and random heap base | 04:01 |
| NCommander | bluefoxicy, PovAddict is right, hence the difficulty, bootstrapping Ubuntu is a lot (and I mean *a lot* of grudge work) | 04:01 |
| bluefoxicy | ok that makes sense | 04:01 |
| NCommander | bluefoxicy, we're already doing that. | 04:01 |
| NCommander | bluefoxicy, not for jaunty, but jaunty+1, MAYBE | 04:01 |
| NCommander | bluefoxicy, its not trivial, you really do need to rebootstrap to make it happen due to the interdependencies in the base system. | 04:02 |
| bluefoxicy | nods. | 04:02 |
| bluefoxicy | I have someone that wants to do that plus some other stuff | 04:02 |
| bluefoxicy | but the only thing that's stopping him is rebuilding world | 04:02 |
| bluefoxicy | from scratch | 04:02 |
| bluefoxicy | non-trivial... no kidding. | 04:02 |
| NCommander | bluefoxicy, trust me when I say if it was that easy, it would have been done already ;-) | 04:03 |
| bluefoxicy | heh | 04:03 |
| bluefoxicy | hmm | 04:06 |
| kees | bluefoxicy: what toolchain modifications does your friend want to see? | 04:31 |
| kees | bluefoxicy: but, if you want, look at "hardening-wrapper" and see how it works. Then you could do archive rebuilds with it installed and enabled. see https://wiki.ubuntu.com/Security/HardeningWrapper and/or http://wiki.debian.org/Hardening | 04:32 |
| kees | bluefoxicy: the stock kernel in ubuntu already supports PIE load randomization | 04:33 |
| bluefoxicy | cool | 04:33 |
| kees | bluefoxicy: also, there is a up to a 15% performance loss on 32bit for PIE | 04:33 |
| kees | I would recommend only doing this on 64bit. | 04:33 |
| bluefoxicy | kees: I can't see that. Is that theoretical? | 04:34 |
| kees | bluefoxicy: it's not theoretical. I've measured it for certain workloads (like, say all of python) | 04:34 |
| kees | as far as 64bit PIE, see https://wiki.ubuntu.com/64BitPIEDefaultSpec | 04:34 |
| bluefoxicy | I did a complete system profile once using oprofile and the overall real impact was about 0.02% <_< | 04:35 |
| kees | bluefoxicy: but most stuff isn't .text heavy (like most scripting languages) and in those cases, it's about 5% loss | 04:35 |
| bluefoxicy | however, microbenchmarks did allow me to produce a 6% performance impact under special conditions (notably, -fomit-frame-pointer gives a 5% speedup, but it's impossible in PIC text) | 04:35 |
| kees | bluefoxicy: 32bit has _very_ few general registers, so stealing one for the relocation thunking really turns up the heat on moving data in and out of memory | 04:35 |
| bluefoxicy | right | 04:35 |
| kees | but, for some people, it's worth it. | 04:36 |
| bluefoxicy | the flip side of that is you really don't spend any time in the main executable :P | 04:36 |
| kees | as far as doing an archive rebuild, NCommander knows a great deal more than I do about that. :) | 04:36 |
| bluefoxicy | (except, apparently, with python) | 04:36 |
| kees | I gotta split, hopefully the above links will be helpful. | 04:37 |
| bluefoxicy | yeah, very, thanks | 04:38 |
| === bluesmoke is now known as Amaranth | ||
| === warp10_ is now known as warp10 | ||
| === thekorn_ is now known as thekorn | ||
| === warp10_ is now known as warp10 | ||
| === LucidFox_ is now known as LucidFox | ||
| * Keybuk likes git reset | 13:45 | |
| Keybuk | now I've figured it out, it's quite useful | 13:45 |
| maxb | Doesn't that sentiment apply to all of git? :-) | 13:47 |
| Keybuk | no, lots of git is "ugh", and "wtf", and "why does it behave like *that*" | 13:47 |
| Keybuk | other bits are "ok, that's as good as bzr" | 13:47 |
| Keybuk | git reset is special in that it's better than bzr, because bzr is sorely missing such a thing! | 13:47 |
| jpds | Does git have an "ignore" function yet? | 13:47 |
| persia | Oooh. That is nice. It's the thing that would make me stop doing everything outside VCS just so I can avoid that sort of mistake. | 13:51 |
| StevenK | bzr has uncommit ... | 13:51 |
| Keybuk | StevenK: it's not the same | 13:51 |
| persia | Not at all. | 13:51 |
| persia | StevenK, It resets the VCS info, while not touching your files, so your files stay dirty (with the changes you wanted). | 13:52 |
| StevenK | Hmmm | 13:52 |
| persia | The bzr workaround is to always push to somewhere on commit, and run bzr diff before each commit, so you can reapply the patch to the last commit to restore the state when you mess up the next commit. | 13:53 |
| persia | (which is annoying and painful) | 13:53 |
| === elkbuntu is now known as elkeee | ||
| === elkeee is now known as elkbuntu | ||
| Keybuk | lool: you didn't commit that watershed change to bzr? | 15:14 |
| lool | Keybuk: Hmm I thought I had checked there was no Vcs-Bzr URL, but I missed it in the showsrc output | 15:17 |
| lool | Keybuk: Will commit now, sorry | 15:17 |
| lool | (I was actually surprized it didn't use Bzr) | 15:17 |
| lool | Keybuk: Pushed, but as a single commit | 15:20 |
| lool | (and tagged) | 15:20 |
| Keybuk | thx! :) | 15:20 |
| gsc | What policy is Ubuntu actually using to push updates to the users? Are they toroughly tested or pushed out asap? | 15:54 |
| persia | gsc, Depends on the type of update. For the development release, there's usually only developer testing. For updates to releases, there is significantly more testing. | 15:55 |
| gsc | And for example a zero-day bugfix? | 15:56 |
| gsc | persia: I can immagine that sometimes an update can break something and the smaller circle of developers cannot forsee all the possible problems on so many different setups and hardware. | 15:58 |
| persia | zero-day bugfix? | 15:58 |
| gsc | persia: I mean a very urgent update that fixes a very serious bug or exploit. | 15:59 |
| persia | Those go to -proposed, and get tested. I don't know of anything that went out without testing, although I could be mistaken. In cases of extreme urgency, I would expect the tests to be performed more quickly, rather than skipped. | 16:00 |
| gsc | persia: why not involve the power-users in this regard? An extra option in the dialog 'installation sources' which power-users can select to get the updates a bit earlier than the rest. That way, a fix/update can be tested on a lot more different setups. | 16:02 |
| persia | gsc, Anyone is welcome to help test -proposed. I'd recommend joining #ubuntu-testers and reading https://wiki.ubuntu.com/Testing/EnableProposed | 16:03 |
| Laney | gsc: That exists and is called -proposed | 16:04 |
| persia | I believe (although I've not checked) that a majority of the people who test the updates are not current developers. | 16:04 |
| directhex | gsc, did you file a security bug on launchpad? | 16:05 |
| gsc | persia: i'll look at it. Thanks for the info. I'm not using (k)Ubuntu that long. Always been a (Open)SUSE since 2000. | 16:05 |
| gsc | directhex: no, I was just curious about the policy. | 16:06 |
| persia | gsc, Thanks for your interest. I do hope you'd be willing to help test. One of the biggest blockers to getting good updates out is lack of testers, so more are always welcome. | 16:07 |
| gsc | persia: I already checked the option for proposed. What is the mean time for tested updates via proposed to go mainstream? | 16:26 |
| persia | I'd say a week or two. | 16:26 |
| persia | Also, while I'm glad to introduce you to the testing procedures here, it's a bit off-topic for the channel. I do encourage you to join #ubuntu-testing and ask more there. | 16:27 |
| gsc | persia:ok | 16:28 |
| ogra | gsc, https://wiki.ubuntu.com/StableReleaseUpdates | 16:28 |
| ogra | and https://wiki.ubuntu.com/SecurityUpdateProcedures | 16:29 |
| gsc | ogra: checking those, thanks. | 16:29 |
| === asac_ is now known as asac | ||
| === Mez_ is now known as Mez | ||
| bluefoxicy | hmm... | 19:08 |
| bluefoxicy | install security updates without confirmation... seems to not continuously download, or install. Is it on a schedule? | 19:09 |
| Zorry | NCommander, ping | 19:47 |
| juliank | documentation makes developers happy. http://people.debian.org/~jak/python-apt-doc/ | 20:25 |
| PovAddict | <.< | 20:49 |
| PovAddict | translations indeed got messed up | 20:50 |
| PovAddict | remember yesterday I said the translation packages had gone from 6MB to 22KB? | 20:50 |
| PovAddict | now things indeed started showing in English | 20:51 |
| PovAddict | reported #316174 | 20:58 |
| ion_ | lssy cmprsson | 20:59 |
| === TheMuso_ is now known as TheMuso | ||
| bluefoxicy | anyone here good with gdb? | 23:35 |
| bluefoxicy | http://rafb.net/p/m1zi2P91.html ok that's a start. | 23:39 |
| bluefoxicy | nm, screw gdb. | 23:40 |
| PovAddict | type bt | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!