[12:54] <doko> infinity, cprov: (I know, weekend ...) please requeue libgtk-java on all archs
[02:01] <raphink> anyone knows if it's possible to assign a value to a varible in make using an external command ?
[02:01] <raphink> e.g. 
[02:01] <raphink>         for image in seq -w 01 36
[02:01] <raphink> doesn't work
[02:02] <crimsun> you need to quote the seq command
[02:02] <crimsun> $(seq -w 01 36)
[02:02] <raphink> doesn't work either
[02:02] <_ion>         seq -w 01 36 | while read image; do \
[02:03] <raphink>         for image in $(seq -w 01 36)
[02:03] <raphink>                 echo $(image)
[02:03] <raphink>         endfor
[02:03] <raphink> that won't work
[02:03] <_ion>           stuff with $$image
[02:03] <raphink> hmm _ion in make?
[02:04] <_ion> _Each_ line is interpreted separately with sh, unless they're merged with the \ char. Also you need to type $$ in the Makefile to give $ to the shell.
[02:05] <raphink> ah
[02:05] <_ion> Also i prefer 'seq ... | while read foo' instead of 'for foo in $(seq ...)' because it allows the length of the sequence to be arbitrary without any concern for memory usage.
[02:06] <raphink> ok
[02:06] <raphink> doesn't seem to work though
[02:06] <raphink> :s
[02:06] <raphink> for some reason
[02:07] <raphink> oh wait yes it does :)
[02:07] <raphink> sorry
[02:07] <raphink> thanks much _ion that helps a lot :)
[02:09] <_ion> Anyway, http://johan.kiviniemi.name/tmp/example-Makefile
[02:11] <bddebian> Howdy
[02:11] <_ion> Howdy-how.
[02:17] <raphink> woot
[02:18] <bddebian> Heya raphink
[02:18] <raphink> hi bddebian :)
[03:31] <lastnode> imbrandon, ping?
[04:05] <netdur> people with compiz respo, got libvte upgrade, it broke synaptic... this bug https://launchpad.net/distros/ubuntu/+source/vte/+bug/56862
[04:06] <Ubugtu> Malone bug 56862 in vte "synaptic requires libvte.so.4, but upgrade of libvte removes it" [Medium,Unconfirmed]  
[04:07] <ajmitch> ah, so it is the fault of 3rd party repositories
[04:13] <netdur> gonna comment
[04:14] <ajmitch> I'm rejecting anyway
[04:15] <netdur> okay
[04:15] <DShepherd> hey edgy users.. the X problem that was happening has it been fixed?
[04:15] <ajmitch> DShepherd: not nearly enough info
[04:16] <DShepherd> ajmitch: ok..
[04:17] <lastnode> infinity, ping?
[04:33] <Keybuk> File 'option.c'
[04:33] <Keybuk> Lines executed:100.00% of 127
[04:33] <Keybuk> option.c:creating 'option.c.gcov'
[04:33] <Keybuk> yay test cases
[04:34] <bddebian> Heya Keybuk
[04:37] <Keybuk> :)
[04:44] <robertj> Keybuk: has there been any discussion about attempting to automating package rebuilds for simple backports?
[04:47] <Keybuk> how do you mean?
[04:48] <robertj> Keybuk: lots of games have simple & relatively stable deps, so backporting is a snap
[04:49] <robertj> the way I currently do it now is I take my sources.list %s/dapper/edgy, update, apt-get src foo, change sources list back & update again, then do the dpkg-buildpackage
[04:49] <Keybuk> we have a theoretical backports acrhive
[04:49] <robertj> ahh?
[04:52] <robertj> "theoretical backports" archive doesn't google for me
[04:54] <bddebian> heh
[05:08] <lastnode> imbrandon, ping?
[05:20] <bluefoxicy> Anyone know when mdz is usually around
[05:20] <bluefoxicy> side question, is anyone from the kernel team here
[05:21] <imbrandon> lastnode: pong
[05:21] <sbalneav> I'm trying to debug some ltsp localdev stuff, so I've ugraded an edubuntu box to edgy.  Now my gnome-panel consumes 70% of my cpu :)  strace shows it to be stuck in a polling loop.  This a known issue that anyone's aware of?
[05:21] <lastnode> imbrandon, got a sec?
[05:22] <imbrandon> bluefoxicy: mdz is usaly arround after 7am london time or there abouts
[05:22] <imbrandon> lastnode: sure
[05:22] <bddebian> What the heck is diff --git in .diff files in debian/patches?
[05:22] <lastnode> imbrandon, #taprobane? Ryan is there too, that's why
[05:23] <bluefoxicy> 2am hm
[05:24] <bluefoxicy> imbrandon:  any idea if I should ask anyone else about switching the name of the 386 kernel?
[05:24] <mjg59> bluefoxicy: ?
[05:24] <bluefoxicy> I saw mdz talking about benchmarking the 386 vs 686 kernels and possibly dropping the other kernels since they offer no performance increase
[05:25] <bluefoxicy> and I looked, indeed, CONFIG_M486=Y; these are not i386, they're i486
[05:25] <mjg59> Right
[05:25] <imbrandon> probably the kernel team i would imagine benc mjg59 mdz etc in -kernel 
[05:25] <mjg59> The fact that it's ever been called 386 is for historical reasons
[05:25] <bluefoxicy> and i386 ubuntu is built with i486 instructions to boot.
[05:25] <bluefoxicy> (cmpxchg ftw)
[05:25] <mjg59> We've never supported 386
[05:25] <mjg59> Nor has Debian since 3.0
[05:25] <imbrandon> i386 is historical i think
[05:25] <bluefoxicy> Yes.
[05:26] <bluefoxicy> I don't think it would hurt to call the kernel linux-image-*-486
[05:26] <mjg59> The standard kernel will be build for 586 SMP
[05:26] <bluefoxicy> renaming the distro i486 would go ARGHFACYOUH@#( probably
[05:26] <mjg59> The alternative kernel will be built for 486 UP
[05:26] <mjg59> The *86 names will be dropped
[05:26] <bluefoxicy> you're going to move to 586?  o.o
[05:27] <mjg59> The standard kernel can't be 686
[05:27] <bluefoxicy> I know
[05:27] <mjg59> And there's approximately no performance difference
[05:27] <imbrandon> not from userland apps anyhow
[05:27] <bluefoxicy> There's no compelling reason to move to 586 that I can see; mdz and benc illustrated this with benchmarks.
[05:27] <imbrandon> exactly
[05:28] <bluefoxicy> I won't protest a move to 586 or 686 mind you
[05:28] <bluefoxicy> I'm just surprised ;P
[05:28] <imbrandon> now the x86 and x86_64 will still need to be seperated i think but thats a whole nother ball game
[05:28] <bluefoxicy> of course
[05:28] <bluefoxicy> USB printing breaks with the x86_64 kernel; and it can't be built with a fallback to x86
[05:29] <mjg59> I doubt there are any 486 systems that can actually usefully run Ubuntu
[05:29] <bluefoxicy> (which would be a waste of time)
[05:29] <mjg59> The USB printing thing is just a bug
[05:29] <imbrandon> bluefoxicy: realy ? usb printing worked afaik on mine 
[05:29] <imbrandon> i need to check that
[05:29] <bluefoxicy> imbrandon:  benc said something about it.
[05:29] <bddebian> Anyone?  How do I properly generate a .diff file for a patching system using them?  I've never heard of --git and it doesn't even appear valid?
[05:30] <bluefoxicy> If it was fixed bravo, offer the x86_64 one for x86
[05:30] <imbrandon> my amd64 machine is still on breezy though so that might be part of it
[05:30] <bluefoxicy> imbrandon:  32-bit userland, not 64-bit.
[05:30] <imbrandon> its the file/web/nfs/nis server here at the house
[05:30] <mjg59> bluefoxicy: Dude, x86_64 kernels are sort of missing x86 functionality
[05:30] <bluefoxicy> it works fine with 64-bit userland.
[05:30] <bluefoxicy> mjg59:  they don't BOOT on x86; but you could run 64-bit kernel on amd64 and keep 32-bit userland (flash...)
[05:31] <imbrandon> ahh yea i dont have any 32bit userland stuff 
[05:31] <mjg59> bluefoxicy: Erm.
[05:31] <mjg59> bluefoxicy: What x86_64 one are we meant to offer for x86?
[05:31] <mjg59> Oh, I see what you mean
[05:31] <imbrandon> bluefoxicy: you can if you dont rely on dpkg , no dual arch support
[05:31] <mjg59> No, that's still not acceptable
[05:31] <bluefoxicy> mjg59:  you don't offer any now.  BenC explains this being due to USB printing not working from 32-bit userland on 64-bit kernel.
[05:31] <mjg59> x86 userland depends on functionality that's not present in x86_64 kernels
[05:31] <mjg59> Like vm86
[05:32] <mjg59> amd64 userland has workarounds for that sort of thing
[05:32] <bluefoxicy> hm
[05:32] <imbrandon> isnt that a proc^Wdesign bug 
[05:32] <mjg59> imbrandon: No
[05:32] <mjg59> imbrandon: Supporting 64 bit, 32 bit /and/ vm86 is pretty much impossible
[05:32] <mjg59> bluefoxicy: They're not using vm86
[05:32] <bluefoxicy> It's not within reach right now and not important.
[05:32] <bluefoxicy> what is vm86
[05:33] <imbrandon> bluefoxicy: me also thats why i'm confused i guess
[05:33] <mjg59> Semi-virtualised x86
[05:33] <imbrandon> infact i have 32bit userland in a chroot on sid
[05:33] <bluefoxicy> vmware?
[05:33] <imbrandon> and 64bit everything else
[05:33] <mjg59> It lets applications run in something that looks like real mode under a protected mode OS
[05:33] <bluefoxicy> oh what
[05:33] <mjg59> Basically a compatibility kludge
[05:33] <bluefoxicy> oh
[05:33] <bluefoxicy> for dosemu
[05:33] <mjg59> A somewhat important compatibility kludge, but still
[05:34] <mjg59> On x86_64 kernels, we need to execute code in an x86 emulator instead
[05:34] <mjg59> That works somewhat less well
[05:34] <bluefoxicy> so you're talking about dosemu and wine, right?  :P
[05:34] <mjg59> No
[05:34] <bluefoxicy> then what
[05:34] <mjg59> vbetool, usplash, X...
[05:35] <bluefoxicy> o.O
[05:35] <bluefoxicy> X is somehow tied to real mode?
[05:35] <mjg59> Various chunks of X make int10 calls
[05:35] <bluefoxicy> I don't remember my interrupt tables.
[05:35] <mjg59> With the potential to fall back to the aforementioned x86 emulator
[05:36] <bluefoxicy> mjg59:  is that a software interrupt to trigger another part of X?
[05:37] <mjg59> No, it calls code in the video BIOS
[05:38] <bluefoxicy> mjg59:  at any rate, on the performance stuff, I've run Dapper on 350MHz AMD K6-2 192M ram systems.  It's SLOW.  Takes 20 minutes to get into the livecd, took 5 tries to get it to finish installing without running outta memory (eventually I hacked up X to run ubiquity straight up)
[05:38] <bluefoxicy> mjg59:  the video bios contains old x86 code that can't be updated then?
[05:38] <bluefoxicy> (obviously it's on a hard-coded rom)
[05:39] <bluefoxicy> I hadn't thought of that possibility.
[05:39] <mjg59> The video bios contains old x86 code that knows how to drive the graphics card, and we don't
[05:39] <mjg59> And yes, the livecd will be very slow when you don't have any RAM to use as cache
[05:39] <bluefoxicy> mjg59:  is there a technical reason why vm86 can't be entered from long mode?
[05:40] <mjg59> Dunno
[05:40] <bluefoxicy> mjg59:  actually, I kept hitting the "Select your timezone" screen and the graphical map would force me to 2000% CPU usage and the CPU maxes at 100% and becomes 20 times slower :>
[05:40] <mjg59> Linux doesn't implement it, and nor does Windows
[05:40] <sbalneav> ah bug 52405
[05:40] <Ubugtu> Malone bug 52405 in gnome-panel "gnome-panel eats 50% cpu for half an hour and flickers" [High,Confirmed]  http://launchpad.net/bugs/52405
[05:40] <sbalneav> bad link in /etc/xdg/menu
[05:41] <bluefoxicy> mjg59:  I'll file that under "fucking bad design" and make the comment that running an x86 video card on a SPARC or PPC sounds hard.
[05:41] <mjg59> bluefoxicy: On PPC it's often impossible, but in those cases we have useful firmware to save us
[05:41] <mjg59> On Sparc, we have x86emu
[05:42] <mjg59> Alphas have always used x86 emulation to boot their graphics cards, anyway
[05:42] <bluefoxicy> mjg59:  moving along, if you don't think Ubuntu is useful on 486 (maxes at what, 66MHz?  No I think my boyfriend has a 100MHz one or such...), why build it with the 486 instruction set at all?  Why not move to i586 instructions?
[05:43] <mjg59> bluefoxicy: Because under some niche circumstances it might be useful
[05:43] <mjg59> But not in the standard configuration
[05:43] <bluefoxicy> yeah.  init=/usr/bin/adventure
[05:43] <mjg59> Using the alternate CD, you ought to be able to produce a workable installation on a DX4
[05:44] <bluefoxicy> nods.
[05:45] <bluefoxicy> mjg59:  So here comes the ugly question.  Would such an installation be workable with GNOME and Firefox?  Or, directly, can we build Firefox for i586 in theory?
[05:46] <bluefoxicy> (firefox, KDE, gnome, other big gigantic things...)
[05:47] <mjg59> It's unlikely to be useful with GNOME, even building userspace for 586 over 486 wins you fuck all
[05:48] <bluefoxicy> yeah
[05:48] <bluefoxicy> http://wiki.ubuntu.com/ubuntu686 head towards the bottom
[05:49] <bluefoxicy> https://wiki.ubuntu.com/ubuntu-i686 rather wtf.
[05:50] <mjg59> Gngk.
[05:51] <mjg59> Any perceived speed difference is unlikely to be due to the instruction set differences.
[05:51] <mjg59> It's far more likely to be related to the rest of the crack
[05:51] <bluefoxicy> yeah
[05:52] <bluefoxicy> there's some nice gains in FP-emulation in i686 vs i386 (50% faster); but guess what?  We have an FPU!  :)
[05:53] <bluefoxicy> the rest is statistically insignificant
[05:53] <bluefoxicy> mjg59:  I'm hoping to get --hash-style used everywhere in Edgy+1
[05:54] <bluefoxicy> mjg59:  also I've had various people tell me the buildd uses -Wl,-O1 everywhere, or that it only uses -Wl,-O1 in a few packages.  I'd like to know which it is.
[05:54] <mjg59> cmov gains you, what? 1 instruction under optimal circumstances?
[05:54] <bluefoxicy> cmov?
[05:54] <mjg59> The useful 686 instruction
[05:55] <bluefoxicy> what does it do
[05:55] <mjg59> It's a mov that's conditional on the previous instruction
[05:55] <mjg59> Avoiding you having to do an explicit check and jmp
[05:56] <bluefoxicy> that sounds useful, just not ground-shakingly so.
[05:57] <Chipzz> [ot]  http://forums.invisionpower.com/lofiversion/index.php/t199177.html [/ot]  :)
[05:59] <bluefoxicy> mjg59:  I'll build flac with -save-temps and scan the assembly files and give you a rough significance :P
[05:59] <bluefoxicy> mjg59: do you know anyone who has access to the buildd's setup?
[05:59] <bluefoxicy> I would like to know the -Wl,-O1 thing, and everyone has been giving me things based on what they "know"
[05:59] <bluefoxicy> but they all seem to "know" different things
[06:03] <mjg59> No clue
[06:09] <bluefoxicy>         cmov:   350
[06:09] <bluefoxicy>         lines:  175072
[06:09] <bluefoxicy>         percnt: .19991774812648510327
[06:10] <bluefoxicy> mjg59:  ^^^ all of the .s files gcc emits when building FLAC without assembly optimizations.  0.2% of the instructions are escaped.
[06:10] <bluefoxicy> (you said cmov saves you one insn right?)
[06:11] <mjg59> Rather than jmc; mov; you can just do cmov
[06:12] <bluefoxicy> mjg59:  when and where would be a good time to discuss changes to the linker in Edgy+1?  It has to be addressed before Edgy+1 opens right?
[06:12] <mjg59> Provide useful benchmarks. Write a spec.
[06:13] <bluefoxicy> Michael Meeks has loads of useful benchmarks.  I can write a spec.
[06:13] <bluefoxicy> Can I ream RedHat for being scum?  :<
[06:14] <zul> actually redhat is quite useful for some things
[06:15] <bluefoxicy>         lines:  191382 ... 16310 extra instructions when built for 486, that's 8% reduction!
[06:17] <bluefoxicy> there's 860 excess lines being counted (ppc/as and ppc/gas files) ... 174212 on 686 and 190522 on 486 .. 16310 difference, 8.56% instead of 8.52%
[06:17] <bluefoxicy> zul:  yeah, I just like to throw rocks at them
[06:17] <mjg59> Wait. Are you optimising for the same processor in all cases?
[06:17] <mjg59> Do bear in mind that not all instructions take the same number of cycles, and various other things
[06:18] <bluefoxicy> mjg59: the first was built with CFLAGS and CXXFLAGS "-save-temps -march=i686" and the second with "-save-temps -march=i486"
[06:18] <bluefoxicy> I could test for i486 with tune for i686
[06:18] <mjg59> Yes
[06:19] <mjg59> That would be somewhat more sensible
[06:19] <bluefoxicy> zul:  the linker optimization thing though basically requires a swat at RedHat
[06:20] <bluefoxicy> Michael Meeks came up with stuff he proposed on the binutils mailing list, after coding it, testing it, benchmarking it... then 9 months later Jakub spits out a re-hashed patch for 2 of Meeks' optimizations, and says that "the initial design was done by Ulrich Drepper; some discussion occurred with Michael Meeks, but nothing came of this and the design used is actually quite different"
[06:20] <bluefoxicy> and Meeks pointed out that it looked like his prototype patches, but that he was too happy to see the stuff go in to quibble
[06:20] <bluefoxicy> and I blinked and said, "Holy SHIT, they just blatantly ripped off his stuff and claimed it was theirs!"
[06:21] <bluefoxicy> so yeah, I'm slightly biased at RedHat, don't mind me.
[06:25] <bluefoxicy> mjg59:  176032 ... - 860 .. 175172, 960 instruction difference.  Only half a percent.
[06:25] <mjg59> bluefoxicy: Right. So the big difference between the 486 and 686 is the tuning, not the instructions
[06:26] <mjg59> buildds already tune for 686
[06:26] <bluefoxicy> right, which brings me back to my benchmarks, which say yeah you'll get a gain on anything alike to floating point emulation, which is not much.  :)
[06:28] <bluefoxicy> https://wiki.ubuntu.com/EdgyPlusOneToolchainRoadmap
[06:28] <bluefoxicy> mjg59:  do you think it's safe to stick "get --hash-style support into our binutils via patch or upstream release; and use --hash-style=both" in Implementation?
[06:29] <mjg59> bluefoxicy: It's safe to do anything in a spec
[06:29] <bluefoxicy> or should I write a separate spec and stick "Examine usefulness of SomeSpec"
[06:29] <mjg59> Note which bits are of higher priority and more likely to work
[06:29] <bluefoxicy> nods
[06:30] <bluefoxicy> I would love to see -Bdirect linking but it's not going to happen, there's maintenance issues with it (it breaks if you build glibc with it!) and some minor hit/miss issues (once in a while it breaks something... it also exposes bugs in stuff once in a while), which is an immediate no.
[06:31] <bluefoxicy> Drepper is doing a good job of making sure it dies too.  It would threaten the usefulness of prelink, after all.
[06:43] <Chipzz> bluefoxicy: with all the quarrel between redhat and novell about xen lately, it surprises me novell didn't fire back with that one
[06:44] <bluefoxicy> Chipzz:  you saw that?
[06:44] <bluefoxicy> yeah Meeks is a novel employee, I'd figure if they took notice they'd be like "AND YOU ARE A BUNCH OF THIEVES AU*#*" and we could all get the popcorn.
[06:44] <Chipzz> bluefoxicy: if redhat ripped off suse with that gcc patch
[06:45] <Chipzz> given the amounts of bad words form redhat about xen
[06:45] <bluefoxicy> http://sourceware.org/ml/libc-alpha/2006-06/msg00095.html second paragraph; http://sourceware.org/ml/binutils/2006-01/msg00171.html and http://sourceware.org/ml/binutils/2006-01/msg00024.html being meeks.
[06:46] <imbrandon> suse just needs to buy redhat and desolve them ;)
[06:46] <Chipzz> heh
[06:46] <bluefoxicy> http://sourceware.org/ml/binutils/2005-10/msg00436.html "Sorry to mail you directly Ulrich - but don't know where glibc /development cogitation occurs."
[06:46] <imbrandon> speaking of suse /me needs to look at porting sax2 to ubuntu
[06:47] <bluefoxicy> anyway does anyone want to keep talking politics or is there a useful topic to pick up?
[06:47] <bluefoxicy> politics are fine with me; especially when RedHat's mascot is Carmen Sandiego :D
[06:48] <imbrandon> lol i've had enough politics myself 
[06:48] <mjg59> OH ARGH THIS IS ALL SO HORRIBLE
[06:48] <imbrandon> ?
[06:49] <mjg59> Bluez makes me sad
[06:50] <imbrandon> heh never had a use for it so never touched it
[06:50] <bddebian> Gnight peoples
[06:50] <imbrandon> gnight bddebian
[06:50] <mjg59> You are lost in a twisty maze of typedefs, all different
[06:53] <bluefoxicy> lol
[06:54] <bluefoxicy> mjg59:  what should I do with the psychotic stuff?
[06:55] <bluefoxicy> https://wiki.ubuntu.com/EdgyPlusOneToolchainRoadmap updated btw
[06:55] <mjg59> bluefoxicy: I recommend seeing a medical professional. The year of med school I have doesn't cover mental disorders.
[06:55] <bluefoxicy> lol
[06:55] <bluefoxicy> no I mean specs that are not likely to ever be carried out
[06:55] <mjg59> Oh
[06:56] <mjg59> I wouldn't bother mentioning them
[06:56] <bluefoxicy> heh
[06:58] <bluefoxicy> I've got a set that defines auditing/configuration/documentation/hardened kernel/source code auditing/hardened toolchain/vulnerability response as an organizational structure of the security team; basically I tried to mimic Hardened Gentoo
[06:58] <bluefoxicy> and I'm not sure if it's ACTUALLY worth trying to make happen or if I should just sit on it
[06:58] <imbrandon> zul: ping , still alive ?
[06:59] <bluefoxicy> the security team already does source code auditing and vulnerability response, AFAIK
[07:01] <imbrandon> Miguel de Icaza
[07:02] <imbrandon> gah i hate this keymap
[07:04] <kylem> 6
[08:01] <bluefoxicy> whew.  16 paragraphs.
[08:01] <bluefoxicy> (my biggest one was 24; the prelink one was 15)
[08:06] <imbrandon> heh, making a book bluefoxicy
[08:06] <imbrandon> just teasin
[08:06] <bluefoxicy> imbrandon:  just expanding my portfolio.
[08:07] <imbrandon> more productive than me i guess, i'm just photoshopin my gotchi whil i wait on kde4 to finish up ( likely to be waiting a while )
[08:07] <bluefoxicy> I'm learning from a couple gentoo guides and trying to persuade the LWN.net guys to let me send a series of 3 articles up (for a nominal price, of course-- this is going to pay for my Nintendo Wii) on some janitorial development tasks
[08:07] <imbrandon> heh nice
[08:07] <bluefoxicy> the first article fired off removing executable stacks; I spent a few days doing a number of these.
[08:08] <imbrandon> yea i read a little about the gcc linking before you talked about it, was kinda funy i ran accross it twice in 2 days
[08:09] <bluefoxicy> I also want to get in fixing code to compile PIC when it doesn't want to (how I'm going to make an ARTICLE about that I have NO idea; it's basically "do not use %ebx when doing assembly"); and removing ELF .text relocations (I can make a full article on this; the security considerations are amusing too)
[08:09] <bluefoxicy> actually I can probably do the PIC thing
[08:10] <imbrandon> heh
[08:10] <bluefoxicy> instead of using registers you can declare variables and have gcc use them; I should probably explain the syntax.
[08:11] <bluefoxicy> obviously the readers will include people who broke the shit in the first place; I understand LWN's audience is technically adept, but I'm CLEARLY discussing something they NEED to know.  :>
[08:12] <imbrandon> ;)
[08:14] <imbrandon> moins jdub
[08:14] <jdub> yo
[08:14] <jdub> pants off
[08:14] <imbrandon> err i guess afternoon for you ;)
[08:14] <jdub> word to yo momma
[08:15] <jdub> <- back from paintball
[08:15] <imbrandon> heh fun, i love paintball
[08:16] <bluefoxicy> pants off wtf?
[08:17] <bluefoxicy> this isn't #mutual-m.... wait, this place is full of computer nerds.
[08:46] <lastnode> imbrandon, ping?
[09:44] <pygi> hey hey pitti 
[09:45] <Hobbsee> hi pitti 
[09:46] <pitti> hey pygi
[09:46] <pitti> hi Hobbsee 
[09:47] <Hobbsee> :)
[09:48] <pygi> pitti, whenever you feel ready to burn cd with k3b without cdrecord :)
[09:48] <pygi> rather one day when it's not weekend :)
[09:51] <pitti> pygi: heh, I have never used k3b :)
[09:52] <pitti> pygi: I had used a simple cdrecord alias for years, and then nautilus-cd-burner for the sake of dogfooding
[09:52] <pygi> pitti, ah,oki :)
[09:53] <pitti> yes, and right now I'm just preparing my laptop for the sprint and pack my stuff
[09:55] <pygi> :)
[09:57] <imbrandon> moins pitti
[09:57] <imbrandon> and pygi ;)
[09:57] <pygi> hey imbrandon 
[09:58] <pygi> imbrandon, ll eat you, you know that, right?
[09:58] <pygi> and you know why,also :P
[09:58] <imbrandon> heh , sorry benn slackin
[09:58] <imbrandon> i should get to that tonight
[09:58] <pygi> imbrandon, I hope :)
[10:32] <Goshawk> hi,  why the file /etc/lsb-base-logging.sh is part of lsb-base in ubuntu ( http://packages.ubuntu.com/cgi-bin//search_contents.pl?version=edgy&arch=amd64&case=insensitive&word=lsb-base&searchmode=filelist ) while in debian it's part of the package usplash? ( http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=usplash&version=unstable&arch=amd64 )
[10:50] <doko> pitti: http://librarian.launchpad.net/3935558/buildlog_ubuntu-edgy-i386.dpkg_1.13.22ubuntu6_FAILEDTOBUILD.txt.gz
[10:58] <pitti> doko: thanks
[10:58] <pitti> doko: something to hack on in the train tomorrow :)
[11:20] <Tonio_> hi
[11:20] <_ion> Hola.
[11:27] <doko> infinity, cprov-afk: please requeue cairo-java on sparc
[12:01] <sladen> "We also believe in proper law enforcement as cyclists are much more likely to be victims, rather than perpetrators, of bad road use."
[12:01] <sladen> "We also believe in proper law enforcement as cyclists are much more likely to be victims, rather than perpetrators, of bad road use."
[01:00] <\sh> moins
[01:00] <imbrandon> heya \sh
[01:00] <pygi> hey \sh
[01:01] <irvin> hey \sh 
[01:04] <cprov-afk> doko: done
[01:04] <doko> cprov-afk: thanks
[02:15] <_ion> Re: https://wiki.ubuntu.com/LibAtaForAtaDisks; don't v1 swap partitions have UUIDs as well? Why aren't they listed in /dev/disk/by-uuid?
[02:19] <sladen> nice.  2.6.17 crashes if you insert an PCMCIA IDE disk
[02:20] <_ion> keybuk: Thoughts?
[02:21] <_ion> Whoops, he isn't online.
[02:53] <lastnode> anyone used the httplib python module here before?
[03:16] <_ion> keybuk: Any thoughts? 151543 < _ion> Re: https://wiki.ubuntu.com/LibAtaForAtaDisks; don't v1 swap partitions have UUIDs as well? Why aren't they listed in /dev/disk/by-uuid?
[03:19] <Keybuk> _ion: ever tried activating a v1 swap partition? :)
[03:19] <Keybuk> you'd have to patch the kernel to support them again
[03:20] <_ion> keybuk: Isn't v1 exactly what is used currently? :-)
[03:20] <_ion> v0 is the old swap format.
[03:21] <Keybuk> err, yes
[03:21] <Keybuk> sorry
[03:21] <Keybuk> in that case, yes v1 swap partitions may have UUIDs
[03:21] <Keybuk> and if they do, they will show up in /dev/disk/by-uuid
[03:22] <Keybuk> note *may* ... the installer never used to set one
[03:22] <_ion> % dd if=/dev/zero of=swap bs=1M count=2; mkswap swap
[03:22] <_ion> no label, UUID=d1937c2d-9b46-4675-8eef-159721d50d35
[03:22] <Keybuk> one of the things that the uuid conversion does is add a UUID to any swap partition that's missing one
[03:22] <_ion> Seems like a UUID is generated by default.
[03:22] <Keybuk> right, by mkswap
[03:22] <Keybuk> d-i doesn't use mkswap :)
[03:22] <_ion> Oh, okay. :-)
[03:23] <Keybuk> syndicate scott% cat /proc/swaps
[03:23] <Keybuk> Filename                                Type            Size    Used    Priority
[03:23] <Keybuk> /dev/hda5                               partition       1622524 0       -1
[03:23] <Keybuk> syndicate scott% udevinfo -qsymlink -nhda5 
[03:23] <Keybuk> disk/by-id/ata-HTS548040M9AT00_MRL242L2HA7L9B-part5 disk/by-path/pci-0000:00:10.0-ide-0:0-part5 disk/by-uuid/49fbf0dc-412a-4a8b-8469-6fa41cf9b78a 
[03:23] <_ion> How to add an UUID to a swap partition by hand?
[03:24] <Keybuk> uuidgen | perl -ne 's/-//g;printf "%c",hex $1 while(/(..)/g)' dd conv=notrunc "of=$DEV" obs=1 seek=1036
[03:24] <Keybuk> (replace $DEV)
[03:24] <_ion> Thanks.
[03:24] <Keybuk> err
[03:24] <Keybuk> uuidgen | perl -ne 's/-//g;printf "%c",hex $1 while(/(..)/g)' | dd conv=notrunc "of=$DEV" obs=1 seek=1036
[03:24] <Keybuk> :p
[03:25] <_ion> Is the edgy UUID conversion code available from somewhere?
[03:26] <Keybuk> /var/lib/dpkg/info/volumeid.postinst
[03:26] <_ion> Thanks again. :-)
[03:50] <_ion> keybuk: Btw, the perl code in a slighty shorter (and one might say clearer) form: s/-//g;chomp;print pack("H*",$_)
[03:51] <lastnode> infinity, ping?
[04:14] <lastnode> imbrandon, ping?
[04:15] <imbrandon> pong
[04:16] <sladen> Keybuk: can that be added to mkswap ?
[04:20] <bddebian> Howdy
[04:21] <Keybuk> sladen: it could I guess
[04:21] <bddebian> Morning Keybuk
[04:22] <lastnode> imbrandon, there is this insane problem with httplib and urllib - t seems to cap the data after a certain number of bytes
[04:22] <lastnode> returns 200 OK, but no data goes across
[04:22] <imbrandon> hrm ok i'm about to head out soon i'll look when i get back
[04:22] <lastnode> ok cool
[04:22] <lastnode> thanks mate
[04:23] <sladen> Keybuk: that would be most useful, people are more likely to use that to create swap partitions than the 'postinst' :)
[04:24] <Mez> Kamion: pinh
[04:24] <Mez> s/pinh/ping/
[04:25] <bddebian> Whoa, heya Mez
[04:25] <Mez> bddebian, hello :D
[04:27] <sladen> Keybuk: btw, do all the other mk.* creation tools generate a UUID automatically?
[05:00] <bddebian> Anyone have the patience/time to explain the 0c2a transition crap to me?
[05:03] <azeem> why should anybody want to explain crap to you?
[05:03] <Nafallo> hehe
[05:07] <bddebian> azeem: Becuase I try to help?
[05:08] <azeem> bddebian: maybe, but calling things people put in a lot of thought "transition crap" won't help a lot
[05:09] <azeem> I'm sure people will gladly answer if you ask a specific question about that transition
[05:09] <bddebian> Did I say that their work was crap?  NO.  It's merely an expression.
[05:10] <tseng> bddebian: you did, actually
[05:10] <tseng> whether you think so or not
[05:10] <bddebian> How so?
[05:10] <tseng> "transition crap", pretty clear
[05:11] <tseng> it helps to understand that someone might interpret something you wrote differently
[05:11] <tseng> esp if they aren't native USians
[05:11] <tseng> who say crap as a manner of speech all day
[05:11] <bddebian> Gah, bbiam
[05:47] <bddebian> OK, how about can someone please help me understand this ingenious wonderful 0c2a transitions stuff?  Better? :-)
[05:47] <azeem> bddebian: what part did you not understand?
[05:48] <bddebian> Well I got the concept but now I'm not sure how to handle something like osgcal
[05:48] <bddebian> We did libosgcal0c2a because of the C transition
[05:49] <bddebian> But now Debian is using the same toolchain (I think).  Do we revert back?
[05:50] <azeem> Debian was doing c2a as well
[05:51] <bddebian> Aye but for osgcal I only ever see a libosgcal0 not c2a
[05:52] <pygi> will  be be dropping cdrecord as well, and use forked cdrtools?
[05:53] <bddebian> azeem: I guess what I am asking is that if I merge osgcal from Debian, I am going to have to deal with conflicts/replaces, etc for the libosgcal0c2a stuff right?
[05:54] <bddebian> See, it's crap to me because I'm too dumb to understand it :-)
[06:00] <geser> if you merge it as libosgcal0 you must conflict/replace libosgcal0c2a
[06:00] <bddebian> geser: That's what I thought, thanks
[06:02] <geser> it's because both packages provide the same files
[10:59] <bluefoxicy> man my hard disk is cranking.
[11:26] <bluefoxicy> I need review for a spec I am going to try to propose for Edgy; is it automatically in the queue, or do I need to do something