[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 <IP_ADDRESS>
[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--> <IP_ADDRESS> 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> <IP_ADDRESS> 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


[08:55] <JonathanD> Morning.
[08:57] <rmg51> Morning JonathanD
[09:03] <JonathanD> Morning.
[12:23] <teddy-dbear> Morning peoples, critters and everything else
[12:26] <lazyPower> o/
[12:44] <teddy-dbear> \o


[00:01] <robert_ancell> brb
[00:13] <robert_ancell> RAOF, MM8 seems to run better for some simple test cases with mir_demo_server
[00:15] <robert_ancell> still falls apart if I plug a monitor while running unity or from the greeter though
[00:39] <RAOF> Ah, good. Valgrind sees all!
[00:40] <robert_ancell> :)
[00:40] <RAOF> Mir doesn't handle monitor unplug, apparently.
[00:41] <RAOF> Unplugging my HDMI monitor and then querying the display config crashes u-s-c
[00:42] <robert_ancell> ah
[00:56]  * robert_ancell -> lunch
[02:02] <robert_ancell> RAOF, any thoughts on that unplug issue? Are you working towards a MM9?
[02:28] <robert_ancell> RAOF, Is there anything I can do to help here - multi-monitor isn't working on my system at all and I don't know of any specific bugs I can fix. If there's no new packages coming I
[02:28] <robert_ancell> 'm not doing anything useful here
[02:31] <RAOF> robert_ancell: I don't think there's anything to test that can't be more easily done by me locally at the moment.
[02:31] <robert_ancell> ok, any idea when something will be testable?
[02:32] <RAOF> I don't think I can give a useful estimate.
[02:32] <RAOF> Should be soonish, but that depends on my understanding of the current problems.
[02:45] <kgunn> what' s up fella's i'm back
[02:45] <kgunn> anything to test ?
[02:47] <robert_ancell> kgunn, nothing at the moment
[02:48]  * RAOF tries with the next set of debug spew.
[03:10] <RAOF> That's *better*; now I merely need to find out where I'm setting the stride incorrectly.
[03:15] <RAOF> Ah!
[03:15] <RAOF> And that's where the pitch is wrong.
[03:20] <duflu> Erm, both testing PPAs populated? Which one should I use?
[03:20] <RAOF> qa-testing2
[03:21] <robert_ancell> duflu, qa-testing is MM+bypass, qa-testing2 is just MM
[03:22] <duflu> Okee
[03:25] <kgunn> duflu: ....just to add, qa-testing2 is a non-starter atm
[03:25] <duflu> Argh.
[03:25]  * duflu cancels upgrade
[03:27] <RAOF> But might soon start & win!
[03:27] <kgunn> RAOF: curious...why is qa-testing xorg mm8 & qa-testing2 mm7 ?
[03:28] <RAOF> kgunn: Because I uploaded mm8 to the wrong PPA
[03:28] <kgunn> :))
[03:28] <duflu> This could cause some pinning confusion...
[03:28] <kgunn> i love you guys....make me feel normal :)
[03:29] <kgunn> duflu: how so ?
[03:30] <duflu> kgunn: My system was pinned for qa-testing. So switching to qa-testing2 might not get all the packages from it
[03:30] <kgunn> duflu: right...you'd have to purge first
[03:30] <robert_ancell> yep, always do a purge
[03:46] <duflu> Hmm, the pointer lag that I previously attributed to software cursors is mostly gone when using a PPA with bypass enabled
[03:46] <kgunn> robert_ancell: you updated qt-testing2 from archive basically ?...thanks for that
[03:46] <duflu> ... mostly
[03:46] <robert_ancell> kgunn, no, just rebasing on archive when it changes
[03:47] <kgunn> robert_ancell: yeah...what i meant...thanks for that
[03:47] <robert_ancell> np
[03:47] <kgunn> i was semi worrying about that
[03:48] <kgunn> btw...did you see olli's ping earlier about u-s-c crashing on him ?
[03:48] <RAOF> When he removes a monitor?
[03:48] <kgunn> no it was just random use of xmir (i think)
[03:48] <kgunn> but then apport said something like...can't report because
[03:49] <kgunn> version of u-s-c changed ?
[03:49] <robert_ancell> kgunn, was he using a PPA?
 kgunn, tvoss|dinner_and_benchmarking seeing something weird
 while working on my kernel issue, I got an apport report of u-s-c crashing
 which in iteself sucks but is no surprise
 however I have #seat=unity
 and when proceeding to file the bug through apport, it complains that the bug can't be filed since u-s-c has changed since the crash occured
