[06:34] <dileks> this might be a noob question: report-bug is not the appropriate tool, ubuntu-bug grumps about app PID
[06:41] <dileks> sudo ubuntu-bug $(pidof NetworkManager)
[06:44] <RAOF> dileks: Works here.
[06:44] <dileks> damn, I need a launchpad account, too
[06:44] <dileks> RAOF: I am on 3.4-rc4
[06:44] <dileks> https://bugzilla.redhat.com/show_bug.cgi?id=785772
[06:44] <RAOF> Likewise :)
[06:45] <ubot2> bugzilla.redhat.com bug 785772 in NetworkManager "Logs filled by ICMPv6 RA: ndisc_router_discovery() failed to add default route" [Unspecified,On_qa]
[06:46] <dileks> damn
[06:47] <dileks> how they want that both captcha words
[06:47] <dileks> with space, no space
[06:47] <RAOF> No idea; I generally space, though.
[06:56] <dileks> w/o space
[06:56] <dileks> lauchpad #988183
[06:57] <dileks> my first BR for ubuntu-bts
[07:00] <dileks> OMG, Sedat-dilek (sedat-dilek) <--- can I change that?
[07:02] <RAOF> dileks: I think so, yes.  Change your LP name.
[07:02] <dileks> hmm, just looking for sth like personal settings. more coffee.
[07:02] <RAOF> (You can't easily change your ID, but you can change the name that gets displayed)
[07:03] <RAOF> launchpad.net/~ will bring up your home page; the “change details” link from there will let you do stuff.
[07:04] <dileks> yupp, just did that
[07:06] <dileks> but I would like to change my "OpenID login" to my nickname, as this is well known on other platforms
[07:07] <dileks> Member since: 2010-09-14 <--- didnt know that (registered today) :-)
[07:11] <dileks> Can I change my OpenID id?
[07:11] <dileks> Yes. You can change your Launchpad id and that will change your identity URL. That could mean that sites you've already logged into using your previous OpenID URL may consider you a new user. 
[07:11] <dileks> NO, I cant
[07:11] <dileks> https://help.launchpad.net/YourAccount/OpenID?action=show&redirect=OpenID#rename-account
[07:15] <dileks> OK, clicked save again
[07:30]  * smb grumbles about the terminator taking over...
[07:54] <amitk> smb: Arnold has taken over what?
[07:54] <smb> amitk, my ctrl-alt-t
[07:56] <smb> I mean I have installed the terminator package, but until this morning the default terminal window was the gnome one
[07:56] <amitk> :)
[07:57] <amitk> I was worried Arnold had taken over handling of the world economy...
[07:57] <smb> Cannot be worse than California... :-P
[08:37] <dileks> RAOF: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/988183/comments/2
[08:37] <ubot2> Launchpad bug 988183 in network-manager "Logs full with "ICMPv6 RA: ndisc_router_discovery() failed to add default route"" [Undecided,New]
[08:42] <RAOF> dileks: Cool.
[08:42] <dileks> rebuilding first ubuntu package
[08:48] <dileks> RAOF: is there a defined length (of chars) for a patch in ubuntu?
[08:48] <dileks> git_core_dont_fight_with_the_kernel_over_the_default_IPv6_route_77de91e5.patch
[08:48] <dileks> is a bit long
[08:55] <RAOF> dileks: No, you can use whatever length you want.  That does seem a bit long, though :)
[08:55] <dileks> yeah, IIRC in debian/changelog
[08:56] <dileks> now, you can propose a patch-name before building :-)
[08:56] <ohsix> that seems a big long even for shortlog :]
[08:58] <dileks> git_core_fix_default_IPv6_rout_handling_77de91e5.patch ?
[08:59] <ohsix> leave_ipv6_route_alone :]
[08:59] <RAOF> dont_fight_kernel_for_default_ipv6_route.patch would be my plan :)
[09:01] <dileks> should I use lp-no as prefix?
[09:01] <dileks> lp988183_dont_fight_kernel_for_default_ipv6_route.patch ?
[09:04] <RAOF> Maybe; you can add that as metadata in the patch header, though.
[09:04] <RAOF> http://dep.debian.net/deps/dep3/
[09:05] <smb> RAOF, Hey there. :) We're having fun with ati this morning. ... :-P
[09:07] <dileks> RAOF: hehe. I proposed DEP-3 in a little router project for years. they love to steal but dont want to document. if this is even GPLv2-conform?
[09:09] <dileks> I think it enough to point lp-no in debian/changelog
[09:11] <dileks> RAOF: http://nopaste.snit.ch/135174
[09:17] <RAOF> smb: Still?  I chose to interpret your “Oh, it's mirroring on the other thing” as meaning that everything was going fine :)
[09:18] <RAOF> dileks: We don't have maintainers in Ubuntu, so we don't have non-maintainer uploads :)  Other than that, I'd probably give a short description of the bug in addition to the LP number; and you want to use the syntax ‘(LP: 988183)’ to do the equivalent of ‘(Closes: 988183)’.
[09:19] <dileks> OK, so drop NMU line?
[09:19] <RAOF> Yup.
[09:22] <dileks> RAOF: the version string is OK?
[09:23] <smb> RAOF, Well there is the explanation. Right after install when I log-in and the displays are in mirror mode there is no launcher and at least for me terminal windows are near unusable. Unpluging the external monitor before loggin in fixes this also changing into seperate monitor mode
[09:24] <smb> And surprisingly switching back into mirror mode still seems to not get into the same trouble again... 
[09:24] <smb> Just sounds like a bit of a big loop to get it working... On the other hand not critical
[09:24] <smb> Unfortunately it means I have to reinstall to get back into the problematic state...
[09:27] <RAOF> :/
[09:28] <RAOF> dileks: It depends on what you want to do with it - if you want to get it into the distro, then no; ~dileks isn't generally in official versions :)
[09:29] <dileks> into the distro would mean to be a ubuntu developer?
[09:30] <RAOF> Yes, but you wouldn't necessarily need upload privileges; you could attach the debdiff to the bug and subscribe ubuntu-sponsors.
[09:30] <dileks> anyway, I build a new NM and see, if it really fixes my issue
[09:30] <RAOF> Good plan :)
[09:30] <dileks> LP registration was hard enough :-)
[09:38] <dileks> RAOF: BTW, I had a lot of WLAN dis- and reconnects
[10:15] <dileks> RAOF: https://launchpadlibrarian.net/103041203/network-manager-0.9.4.0.debdiff
[10:15] <dileks> it fixes my issue
[10:28] <smb> apw, RAOF, FYI about that dual display issue. bug 988252
[10:28] <ubot2> Launchpad bug 988252 in unity "Launcher missing after desktop install" [Undecided,New] https://launchpad.net/bugs/988252
[10:29] <smb> cking, ^ if you want to add comments of your own
[10:29] <cking> smb, will do
[10:57] <orated> Hello! Could anyone suggest me resources which describes what porting is and how it is done? And how porting an OS different from rebuilding one?
[11:01] <apw> orated, porting is making something work on something where it did not work before
[11:03] <orated> And usually what all steps are involved in it?
[11:04] <cking> http://en.wikipedia.org/wiki/Porting
[11:04] <cking> is this a homework assignment?
[11:04] <orated> ?!
[11:04] <orated> No, it isn't cking
[11:07] <orated> I don't know what makes you ask that. apw: Then how is that different from a rebuild?
[11:07] <cking> orated, so, when porting to a new architecture one needs to port the compiler (which is hard work, which is described will in the Aho, Sethi and Ullman dragon compiler book). Then one has to write or port a boot loader and also write the architecture specific parts of the kernel (which involves understanding the low-level arch specific details and writing a lot of low-level code in assembler). 
[11:08] <cking> ..however a lot of arch specific code can be written in C too.
[11:09] <cking> the compiler side is interesting, one normally creates a cross compiler, and one can eventually boot strap up from this a native compiler, but one has to do a lot of work up front to create the back-end for the target architecture
[11:10] <cking> see http://en.wikipedia.org/wiki/Porting#Porting_compilers
[11:10] <orated> Ah, thank. Making an OS cross platform -- x86>arm>sparc - making it run from one architecture to another, right?
[11:11] <orated> processor architecture, instruction set etc ...
[11:11] <cking> yep
[11:12] <cking> however, one can port applications by re-compiling them if one has the OS and the compiler already and if the program is written in a portable way
[11:12] <orated> So for example when ubuntu ARM is being installed on beagleaboard/pandaboard... is that really porting?
[11:12] <orated> that is rebuilding what you said above ^?
[11:12] <cking> installing is just copying it onto the machine
[11:13] <orated> So the image is what is already prepared to run on a arm based system?
[11:13] <orated> installation image
[11:15] <cking> to get to the installation image, work had to be done to get it working on that architecture and then build all the necessary software (packages) to make it into a working system and then create an installation image to allow one to get it copied and running on that target platform
[11:16] <orated> So that is what basically involves porting? To prepare an installation image?
[11:17] <cking> orated, read http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=14&ved=0CDwQFjADOAo&url=http%3A%2F%2Fwww.usenix.org%2Fpublications%2Flibrary%2Fproceedings%2Fusenix98%2Finvited_talks%2Fjohnson.ps&ei=Bt2XT9OSNsjg8APzrr2DBg&usg=AFQjCNFNr1GoorYkVMfYkKIz1ewCqrUxNw&sig2=wtmJ9C0TJpyBXeS_Q6Acwg
[11:20] <orated> Sure, I'll read that ps file and the wiki. Thanks. 
[11:23] <orated> cking:  I was wondering about the installation image download option which comes on ubuntu site. It asks to select image for x86 or x86_64 -- instruction set. In the same way I found that certain images are for omap_ armel for ARM..  so these images which are created, does the process of it involves what you said above about porting?
[11:24] <orated> ... building kernel based on the target hardware?
[11:42] <cking> orated, well some body had to originally port the code. we however are packaging it up
[11:44] <cking> orated, for a lot of ARM systems the porting work isn't so bad, the work goes into writing the platform specific board support
[11:47] <cking> orated, note that sometimes when porting applications one has to fix bad code that doesn't handle CPU endianess or alignment issues correctly.
[11:47] <orated> writing platform specific board support like ?
[11:48] <cking> orated, I can't parse your last question
[11:48] <orated> " for a lot of ARM systems the porting work isn't so bad, the work goes into writing the platform specific board support" :)
[11:49] <orated> so in that context I meant to ask for examples for platform specific board support ...
[11:52] <cking> orated, so the board support code for each platform (e.g. omap2, beagleboard, etc) has to be written to port a system - sometimes the code can be re-used, but most likely somebody has to write specific drivers to handle the hardware on a platform
[11:54] <cking> ..but since these are ARM based, the tool chain and a lot of the kernel functionality to support the CPU is already there from previous porting exercises
[11:56] <orated> cking:  Ah, ok. I'd like to confirm the ubuntu ARM and beagleboard part. When one uses the preinstalled armel omap image to try on ARM based boards like beagle/panda, then that actually is installing ubuntu and not porting
[11:56] <orated> right?
[11:57] <orated> https://wiki.ubuntu.com/ARM/OmapNetbook
[11:58] <cking> yep, installing is just the act of copying it to your board
[11:59] <orated> But I noticed that sometimes compiling is also required like for example here for demo images - http://elinux.org/BeagleBoardUbuntu#Demo_Image
[11:59] <orated> linux kernel compile 
[12:01] <cking> orated, in my book, porting is when some poor soul has to get software working on a different system and it involves some effort to get it into the shape where it builds correctly and runs  in the way that is expected. 
[12:03] <cking> sometimes that can be weeks of effort because of the quality of software, missing or different architecture features or assumptions made about of the target platform.  just downloading the source, building it and it works is just rebuilding it IMHO
[12:03] <orated> well, I don;t understand then why many put up instructions on 'porting Ubuntu on Beagleboard' when its basic installation from the image
[12:04] <orated> ah
[12:04] <orated> rebuilding, porting, image creation, image installing -- all different thing
[12:07] <cking> depending on how people want to defined terms. Quoting Lewis Carroll: “When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean - neither more nor less.”
[12:09] <cking> orated, anyhow, I suspect at this point "google" is your friend in helping you find out more
[12:14] <orated> Could you suggest me any book/resource on basics of porting other than what you suggested above for compilers?
[12:35] <brendand> cking - did you want to have a look at bug 926136
[12:35] <ubot2> Launchpad bug 926136 in linux "CPU1 on Dell PowerEdge M610, R715 and IBM X3500 M3 goes offline after exercising frequency governors" [Medium,Triaged] https://launchpad.net/bugs/926136
[12:35] <brendand> ?
[12:35] <cking> brendand, sure, once I've finished my lunch
[13:59] <dupondje> kamal not here ?
[14:39] <hggdh> apw, pgraner: the 0-day kernel for precise does not show any regressions on the QRT
[14:41] <tgardner> ogasawara, ^^
[14:41] <ogasawara> nice, that's comforting
[14:41] <hggdh> ogasawara: ah, I did not know you were the one interested in it, sorry (apw asked for it, relaying Pete's request)
[14:42] <ogasawara> hggdh: I'm sure they're interested as well
[14:48]  * ogasawara back in 20
[14:49] <diwic> hggdh, fyi, are you - or do you know any of the QA folks that would be interested in https://blueprints.launchpad.net/ubuntu/+spec/hardware-q-hda-automated-qa
[14:49] <diwic> might interest some kernel folks as well
[14:49] <hggdh> diwic: I am certainly interested :-)
[14:50] <diwic> hggdh, ok, let's discuss more at UDS then
[14:50] <diwic> :-)
[14:50] <hggdh> diwic: I subscribed to it, thank you for the heads up
[14:51] <diwic> hggdh, while I have an idea of how to develop the stuff, the actual integration with existing QA and kernel scripts is mostly a black box for me
[14:51] <hggdh> diwic: heh. And we are moving to a more flexible approach there also, so it would be an even blacker box
[15:07] <apw> hggdh, thanks :)
[15:08] <hggdh> apw: yw. for the record, I had to run it manually, there is no support for testing off a PPA
[15:20] <apw> hggdh, thanks, this was definatly a non-standard kernel as we wanted it out very rapidly; ie. not following standard process at all
[15:20]  * ogasawara check if it's finished building on i386
[15:20] <hggdh> apw: no problem from me, I just did not want people to think results would be available on jenkins
[15:21] <apw> hggdh, understood
[15:56] <tgardner> apw, so, what are you thinking about this fsnotify/fanotify patch set ? have you had any indication from upstream whether this is gonna fly ?
[15:57] <apw> tgardner, i had no feedback what so ever, i was thinking of reviving it once the release is done
[15:57] <apw> and starting the effort to repeat myself enough it gets accepted
[15:57] <tgardner> apw, you mean no feedback from upstream ?
[15:57] <apw> tgardner, no they never responded as far as i recall
[15:58] <apw> the next logical step is to clean the patches up a bit so they are only vile and push them as an RFC
[15:58] <tgardner> apw, do you know under what circumstance this ticket lock is most likely to occur ?
[16:00] <apw> the ticket lock bug, i think it was henrix or sforshee who could reproduce it, i think it was mostly triggered by stuff which occured automatically as soon as you shove in USB sticks etc
[16:00] <sforshee> apw, wasn't me, must have been henrix
[16:00] <tgardner> apw, so its likely to nail a bunch of folks regularly.
[16:00] <henrix> apw: yep, it was me
[16:00] <apw> yeah i think henrix you could repro it ?  and did test?
[16:01]  * henrix reads backlog...
[16:01] <hggdh> apw, ogasawara: hold on the kernel for a while -- one of the machines seems to be having problems rebooting, and I want to find out why
[16:01] <henrix> apw: yeah, so i was able to reproduce it using 2 scripts (link in LP)
[16:02] <hggdh> (this was after the tests, and I was just being cautious, trying to reboot  sometimes)
[16:02] <tgardner> apw, henrix: just trying to evaluate the ensuing carnage v.s. the maintenance hassle of the patch set
[16:02] <henrix> apw: i reproduced it using a virtual machine, with a single CPU, mounting and unmount a filesystem with a notification setup to the mounting dir
[16:03] <henrix> so, there were 2 reporters claiming that the issue is still present
[16:03] <henrix> but at least one of them is actually hitting a different issue
[16:03] <henrix> obviously, the "different issue" may be introduced by the patch... but IMO it is not...
[16:04] <ogasawara> hggdh: ack, keep us posted.
[16:04] <henrix> apw: tgardner: let me know if you would like some more testing on this
[16:05] <henrix> the issue is triggered very quickly (seconds); with the patched kernel, i wasn't able to reproduce it
[16:05] <tgardner> henrix, I'm mostly interested in knowing what scenarios cause the lockup. Is this something that will be common? I assume so if its triggered by inserting  a USB stick.
[16:05] <hggdh> apw, ogasawara: http://paste.ubuntu.com/945894/
[16:06] <ogasawara> hggdh: do you see the same issue with the 3.2.0-23.36 kernel we're releasing with?
[16:06] <henrix> tgardner: i guess it can happen with different devices, as long as there is a notifier set on the mount point
[16:07] <hggdh> ogasawara: I did not. But I also did not see this on the first 3 boots on this kernel
[16:07] <henrix> tgardner: in my test scenario, i was actually mounting/unmounting an HD partition under kvm
[16:07] <henrix> tgardner: s/kvm/virtualbox/
[16:12] <ogasawara> hggdh: can you see if you are able to find a reproducer with the day-0?  I'm not convinced this is a regression with the day-0 and warrant it being upheld.
[16:18] <hggdh> ogasawara: I also do not see it as a regression
[16:20] <ogasawara> bjf: https://launchpad.net/ubuntu/+source/linux/3.2.0-24.37
[16:20] <ogasawara> bjf: i386 is still building though
[16:31] <tgardner> smb, are you deploying your dom0 servers using MAAS ?
[16:57] <hggdh> ogasawara: only one machine seems to suffer from the slowpath on boot (not always, but frequently). I tend to see it as non-critical issue right now
[16:58] <ogasawara> hggdh: ack
[16:58] <ogasawara> hggdh: are you seeing it with previous kernels as well?
[16:59] <ogasawara> hggdh: lets get it filed as a bug for now so we can track it going forward
[16:59] <hggdh> ogasawara: I did not, on the last sru runs. I wil keep my eyes on this machine
[16:59] <hggdh> ogasawara: will do
[17:00] <ogasawara> hggdh: when you say the last SRU runs, I assume you mean Oneiric SRU's?
[17:00] <hggdh> ogasawara: and previous, and last precise run (with 3.2.0-23
[17:02] <ogasawara> hggdh: if you could try to hammer on it with the 3.2.0-23.36 kernel to see if you can reproduce there as well it would be good.  As I'm not seeing anything obvious from the day-0 changes
[17:02] <hggdh> ogasawara: will try
[17:17] <hggdh> ogasawara: bug 988430
[17:17] <ubot2> Launchpad bug 988430 in linux "slowpath very early in the boot process" [Undecided,New] https://launchpad.net/bugs/988430
[17:58] <arges> apw, hey are you around?
[17:58] <apw> arges, of a sorts
[18:56] <ogasawara> tgardner: https://launchpadlibrarian.net/103072856/buildlog_ubuntu-precise-i386.linux-backports-modules-3.2.0_3.2.0-24.7_FAILEDTOBUILD.txt.gz
[18:56] <tgardner> ogasawara, ok, I'll have a look
[18:57] <ogasawara> tgardner: I'm not sure what's happening there exactly, I did a local test build on both amd64 and i386 before uploading and they passed
[18:57] <tgardner> ogasawara, did the PPA overflow? sometimes it runs out of disk space, or just craps out.
[18:58] <tgardner> ogasawara, hmm, looks like the ixgbe makefile is kind of cranky.
[18:59] <tgardner> ogasawara, could be a host kernel version mismatch.
[19:06] <tgardner> bjf, I just you hate mail about your Hardy CVE patch
[19:06] <tgardner> sent you*
[19:07] <tgardner> ogasawara, did you ever build Precise LBM on gomeisa ?
[19:07] <ogasawara> tgardner: nope
[19:07] <tgardner> I'll bet it fails there
[19:08] <smb> tgardner, no
[19:09] <tgardner> smb, please elaborate. I can't remember what I asked.
[19:09] <tgardner> oh, xen MAAS deploym,ent
[19:09] <smb> tgardner, :) I am not using MAAS to deploy xen servers. To a degree I used cobbler to deplay clients
[19:10] <smb> *deploy
[19:10] <tgardner> smb, so how are the server folks doing it? wouldn't they use MAAS to deploy the hypervisors, then cobbler to provision the clients ?
[19:11] <smb> tgardner, Actually this would be both the same. In theory. However last time I looked MAAS would not install into something usable
[19:11] <ogasawara> tgardner: could you install the linux-headers-3.2.0-24-generic linux-headers-3.2.0-24-generic-pae in the precise-i386 chroot
[19:12] <tgardner> ogasawara, yep, working on it
[19:12] <tgardner> ogasawara, note that the failing build host is hardy based
[19:13] <smb> tgardner, Just as I only have a limited number of machines (at most two) to act as servers and those usually also are set up in a rather development way (having multiple releases in a special multiboot) it was not worth the effort to me. 
[19:13] <tgardner> smb, ok. I have some boxes that are fungible. I'll see if I can get that working.
[19:13] <bjf> tgardner: sent hate mail of my own
[19:13] <smb> But you could have the server installed by maas  and then use koan (orh whatever it is then) to create/register guests
[19:14] <tgardner> smb, ok, I'll likely have some questions for you about it tomorrow
[19:15] <smb> tgardner, sure and if that is not enough I am sure we can grab beers and a laptop in soonish UDS time
[19:15] <tgardner> ogasawara, 3.2.0.23 headers installed on precise-i386. just hack the LBM changelog to build against -23
[19:17] <bjf> tgardner: my reply doesn't say so but i acknowledge the need to apply the patch to openvz and xen
[19:17] <tgardner> bjf, ack
[19:21] <tgardner> ogasawara, build fails as expected on gomeisa
[19:21] <ogasawara> tgardner: yep, just saw the same
[19:21] <tgardner> ogasawara, you wanna fix it? no use both of us working on it
[19:21] <ogasawara> tgardner: sure
[19:25]  * apw goes mad watching images install
[19:25] <tgardner> ogasawara, its almost certainly this line in the ixgbe makefile: BUILD_KERNEL=$(shell uname -r)
[19:26]  * tgardner wonders what the hell apw is still doing at work 
[19:26] <apw> thats release for you
[19:27] <tgardner> apw, you in millbank ?
[19:36] <tgardner> cnd, sforshee says you could use a MB Air to debug touchpad issues. I've got a newer one that isn't in heavy use right now.
[19:38] <cnd> tgardner, I won't turn down someone giving me one
[19:38] <tgardner> cnd, email or PM your address.
[19:38] <cnd> but we might be able to fix things at UDS too
[20:27] <tgardner> ogasawara, any idea why no_dumpfile=true for Percise x86'en ? it was off for every prior release. vmcore is only built if no_dumpfile is empty. see bug #988512
[20:27] <ubot2> Launchpad bug 988512 in linux "Missing /boot/vmcoreinfo-{version} file is breaking kdump" [Undecided,New] https://launchpad.net/bugs/988512
[20:28] <ogasawara> tgardner: hrm, can't remember anything off the top of my head
[20:28] <tgardner> ogasawara, ok, I'm gonna SRU a patch for it. vmcore should be getting built
[20:28] <ogasawara> tgardner: ack
[20:28] <ogasawara> tgardner: I also uploaded the lbm fix
[20:28] <tgardner> ogasawara, ack
[20:35] <ogasawara> commit a450f280e14071376484af512d67446c6c75d964
[20:35] <ogasawara> Author: Tim Gardner <tim.gardner@canonical.com>
[20:35] <ogasawara> Date:   Tue Sep 6 10:25:34 2011 -0600
[20:35] <ogasawara>     UBUNTU: [Config] Disable makedumpfile for i386/amd64
[20:35] <ogasawara>     
[20:35] <ogasawara>     Disable this until upstream produces a version that understands a 3.1
[20:35] <ogasawara>     kernel layout.
[20:35] <tgardner> ogasawara, damn.
[20:37] <tgardner> ogasawara, I remember that now. seems like a long time ago.
[20:38] <tgardner> guess I'll find out in a few minutes if makedumpfile is any smarter
[20:40] <tgardner> ogasawara, bummer, burned in on makedumpfile
[20:40] <tgardner> I'll look at it tomorrow.
[20:40]  * tgardner -> EOD
[20:40] <ogasawara> tgardner: ack
[21:05] <cking> apw_, what's the situation now with testing?
[23:31] <hallyn> has tangerine just been rebooted, or is my network wonky?