[02:50] <Robot101> hmm, who's responsible for Release files on archive.u.c?
[02:50] <Robot101> feisty-updates and feisty-securoty claim to be v=6.10, its throwing my apt pinning off
[02:51] <Robot101> actually, it might not be, but it still looks suspicious.
[03:35] <rideout> hello, I'm just upgraded to feisty an noticed a problem, when compiling kde trunk, I get a linker error for a class that links to openexr, it isn't linking to libstdc++, this a regression from edgy
[08:27] <pitti> good morning
[08:40] <Mithrandir> somerville32: yes, sure.  Which date is good?
[08:41] <somerville32> Mithrandir, What ever is best for you.
[08:41] <Mithrandir> somerville32: uh; which date have you tested and such?  I'm not going to just release a random snapshot and hope it works.
[08:41] <Mithrandir> Adri2000: no, no point.  There's a missing build-dep on python-dev there.
[08:42] <somerville32> Mithrandir, I got the impression from Jani that it was already tested.
[08:43] <Mithrandir> somerville32: well, then there is a particular image which is tested.
[08:43] <somerville32> ok
[08:55] <dholbach> good morning
[09:38] <dholbach> ogra: new dia release
[10:38] <cjwatson> Robot101: I think it's just because they haven't been regenerated since November, but I'll follow it up
[10:39] <cjwatson> in fact, since they haven't been regenerated, screw it, I'll just edit them
[10:39] <cjwatson> or, no I won't, that would break signatures
[10:41] <cjwatson> Robot101: chasing it up with the soyuz team
[11:00] <pitti> Mithrandir: changelog-closes-bugs, the dpkg-scanchangelog side?
[11:00] <Mithrandir> pitti: yes.
[11:00] <pitti> s/scan/parse/
[11:01] <Mithrandir> : tfheen@golem /tmp/hello-2.2 > dpkg-parsechangelog | grep ^L
[11:01] <Mithrandir> Launchpad-bugs-fixed: 1112 1234 2345
[11:01] <pitti> yay
[11:03] <Mez> Mithrandir, I've just modified the backports task for wordpress, you closed the dapper backports instead of the edgy backports ;)
[11:03] <Mithrandir> Mez: oh, sorry.  Thanks.
[11:03] <Mithrandir> Mez: finger macros..
[11:04] <Mez> Mithrandir, no problems, the dapper one's approved now too (I lost it in the ether cause it was closes! thank god someone poked me!)
[11:04] <Mithrandir> Mez: seb will hopefully get to it tomorrow, then
[11:05] <Mez> cool ;)
[11:28] <glatzor> mpt: hi, some time ago we talked about the software-properties and about where it should be accessible.
[11:30] <glatzor> mpt: it would be nice if you could also leave a comment on the universe-multiverse-by-default spec.
[11:30] <glatzor> mpt: mainly it is about removing s-p from the control center and gnome-app-install. and only making it available in update-manager and synaptic
[11:33] <seb128> ogra: there is a new dia pre version available
[11:35] <Mirv> pitti: thanks for handling bug 82143. feisty will be so bercool for the Finnish people now :)
[11:35] <Ubugtu> Malone bug 82143 in language-support-fi "Add main-accepted Voikko packages to a seed, language-support-fi should depend on Voikko spellchecking libraries in 7.04" [Undecided,Fix released]  https://launchpad.net/bugs/82143
[11:35] <pitti> Mirv: yay
[11:38] <tepsipakki> yes, that's cool
[12:42] <Adri2000> hi Mithrandir 
[12:43] <Hobbsee> Mithrandir
[12:43] <Hobbsee> !!!
[12:43] <Mithrandir> hiya Hobbsee, Adri2000
[12:43] <Hobbsee> :(
[12:43] <Hobbsee> * :)
[12:43] <Fujitsu> Greet, Adri2000, Hobbsee, Mithrandir.
[12:43] <Treenaks> Hobbsee: just blame your cat ;)
[12:44] <Mithrandir> downtime was a bit larger than anticipated, I forgot to plug in power to one of the RAID drives and wondered why it refused to start..
[12:44] <Hobbsee> Mithrandir: heh
[12:44] <Hobbsee> hey Fujitsu 
[12:44] <Hobbsee> Treenaks: hrm, there's an idea.  or my fish
[12:44] <Treenaks> Hobbsee: something like that
[12:44] <Adri2000> Mithrandir: gaupol already build depends on python-dev, and I asked a give-back because there is no problem when building it in my up to date pbuilder
[12:46] <Mez> Mithrandir, tis an easy mistake to make
[12:46] <Mithrandir> Adri2000: then why isn't python-dev mentioned in the build log?
[12:48] <Adri2000> Mithrandir: ah sorry, I apt-get source'd it but didn't see I was downloading the version in debian
[12:48] <Adri2000> I will request a sync
[12:49] <Mithrandir> ah. :-)
[12:49] <Adri2000> gaupol (0.7.2-2) unstable; * Add python-dev build requirement (FTBFS with python2.5)
[12:49] <Adri2000> :)
[12:49] <Mithrandir> indeed.
[12:53] <Adri2000> well, sync already requested
[12:53] <Adri2000> but needs an ack
[12:53] <Fujitsu> Adri2000, I'm sure you can organise that :)
[12:55] <Mithrandir> iirc, he became one like a week ago.
[12:55] <Adri2000> I am now, and I've just acked the sync
[01:04] <cjwatson> mvo: in progress on the edubuntu-on-two-cds g-a-i work now
[01:04] <mvo> cjwatson: me too
[01:05] <cjwatson> mvo: you'll get a .disk/add-on file on the add-on CD containing a path to the app-install data directory relative to the CD root (i.e. '/app-install')
[01:05] <mvo> cjwatson: ok, thanks. I have a patch for update-notifier to get the detection done. and now I'm working on the g-a-i integration
[01:06] <mvo> cjwatson: we probably need a applications.menu file on the cd as well (from app-install) so that people can customize that
[01:06] <mvo> customize the menu structure
[01:06] <mvo> that is displayed
[01:06] <cjwatson> is there one of those in app-install-data?
[01:07] <ogra> i guess we need a dedicated one, no ?
[01:07] <ogra> depending on the shipped apps
[01:07] <cjwatson> ah, yes
[01:07] <cjwatson> won't the menu code just automatically ignore the irrelevant bits?
[01:07] <ogra> i'm fine with manually generating that for one release though ...
[01:08] <cjwatson> I'd much rather it did it automatically - excluding bits of XML in debian-cd will be a pain
[01:08] <cjwatson> can I just try it and see what happens? :)
[01:08] <ogra> heh :)
[01:08] <mvo> the stock one should work fine 
[01:09] <mvo> ie. the one that is normally in /usr/share/app-install/desktop
[01:09] <cjwatson> mvo: ok, done
[01:09] <mvo> thanks
[01:13] <elkbuntu> hello ogra :)
[01:18] <fabbione> morning guys
[01:33] <sladen> jbabies!
[01:44] <Hobbsee> Keybuk: he might bite, you know
[01:49] <kwwii> dholbach: did you see the process-stop icon improvement? I tihnk we should include it
[01:50] <dholbach> kwwii: ok, I just needed a decision on it
[01:50] <dholbach> kwwii: will do it
[01:50] <kwwii> dholbach: great, thanks :-)
[01:50] <mvo> cjwatson: is the addon cd for amd64 good? should I download it for testing?
[01:51] <dholbach> kwwii: i'll also add some translations to h-i-t
[01:51] <mvo> cjwatson: does the .disk/ contain information about the distro/architecture that the cd is designed
[01:52] <mvo> for?
[01:52] <kwwii> dholbach: h-i-t? 
[01:52] <dholbach> kwwii: human-icon-theme
[01:52] <kwwii> dholbach: hehe, gona take awhile till I know all the acronyms ;-)
[01:53] <cjwatson> mvo: the 20070206.1 build should be good
[01:53] <dholbach> np ;-)
[01:53] <cjwatson> mvo: it does, but it's not all that easily parseable
[01:54] <cjwatson> mvo: wouldn't it be easier to look in dists/ ?
[01:54] <cjwatson> I think that's normal
[01:54] <cjwatson> dists/blah/Release I mean
[01:54] <mvo> cjwatson: fine with me, I was just wondering
[01:59] <Kagou> anyone know why murrine is compiled but not available ?! ( https://launchpad.net/+builds/+build/298279 )
[02:02] <Hobbsee> Kagou: probably sitting in binary NEW
[02:02] <dholbach> same as libtapioca-cil, I guess
[02:02] <Hobbsee> https://launchpad.net/ubuntu/feisty/+queue?queue_state=0&queue_text=murrine
[02:02] <Hobbsee> yep
[02:03] <dholbach> yep
[02:05] <dholbach> can somebody promote espeak to main? I'll do a ubuntu-meta upload later then.
[02:05] <Kagou> thanks Hobbsee 
[02:06] <Mithrandir> dholbach: it's not promoted until it shows up in anastacia.txt
[02:08] <dholbach> hum, it's in there
[02:08] <dholbach> I wonder why ubuntu-meta's ./update doesn't reflect the seed change I did like 2-3h ago
[02:12] <carlos> seb128, pitti: Last fesity translation opening went quite well, I'm going to schedule the final opening with Stuart
[02:12] <seb128> carlos: ah, good
[02:12] <seb128> carlos: did you make it faster? ;)
[02:13] <carlos> seb128: it took 2 hours and 15 minutes 
[02:14] <carlos> instead of 29 hours..
[02:14] <seb128> what did you change?
[02:14] <carlos> so I guess the answer is 'yes'
[02:14] <cjwatson> dholbach: ubuntu-meta will only ever accept items in main
[02:14] <cjwatson> dholbach: so the promotion has to be done before ./update will pick it up
[02:14] <carlos> seb128: we disabled a trigger that updates another table that is not needed for this process
[02:14] <seb128> ok
[02:15] <dholbach> cjwatson: ok, thanks - that's how I understood it also.
[02:33] <dholbach> kwwii: uploaded
[02:33] <kwwii> dholbach: great, thanks :-)
[02:34] <dholbach> kwwii: lapo wants to work on tangerine-icon-theme again
[02:35] <kwwii> dholbach: I never understood what the point was with the tangerine theme...it is very close to the human theme, or?
[02:36] <dholbach> kwwii: they recolored a bunch of tango icons to make the whole feeling smoother (we use Human, then fallback to Tangerine, then Tango, then GNOME, then hicolor)
[02:37] <kwwii> dholbach: ahaa, now I get it
[02:37] <pitti> carlos: yay!
[02:38] <kwwii> dholbach: good to see that people are being productive :-)
[02:38] <dholbach> yeah :)
[02:39] <Robot101> is feisty going to ship with pulse as default?
[02:39] <elmo> edgy has madwifi-ng right?
[02:39] <Robot101> pulseaudio
[02:39] <Ng> yes
[02:40] <Robot101> if so, could I recommend /etc/libao.conf having the default driver as pulse? then ogg123 and mpg321 will work.
[02:40] <elmo> how do I tell madwifi-ng from madwifi?
[02:46] <Keybuk> elmo: ifconfig | grep wifi0
[02:46] <elmo> Keybuk: I had to modprobe ath_pci manually, and even then it didn't detect the card
[02:46] <Keybuk> odd
[02:46] <elmo> it's yet another f"^#$ing intel macbook
[02:47] <asac> pitti: are -dbg packages automagically generated in future?
[02:47] <elmo> these things follow me around like lost puppies.  and like lost puppies, I just want to kick them
[02:47] <pitti> asac: not -dbg, bug -dbgsym packages are automatically created since edgy
[02:47] <pitti> asac: I called them -dbgsym in order to not conflict with the already existing -dbg packages
[02:47] <pitti> asac: we don't need the -dbg ones any more, but removing them all would be too much (and pointless) work
[02:48] <asac> pitti: ok so we don't need one for thunderbird ... fine :)
[02:48] <Keybuk> elmo: lspci -n -v > #ubuntu-kernel
[02:48] <pitti> asac: yep
[02:48] <pitti> asac: if you touch the firefox package, feel free to remove that one, too
[02:48] <thom> elmo: new macbook(pro) atheros parts aren't supported yet
[02:50] <pkl_> thom: by Edgy, or by madwifi-ng?
[02:50] <asac> pitti: ah ok ... and apport-retrace is ment to be run by developers/bug-triagers vs. the user himself?
[02:50] <thom> pkl_: latter
[02:50] <thom> needs new HAL
[02:50] <pitti> asac: yes, so far; however, I'm working on an automatic solution
[02:50] <mjg59_> pitti: I can't get apport to stop giving me crash dialogs for the same application
[02:51] <mjg59_> Even if I tick the "Don't tell me again for this version" box
[02:51] <pitti> mjg59_: it will show up again once the binary gets touched
[02:51] <thom> pkl_/elmo: http://madwifi.org/ticket/1001 or so; kyle was thinking about trying to rip the hal out of osx
[02:51] <asac> pitti: gogo ;)
[02:51] <Kano> hi, why do linux-headers require libc6?
[02:52] <elmo> thom: ! because there's no potential license issues with that :-P
[02:52] <thom> yeah yeah, didn't say it would go in the distro :P
[02:52] <mjg59_> pitti: I haven't done anything that ought to touch the binary
[02:53] <pitti> mjg59_: do you have an ~/.apport-ignore.xml, and does the process in question run as your user?
[02:53] <mjg59_> pitti: I do, and it does
[02:54] <mjg59_> mtime is in January
[02:54] <pitti> mjg59_: can you put /var/log/apport.log somewhere?
[02:54] <mjg59_> pitti: www.codon.org.uk/~mjg59/tmp/apport.log
[02:54] <mjg59_> Oh, hang on, 403
[02:54] <mjg59_> Try again
[02:54] <cjwatson> belatedly
[02:55] <mjg59_> pitti: Eh, it's been rotated
[02:56] <mjg59_> pitti: Hm. I just got a crash dialog without anything appearing in apport.log
[02:57] <mjg59_> pitti: It seems to be the apport dialog (it's got the "Ignore future crashes of this program version" button)
[02:57] <pitti> mjg59_: hm, /var doesn't happen to be mounted noatime for you or so?
[02:57] <mjg59_> No
[02:57] <cjwatson> Kano: because executables in the scripts subdirectory are linked against it
[02:58] <Kano> i really dislike that the libc6 is differnet than in etch
[02:58] <mjg59_> cjwatson: Should just need you to drop x86emu and link against libx86 instead of lrmi.o
[02:58] <cjwatson> mjg59_: yup, that's what I'm doing
[02:58] <cjwatson> Kano: use a chroot, and deal
[02:58] <mjg59_> Ok. Let me know if there's any trouble.
[02:58] <Mithrandir> we should sync libx86 first, though
[02:59] <Mithrandir> since it's not in the archive, at least wasn't a week or so ago
[02:59] <cjwatson> I apt-get sourced it today
[02:59] <Mithrandir> oh sure, it's not hard, we just need to do it.
[02:59] <mjg59_> pitti: Anything useful I can provide?
[02:59] <Kano> cjwatson, that linux-kernel package creates more than 1 kernel it seems. how to compile only one?
[02:59] <Mithrandir> Kano: it's on the wiki
[02:59] <mjg59_> Kano: The package is designed to build all flavours.
[03:00] <pitti> mjg59_: so, do you get the same report displayed in apport-gtk over and over, or do you actually have new crashes in between?
[03:00] <Kano> the generic one would be enough for me
[03:00] <mjg59_> pitti: New crashes in between
[03:00] <pitti> mjg59_: log file would still be interesting
[03:00] <mjg59_> telepathy-butterfly is utterly funted
[03:00] <mjg59_> pitti: There's nothing in the logfile
[03:00] <pitti> ugh
[03:00] <cjwatson> Kano: prod debian/rules, it should be obvious
[03:00] <Nafallo> cjwatson: rock on! :-)
[03:00] <Kano> will look into it
[03:00] <pitti> mjg59_: which process crashes?
[03:01] <mjg59_> pitti: telepathy-butterfly
[03:01] <mjg59_> pitti: It doesn't have a "restart program" option
[03:01] <Nafallo> cjwatson: feel free asking me to test usplash if you need it later :-)
[03:01] <Kano> is there a new source available which is 2.6.20 final based?
[03:01] <cjwatson> we do need to promote libx86 though
[03:01] <cjwatson> Nafallo: if it works for me I'll just punt it at the archive; I'm sure you'll notice ;-)
[03:01] <pitti> mjg59_: ah, it's a python crash then, no SIGSEGV or so
[03:02] <mjg59_> pitti: Right
[03:02] <pitti> mjg59_: right, those cannot go into the log file, since they are called as user
[03:02] <Nafallo> cjwatson: :-(
[03:02] <Nafallo> cjwatson: :-) even
[03:02] <mjg59_> pitti: Ok. That explains the lack of logging, but not the fact that it keeps showing me the dialog :)
[03:02] <pitti> mjg59_: right, then I know what's wrong
[03:02] <mjg59_> pitti: Ok, cool. Do you want a bug filing?
[03:02] <pitti> mjg59_: in apport I check the 'ExecutablePath', which is still 'python2.5' at that time
[03:03] <mjg59_> pitti: Ah! Figures.
[03:03] <pitti> mjg59_: bug report would be nice
[03:03] <pitti> mjg59_: so for interpreted programs I need to check mtime of the interpreted script, not mtime of the interpreter
[03:03] <Mithrandir> cjwatson: fyi, sync request filed.
[03:03] <pitti> mjg59_: thanks for pointing that out
[03:03] <cjwatson> pitti: what's the difference between "Packages proposed to be included into main" and "Unreviewed packages" in UbuntuMainInclusionQueue
[03:03] <cjwatson> Mithrandir: please reject it. It's already there.
[03:03] <cjwatson>     libx86 |     0.99-1 |       testing | source
[03:03] <cjwatson>     libx86 |     0.99-1 |      unstable | source
[03:03] <mjg59_> pitti: apport or python-apport?
[03:03] <cjwatson>     libx86 |     0.99-1 | feisty/universe | source
[03:03] <Mithrandir> cjwatson: oh, ok
[03:04] <Mithrandir> cjwatson: meh, ok.
[03:04] <pitti> mjg59_: it's just one source, 'apport'; the particular binary is python-apport, but that's not really important for the bug
[03:04] <cjwatson> it failed to build on amd64, though
[03:04] <cjwatson> mjg59_: http://librarian.launchpad.net/5155088/buildlog_ubuntu-feisty-amd64.libx86_0.99-1_FAILEDTOBUILD.txt.gz
[03:05] <Mithrandir> I have a fix for that somewhere.
[03:05] <pitti> cjwatson: good question, I didn't see this section before; iwj?
[03:05] <mjg59_> cjwatson: Needs to build with backend=X86EMU or something, which I thought rules did but I may have been wrong
[03:05] <cjwatson> looks like just incorrect build rules - it shouldn't be using lrmi on amd64
[03:06] <cjwatson> debian/rules looks to be using spaces wrongly
[03:06] <mjg59_> Eh, could be
[03:06] <mjg59_> Feel free to NMU a fixed version to Debian :)
[03:06] <cjwatson> I'll prod it once my amd64 box upgrades, if Tollef doesn't beat me to it
[03:06] <pitti> cjwatson: that section should just be merged into unreviewed, I figure
[03:06] <mvo_> ogra: the support for edubuntu-on-two-cds should be finished with the recent upoads of u-n, g-a-i and python-apt. please test. there are some warts left, but that seems to be mostly ui-glitches
[03:07] <Mithrandir> cjwatson: nah, I'd need to dig it out of somewhere so I'll just leave it to you, but you seen to have identified the problem, so. :-9
[03:07] <Mithrandir> s/9/)/
[03:07] <mjg59_> Kano: Check git.
[03:08] <iwj> fabbione: So do you have actual boxes with root on lvm and the standard setup ?  Are they using lilo or grub ?  And when update-initramfs runs, what runs lilo ?
[03:08] <iwj> This stuff all looks quite broken to me.
[03:08] <cjwatson> mjg59_: is it in bzr or anything?
[03:09] <fabbione> iwj: i have them yes. they are using grub (/boot is not on lvm). no idea about lilo
[03:09] <fabbione> iwj: note that I am montreal now so i don't have access to all of them
[03:09] <mjg59_> cjwatson: Nope
[03:09] <fabbione> iwj: the default install autopartitioner will always keep /boot outside lvm
[03:09] <iwj> fabbione: OIC
[03:10] <iwj> fabbione: OK.  AFAICT anyone who is using lilo with ubuntu atm is completely SOL.
[03:10] <fabbione> iwj: if people force /boot on LVM, only lilo *might* work
[03:10] <iwj> fabbione: Yes, but everything and its dog runs update-initramfs and nothing runs lilo.
[03:10] <fabbione> iwj: i do have a server with lilo but it's still running breezy... 
[03:10] <iwj> Do you run lilo by hand ?
[03:10] <fabbione> yes i do because
[03:10] <fabbione> because of old memories...
[03:10] <iwj> Yes.  Well.
[03:11] <fabbione> yeah you get my point
[03:11] <iwj> Very wise of you is all I can say.
[03:11] <fabbione> it's a production server and  i can't cope with minimal breakage there
[03:11] <iwj> I think I might try to fix that with an initramfs hook script, but after feature freeze.
[03:11] <fabbione> but i have machines we can test on
[03:11] <fabbione> as many we like
[03:12] <iwj> Test boxes aren't a problem really.  I have a perfectly good test setup here.  Well, when I say perfectly good I mean that it demonstrates very well all of the things that are hosed.
[03:12] <fabbione> iwj: ehehe ok..
[03:13] <iwj> But it's nice to be a bit reassured that it's not just me.  It's definitely a case of "this couldn't possibly work" and the answer seems to be "it doesn't".
[03:13] <fabbione> iwj: the whole raid/lvm thing is busted... we do agree and needs fixing..
[03:13] <cjwatson> I suspect that at the moment it would be best fixed in kernel-package
[03:13] <fabbione> so it's just not us
[03:13] <cjwatson> which is what is *supposed* to take care of running boot loader installers
[03:13] <fabbione> cjwatson: the kernel does run lilo on upgrades
[03:14] <cjwatson> oh I see, it's stuff other than the kernel, ok
[03:14] <fabbione> the issue that iwj is thinking about is that we do run a lot of update-initramfs
[03:14] <fabbione> triggered by other pkgs
[03:14] <iwj> cjwatson: update-initramfs which is run by the postinsts of about a dozen packages will break your boot.
[03:14] <iwj> Unless we fix it to run lilo.
[03:14] <fabbione> yeps
[03:14] <cjwatson> yeah, sorry, forgot about that
[03:15] <iwj> Still, I'm making surprisingly good progress.
[03:15] <fabbione> anyone wants some? mneptok is really good as coffe maker :P
[03:15] <cjwatson> mjg59_: you'll have an NMU as soon as I can convince the damn thing to build on powerpc, which I think will take upgrading my Debian chroot from prehistoric
[03:15] <iwj> I have / on lvm and I think I can boot it (one more test to do).
[03:16] <mjg59_> cjwatson: Ah. PPC may still be an issue.
[03:16] <pkl_> everyone who installs Ubuntu on an Intel Mac uses Lilo...
[03:16] <iwj> We should get the ftpmasters to make links for all of {unstable,testing,stable,oldstable,old,ancient,prehistoric} on archive.debian.org.
[03:17] <iwj> pkl_: Presumably they are used to all of this crazy lossage ?
[03:17] <mjg59_> pkl_: Not nowadays
[03:18] <mjg59_> iwj: grub used to fail with the Mac bios emulation, but that's been fixed for some time
[03:18] <iwj> Is watershed wrong to expect /var/run to exist ?
[03:18] <fabbione> iwj: do you have a second for a dpkg question?
[03:18] <iwj> mjg59_: Aha.
[03:18] <iwj> fabbione: Sure.
[03:18] <pkl_> Grub doesn't work on bootcamp.  There's an article in the latest Linux Format (MacBook HowTo/February) which tells people to use lilo :-) 
[03:19] <mjg59_> pkl_: No, it really does
[03:19] <fabbione> iwj: is there any specific reason why dpkg -l doesn't output the epoch in the version?
[03:19] <iwj> fabbione: My mistaken belief at the time that people wanted pretty rather than complete output.
[03:19] <iwj> See also field truncation.
[03:20] <fabbione> iwj: the field truncation happens only when directing to a terminal.. i noticed that
[03:20] <fabbione> when redirected to a file it comes in full
[03:20] <iwj> I really need to make  dpkg -s DTRT if you pass it no package names.
[03:20] <fabbione> but still no epoch
[03:20] <fabbione> hmm
[03:20] <iwj> fabbione: I think that's a bug.
[03:20] <fabbione> ok thanks for the explanation.. 
[03:20] <fabbione> mind if i file a bug to get epoch?
[03:20] <iwj> NP.  Sure.  Sorry :-).
[03:21] <fabbione> iwj: sorry for what? thanks for the help :)
[03:21] <iwj> Assign it to me.  Sorry for making it wrong to begin with :-).
[03:21] <pkl_> mjg59: since when was it fixed, I tried installing edgy under bootcamp about a month ago, and it failed.  Even if its fixed, articles are still saying use lilo anyway.
[03:21] <mjg59_> pkl_: I don't know precisely when it was fixed, merely that it's been fixed.
[03:21] <fabbione> iwj: if it has gone unseen for all this time, i guess not that many did really care..
[03:21] <mjg59_> Anyway, it's hardly unusual for articles to contradict documentation.
[03:22] <iwj> If there are people using lilo they must be having a pretty fun time.
[03:22] <evand> bootcamp, refit and grub work fine for me (short of not being able to use the keyboard in grub)
[03:25] <fabbione> iwj: done thanks. bug #83567
[03:25] <Ubugtu> Malone bug 83567 in dpkg "dpkg -l doesn't display the epoch" [Wishlist,Confirmed]  https://launchpad.net/bugs/83567
[03:25] <pkl_> Yeah, articles often don't follow documantion or are plain wrong.  Fact of life.  I wasn't reading the article for myself :-) just seeing ehat was being said etc.
[03:25] <iwj> fabbione: Ta.
[03:26] <fabbione> iwj: you can specify what version you want to upgrade..
[03:26] <fabbione> update-initramfs -u -k $version
[03:27] <pkl_> evand: when I found wifi didb't work under edgy, that was reason enough to run Linux only in Parallels.
[03:27] <cjwatson> pkl_: as mjg59 says, that's been fixed since. There were two issues: one was grub trying to use BIOS calls that bootcamp didn't emulate (AIUI), and the other was grub not supporting GPT so you had to use a tool called mbrsync to copy the GPT into the MBR partition table (which is no longer necessary)
[03:27] <cjwatson> pkl_: the latter part was certainly broken in edgy
[03:28] <evand> pkl_: If it's the same model (BCM4328 wifi), just use ndiswrapper.
[03:28] <cjwatson> pkl_: that's not fixed in grub upstream though, just in Ubuntu's grub (though I got the patch from the upstream mailing list)
[03:29] <mjg59_> Please don't say "Just use ndiswrapper"
[03:29] <cjwatson> mjg59_: at the moment it's failing due to lack of sys/io.h
[03:29] <mjg59_> cjwatson: Yes, PPC doesn't have port i/o
[03:30] <pkl_> evand: yes I saw that on the madwifi ticket mentioned previously.  I've lots of machines running Linux, and so it wasn't important for me to get it running under BootCamp.  I wanted to see how it worked "out of the box"
[03:30] <cjwatson> mjg59_: oh, joy
[03:30] <cjwatson> I'll just build the thing on amd64 then
[03:30] <mjg59_> cjwatson: So that actually needs to be implemented in libx86
[03:30] <mjg59_> I'll rip the code out of X at some point
[03:31] <evand> pkl_: If it's the same model (BCM4328 wifi), just use ndiswrapper.
[03:31] <evand> sorry
[03:31] <evand> wrong terminal
[03:32] <xerxas> cjwatson,  are you an uploader on the ftp ?
[03:33] <cjwatson> xerxas: why?
[03:33] <xerxas> I have a package that have been advocated on revu but it doesn't appear on the distribution , for sth like 10 days 
[03:33] <cjwatson> -> #ubuntu-motu
[03:33] <xerxas> I'm waiting that package to package other things 
[03:33] <xerxas> cjwatson,  I've asked on #ubuntu-motu 
[03:33] <cjwatson> don't ask here, then
[03:33] <Hobbsee> xerxas: wasnt it decided that it was in binary NEW?
[03:34] <xerxas> Hobbsee,  ahh , and then ? 
[03:34] <xerxas> where it is ? 
[03:34] <cjwatson> oh, sure, if it's in NEW, that can be dealt with here
[03:34] <xerxas> what is binary new ? 
[03:34] <cjwatson> what's the package name?
[03:34] <Hobbsee> xerxas: then you wait for it to be fixed, or poke
[03:34] <xerxas> libtapioca-cil 
[03:34] <xerxas> Hobbsee,  I don't see any build problems 
[03:34] <cjwatson> NEW queue> https://wiki.ubuntu.com/UbuntuDevelopment#head-48234c6bdac8679844493fcc4613f128adf658eb
[03:35] <Hobbsee> xerxas: all new binaries, including those from packages new to ubuntu, go into binary NEW queue.
[03:35] <Hobbsee> aka the abyss, maybe
[03:35] <cjwatson> rubbish
[03:35] <cjwatson> it's nowhere near that bad
[03:35] <Hobbsee> :P
[03:35] <Hobbsee> oh, sorry, SRU process is the abyss
[03:36] <cjwatson> xerxas: processed; it'll be in the archive in about an hour
[03:36] <Mithrandir> it's been in binary new for four days, which is a bit much, but not horrendous
[03:36] <xerxas> cjwatson,  cool 
[03:36] <xerxas> what does that mean ? 
[03:36] <xerxas> cjwatson,  can I apt-get install libtapioca-cil in 2 hours on a feisty ? 
[03:36] <cjwatson> yes
[03:36] <Hobbsee> xerxas: wait ~1hr, then download it
[03:36] <xerxas> what happened ?
[03:36] <cjwatson> I processed it
[03:37] <xerxas> should I bug you again if my next package is slow to appear ? 
[03:37] <Mithrandir> no, please don't
[03:37] <cjwatson> not me personally
[03:37] <Hobbsee> xerxas: the archive admins bite if poked too much
[03:37] <cjwatson> and no, you shouldn't bug in general
[03:37] <Hobbsee> dont they, Mithrandir?
[03:37] <cjwatson> we have a queue for this
[03:37] <Mithrandir> binary new is processed as a queue, there is no need to poke us unless it's urgent for some reason.
[03:37] <Mithrandir> Hobbsee: we breathe fire first, because we like our food roasted.
[03:37] <Hobbsee> Mithrandir: hhe
[03:37] <Hobbsee> *hehe
[03:38] <Mithrandir> of course, if it's urgent or holding up something, feel free to ask.
[03:38] <xerxas> ok , in my case, I need that package to continue my work , I can bug you, right ? 
[03:38] <Keybuk> you don't need that package to continue your work -- you can build it yourself for testing
[03:38] <xerxas> but the next package is the final, so I'll just wait .. 
[03:38] <Hobbsee> xerxas: of course, the next package, if it's new to ubuntu, will sit in NEW too.
[03:38] <xerxas> Keybuk,  it works, but then if I want to pbuild sth that require that package , I need the uploaded package
[03:39] <Mithrandir> xerxas: no, you don't.  You can easily set up a local repository.
[03:39] <Hobbsee> xerxas: then there's pbuilder magic that gets around that.
[03:39] <Keybuk> no you don't; set up a local repository for pbuilder
[03:39] <Hobbsee> Mithrandir: you dotn even have to go that far, do you?
[03:39] <xerxas> me fault then :)
[03:39] <Mithrandir> Hobbsee: maybe not, but I have all the stuff running already, so it's easier that way.
[03:39] <xerxas> too much things to learn :)
[03:40] <Hobbsee> heh
[03:40] <Mithrandir> Hobbsee: oh, sure, that works too
[03:40] <Hobbsee> that's what i tend to do, at least
[03:40] <Mithrandir> or you could just build in a regular system, there's nothing magic about chroots.
[03:41] <Hobbsee> Mithrandir: yes, only uploads ftbfs whenever someone else tries to build them.
[03:41] <Mithrandir> and if building in a regular system produces a different binary or different depends than what you get in a chroot, that's (arguably) a bug.
[03:41] <Mithrandir> or rather, it's a bug, but we can discuss the severity.
[03:41] <Hobbsee> good point
[03:44] <iwj> Aaargh.  If you say to udev   RUN+="one thing", RUN+="another thing"   it only does the second1
[03:44] <iwj> s/1/!
[03:46] <Keybuk> it does?  arguably that's a bug
[03:46] <cjwatson> it's certainly not as documented
[03:47] <Keybuk> cjwatson: it kinda is
[03:47] <cjwatson>        RUN
[03:47] <cjwatson>           Add a program to the list of programs to be executed for a
[03:47] <cjwatson>           specific device.
[03:47] <Keybuk> yes, but read above as to the actual format of each line
[03:47] <Keybuk> each line is a series of key/value pairs
[03:48] <Keybuk> it never says you can use a key more than once :p
[03:48] <cjwatson> oh, I didn't realise iwj was literally talking about a single rule there
[03:48] <Keybuk> you can certainly do...
[03:48] <Keybuk> something, something, RUN+="one thing"
[03:48] <Keybuk> something, something, RUN+="another thing"
[03:48] <Keybuk> on separate lines
[03:48] <iwj> That's pretty damn lame.
[03:49] <Keybuk> iwj: work around it for now -- I'll chat to kay later about fixing it
[03:49] <iwj> Right.
[03:49] <Keybuk> you could do something like:
[03:50] <Keybuk> something, something, GOTO="run_the_thing"
[03:50] <iwj> Yes.
[03:50] <Keybuk> GOTO="dont_run_the_thing"
[03:50] <Keybuk> LABEL="run_the_thing"
[03:50] <Keybuk> RUN+="one thing"
[03:50] <Keybuk> RUN+"another thing"
[03:50] <iwj> But actually sh -c is nicer because it involves only one copy of watershed.
[03:50] <Keybuk> LABEL="dont_run_the_thing"
[03:50] <Keybuk> ok
[03:50] <iwj> Also, why oh why oh why doesn't it use PATH ?  (Not that that's annoying me today but it's very silly.)
[03:51] <zul> Mithrandir:/win 12
[03:51] <zul> oops..
[03:51] <Keybuk> because most of PATH is usually not available while udev is running
[03:51] <Mithrandir> zul: you're not in my windows # 12. :-P
[03:51] <Keybuk> so it instead makes people put things in /lib/udev and defaults to there
[03:52] <zul> Mithrandir: obviously :)
[04:16] <popey> is cdimage. down?
[04:17] <popey> well, files unavailable
[04:17] <cjwatson> popey: in particular?
[04:17] <popey> http://cdimage.ubuntu.com/releases/feisty/herd3
[04:17] <popey> "The requested URL /releases/feisty/herd3 was not found on this server." 
[04:17] <cjwatson> works fine here ...
[04:18] <popey> aha
[04:18] <popey> herd-3
[04:18] <cjwatson> ah yes, I was following the links ;-)
[04:18] <cjwatson> did something link to the URL you gave?
[04:18] <popey> hehe
[04:18] <popey> a support ticket, dunno where he got that url from tho
[04:20] <popey> https://answers.launchpad.net/ubuntu/+ticket/3528
[04:42] <iwj> Yay!  Finally I have defeated it.
[04:43] <iwj> it = udev+lvm2+devmapper+lilo+aargh
[04:44] <pitti> mjg59_: fixed the apport ignoring bug (one of these cases where it takes 20 minutes to write the test case and 10 seconds to fix the bug...)
[04:44] <cjwatson> iwj: Well done on fixing aargh. That one has been bugging me too.
[04:44] <mjg59_> pitti: Heh
[04:44] <mjg59_> pitti: Thakns!
[04:50] <fabbione> cjwatson: i am having a small problem with preseeding netcfg. basically the 2 interfaces (one standard realtek and a wireless) keeps swapping name
[04:50] <fabbione> cjwatson: is there a way i can tell netcfg to skip the wireless reliably?
[04:50] <fabbione> or make sure to always use the fixed one, no matter of the name?
[04:51] <fabbione> (this is on a dapper install)
[04:51] <Keybuk> seed /etc/iftab so they don't swap?
[04:52] <cjwatson> fabbione: not within netcfg AFAIK; I think the right answer is to make netcfg preseedable with a MAC
[04:52] <cjwatson> you could seed /etc/iftab from a preseed/early_command if this is a CD install, or from /preseed.cfg in the initrd if this is a netboot install
[04:52] <fabbione> MAC can change
[04:53] <fabbione> i mean this is a test box out of N for massive install
[04:54] <Keybuk> what can't change?
[04:54] <elmo> 915resolution is in main for feisty right?
[04:54] <Keybuk> elmo: I hope not!
[04:54] <fabbione> Keybuk: what do you mean?
[04:54] <fabbione> Keybuk: if i preseed iftab, it won't match at the next machine
[04:55] <Keybuk> fabbione: what about the two interfaces is unique, and cannot change?
[04:55] <fabbione> the model
[04:55] <Keybuk> if the MAC can change, you can't use that to uniquely identify them
[04:55] <fabbione> one is realtek and one is ipwsomething
[04:55] <cjwatson> it's fairly straightforward to implement per-machine preseeding
[04:55] <Nafallo> elmo: universe
[04:55] <cjwatson> although a bit of a pain in the initrd, granted, but you could make it a boot option
[04:56] <Keybuk> elmo: install xserver-xorg-video-i810-modesetting instead
[04:56] <cjwatson> then the DHCP server can set it per-machine
[04:56] <Keybuk> elmo: you'll have *MUCH* better luck, plus projectors will work, and kittens will come back to life
[04:56] <mjg59_> Keybuk: Uh, no
[04:56] <mjg59_> It won't give any projector-based advantages
[04:56] <fabbione> cjwatson: i have no control over the dhpcd
[04:57] <cjwatson> !
[04:57] <Keybuk> mjg59: it does, because you can then just RandR to different resolutions for the projector
[04:57] <mjg59_> Keybuk: No, it won't
[04:57] <Keybuk> mjg59: with 915resolution, that doesn't work, because that only programs one mode into the card
[04:57] <troy_s> is the gksudo source code on bzr somewhere?
[04:57] <cjwatson> effective netboot preseeding assumes control over the dhcpd
[04:57] <mjg59_> Keybuk: Uh, that's really not true.
[04:57] <Keybuk> mjg59: works for me
[04:57] <Keybuk> mjg59: then what is true?  because the above is what Keith told me
[04:57] <mjg59_> 915resolution doesn't just program one mode. It modifies one mode.
[04:57] <Keybuk> right, and what it modifies it to is hard-coded in a particular config file?
[04:57] <mjg59_> You still have all the other modes
[04:58] <mjg59_> Yes, but your bios will still have 1024x768 and so on
[04:58] <Keybuk> isn't that the one it reprograms?
[04:58] <mjg59_> I sincerely hope not
[04:58] <mjg59_> If it is, that's a bug in our package rather than anything else
[04:58] <elmo> ok, so, all I care about is the macbook having working video out of the box :)
[04:59] <Keybuk> with 915resolution, I couldn't get my laptop to talk to a projector
[04:59] <Keybuk> with modesetting everything just worked
[04:59] <elmo> whether that's -modesetting or 915resolution, I don't mind
[04:59] <Keybuk> and I can change resolution to whatever I want
[04:59] <fabbione> Keybuk: do you know if udev-udeb can be preseeded to blacklist module loading?
[04:59] <Keybuk> fabbione: it cannot
[04:59] <fabbione> (if you remember)
[04:59] <fabbione> ok
[04:59] <Keybuk> it would be module-init-tools-udeb anyway
[04:59] <Keybuk> and that can't either afaik
[04:59] <elmo> mvo_: ping
[05:00] <Keybuk> mjg59: you'd recommend 915resolution over the modesetting video driver?
[05:00] <mjg59_> Keybuk: No
[05:00] <mjg59_> Well, not for 915 and higher
[05:00] <mjg59_> But a great deal of its extra functionality is limited for us because we have relatively ancient X
[05:00] <Keybuk> well, yes
[05:00] <mjg59_> xorg 7.2 will be out next week - are we planning on shifting?
[05:01] <Keybuk> haven't got anybody to do the shift for us :-/
[05:01] <mjg59_> Yeah, thought that might be the problem
[05:01] <Keybuk> we've having lots of luck hiring the X.org maintainer position
[05:01] <Keybuk> unfortunately all the luck is bad
[05:01] <mjg59_> It's a shame - all the code to move to randr 1.2 for feisty exists
[05:02] <mjg59_> And when I say "xorg 7.2 will be out next week", I mean "it's already all been released except for the docs"
[05:05] <mvo_> hello elmo
[05:06] <elmo> mvo: hi - is it a known bug (in edgy) that searching for '915' or 'resolution' returns nothing in add/remove programs?
[05:07] <mvo> elmo: add/remove only contains stuff that has a .desktop file
[05:08] <mvo> elmo: 915resolution apparently does not have one
[05:08] <elmo> mvo: oh
[05:08] <mvo> I assume this is what you looked for, right?
[05:08] <elmo> hmm, how confusing
[05:08] <elmo> mvo: yes
[05:08] <mvo> elmo: sorry. the idea for add/remove is to only show "end-user" applications
[05:08] <mvo> and that includes desktop files, otherwise its hard for end-users to find the programs :)
[05:11] <mvo> elmo: if you think 915resolution should be there, I can add it. we have a special section for stuff like codecs and plugins and the like
[05:12] <elmo> mvo: no, it's fine - I just forgot about the .desktop thing.  which is reasonable, it's just hard to explain to a new user
[05:14] <pitti> Riddell: I need a simple heuristic check whether the current session is KDE (for Gnome I use 'pgrep -u 1000 gnome-session'); what's a typical process for a KDE session?
[05:16] <Riddell> pitti: ksmserver iseh kde equivalent of gnome-session
[05:16] <pitti> Riddell: thanks
[05:36] <ogra_> meh, any archive admin around who could push thin-client-manager through new ? its student-control panel with new name and new binary names
[05:38] <pitti> ogra_: source or binary new?
[05:39] <pitti> ah, I see
[05:39] <ogra_> both
[05:39] <pitti> ogra_: it's really just a rename?
[05:40] <ogra_> thin-client-manager -> source; thin-client-manager-backend (all the cli functions of student-control-panel), python-tcm (all functions that could go into py modules); thin-client-manager-gnome (the gnome frontend and glade stuff from student-control-panel)
[05:40] <ogra_> apart from being a rename it implements the features from https://wiki.ubuntu.com/StudentControlPanelSpec
[05:41] <ogra_> (one of them is "Generalisation of SCP", which means renaming it to thin-client-manager)
[05:41] <ogra_> ... and splitting it
[05:44] <cjwatson> hooray, no more confusing acronym
[05:44] <ogra_> hehe
[05:45] <ogra_> well, tcm is a nonfood chain selling stuff at coffeeshops in germany ...
[05:45] <geser> Mithrandir: do you know what happend to the last python2.5 build on amd64? LP reports a successfull build but the debs didn't hit the archive yet
[05:45] <ogra_> i strill find it confusing :)
[05:45] <pitti> ogra_: ok, a quick check looks good
[05:45] <ogra_> thanks 
[05:46] <pitti> ogra_: accepted
[05:46] <ogra_> thanks even more :)
[05:46] <pitti> ogra_: it'll need a binary NEW after it built
[05:46] <pitti> ogra_: please ping me again
[05:46] <ogra_> yep
[05:46] <pitti> ogra_: shall I remove s-c-p?
[05:46] <ogra_> willdo
[05:46] <ogra_> from feisty, yes please
[05:46] <pitti> ogra_: (I guess the transitional package shuold be built from t-c-m)
[05:47] <pitti> ogra_: btw, the current t-c-m doesn't build a transitional package, will you still add that?
[05:47] <ogra_> yep
[05:47] <ogra_> i didnt find it FF critical ... will be done before next herd
[05:47] <pitti> right, no problem
[05:48] <pitti> ogra_: ^ done
[05:48] <ogra_> thanks ! :)
[05:53] <Mithrandir> geser: no, sorry.
[05:57] <iwj> fabbione: I'm a bit confused by the status of https://blueprints.launchpad.net/ubuntu/+spec/udev-mdadm.
[05:58] <iwj> Have you done anything about or to it ?
[05:59] <iwj> Keybuk: Hmm, I see that you were the person who wrote "Most of the work for this to be supported has been done in Debian, ensuring that mdadm is run on udev events for the md block devices" but AFAICT that's not true.
[06:00] <cjwatson> there was certainly a good deal done in the mdadm package (by madduck), although it's possible it's not complete
[06:00] <fabbione> iwj: not since we did talk at UDS..
[06:00] <fabbione> iwj: there is an general issue that mdadm needs to be converted to udev events
[06:01] <fabbione> iwj: because as it is now, if a device appears later than when we run the script, it's all doomed
[06:01] <fabbione> iwj: if you have time to look at it, it would be great, otherwise i guess i will have to work extra time next week
[06:02] <iwj> fabbione: I'm just checking that I'm not missing something because the info in the wiki seems to be wrong.
[06:02] <fabbione> iwj: Keybuk did misinterpreted what has been done in Debian
[06:02] <iwj> IC
[06:02] <iwj> I don't really have time now to set up a root-on-md test setup (or at least, not if it's going to be as much of a PITA as root-on-lvm).
[06:02] <fabbione> iwj: basically mdadm in Debian *after* a raid is started, will make sure that a udev event is generated
[06:03] <Keybuk> nothing to do with me
[06:03] <Keybuk> I just drafted the spec
[06:03] <Keybuk> other people discussed it and decided what was done in Debian was sufficient
[06:03] <iwj> "What was done in Debian" seems to be nothing.
[06:03] <fabbione> Keybuk: ok.. the comment was from you.. so i assumed
[06:03] <fabbione> iwj: but it doesn't solve the main issue that we need to wait for devices to appear before we run mdadm
[06:04] <fabbione> anyway.. the spec needs to be implemented...
[06:04] <iwj> The spec currently says `Implementation:  * Merge mdadm from Debian.   * Upload udev 103."
[06:04] <iwj> But those have both been done and we still have no support.
[06:05] <iwj> So before I go and just make something up I'd like to check that (a) that's OK with everyone and (b) we have some way to test it.
[06:05] <iwj> fabbione: So do you have a root-on-md system you don't mind breaking ?
[06:05] <fabbione> iwj: i am ok if you want to do it otherwise i will take it i guess. (b) yes we do.. plenty
[06:05] <fabbione> iwj: i have 2 of them
[06:05] <cjwatson> iwj: I think the information in the discussion came from me, because I was aware that a lot of work *had* been done in Debian's mdadm since edgy
[06:05] <fabbione> iwj: and they can break
[06:05] <cjwatson> iwj: it's not nothing - but it may well not be enough
[06:05] <iwj> cjwatson: They seem to have reverted quite a bit of it.
[06:06] <cjwatson> I'm entirely happy to be wrong there
[06:06] <fabbione> iwj: i can even give you console on one of them if you want
[06:06] <Keybuk> if it's been reverted ... then the spec isn't wrong, merely out of date
[06:06] <iwj> `Removed all udev-related stuff.' etc.
[06:06] <cjwatson> joy
[06:06] <fabbione> iwj: i am happy to give you access
[06:06] <iwj> Keybuk: "[not]  wrong, merely out of date".  You're obviously an incurable optimist :-).
[06:06] <keescook> goood mornin'
[06:08] <iwj> fabbione: Well, I'm not really familiar with mdadm so if you want to take it feel free.  Otherwise I'll RTFM and make something up.  I'm not too happy about the timing of my discovery that it wasn't already basically done ...
[06:09] <fabbione> iwj: if it's ok with you, i will work on it next week. I won't be able any time before.
[06:09] <iwj> fabbione: That's fine by me but you will need a freeze exception, surely ?
[06:09] <fabbione> iwj: implementing this spec means fixing  plenty of bugs
[06:09] <fabbione> iwj: not really....
[06:09] <fabbione> we have bugs that must be fixed and they rely on that spec
[06:09] <fabbione> so look at it as fixing bugs
[06:09] <fabbione> or implementing a spec
[06:09] <fabbione> makes no diff
[06:10] <iwj> fabbione: Err, OK.  You can argue that with Tollef or Scott or Colin or someone.
[06:10] <iwj> I don't have an opinion.
[06:10] <iwj> Keybuk: ^
[06:10] <iwj> or,
[06:10] <iwj> cjwatson: ^
[06:10] <fabbione> iwj: sure don't worry.. i have enough bugs and arguments... we all have 24h/day :)
[06:10] <fabbione> iwj: and 2 hands
[06:10] <iwj> *snort*
[06:10] <Keybuk> iwj: when would you have time to work on it?
[06:11] <iwj> Well, I could do it right now this instant.
[06:11] <cjwatson> iwj: up to Scott as far as I'm concerned
[06:11] <iwj> But Fabio seems to prefer to do it himself, which I can understand as I think he actually knows more about mdadm.
[06:11] <Keybuk> iwj: the spec is assigned to you -- please go ahead and do it
[06:12] <iwj> Keybuk: OK.  But consider this a heads-up: since I've discovered that the spec turned out not to be true any more, it may miss the feature freeze deadline.
[06:12] <Keybuk> noted
[06:12] <Keybuk> you're pretty familar with the races and the solution employed for lvm, so you've already got a head start on it
[06:12] <fabbione> Keybuk: we need it done. FF or not FF.. systems with / on raid or / on lvm on raid are unbootable atm
[06:12] <iwj> Keybuk: True.
[06:13] <fabbione> and we bugs tracked in LP
[06:14] <fabbione> cjwatson: do you happen to remember what's the equivalent of finish-install in dapper?
[06:14] <cjwatson> fabbione: prebaseconfig
[06:14] <fabbione> cjwatson: thanks
[06:16] <fabbione> iwj: worst case scenario, i am here on IRC till thursday your late afternoon and then back on monday
[06:16] <fabbione> iwj: so if you need any help or you have questions... i will be around
[06:16] <fabbione> iwj: also if you want access to hw
[06:16] <iwj> fabbione: Right, thanks.
[06:16] <iwj> I'll see how I get on.
[06:16] <iwj> I'm currently RTFMing and writing a designlet. 
[06:16] <fabbione> iwj: no problem.. sorry you are getting this spec dumped on you..
[06:17] <cjwatson> hmm, usplash still not happy
[06:17] <iwj> Oh, I was expecting this spec but I wasn't expecting it to be lies :-).
[06:32] <exobuzz> knetworkmanager is very nice, but there is a problem, since multiple network profiles are broken in knetworkconf, which makes the while knetworkmanager less useful (when it comes to cabled networks).
[06:32] <exobuzz> https://launchpad.net/ubuntu/+source/kdeadmin/+bug/73788
[06:32] <Ubugtu> Malone bug 73788 in kdeadmin "Network profiles completely broken" [Undecided,Confirmed]  
[06:33] <iwj> fabbione: So AFAICT mdadm-using systems pretty much always have an mdadm.conf to tell it what to do ?
[06:33] <fabbione> iwj: yes and you can use /usr/share/mdadm/mkconf to generate one on the fly if there is no config
[06:34] <fabbione> iwj: the major issue here is: install system -> boot -> add raids -> reboot.
[06:34] <fabbione> iwj: or better.. one of the major issues..
[06:34] <fabbione> mdadm.conf is not updated in that specific case
[06:35] <iwj> Right, I don't propose to fix that now.
[06:36] <fabbione> right
[06:36] <Riddell> exobuzz: so set up a static config and network manager will stop interfering
[06:36] <iwj> Yay!  If you run   mdadm -As   3 times in parallel, two of the copies segfault.
[06:36] <exobuzz> Riddell: thats not the problem
[06:37] <exobuzz> Riddell: the problem is that knetworkconf (which knetworkmanager calls for settings up static networks), has a profile feature, which doesnt work
[06:37] <Riddell> oh, right, it's full of bugs is knetworkconf
[06:38] <Riddell> I can add it to my todo of stuff to look at, but can't promis it'll get fixed in time
[06:38] <exobuzz> but as knetworkconf is so broken, perhaps knetworkmanager shouldnt "call it"
[06:38] <exobuzz> ok
[06:38] <fabbione> iwj: FTW!
[06:38] <exobuzz> thanks :)
[06:38] <Riddell> it's still the best thing we have for many uses
[07:13] <alex-weej> crash reporting has b0rked and i'm getting this in my kernel log: [32666.206448]  Core dump to |/usr/share/apport/apport.5908 pipe failed - any ideas?
[07:15] <pitti> alex-weej: file a bug against apport, please (sorry, I'm in a terrible hurry)
[07:15] <pitti> alex-weej: I see the problem
[07:15] <alex-weej> pitti: ok
[07:15] <pitti> thanks!
[07:49] <Keybuk> hmm, where did OFTC go>
[07:50] <kylem> dunno, it's been screwy all day for me
[07:50] <Keybuk> irc.oftc.net has address 127.0.0.1
[07:51] <Treenaks> maybe they're having scr1pt k1ddi3 problems?
[07:51] <iwj> There is a kernel bug here.
[07:53] <Keybuk> -- The kernel bug attacks.
[07:53] <Keybuk> -- You hit the kernel bug.
[07:53] <Keybuk> -- The kernel bug dies.
[07:53] <iwj> So far I've forgotten to not have X running at the time.
[08:07] <jwest--> Keybuk: tor?
[08:07] <Keybuk> jwendell: ?
[08:07] <jwest--> ?
[08:07] <Keybuk> uh jwest--: ?
[08:08] <jwest--> 127.0.0.1 is tor right
[08:08] <Keybuk> what's tor?
[08:08] <Keybuk> apart from a hill with a granite outcrop on it
[08:08] <elmo> an anonymizing router/proxy thing
[08:08] <jwest--> localhost
[08:08] <jwest--> for anonymioty
[08:08] <Keybuk> 127.0.0.1 is localhost
[08:08] <Keybuk> there ain't no IRC server running on localhost :p
[08:09] <_ion> irc6.oftc.net resolves to 2001:968:1::6666
[08:09] <Keybuk> I have a routed block, but haven't yet had sufficient CFT to do anything about it
[08:10] <Keybuk> ipv6 either :p
[08:10] <pkl_> http://tor.eff.org/
[08:12] <jwest--> to connect to freenode they have an onion server for it something
[08:13] <maswan> Keybuk: yes, they are having serious packeting issues
[08:13] <maswan> now they have a total of one server in rotation though. :)
[08:14] <Keybuk> I don't get the anonymizing proxy thing; I spend sufficient time and money making sure I have real, routeable IP addresses -- hiding that seems pointless
[08:14] <maswan> Keybuk: It depends on if you are doing something that you need to hide.
[08:14] <Treenaks> Keybuk: but you don't live in China
[08:15] <Treenaks> (to give the 'standard' argument)
[08:15] <maswan> Like posting political blogs in iran/china or cracking nsa.gov machines in the US
[08:16] <Keybuk> if the proxy is outside of china, how does that help?
[08:16] <elmo> the whole live in china argument is very valid, it's just a shame tor is mostly visible for all the jerkwads (who don't live in restrictive countries like china or iran) who use it purely to abuse other people
[08:16] <_ion> Or posting political blogs in the US in a few years, by the looks of things ;-)
[08:17] <Treenaks> elmo: every anonymising service will attact unwanted guests
[08:17] <Treenaks> elmo: (and always will)
[08:17] <Keybuk> proxy outside of china => great firewall of china will show the real IPs => doom
[08:17] <Keybuk> proxy inside china => subject to chinese law => can get real IPs by force of law => doom
[08:17] <Keybuk> unless I'm missing something
[08:17] <Treenaks> Keybuk: it's encrypted and doesn't keep logs by default
[08:18] <elmo> Keybuk: it's an onion based system, knowing the IP of the first hop doesn't get you much
[08:18] <Keybuk> encryption isn't useful
[08:18] <Keybuk> as you just set up a man in the middle that proxies that
[08:19] <Treenaks> Keybuk: it is if They are sniffing the link between you and the Tor network
[08:19] <Keybuk> certification of the remote end is useful, assuming that it can obtain the fingerprint of the cert by some means other than across the internet
[08:19] <Keybuk> if over the internet, it's trivial to intercept and change the cert
[08:20] <Keybuk> Treenaks: assuming It is used for illegal purposes, and They care about it, then They will do this kind of thing
[08:20] <Treenaks> Keybuk: you choose your own entrypoint
[08:20] <Keybuk> and where does the list of entrypoints come from?
[08:20] <Treenaks> Keybuk: so all you have to do is know someone 'outside' you trust
[08:21] <Spads> the sad thing about tor is that the location of all tor servers is necessarily published
[08:21] <Keybuk> so you can intercept the list of servers, and change them
[08:21] <Keybuk> we used to do this all the time with file sharing apps :p
[08:21] <Spads> making it less of a whack-a-mole for those who wish to suppress it
[08:22] <Treenaks> Keybuk: ask the EFF, they seem to believe in it
[08:23] <Keybuk> in order for it to be "useful" for people in $STATE, it needs some component that is not transmitted over a medium commonly intercepted by the government of $STATE
[08:23] <Keybuk> otherwise if I were government of $STATE, I'd cheerfully intercept it and log it
[08:23] <Keybuk> and never tell anyone
[08:25] <Keybuk> I would have thought these kinds of things are great for them -- makes it easy to spot the naughty people
[08:26] <Spads> Treenaks: it was Seth Schoen at the EFF who first told me of Tor's limitations
[08:26] <Keybuk> the thing about governments is that they like to get what they want
[08:26] <givre> cjwatson: there is something strange with fuse package. binary of the latest version are available for sparc and powerpc since friday night, but not yet for i386 and amd64. Is this normal ?
[08:26] <Treenaks> Keybuk: the thing about a repressed people is that they always seem to find a way
[08:27] <Keybuk> they don't think anything of turning up at a major ISP and using arguments like "we've got a big truck outside, we're going to confiscate every single piece of equipment in your data centre ... unless you fancy helping us find people downloading kiddie porn off usenet?"
[08:28] <Keybuk> Treenaks: sure, I'm not disputing the will to be non-repressed ... I'm just slightly amused that Tor seems to make it easier for the government to intercept than simply not using it at all
[08:28] <elmo> Keybuk: at which point you say "sure, he's the tor server" and they find nothing useful?
[08:28] <elmo> anyway, this is wildly off topic
[08:28] <Keybuk> elmo: ime, they'd cheerfully replace it with one that looks and acts the same -- but logs everything
[08:29] <Keybuk> of course, me is with the UK government and police, who may be somewhat more with it and evil than the chinese police :p
[08:29] <elmo> Keybuk: and someone from the ISP lets the tor community know that that server is compromised?
[08:30] <Treenaks> Keybuk: You need a government? A popular cable ISP here will start filtering all web traffic soon
[08:30] <Keybuk> elmo: wouldn't happen -- they would have used some very serious leverage to get into the ISP in the first place
[08:30] <Treenaks> Keybuk: officially only the child porn.. but who knows what else#
[08:31] <Keybuk> leaking that wouldn't be a CLM, so much as a FLM
[08:32] <elmo> Keybuk: *shrug* I still think it'd happen - if someone cared enough about tor in the first place to risk the CLM of getting one put in place, I think they'd be find a way to anonymously report  it as compromised
[08:32] <Keybuk> assuming they know at all
[08:34] <cjwatson> FLM?
[08:34] <Keybuk> Freedom Limiting Move
[08:35] <cjwatson> givre: dunno, dinnertime, sorry
[08:35] <givre> cjwatson: that's ok, it's dinner time for me too anyway ;)
[08:36] <Keybuk> (I realise the above shows a high degree of pessimism; however the "Chinese Argument" requires it.  If you have that kind of reason to use something like Tor in the first place, you have to assume that, by the same reason, the thing you're using is the first target for compromise)
[08:38] <LaserJock> do MIRs have to be completely processed by FF or only filed?
[08:44] <LaserJock> Keybuk: do you know about ^^ ?
[08:45] <Keybuk> is the MIR for a feature?
[08:45] <LaserJock> hmmm, hard to say
[08:45] <LaserJock> it's for Edubuntu-on-2-CDs so I guess yes
[08:46] <LaserJock> the build/install structure is complete
[08:46] <LaserJock> so now we just need to populate the 2nd CD
[08:47] <Keybuk> ogra's call then
[08:48] <LaserJock> k
[09:03] <mvo> LaserJock: edubuntu-on2-cds? this should be mostly done, no?
[09:03] <LaserJock> well, yes, according to the spec you, ogra, and cjwatson got all the needed pieces
[09:03] <LaserJock> but now we need to get package to put on the 2nd CD
[09:04] <LaserJock> we're moving the educational apps that we used to ship (gcompris, KDEEdu) there
[09:04] <LaserJock> but we wanted to put more, especially high-school and uni level
[09:05] <LaserJock> so I'm not sure if the actual CD contents count as a part of the feature
[09:05] <mvo> LaserJock: aha, I see. yeah, the infrastructure should be in place. its generic enough for any kind of add-on CD
[09:05] <LaserJock> the spec itself was about the needed infrastructure
[09:06] <LaserJock> uh oh, sounds like a slippery slope ;-)
[09:15] <Kano> hi, i dont get how the source package of the 2.6.20-6 kernel was done
[09:15] <Kano> a) kernel-wedge is a build-dep
[09:16] <Kano> b) it searches for abi/2.6.20-6.11/abiname
[09:16] <Kano> but there is only 2.6.20-5.7
[09:16] <fabbione> Kano: all of this is documented in the wiki
[09:16] <fabbione> if you don't understand look at debian/rules and debian/changelog
[09:16] <Kano> but debuild -S even fails on the original sources...
[09:16] <fabbione> this isn't a support channel
[09:17] <Kano> that seems a packageing error
[09:17] <fabbione> no it's not... 
[09:17] <fabbione> as i said.. read debian/changelog
[09:17] <fabbione> all of it
[09:22] <bddebian> Heya
[09:30] <mjg59_> Hm.
[09:31] <mjg59_> Compiz nearly works fine in feisty, but there's no window decorations.
[09:31] <rtg> zul: You there?
[09:31] <zul> rtg: kind of 
[09:32] <rtg> zul: I just wanted to introduce myself. I'm working with Ben Collins on the 2.6.12 release of the kernel.
[09:32] <rtg> zul: He says he has spoken to you about this?
[09:32] <zul> rtg: ah hello
[09:32] <zul> rtg: yep
[09:32] <rtg> zul: Good, though I'll be  of little use for the next week as I am out until the 14th.
[09:33] <zul> rtg: not a problem im always around
[09:33] <rtg> zul: I'll get in touch upon my return.
[09:33] <zul> sure
[09:34] <mjg59_> Ah, works if I nuke my gconf settings
[09:34] <mjg59_> Wonder whose fault it is...
[09:39] <mjg59_> Except that windows aren't being updated when I type stuff into them
[09:51] <Amaranth> mjg59_: yes, fun bug
[09:51] <Amaranth> mjg59_: should be fixed in git, i'll pull out the patches for it if you want
[09:52] <mjg59_> Amaranth: Winning
[09:52] <mjg59_> To which one?
[09:53] <Amaranth> the updating thing
[09:54] <Amaranth> the commit say something about sync, iirc
[09:56] <mjg59_> Ah, ok
[09:57] <Amaranth> it's two parts
[09:57] <Amaranth> the second part makes unredirect_fullscreen_windows work correctly
[09:58] <Amaranth> oh, there is a patch in there that fixes the dbus plugin too, if you're pulling in patches for the package :)
[10:00] <mjg59_> Amaranth: Heh. Could you do me a huge favour and file a couple of wishlist bugs with them in?
[10:00] <mjg59_> Someone else seems to be taking care of it now, which is great
[10:00] <Amaranth> gandalfn and seb128 are doing it, i guess
[10:01] <Amaranth> i'll file the bugs, sure
[10:01] <Amaranth> actually a full update to current git would only be a good thing, as far as i can tell
[10:01] <mjg59_> Amaranth: Sounds fine by me
[10:14] <LaserJock> any almighty Ubuntu core-dev gods know of a script to check deps for MIRs?
[10:15] <mvo> MIR?
[10:15] <bhale> main inclusion
[10:15] <mvo> thanks
[10:15] <LaserJock> I'm trying to track down all the deps
[10:15] <bhale> you can run each of build-dep and depends through apt-cache show | grep Filename
[10:16] <bhale> and search for !main
[10:16] <bhale> but you knew that
[10:16] <LaserJock> sure, but I was hoping for a faster solution
[10:16] <bhale> few minutes of bash
[10:16] <LaserJock> I've got a lot to go through
[10:16] <bhale> ...bash?
[10:17] <LaserJock> my bash skills aren't good enough to get it to recursively do that and handle |'s , etc.
[10:19] <bhale> apt-cache showsrc beagle | grep Build-Dep | sed -e "s/, /\n/g"
[10:19] <bhale> will give you a seed file
[10:19] <bhale> clean it up with awk
[10:20] <bhale> for i in `cat mydepfile`; do apt-cache show $i | grep Filename | grep -v main; done
[10:20] <bhale> something like that, untested
[10:20] <bhale> rinse and repeat for runtime deps
[10:21] <LaserJock> k, let me play around with that
[10:52] <Burgwork> Amaranth: do you know when 0.3.7 will be released? is it worth waiting for it
[10:52] <Burgwork> ?
[10:58] <sfllaw> Mithrandir: What isolinux.bin do you use for the LiveCD?
[10:58] <Mithrandir> sfllaw: the one in the syslinux package, iirc
[10:58] <sfllaw> I suspected so.
[10:58] <sfllaw> Thanks.
[11:01] <Mithrandir> unsure about the version; I can find that out tomorrow if you need it.
[11:10] <Nafallo> hi jono! :-)
[11:10] <jono> hey
[11:10] <jono> :)
[11:12] <gnomefreak> jono: i havent had a chance to check mail but tomorrow i will check and respond 
[11:12] <jono> gnomefreak: no worries :)
[11:26] <LaserJock> jono! just the man I've been looking for
[11:26] <jono> LaserJock: :)
[11:27] <LaserJock> jono: you wouldn't mind if jokosher was in Main would you?
[11:27] <jono> in Ubuntu Main? serious?
[11:27] <LaserJock> I'm trying to add to Edubuntu
[11:27] <jono> ahhh cool
[11:27] <jono> I think it should be fine for 0.9 (our next release)
[11:28] <jono> but not for 0.2, too buggy
[11:28] <LaserJock> jono: ok fine, be that way then ;p
[11:28] <jono> LaserJock: :)
[11:29] <jono> yeah we have nailed *loads* of bugs for the next release
[11:29] <LaserJock> that's one less MIR I have to file
[11:29] <jono> :)
[11:29] <jono> wow, Jokosher in main :)
[11:29] <jono> is ubuntu and edubuntu main the same?
[11:29] <LaserJock> yep
[11:29] <jono> wow cool
[11:29] <LaserJock> well, we'd like to have more music apps
[11:30] <jono> is this confirmed that it will go into main?
[11:30] <jono> can we announce this?
[11:30] <LaserJock> hang on, hang on
[11:30] <LaserJock> you said 0.2 was too buggy
[11:30] <jono> yeah, I mean 0.9
[11:30] <jono> 0.9 is released in March
[11:30] <LaserJock> hmm
[11:31] <Keybuk> jono: that's an interesting way of doing releases
[11:31] <jono> :)
[11:31] <Keybuk> personally I tend to say that there are *loads* of bugs for the next release
[11:31] <Keybuk> omitting the "nailed"
[11:31] <jono> heh
[11:32] <jono> I know Jokosher will enter main at some point, and I am happy if it is not with 0.9 if needed
[11:32] <jono> the main focus right now is bug fixing
[11:32] <sistpoty> LaserJock: what do you want to include into main?
[11:32] <sistpoty> (just curious)
[11:32] <LaserJock> nothing, nothing
[11:32] <LaserJock> nothing to see here ;-)
[11:32] <sistpoty> hehe
[11:32] <LaserJock> sistpoty: working on a 2nd CD for Edubuntu
[11:33] <sistpoty> LaserJock: oh, nice
[11:34] <LaserJock> I'm trying to narrow down what I can get in
[11:34] <LaserJock> the deps are killing me ;-)
[11:58] <jwest--> if i have the 6.06 version of ubuntu, can i upgrade to 6.10 with ease? (including all other software?)
[12:01] <sistpoty> jwest--: you can upgrade all software installed from official repositories, but this question is rather suited for #ubuntu than for this channel
[12:03] <cbx33> LaserJock, but i bet the deps are easier to find now ;)
[12:03] <cbx33> hehehe
[12:03] <cbx33> mwuhahah
[12:03] <jwest--> gotcha