[03:50] <robert_ancell> might be an old crash report
[03:50] <RAOF> Ok. Lets see if mm9 + a new intel driver gets us all the way to spanned displays.
[03:53] <duflu> Is anyone testing non-intel? I can't with saucy :(
[03:53] <RAOF> It almost certainly won't work with !intel at the moment; I'll get to that after intel works.
[03:55] <duflu> I can test radeon and nouveau on raring tho... Need to build everything by hand
[03:58] <RAOF> Hm. Might be lunch time.
[04:03] <duflu> Hm. Might be breakfast time
[04:04] <robert_ancell> Hm. Might be dinner time
[04:06] <olli> Hm. Might be bed time
[04:07] <olli> is there anything worth testing?
[04:12] <tvoss> good morning :)
[04:12] <olli> kgunn, I was bisecting kernels and it might have been just a weird side effect
[04:13] <olli>  tvoss says: Hm. Might be breakfast time
[04:13]  * duflu concurs.
[04:13] <duflu> Brunch even
[04:13] <tvoss> olli, indeed :)
[04:13] <olli> well, it's beer o'clock somewhere
[04:14] <kgunn> olli: i thot you were in some remote forest or canyon or something
[04:15] <olli> kgunn, I will be in 12h
[04:16] <olli> right now though I am having ice cream and redwine
[04:16] <olli> waiting for the miracle in #ubuntu-mir street
[04:17] <olli> duflu, anything worth giving a shot?
[04:17] <kgunn> i think waiting on a mir-acle makes you gain weight...waffling between beer & choc chip cookies
[04:18] <olli> hah, kgunn just inspired me for the blog post once everything has landed
[04:18] <olli> +title
[04:41]  * tvoss hands coffee to RAOF :)
[04:46] <duflu> olli: I know as much as you. RAOF and robert_ancell are in control of PPAs
[04:47] <robert_ancell> olli, there's no changes worth testing. RAOF is working on X changes and the PPAs are ready for that when available
[04:48] <RAOF> Xserver MM9 should be in qa-testing2, but that's not going to work properly until xf86-video-intel mm5
[04:49] <RAOF> Which, assuming I've fixed the build properly this time, should be uploaded soon.
[04:50]  * tvoss hugs RAOF
[04:50] <olli> alrighty, will keep my fingers crossed
[04:50] <olli> (start getting calluses though)
[05:01] <RAOF> Ok. Let's see if this works?
[05:02] <kgunn> RAOF: amd64 failed
[05:03] <tvoss> kgunn, in qa-testing2?
[05:04] <kgunn> tvoss: my bad
[05:04] <kgunn> too many tabs
[05:05] <tvoss> RAOF, did you upload mm5, yet?
[05:12] <olli> RAOF, qa-testing2?
[05:12] <RAOF> Yeah, that's where it'll end up
[05:12] <RAOF> Just testing it locally.
[05:12] <tvoss> duflu, did you see https://code.launchpad.net/~robertcarr/mir/weak-session-for-session-mediator/+merge/181924
[05:12] <tvoss> ?
[05:12] <olli> RAOF, ok
[05:13] <RAOF> Just worked out why it tends to turn my HDMI output off, too, which once fixed will make it easier to test :)
[05:13] <duflu> tvoss: I intentionally don't look at code reviews until I have a longer stretch of hours to fuss over them. So... soon
[05:13] <tvoss> duflu, ack :)
[05:25] <RAOF> Win!
[05:28] <duflu> Where?
[05:28] <RAOF> qa-testing2, xorg-server MM10, xf86-video-intel MM5
[05:28] <duflu> Righto
[05:29] <RAOF> You'll need to wait for them to build, obviously.
[05:29] <RAOF> Well, not obviously. But you will need to wait for them to build :)
[05:29] <duflu> Now obvious
[05:30] <kgunn> in the words of tom petty "the waiting is the hardest part"
[05:31]  * kgunn subscribes to the theory there's a song lyric for every situation
[05:31] <duflu> RAOF: You silently switched from qa-testing to qa-testing2 ... is that because bypass is still suspicious? or you want to keep it simple testing one thing at a time?
[05:31] <RAOF> Oh, because bypass is still suspicious.
[05:31] <duflu> kgunn: Generally true.
[05:32] <duflu> RAOF: Suspected of ... (something I can test for?)
[05:32] <RAOF> Suspected of failing to send buffers appropriately.
[05:32] <RAOF> Now that MM works I can dig deeper there.
[05:32] <duflu> RAOF: How so?
[05:33] <robert_ancell> I have to go, I'll try and hop on later tonight and check in
[05:33] <kgunn> or duflu could dig there...while you dig on ati :)
[05:33] <kgunn> robert_ancell: o/
[05:33] <RAOF> duflu: Because, when XMir is driving multiple displays, unity-system-compositor only shows the first frame since it was VT switched to.
[05:33] <RAOF> robert_ancell: Have fun wherever :)
[05:33] <duflu> kgunn: Due to multiple kernel bugs, I cannot test bypass on radeon. Only alf could
[05:34] <kgunn> duflu: even after the 3.11 arrival ?
[05:35] <duflu> kgunn: Because of 3.11. Booting 3.11 on raring broke too much, and booting saucy on my radeon machine fails to boot at all for unknown reasons
[05:36] <tvoss> RAOF, did you upload mm5 for the intel driver, yet?
[05:36] <duflu> kgunn: So I was going to call that a blocker till alf tested it for me
[05:37] <kgunn> yeah
[05:38] <duflu> RAOF: I got exceptions from USC yesterday suggesting bypass might fail due to outputs not having CRTCs assigned at times. Is that meant to be possible?
[05:38] <duflu> It's not possible to reproduce with plain Mir. Only saw it with XMir + MM setup
[05:39] <duflu> Which reminds me. I need to beef up our exceptions if it happens again
[05:43] <RAOF> tvoss: Yeah, I've uploaded MM5 of -intel
[05:44] <tvoss> RAOF, in qa-testing2?
[05:44] <RAOF> ...but I don't see it in the PPA, so I'll check my email.
[05:44] <tvoss> yup :)
[05:44] <RAOF> Hah! Which says ‘you sent it to qa-testing, dufus’
[05:45] <kgunn> tvoss: so i was playing with lttng....trying to follow the http://unity.ubuntu.com/mir/component_reports.html
[05:45] <kgunn> so when i cd into /tmp/ i don't mirsession
[05:46] <RAOF> Why is everything terrible?
[05:46] <kgunn> or rather...if i follow those instructions...what is substituted for <sub dir> in ....babeltrace /tmp/mirsession/<trace-subdir>
[05:46]  * RAOF cancels the amd64 xserver build that hung in the xvfb-run test
[05:49] <tvoss> RAOF, kgunn moving over to the new house with a second monitor with me :) back in ~20
[05:58] <RAOF> Hm. Damage is slightly off.
[05:58] <RAOF> But mostly ok.
[06:01] <RAOF> i386 build, take 2, is done.
[06:05] <RAOF> amd64 build is nearly done.
[06:05] <RAOF> Happy testing, gentlemen.
[06:06] <RAOF> I'm off to get groceries.
[06:11] <tvoss> back again
[06:12] <tvoss> RAOF, dist-upgrading
[06:13] <tvoss> kgunn, can you check your lttng version? please see the remark at the bottom of the page
[06:15] <kgunn> tvoss: hmm, says 2.1.1...
[06:17] <kgunn> but thanks for that...that pointer to the 2.2+ might be an issue on my android effort
[06:18] <olli> kgunn, which PPA did RAOF suggest
[06:18] <kgunn> https://launchpad.net/~mir-team/+archive/qa-testing2/+packages
[06:18] <kgunn> olli: ^
[06:19] <kgunn> olli: don't forget to purge first (if you had been using qa-testing....not qa-testing2)
[06:19] <kgunn> and of course updaet your pinning pref file
[06:20] <olli> kgunn, on it
[06:21] <tvoss> kgunn, did you try the ppa, yet?
[06:21] <kgunn> tvoss: yep...just incessant punting to the greeter
[06:21] <kgunn> i wanna double check all my packages first thos
[06:21] <kgunn> just in case
[06:25]  * olli finishes the install of qa-testing2
[06:25] <olli> what do we expect to work?
[06:25] <kgunn> tvoss: you ?
[06:25] <kgunn> olli: i would just try vga hotplug
[06:27] <kgunn> all my packages match :(
[06:27] <olli> kgunn, should I refrain from testing?
[06:27] <olli> or are you talking lttng?
[06:27] <kgunn> second data point can't hurt
[06:28] <kgunn> unfortunately....i'm talkin' bout qa-testing2
[06:28] <olli> brb
[06:29] <kgunn> hmmmm....hdmi worked....after 1 punting to greeter
[06:30] <kgunn> all the sizes even look proper (mirrored)
[06:31] <kgunn> ooo, it's pissed...did not like me unchecking mirrored
[06:31] <kgunn> just hung
[06:33] <olli> arg
[06:33] <olli> can't find the vga cable
[06:33] <olli> am on dvi via dock
[06:33] <olli> so far it's just mirrored
[06:33] <olli> doesn't detect 2nd display
[06:36] <duflu> Are we meant to having working hotplugging yet? Even when I had two monitors working this morning, I had to reboot before xrandr detected the second one
[06:36]  * tvoss reboots
[06:36] <kgunn> hotplugging works on standalone X
[06:36] <kgunn> and at least that was the goal...to have parity
[06:36] <duflu> kgunn: Yeah. But I mean have we implemented it yet?
[06:37]  * duflu isn't sure
[06:37] <kgunn> at least mir mm (demo clients) was ok with this (i think...)
[06:37]  * kgunn now doubts self
[06:39] <tvoss_> RAOF, are we supposed to have hotplugging working?
[06:39] <kgunn> ok...so hotplug on vga (1 test) didn't work, hdmi hotplug punted me to greeter but then on login worked...
[06:39] <kgunn> from boot both vga & hdmi work in mirror mode
[06:40] <kgunn> ooo, take that back hdmi worked in mirror mode, vga does not
[06:41] <kgunn> hdmi also worked when in mirror mode...deselect mirror + built in display off.....it went to 2nd monitor only
[06:41] <kgunn> (which is a lot like hotplug)
[06:41] <kgunn> and hdmi was ok, with switching mirror mode on (from the state of built in display off)
[06:41] <kgunn> ok....that does it for me...i'm totally crashing (i feel asleep mid reboot)
[06:42] <kgunn> vga no good...hdmi seems pretty ok (mirror & going to second display only)
[06:42] <kgunn> hotplug wonky on hdmi, no good on vga
[06:42] <duflu> RAOF: Looks like XMir is honouring the desktop's alpha channel. I can "see through" the unity launcher when dragged
[06:44] <olli> well, that didn't work so well
[06:45] <olli> I am off for today
[06:45] <olli> good luck gentlemen
[06:45] <olli> appreciate your work on the weekend
[06:45] <duflu> Alright.  But no logs show a crash... ?
[06:46] <tvoss_> duflu, RAOF hotplug with vga not working for me
[06:47] <tvoss_> I'm afk for some 30 minutes now, with you later
[06:47] <RAOF> Hm.
[06:55] <RAOF> duflu: What do you mean by "see through"?
[06:55] <RAOF> Well, HDMI hotplug worksish for me, although X doesn't seem to notice when its connected.
[06:55] <duflu> RAOF: Drag the launcher down and you can see a stationary one underneath. Perhaps an old frame or intended for a different screen
[06:56] <duflu> It seems Compiz/Unity has some pixels with alpha < 1.0, which never used to matter but now they're translucent
[06:57] <RAOF> They *shouldn't* be translucent. If they are it's a Mir bug, as Xmir chooses an xrgb pixel format.
[07:00] <duflu> Hmm, well that's the least severe issue right now
[07:01] <RAOF> Resolution changing seems to be working pretty well here.
[07:02] <RAOF> Turning the hdmi off, turning it on, changing the mode, moving it, all work.
[07:02]  * duflu restarts with a more sane single output setup
[07:02] <RAOF> Although I *am* ussing the locally built packages
[07:02]  * RAOF upgrades from the PPA
[07:04] <duflu> Hmm, I don't get any resolution choices for LVDS. Only DisplayPort
[07:05] <RAOF> Yup.
[07:05] <RAOF> We only pass on the modes the monitor supports.
[07:05] <RAOF> Internal panels almost uniformly lack scalers, so they only support their native mode.
[07:08] <duflu> Really? Every laptop I've tried had reasonable scaling for low-res modes
[07:11] <RAOF> No, it's had faked scaling for low-res modes :)
[07:11] <RAOF> Or, rather, the scaling has been done on the GPU rather than by the panel.
[07:17] <duflu> RAOF: Yeah. For many people trying to run Unity on full-HD laptops, that feature is rather important
[07:48] <tvoss_> back
[07:48] <tvoss_> RAOF, duflu anything you want me to test?
[07:49] <duflu> tvoss_: Can you confirm any of my bugs? https://bugs.launchpad.net/xmir/+bugs?field.tag=multimonitor
[07:49] <tvoss_> duflu, walking through them
[08:01] <duflu> It's rather cool that you can still start native Mir clients inside unity-system-compositor and XMir just (correctly) gets out the way
[08:09] <duflu> Oh wow, my translucent desktops are responding separately. It really is two launchers
[08:14] <RAOF> duflu: Can you modeset/change layouts with the xrandr tool?
[08:14] <tvoss_> duflu, you might want to give https://code.launchpad.net/~thomas-voss/glmark2/mir-no-deprecated-functions a spin
[08:15] <duflu> RAOF: I was just about to. Got side-tracked taking awesome blurry-cam video
[08:16] <RAOF> :)
[08:17] <duflu> RAOF: I suspect the blending issue is just "normal" for Compiz/Unity when you have two different displaybuffers physically overlapping
[08:17] <RAOF> Likely, yes.
[08:18] <duflu> Hence, it's "pre-blended" before it hits Mir
[08:20] <duflu> RAOF: Yes, xrandr layout changes work.
[08:20] <duflu> Only crashes with Control Center
[08:21] <RAOF> Yeah. I suspect that it's actually broken with xrandr too, but we mostly don't hit it, whereas the little labels gnome-control-centre has makes it hit.
[08:23] <duflu> RAOF: Kinda. I tried some --off and then on again. And eventually broke it with xrandr
[08:24] <duflu> RAOF: Do the labels cause immediate damage or something strange?
[08:26] <duflu> tvoss_: Cool. But I've never built glmark2 and might not get to it today
[08:26] <tvoss_> duflu, I will produce some numbers over the weekend for intel and amd
[08:27] <duflu> tvoss_: Excellent. Can you see if a single build can support X and native Mir? Because glmark2 does. Then we can compare them directly. Even both running on the same USC instance :)
[08:27] <tvoss_> duflu, yup, you can build multiple flavors
[08:27] <duflu> tvoss_: I mean build once, run anywhere
[08:27] <tvoss_> duflu, yup, that's what I mean, too :)
[08:28] <duflu> tvoss: Nice. You could even run an X glmark2 and Mir glmark2 simultaneously on USC :)
[08:28] <tvoss_> duflu, exactly ;)
[08:28] <tvoss_> duflu, makes for nice blurry cam videos, too
[08:28] <duflu> Though they would fight for GPU
[08:29] <tvoss_> duflu, right, not so interesting for producing numbers
[08:30] <tvoss_> duflu, walked through the multi-monitor bugs and tagged them with affects me
[08:30] <duflu> tvoss_, New --> Confirmed ?
[08:31] <tvoss_> duflu, nope, only affects me. Can set to confirmed
[08:31] <duflu> Please
[08:32] <tvoss_> duflu, I will confirm against xmir
[08:33] <tvoss_> duflu, cannot check on displayport, though
[08:33] <duflu> tvoss_: In theory the connector doesn't matter. Mir has no connector-specific code
[08:34] <duflu> Anyway, this is Intel, which means DisplayPort + DVI adapter = "HDMI" :)
[08:34] <duflu> That's an old bug
[08:40] <tvoss_> duflu, ack
[08:44]  * duflu wonders why we don't have an xrandr equivalent for Mir yet
[08:45] <duflu> We have a demo client which shows it's possible. But that's just a toy
[08:59] <robert_ancell> RAOF, what's the state of MM10?
[09:03] <duflu> robert_ancell: Unchanged for a while. Bugs are against mir/xmir projects with "multimonitor" tag
[09:03] <robert_ancell> duflu, is MM10 considered mostly working?
[09:04] <duflu> robert_ancell: Hard to judge what mostly would be. I think maybe 30%
[09:04] <robert_ancell> ok
[09:06] <duflu> robert_ancell: The strangest one is X crashes if you use Control Center to change settings. xrandr works much better, but not 100%
[09:23] <duflu> Going
[09:24] <duflu> Going
[09:26] <duflu> Gone
[10:12] <tvoss_> RAOF, ping
[10:18] <RAOF> tvoss_: Pong
[10:44] <tvoss_> olli, ping
[13:12] <olli> tvoss|test, pong
[14:36] <kgunn> RAOF: vga connected at boot, just checked the xorg log its shows EE backtrace but nothing under it (like crashed before write out)
[14:36] <kgunn> right at "updated configuration" where it has output5/12 connected..then post-modeset config
[14:45] <kgunn> https://pastebin.canonical.com/96336/
[14:46] <kgunn> to be clear that was pre-boot vga connected....never got past greeter (greeter cycling)
[15:06] <kgunn> ok...then i retested vga hotplug and got this https://pastebin.canonical.com/96336/
[15:07] <kgunn> seems different...like it almost reconfigured, but then went thru a bunch of keyboard/trackpad setup then bailed
[15:11] <kgunn> huh...hotplug on hdmi worked (with adjusted res) but upon second connect/disconnect....its not alter the second screen res properly to fit it
[15:12] <kgunn> but hdmi hotplug seems robust enough to have repeated connect/disconnect
[15:14] <kgunn> oh...and on hdmi hotplug...let it sit...not its frozen, can't even vtswitch
[15:25] <kgunn> corraction vga hotplug > https://pastebin.canonical.com/96337/
[15:25] <kgunn> seems hdmi hotplug will eventually fail in the same way
[17:37] <rigved> hi everyone.
[17:38] <rigved> i am running xmir on my 13.10 laptop.
[17:39] <rigved> everytime i try to open the dash or click on the shutdown menu item, my system freezes for a 2-3 minutes and then comes back to normal.
[17:39] <rigved> everything else seems to be running fine.
[17:40] <rigved> can someone help me diagnose the problem?
[23:06] <robert_ancell> RAOF, morning
[23:23] <robert_ancell> kgunn, around?
[23:42] <kgunn> robert_ancell: hey kinda
[23:43] <kgunn> robert_ancell: i was actually thinking about going to bed early and getting up around 4....since images don't usually show up until 1 -ish
[23:43] <kgunn> my time...
[23:43] <robert_ancell> kgunn, I get slight improvements with MM10, looking at logs I don't think there's been any improvement until then
[23:43] <robert_ancell> right
[23:44] <robert_ancell> Chris said he'd be here in ~1:15, which means an image in ~2hrs perhaps?
[23:44] <kgunn> robert_ancell: what are your results for hot plug?
[23:44] <robert_ancell> kgunn, I got it spanning on the greeter once, but it seems a bit random
[23:44] <kgunn> robert_ancell: right...but you can't ever get past greeter?
[23:44] <robert_ancell> most of the time it mirrors and u-g/XMir restarts quite a bit
[23:44] <robert_ancell> I can without the external monitor
[23:45] <robert_ancell> otherwise it's a bit random, sometimes it works, sometimes it doesn't
[23:45] <robert_ancell> I've only seen mirroring inside Unity
[23:46] <kgunn> robert_ancell: right...i roughly see the same...
[23:46] <kgunn> altho hdmi more stable than vga....
[23:46] <kgunn> which i never would've bet on
[23:46] <robert_ancell> yeah!
[23:46] <robert_ancell> I'm just testing VGA here


