[03:49] <bullgard4> How is the 'machine hardware name' defined that the command '~$ uname -m' outputs? '~$ info coreutils 'uname invocation' returns the additional information: "sometimes called the hardware class or hardware type" and does not give a definition either.
[04:06] <jk-> bullgard4: it's defined when the kernel is built
[04:36] <bullgard4> jk-: Right. And what is the definiton for 'machine hardware name' in this situation?
[04:36] <bullgard4> jk-: Right. And what is the definiton for the term 'machine hardware name' in this situation?
[05:09] <jk-> bullgard4: it's a string describing the system architecture
[05:09] <jk-> x86_64 / ix86 / powerpc / arm / etc
[05:32] <bullgard4> jk-: Where does '~$ uname -m' take this "string describing the system architecture" information from?
[05:33] <jk-> bullgard4: from the kernel, through the 'uname' syscall.
[05:45] <bullgard4> jk-: Thank you very much for your help.
[06:20] <diwic> good morning
[06:23] <diwic> since I upgraded to oneiric on my development machine, I'm occasionally having network troubles. (i e, this machine can successfully connect anywhere, whereas the other one gets things as "interrupted connection" or "connection timed out" errors, even though they are connected to the same router). It's happening right now, should I attempt some kind of debugging before trying to resolve the problem?
[06:33] <diwic> timeout - I shutdown/rebooted the faulty computer which resolved the problem
=== Quintasan_ is now known as Quintasan
[07:12]  * smb regretfully stomps in
[08:00] <ppisati> morning *
[08:00]  * ppisati go get a lot of coffee...
[08:03]  * smb already trying that for a while now...
[08:04]  * smb watches apw's cve frobber produce incoming mail
[08:05] <ppisati> smb: ah, welcome back Stefan! :)
[08:05] <smb> ppisati, Thanks, though it probably needs a bit till I am really back (iow not half asleep)
[08:22]  * apw giggles ...
[08:24] <jk-> hey apw, ppisati, smb 
[08:24] <apw> jk-, moin ... how you doing
[08:24] <jk-> apw: yeah, not too bad. yourself?
[08:31] <apw> jk-, tired as heck still :/  i hate travel
[08:31] <apw> smb, http://people.canonical.com/~ubuntu-security/cve/2011/CVE-2011-1747.html
[08:31] <ubot2> apw: The agp subsystem in the Linux kernel 2.6.38.5 and earlier does not properly restrict memory allocation by the (1) AGPIOC_RESERVE and (2) AGPIOC_ALLOCATE ioctls, which allows local users to cause a denial of service (memory consumption) by making many calls to these ioctls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1747)
[08:32] <apw> http://people.canonical.com/~ubuntu-security/cve/2011/CVE-2011-1576.html
[08:32] <ubot2> apw: Red Hat Enterprise Virtualization (RHEV) Hypervisor allows remote attackers to cause a denial of service via unspecified vectors that cause the napi_reuse_skb function to be used on VLAN packets, which triggers (1) a memory leak or (2) memory corruption, a different vulnerability than CVE-2011-1478. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1576)
[08:32] <jk-> apw: still? argh. I seemed to reset okay this time.
[08:32] <apw> thats the one
[08:32] <apw> jk-, yeah feels like that
[08:48] <apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/852653/comments/2
[08:48] <ubot2> Ubuntu bug 852653 in linux "BUG: unable to handle kernel NULL pointer dereference at (null)" [Undecided,Confirmed]
=== chrisccoulson_ is now known as chrisccoulson
[08:58] <diwic> apw, have you heard anything about the downtime of kernel.org, as of when they expect to be back online?
[08:58] <apw> diwic, not a damn thing.  it has been a long time now
[08:58] <diwic> ok
[09:06] <ppisati> lamont: how did the builder reacted to the new kernel?
[10:42] <apw> smb, the virtual-extra stuff got approved and applied, so you might want to review your blocked WI and see if it can be closed or not
[10:45] <lamont> ppisati: the new kernel did nothing for the build issue, which was root-caused to binfmt-support being a build-dep. Other than not fixing the unrelated problem (which _would_ be worrisome), the machine is doing just fine with the new kernel.  I support this kernel for SRUdom
[11:11] <ppisati> lamont: cool, thanks
[11:11] <ppisati> lamont: uhm
[11:12] <ppisati> lamont: nothing, nevermind
[11:12] <ppisati> i filled a bug against linux-omap, but LP keeps saying it's against linux-meta
[11:12] <ppisati> bug 853783
[11:12] <ubot2> Launchpad bug 853783 in linux-meta "vfat support=m: chicken egg situation while removing the running kernel" [Undecided,New] https://launchpad.net/bugs/853783
[11:16] <lamont> maybe it needs an "also affects" and then a close of the linux-meta one... that's what you get for splitting the metapackage out into realness. :-p
[11:26] <ppisati> because it was linux-ti-omap...
[11:26] <ppisati> damn...
[12:14] <smb> apw, Yes I was just thinking the same this morning. I would say I can close it as the extra package removes the need for better selection of what is included in the main one.
[13:38] <lamont> ppisati: in fact, if you want to hand me a source package with a ~ version number so that the natty SRU wins, I might be highly interested in that
[13:40] <apw> smb, yeah just make a note in the Results section of the spec and move it Done i say
[13:42] <smb> apw, Ok, may have made the note in the wrong place then (in the blueprint) but otherwise its done.
[13:45] <smb> apw, Hm, maybe not. Since that was only a collection of open ends, I think there was no specific spec for that. So I hope the whiteboard is enough
[13:45] <apw> will have to be indeed smb
[14:11]  * ogasawara back in 20
=== bdmurray_ is now known as bdmurray
[14:47] <ppisati> lamont: a dpkg -b <natty kernel dir> has created a .dsc and a huge .tar.gz (~760MB)
[14:47] <ppisati> doh!
[14:48] <smb> ppisati, Could it be you are missing the appropriate orig.tar.gz?
[14:48] <lamont> ppisati: and here I was hoping you had a better handle on the whole packaging process than I did.... I suspect that it wants a tar.orig.gz from the archive or so
[14:50] <ppisati> dunno
[14:51] <ppisati> actually i did a dpkg-source -b <dir>
[14:51] <ppisati> to get the src pkg
[14:51] <ppisati> lamont: what if i create a branch on zinc, tag it and you get from there the src?
[14:51] <lamont> sure
[14:51] <ppisati> perfect
[14:53] <smb> ppisati, Oh right should be a binary package which has nothing to do with orig.tar.gz... Hm, that sounds then a bit like packing up the unstripped versions... 
[14:53]  * smb wonders how big the packages in the archive are...
[15:04] <ppisati> lamont: git://kernel.ubuntu.com/ppisati/ubuntu-natty.git omap4_natty_ehci
[15:05] <lamont> ta
[15:07] <ppisati> lamont: so, in the end the problem was in userland, right?
[15:07] <ppisati> lamont: did you retry with the oneiric kernel?
[15:08] <lamont> ppisati: the problem was isolated to trying to umount /proc before umounting /proc/foo
[15:08] <lamont> which is 100% userland
[15:10] <ppisati> ah ok
[15:10] <ppisati> got it
=== kamalmostafa is now known as kamal
[15:41] <cr3> is it true to assume that unless a child device path under sysfs specifies a driver explicitly then it necessarily uses the driver from a parent device path? ie, /sys//devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill0 probably uses the same driver as /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0
[15:44] <cr3> ... where driver information is retrieved from the DRIVER entry in udev
[15:44] <tgardner> dmesg
[15:44] <tgardner> -EWRONGWINDOW
[15:49] <smb> herton, Heck if I could remember. When I think the changes of a rebase have no effect on a topic branch, I set the workflow task to invalid, is that right?
[15:50] <herton> smb: yep, that's ok
[15:50] <smb> herton, Ok, thanks. 
[15:51] <herton> smb: you can use check-release-tracking-bugs --invalidate --bug=<number> for that
[15:52] <smb> herton, Ah, ok there was something more to it then. I remember now. That also changes something else to please ignore...
[15:54] <herton> yes, the bug title, the cmd line tools does in one go everything so it's easier
[15:54] <herton> *tool
[15:55] <smb> herton, right. done now. and hopefully one day I *will* remember the tool...
[16:08]  * herton -> lunch
[16:40] <tgardner> ogasawara, 'UBUNTU: SAUCE: Unregister input device only if it is registered' has the wrong bug number in the commit log
[16:41] <ogasawara> tgardner: bah, really? 
[16:41] <tgardner> ogasawara, would I lie to you ? :)
[16:43] <ogasawara> bug 839238
[16:43] <ubot2> Launchpad bug 839238 in linux "[Dell Vostro 1450] System halted when unit is idle for a while." [Medium,In progress] https://launchpad.net/bugs/839238
[16:43] <tgardner> ogasawara, I didn't look too close, but that doesn't seem related.
[16:58] <cking> again?
[16:58] <cking> oops, wrong window
[17:00] <smb> There seems to be a united pattern somewehere
[17:02] <bdmurray> ogasawara: I'll prepare the kerneloops upload disabling today right?
[17:02] <cking> just losing focus
[17:03] <ogasawara> bdmurray: yep, that'd be great.  thanks.
=== tyhicks` is now known as tyhicks
[18:08]  * tgardner --> lunch
[18:18] <bdmurray> bjf: what log files is bug 728034 missing?
[18:18] <ubot2> Launchpad bug 728034 in linux "[Dell DXP051, SigmaTel STAC9221 A1, Green Headphone Out, Front] Playback problem" [Undecided,Incomplete] https://launchpad.net/bugs/728034
[18:18] <bjf> bdmurray, looking
[18:22] <bjf> bdmurray, lspci is missing
[18:23] <bjf> bdmurray, not saying it's right, but that's what caused the spam
[18:24] <bdmurray> bjf: okay I reported it using the audio symptom so either that or the criteria should change
[18:24] <bjf> bdmurray, i did think that we got lspci for everything though
[18:27] <cking> curses pulse audio
[18:43] <bjf> apw, that system just arrived
[18:55] <apw> bjf, awsome, two boxes yes
[18:55] <bjf> apw, ack
[18:55] <apw> bjf, alledgedly the small one is the upgrade for the large one, have fun :)
[18:56] <bjf> apw, it seems pretty heavy for an upgrade, will have to see
[18:58] <bjf> apw, no wonder, the "upgrade kit" is a new mainboard, a 1200 watt power supply and a new heatsink
[19:01] <apw> bjf, yeah a 1.2kw powersupply
[19:02]  * apw thinks he has had enough for one day ... see you tommorrow
[19:19] <komputes> Does anyone know where I can find an updated list of kernel parameters like this: http://www.cyberciti.biz/howto/question/static/linux-kernel-parameters.php
[19:19] <mjg59> Documents/kernel-parameters.txt in the kernel source
[19:20] <komputes> mjg59: is there a way to see that using a web browser (a URL I can use to always see the latest)?
[19:20] <Sarvatt> https://github.com/torvalds/linux/blob/master/Documentation/kernel-parameters.txt
[19:21] <komputes> http://www.kernel.org/doc/Documentation/kernel-parameters.txt :(
[19:21] <komputes> thanks Sarvatt 
[19:38] <komputes> when using the 'debug' kernel parameter is it used in this manner 'debug=1' (debugging on) 'debug=0' (debugging off) OR doe it use log levels 'debug=[1-7]'. Secondly, where are these (verbose) debug logs to be found?
[20:09] <komputes> I'm having a hard time understanding what "iommu=off" actually does.
[20:29]  * jjohansen -> lunch
[21:43] <dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/703180 any chance this could be fixed before final?
[21:43] <ubot2> Ubuntu bug 703180 in linux "SD card reader inaccessible without pci bus rescan" [Undecided,Confirmed]
[21:52] <jjohansen> dupondje: before release?  possible but unlikely.  The oneiric kernel is now in kernel freeze so all patches have to go through the SRU process.