[15:48] <xu-irc97w> hi, I have this issue with the wifi driver: https://askubuntu.com/questions/1388628/xubuntu-usb-wifi-driver-lost-with-recent-update?noredirect=1#comment2398458_1388628  .   Do you have a work-around or alternative to get me going again?
[15:50] <xu-contribute23w> Hey, I'm thinking of trying 22.04, does it use wayland?
[15:55] <tomreyn> i *assume* xfce does not fully support wayland, yet
[15:55] <tomreyn> generally, there is #ubuntu-next for 22.04 questions
[16:02] <tomreyn> xu-irc97w: are you able to bring this system online by other means temporarily? if so, install the latest kernel version and try running dkms again. if it still errors out, post the log referenced in the error message
[17:19] <xu-help58w> Hey. Was using xubuntu just fine for a month or so now, when suddenly I have this problem, where my ethernet just won't connect. Maybe anyone else had this problem?
[17:23] <diogenes_> xu-help58w: have you tried rebooting?
[17:24] <xu-help58w> I have. Multiple times. I have tried connecting to the ethernet connection on multiple days. I checked if maybe it was the wire, but on my windows machine it works. Also, the wifi works, it's only the ethernet.
[17:26] <diogenes_> xu-help58w: you can try booting the oldest kernel you can find in the list and see if that makes any difference.
[17:27] <xu-help58w> what list? sorry, kinda new to linux and stuff
[17:34] <xu-help58w> okay, I found the list you were probably talking about, but it is still not fixed.
[17:35] <xu-help58w> although now when I boot I get a message saying "System program problem detected"
[17:38] <rfm> xu-help58w, when you say "on my windows machine ]the wire] works, do you mean you took the ethernet cable from your xubuntu machine and plugged it into your separate Windows machine?
[17:38] <rfm> xu-help58w, or is the windows machine a dual-boot with xubuntu on the same box?
[17:39] <xu-help58w> yes. I have my switch here, kept it plugged into the switch, unplugged from my xubuntu machine, plugged into my windows machine
[17:40] <diogenes_> xu-help58w: in a terminal run the following: ls /etc/apt/sources.list.d
[17:40] <diogenes_> What result do you get?
[17:41] <xu-help58w> well, a bunch of apps I have installed. are you looking for something in specific, or do you want me to type out every single result I get? I am currently not on my xubuntu machine.
[17:42] <rfm> xu-help58w, ok. so the problem could be in the ethernet adapter in your xubuntu machine.   It seems really unlikely to me that it's a software/driver problem, since the linux ethernet drivers are pretty stable.
[17:42] <xu-help58w> let me just see. I have windows installed on my xubuntu machine as well. Might just check that out.
[17:44] <rfm> xu-help58w, the first thing I'd do is  unplug the ethernet cable and look into the jack to see if one of the little wires has gotten bent
[17:45] <xu-help58w> jesus, one pin is just bent straight down. didn't expect that, since the device is only around 6 months old, so you'd assume the jack holds up, especially if it only had a wire plugged into it like 6 times
[17:45] <xu-help58w> well, that should be the problem source, hopefully I can get this fixed. thank you very much for the help.
[22:52] <xu-irc97w> Thanks TomReyn for the suggestion to re-install. Did that got connect, updated everything and so far, good. Except, it failed to fetch archives - is that a concern or just retry tomorrow?
[23:45] <guiverc> xu-irc97w, you didn't say what mirror (if any) you're using... If using a country mirror (esp. if it's 3rd party provided/managed, even if official) I'd consider changing mirrors   https://launchpad.net/ubuntu/+archivemirrors
[23:50] <xu-irc97w> Thanks I used qbittorrent and link posted on Xubuntu


[08:53] <bloodearnest> ing
[14:25] <gbaman> hey guys, got a quick question, i have a rather complicated edubuntu install for testing with and need a little help :)
[14:25] <gbaman> anyone around?
[14:38] <gbaman> I am trying to install ubuntu on an external HDD which already has data on it on 2 seperate partitions then i have my 3rd edubuntu partition. I have a 20gb partiton for edubuntu testing allocated and just need to install it now, but what is the best way to do this, taking into account the bootloader as that seems to be causing problems
[14:43] <alkisg> gbaman: what other OSes do you have?
[14:44] <gbaman> no other OSs on the HDD, just data
[14:45] <gbaman> an HFS+ partiton and a fat32 partition
[14:45] <alkisg> So what is complicated about it?
[14:45] <alkisg> HFS? mac os?
[14:45] <gbaman> when i tried to install it it complained grub counldnt be installed
[14:45] <alkisg> Are you booted into the edubuntu live cd?
[14:46] <gbaman> yes
[14:46] <gbaman> well, pendrive
[14:46] <gbaman> but yes
[14:46] <alkisg> What's the output of sudo sfdisk -d ?
[14:46] <alkisg> !pastebinit
[14:46] <alkisg> !pastebin
[14:46] <alkisg> That one ^ :)
[14:46] <alkisg> I.e. don't paste the output here if it's many lines... e.g. above 5
[14:47] <gbaman> that would involve me rebooting into the actual try version, one sec
[14:49] <gbaman> sfdisk -d did nothing
[14:50] <alkisg> There's a sudo there too
[14:50] <gbaman> there we go
[14:50] <gbaman> one sec
[14:53] <gbaman-edubuntu> http://paste.ubuntu.com/1454880/
[14:53] <gbaman> the drive i am trying to install it onto is sdc
[14:54] <gbaman> well, sdc3
[14:54] <alkisg> Ah, it's GPT, not normal MBR
[14:54] <alkisg> Try another tool: sudo fdisk -l
[14:54] <alkisg> (btw how come you're using GPT? for mac?)
[14:55] <gbaman-edubuntu> http://paste.ubuntu.com/1454884/
[14:55] <gbaman> yes
[14:55] <gbaman> my main machine is a mac
[14:55] <gbaman> but also have a windows machine
[14:56] <gbaman> which is why there is a fat32 partition on there
[14:57] <alkisg> gbaman: fdisk doesn't support GPT disks either... so you'd need to install "parted" to check the disk layout
[14:57] <alkisg> I'm guessing that the "embedding area" is too small for grub to be installed
[14:58] <alkisg> Try asking in #grub
[14:58] <gbaman-edubuntu> ..
[14:58] <gbaman-edubuntu> ok
[14:58]  * alkisg has never even seen a disk with a GPT table layout :-/
[14:58] <gbaman> parted installed :)
[14:59] <alkisg> sudo parted -l
[15:00] <alkisg> https://wiki.archlinux.org/index.php/GRUB#GPT_specific_instructions
[15:00] <alkisg> It sounds a bit complicated, so #grub would be your friend there
[15:00] <alkisg> Or, you could just use an MBR-based disk
[15:00] <gbaman-edubuntu> http://paste.ubuntu.com/1454894/
[15:03] <alkisg> Check the wiki page above, it has instructions on what to do for grub-install to succeed