[01:53] <Guest93> It looks like the DataSourceEC2 manages block device mappings and it's the only datasource that does so. Is your custom datasource "done" when you have it being detected and setting up networking basically?
[15:58] <johnjaye> hrm. if i specify simply password=foo in the seed file does that apply to the root account by default, or some other account?
[15:59] <johnjaye> i thought the acc name on debian clouds was 'debian' but debian/foo isn't working
[16:11] <minimal> johnjaye: which "seed file"? password=foo is not valid in the user-data YAML file is that is what you are referring to
[17:20] <johnjaye> well ok. but that's what the man page for cloud-localds said to write
[17:20] <johnjaye> so i assumed it was a meaningful example
[17:23] <minimal> johnjaye: you mean the Examples section of that manpage? it mentions "password: <whatever>", not "password=<whatever>"
[17:23] <minimal> as the first form *is* valid YAML
[17:24] <johnjaye> i have it as password: blah
[17:25] <minimal> johnjaye: ok, in your earlier post you said "password=foo" so that what what I commented on
[17:25] <johnjaye> so unless yaml has some sneaky way of tricking you with non-printable characters i got no idea
[17:25] <minimal> s/what what/was what.
[17:26] <johnjaye> i guess the first line has to be like #cloud-config or something
[17:26] <johnjaye> the manual said that i thought
[17:28] <minimal> best to look at the cloud-init docs for examples
[17:33] <minimal> johnjaye: when you say "debian/foo" isn't working do you for logging onto the VM's console? or via SSH? typically in "cloud" images SSH access is only enable via SSH key and not via password
[17:35] <johnjaye> the vm console
[17:35] <johnjaye> oh i see. so i need to forward ssh to this qemu instance then
[17:35] <minimal> johnjaye: ? you just said you are using the console so then SSH is not relevant
[17:36] <johnjaye> yeah. you made it sound like direct login wouldn't work
[17:36] <johnjaye> so i may need to add something for that
[17:37] <minimal> so assuming that the VM image you are using has defined "debian" as the default user for cloud-init (you would have to either check the image yourself or ask whomever created the image to determine this) and that you created a seed ISO with user-data containing "#cloud-config\npassword: foo\n" then yes you should be able to login as debian/foo
[17:42] <minimal> where the "\n" above represent actual line breaks
[17:44] <johnjaye> hmm that didn't work either. i'll read the manual and play 20 questions with the syntax later
[17:46] <minimal> johnjaye: which exact debian image are you using?
[17:47] <johnjaye> ones from the wiki, under 'cloud'. they provide several. named like debian-12-generic-i386.{raw,qcow2,vmdk}
[17:47] <minimal> johnjaye: which *exact* one?
[17:47] <johnjaye> idk what you mean. the copy i have is debian-11-generic-arm64.qcow2
[17:48] <johnjaye> is it customary to provide daily cloud image snapshots? i thought there were dozens of them by date
[17:51] <minimal> johnjaye: that's that Debian decision
[17:52] <minimal> s/that /a /
[18:06] <minimal> johnjayne: right, add the following line to your user-data file: "lock_passwd: false", rebuild the seed ISO and try again
[18:06] <johnjaye> by the way, can cloud-init do stuff like setup sudo or user groups and such things?
[18:06] <minimal> that Debian image does use "debian" as the default username but it also locked that user for password access
[18:06] <falcojr> johnjaye: yes, see https://cloudinit.readthedocs.io/en/latest/topics/modules.html#users-and-groups
[18:10] <johnjaye> is False interchangeable with false
[18:10] <johnjaye> either way i capitalized it
[18:10] <minimal> I believe YAML treats "false" and "False" as the same
[18:10] <falcojr> actually...I don't think so. In yaml I think it's only false
[18:11] <johnjaye> falcojr: ok. i was wondering if it would be that unusual to try using cloud-init to change settings on a regular system.
[18:11] <minimal> falcojr: "yamllint" could be used to be sure...
[18:12] <johnjaye> minimal: when you say you're a cloud dev, does that mean you work on cloud-init itself or that you use it
[18:13] <minimal> both
[18:13] <johnjaye> oh. i see
[18:13] <johnjaye> this whole cloud world seems like it has its own culture and idioms
[18:13] <johnjaye> like provisioning. the disk being called /dev/vda
[18:13] <johnjaye> or ssh being the 'obvious' default
[18:14] <minimal> johnjaye: /dev/vda is a virtio-blk devices, that's nothing specific to cloud-init
[18:14] <minimal> whereas /dev/sda could be a SCSI device, or a virtio-scsi device, or a SATA device
[18:14] <minimal> that's a Linux thing, not a cloud-init thing
[18:14] <johnjaye> ah my bad. ok it says the root account is locked
[18:15] <johnjaye> maybe i should have said false not False...
[18:15] <minimal> johnjaye: root? you're supposed to be testing the "debian" account
[18:15] <johnjaye> right. i mean, that's what the startup message says
[18:15] <johnjaye> Cannot open access to console, the root account is locked.
[18:16] <minimal> have you tried to login as debian/foo ?
[18:16] <johnjaye> hrm. i think it's just taking a lot longer. i'm on my pi now and it has an sdcard
[18:16] <johnjaye> so qemu takes like 4x as long to boot up.
[18:17] <johnjaye> maybe if i plug in a usb stick it would be faster
[18:17] <johnjaye> lol. what is a randomart image for an ssh key.
[18:17] <johnjaye> it shows several
[18:19] <johnjaye> ok debian/foo did work and i logged in
[18:19] <minimal> johnjaye: have you not seen this output when you booted this VM image previously? It should appear the 1st time you boot a cloud-init based VM
[18:19] <johnjaye> \o
[18:19] <johnjaye> minimal: it all goes by so fast you can't read it
[18:19] <minimal> look at /var/log/cloud-init-output.log
[18:20] <johnjaye> now i do believe you're a cloud dev. i would never have randomly guessed that filename
[18:21] <johnjaye> that only shows the ssh art and something about ipv6
[18:22] <johnjaye> cloud-init.log doesn't either afaik. so maybe those were dmesg
[18:23] <johnjaye> ah at least sudo is configured. that's nice
[18:23] <minimal> which output were you looking for? I thought you wanted to see the ssh art again
[18:24] <johnjaye> heh. no that message about root account being locked. i don't see it in those logs you said
[18:24] <johnjaye> or in dmesg
[18:25] <johnjaye> but hey at least it lets me login. that's amazing
[18:25] <minimal> so for that debian VM image the root account is locked, it is configured so that cloud-init will create a "debian" user by default but lock the account's password, so you need to set user-data appropriate for what you want.
[18:26] <johnjaye> is that common in cloud stuff
[18:26] <minimal> johnjaye: that would be likely in "journalctl" output as usual, nothing to do with cloud-init
[18:26] <johnjaye> like when i said password: foo how did that automatically apply to 'debian' and not say 'root'. or 'admin'. or something else
[18:27] <minimal> johnjaye: it's up to whoever packaged the disk image to decide, typically for images on cloud providers password access via SSH is disabled and SSH public keys have to be provided in user-data (along with any users/groups you want to add)
[18:27] <johnjaye> yeah but i meant the yaml file
[18:28] <johnjaye> how does it decide what to apply password: foo to. just the first user account?
[18:28] <minimal> johnjaye: "password: " applies to the default user defined in /etc/cloud/cloud.cfg ("default_user:", "name:") set by the Debian people
[18:28] <johnjaye> what if there isn't one
[18:28] <minimal> the same way that they alos have "lock_passwd: True" in there
[18:28] <johnjaye> then there's just no login as root or anything else
[18:29] <minimal> johnjaye: there's always a default user, that's why it is called the default user...
[18:29] <johnjaye> i thought you can create unix systems with no users. just root
[18:29] <johnjaye> like in the past when i install debian sometimes it does that
[18:30] <johnjaye> no users, i have to manually create them
[18:31] <minimal> well my previous statement is not 100%, when you create additional users in user-data you can decide whether or not the default user is also created
[18:31] <johnjaye> oh ok
[18:32] <johnjaye> and when you're doing this sort of thing is it for a person usually
[18:32] <minimal> but the idea is "out of the box" if you don't specify users then you get the default user
[18:32] <johnjaye> as in like an individual customer. or is it more like you need to automate setting up 1000 debian instances for a CI thing
[18:33] <minimal> it is whatever you want to do - for each Vm you create you provide user-data (and other settings) for that VM
[18:33] <johnjaye> ok. i was reading about google cloud and you basically write a command like 'give me a ubuntu 18 instance with username password foo/bar' and it instantly copies all the relevant data into it
[18:34] <johnjaye> so i assume all these cloud providers either use cloud-init or else have something themselves
[18:37] <minimal> johnjaye: yes the vast majority of cloud providers can or do use cloud-init (I think GCE had some alternative system in the past, not sure if it is still used)
[18:37] <minimal> so when you provision a Linux instance/VM on AWS, GCE, Azure, etc you give it user-data for that VM
[19:44] <meena> falcojr: I lost a day to migraine
[19:45] <falcojr> :( Migraines suck
[20:03] <meena> I think it might have been just (lack of) caffeine induced, but it took almost a full day, and did not respond to ibuprofen. I've also started mapping them, to see if there's a pattern, cuz I feel that since i went thru Covid it's become a monthly recurrence
[20:40] <meena> falcojr: will need fresher head to go fixing all those test failures when moving the ifconfig invocation into __init__
[20:41] <meena> but, I think that will also make it a good opportunity to extend tests to fit these new code paths
[21:03] <meena> falcojr: i really need to start looking into TypedDict… it seems like it would solve a lot of problems… a lot of problems i have created for myself.
[21:06] <meena> oh, i … went too far…
[21:06] <meena>     def is_physical(self) -> bool:
[21:06] <meena>         # OpenBSD makes this very easy:
[21:06] <meena>         return "egress" in self.groups
[21:06] <meena>         return self.groups == [] and self.media and "Ethernet" in self.media
[21:06] <meena> This isn't erlang…
[21:11] <meena> falcojr: absolutely no idea how to do this: https://github.com/canonical/cloud-init/pull/1779#discussion_r999877423 (without ruining typing)
[21:11] -ubottu:#cloud-init- Pull 1779 in canonical/cloud-init "Net: add BSD ifconfig(8) parser" [Open]
[21:46] <falcojr> meena: sorry, was a suggestion. If it works better for you to keep it as-is, that's fine
[21:47] <falcojr> also, IIRC, TypedDict isn't supported on 3.6 which is still cloud-init's minimum version
[21:47] <meena> falcojr: if you initialize dev = None at the top, it becomes Optional[Ifstate] and a lot more complicated
[21:47] <meena> aye…
[21:48] <holman> TypeDict is in the codebase already
[21:48] <holman> I added it
[21:48] <holman> I think it's available, but limited in what syntax you can use iirc
[21:48] <falcojr> holman: you added a version gate I think...so I don't think I want to keep doing that everywhere
[21:49] <meena> and now, to break some tests
[21:49] <meena> and then goto bed.
[21:49] <holman> oh you're right
[22:03] <meena> okay, so, basically, now i need to mock every creation of a BSD mock distro, with a test appropriate output of subp([ifconfig -a])
[22:11] <meena> yeah, i don't think I'm getting any fresher ideas
[22:11] <meena> Good night folks o/~
[22:23] <meena> weird… make check fails on my laptop, but not on Travis?


[00:44] <bjf> ogasawara: you ever build lbm by hand?
[07:04] <diwic> According to ubuntu-kernel's meeting minutes, I have at least one "work item". How do I find out what that work item is?
[07:07] <RAOF> diwic: Check out http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team.html
[07:11] <diwic> RAOF, thanks
[08:30] <lacostej> Anyone does know how to bring attention to a regression with a patch ? See bug #86820. I've nominated it for Maverick in launchpad but that was probably not the right thing to do...
[08:34] <diwic> lacostej, if there is a patch in 2.6.36, you have tested it and it works okay, you might want to send a pull request on the ubuntu-kernel mailing list
[08:34] <lacostej> I've backported it to 2.6.32 and I use it everyday
[08:34] <diwic> lacostej, https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
[08:35] <lacostej> I can upgrade to 10.10 beta, and try backporting it to 2.6.35 as well if needed
[08:59] <lacostej> diwic: I mailed the list. I am not subscribed so I hope it will go through.
[09:00] <diwic> lacostej, nothing showed up yet, it's likely moderated
[09:01] <lacostej> ok. I will stick here for a while then :)
[09:46] <apw> lacostej, it is indeed moderated for non-members ... spam overload elsewise
[09:47] <lacostej> apw should I register and re-send or just wait for the moderation to happen ?
[09:47] <apw> lacostej, it should appear shortly
[09:47] <lacostej> ah yes. it did in the archive
[09:48] <lacostej> mmm it got truncated in the web archive. The patch isn't there
[09:48] <apw> lacostej, subject ?
[09:48] <lacostej> https://lists.ubuntu.com/archives/kernel-team/2010-September/012634.html
[09:48] <lacostej> "[Maverick] [pull request] Input: i8042 - reset keyboard controller	wehen resuming from S2R"
[09:48] <apw> who knows where the actual email is
[09:49] <lacostej> apw: in my sent box ;)
[09:50] <apw> heh arrived finally ... you'd think there were 100s of people on the list
[09:52] <jjohansen> good night *
[09:53] <lacostej> apw: does my mail contain the patch ?
[09:53] <lacostej> because the web version doesn't
[09:53] <apw> yep all there
[09:53] <lacostej> good
[09:53] <apw> though its not a pull request :)  its the patch
[09:53] <lacostej> thanks for the help
[09:54] <apw> all i did was tell it you wern't a spammer
[09:54] <lacostej> that's all that was required :)
[09:55] <lacostej> yea it's not a pull request, but the upstream commit id is in the mail. I guess they can cherry pick the patch if needed. Not sure how they would do that. maybe a format-patch + patch or a merge. I don't have great git skills
[09:56] <apw> the contents of the email is just fine, i'd have put [PATCH] on it not [pull request] just cause its just a patch.  you did the right things putting the upstream id in there etc
[09:56] <apw> everything someone needs to find and apply the original themselves is in there so its good
[09:59] <apw> lacostej, done the admin on the bug, the fix will get tracked on the mailing list now
[09:59] <lacostej> great
[11:34] <cking> apw, http://kernel.ubuntu.com/~cking/dust.jpg
[13:45] <apw> cking, we didi change how we work out if you have CPU internal sensors in 2.6.35, using cpuid instread of a hard coded list
[13:45] <apw> so it is entirly possible it is different
[13:45] <apw> sensors command may twll you where they are coming from
[13:46]  * cking looks
[13:56] <apw> cking, does sensors say 'owt ?
[13:57] <cking> no
[13:57] <cking> apw, sensors
[13:57] <cking> coretemp-isa-0000
[13:57] <cking> Adapter: ISA adapter
[13:57] <cking> Core 0:      +61.0°C  (high = +100.0°C, crit = +100.0°C)
[13:57] <cking> coretemp-isa-0001
[13:57] <cking> Adapter: ISA adapter
[13:57] <cking> Core 1:      +61.0°C  (high = +100.0°C, crit = +100.0°C)
[13:58] <apw> i wonder if you had those before, worth checking in lucid next time you are forced to reboot
[13:58] <apw> 61 is still jolly hot
[13:58] <cking> I assume ISA adapter refers to the fact that sensors is getting info from the lower 64K I/O port
[13:59] <apw> yeah i'd been assuming something similar
[13:59] <apw> time for a temperature gague on the air coming out :)
[13:59] <cking> 61 is better than the 91 degrees I saw before cleaning out the dust puppies
[13:59] <apw> heheh
[13:59] <apw> mad
[14:03] <apw> jk-, what was the symptoms on your battery failure
[14:03] <jk-> apw: flashing amber battery light
[14:04] <jk-> (inc. in BIOS)
[14:04] <mjg59> Doesn't coretemp read from an msr?
[14:04] <apw> jk-, i have also killed a battery recently on a dell, just wondered if it sounded similar
[14:04] <apw> but it sounds like different symptom
[14:04] <apw> mjg59, yeah, i suspect the isa one is 'under' the CPU
[14:04] <jk-> yeah, I was suspicious it was caused by an upgrade
[14:05] <jk-> but I think that's just coincidence
[14:05] <jk-> more likely caused by the warranty expiring :D
[14:05] <apw> heh yeah
[14:22] <AnAnt> Hello, how can I enable CONFIG_SND_HDA_INPUT_BEEP_MODE ? I read that it is runtime configurable via sysfs
[14:27] <AnAnt> sudo sh -c "echo 1 > /sys/module/snd_hda_intel/parameters/beep_mode"
[14:27] <AnAnt> sh: cannot create /sys/module/snd_hda_intel/parameters/beep_mode: Permission denied
[14:30] <abogani> AnAnt: Could you try as root effective user?
[14:30] <mjg59> apw: Does /sys/module/snd_hda_intel/parameters/beep_mode exist?
[14:32] <apw> AnAnt, ^^
[14:45] <mjg59> apw: Whoops, sorry
[14:51] <apw> :)
[15:14] <AnAnt> mjg59: yes it does exist
[15:14] <AnAnt> mjg59: funny, is that it did get written to
[15:14] <AnAnt> that's is the contents of the file:
[15:15] <AnAnt> 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[15:15] <AnAnt> I dunno what are all those values, shouldn't it just be 0 or 1 or 2 ?
[15:21] <apw> bjf[afk], poke
[15:21] <bjf> ouch
[15:22] <bjf> apw, how can i be of no use to you today?
[15:23] <ogasawara> bjf: did you get your answer about building lbm?
[15:23] <apw> bjf, wanted to chat about the CD create scripts
[15:23] <apw> mumble ?
[15:24] <bjf> apw, give me a sec, got to straighten out a 9 yr old
[15:24] <apw> bjf, np
[15:24] <bjf> ogasawara: talk to you about it in a bit maybe
[15:29] <JFo> bjf, or sconklin will we be doing an upload to -proposed sometime soon? QA is asking.
[15:29] <bjf> JFo: did one last week
[15:29] <sconklin> ^^
[15:29] <JFo> k
[15:29] <bjf> JFo: why is qa asking? do they want to test it?
[15:30] <sconklin> bjf: good one ;-)
[15:30] <JFo> yep
[15:30] <JFo> they are wanting to do a run on the planned testing
[15:30] <bjf> JFo: as long as you're talking to them about it, it would be nice if we could see some results
[15:30] <JFo> ok
[15:30] <bjf> JFo: we've been asking about that for a while
[15:31] <JFo> yeah, I've asked
[15:31] <sconklin> This is an especially good one to test, as it's a lot of changes
[15:31] <bjf> JFo: the one that is there now is a very good candidate
[15:31] <JFo> will let you know what the result is
[15:31] <JFo> cool
[15:32] <sconklin> JFo: Do you think that they can actually test any of the bugs that should be closed by this one?
[15:32] <JFo> not sure:
 JFo, I can point you to how they would look, but I don't have current results for kernels... there was stuff missing in checkbox as well to link packages to tests
[15:32] <JFo> :-/
 JFo, yeah, it's just the code changes weren't done last week... I'm looking for a future upload to see that what tracks uploads really works properly :/
[15:34] <JFo> they are rolling out an updated checkbox to test
[15:34] <JFo> he will retest the kernel in -proposed
[15:35] <JFo> and I'll let you know the results of the testing
[15:35] <sconklin> JFo: it'll likely be a couple of weeks at least before we get a new proposed.
[15:35] <JFo> no problem
[15:35] <JFo> he is going to run the tests on the one there again
[15:35] <sconklin> and that's only if this one has no issues
[15:35] <JFo> yep
[16:42]  * tgardner packs for wireless mini-summit
[17:37] <ogra> tgardner, could you hold back with the omap4 upload until tomorrow, we need to build an image for TI with the new kernel and couldnt build any since beta due to the kernel vs meta skew on omap4
[17:38] <bjf> ogasawara: i'm trying to build ubuntu-lucid-lbm in a lucid-amd64 chroot ...
[17:39] <bjf> ogasawara: i did an "fdr clean" and then an "dpkg-buildpackage -b -rfakeroot -uc -us"...
[17:39] <ogasawara> bjf: the corresponding linux-headers are also installed right?
[17:39] <bjf> ogasawara: this seems to have gotten through compatwireless and alsa but is dieing on wwan-drivers with: ccache: failed to create /root/.ccache (Permission denied)
[17:40] <bjf> ogasawara: yes and i modified the debian/changelog to match the headers :-)
[17:40] <bjf> ogasawara: i went backwards one abi
[17:41] <tgardner> ogra, there is an omap4 currently building with some packaging fixes. I'll hold off until next week unless you hassle me about it.
[17:42] <ogra> tgardner, well, just because you said in your mail you'd upload immediately after that built
[17:42] <ogasawara> bjf: hrm, not sure about the Permission denied error.  when I built my test debs for the maverick, I did 'fdr clean' followed by 'fdr binary-arch'
[17:42] <ogra> if you planned to hold back longer anyway, i wont complain
[17:42] <bjf> ogasawara: will give that a try
[17:42] <tgardner> ogra, will do. apw ^^
[17:42] <ogra> tgardner, and i know about the current build, eagerly waiting for it :)
[17:43] <bjf> ogasawara: same error, will retry it clean
[17:43] <diwic_dinner> fdr?
[17:43] <bjf> diwic_dinner: an alias for "fakeroot debian/rules"
[17:43] <diwic_dinner> aha
[17:44] <tgardner> bjf, why is there a ccache in there? perhaps something in your environment is scrogged?
[17:45] <apw> tgardner, its nearly complete as far as i can tell.. i assume i did push everything so you had something to base your pull into
[17:45] <bjf> tgardner: don't know what to tell you
[17:45] <tgardner> apw, yep, it all looked corect
[17:45] <apw> good ... so are you asking if you should wait ?
[17:46] <tgardner> bjf, is it clean, clean ?
[17:46] <ogra> apw, btw, see -devel ... if we would not try to strip translations from the linux package that might speed up building ;)
[17:46] <ogra> especially on arm
[17:47] <bjf> tgardner: yes, fresh clone
[17:47] <bjf> tgardner: going to try again on tangerine in case it's my chroot somehow
[18:05] <manjo> cking, yo!
[18:06] <cking> manjo, hi
[18:06] <manjo> cking, sorry I missed this mornings chat on mumble
[18:07] <cking> what time does that mumble session start for you?
[18:08] <manjo> cking, heh 8am :)
[18:08] <cking> oh, zzz time then :-)
[18:09] <manjo> heh
[18:09] <manjo> no I forgot about it
[18:09] <manjo> cking can you hear me on mumble ?
[18:09] <cking> no, my audio is off (again!)
[18:09] <manjo> ah
[18:39] <gbledsoe> greetings all - do we have members of the kernel team on presently?
[18:43] <JFo> gbledsoe, always
[18:43] <bjf> ogasawara: i was able to build the maverick lbm on tangerine but not the lucid lbm
[18:43] <JFo> :)
[18:44] <bjf> ogasawara: still pounding my head against it
[18:44] <gbledsoe> thanks JFo
[18:44] <JFo> gbledsoe, my pleasure
[18:44] <gbledsoe> I had a couple quick questions and hope I won't take up too much of anybody's time
[18:45] <JFo> ask away gbledsoe
[18:45] <ogasawara> bjf: hrm, I'll see if I can get lucid lbm to build.
[18:45] <JFo> if anyone is available and knows, they will answer
[18:45] <gbledsoe> I run a number of freeswitch servers that see a pretty good load (15 mb/s in rtp traffic, 100 calls apiece or so)
[18:45] <gbledsoe> so the server kernel has always given us quite a bit lower load
[18:46] <gbledsoe> I tested the upgrade from 8.04 to 10.04 and found that the server kernel has gone away?
[18:46] <gbledsoe> now it appears (on x86) to be a pointer to generic pae
[18:46] <gbledsoe> which uses 250 Hz clock and cfq schedular
[18:46] <gbledsoe> under load, this produces about 4x the load average for us
[18:47] <gbledsoe> so is this a permanent?  and has anyone complained about this at all?
[18:48] <gbledsoe> and what are the chances of resurrecting the x86 server kernel?  :-D
[18:49] <apw> gbledsoe, yep that is deliberate and permenant.  server class h/w normally is 64bit now, so why not use that kernel
[18:49] <apw> noone complained about it at the UDS sessions when it was discussed, nor really complained when it was announced close to a year back now
[18:50] <gbledsoe> in my experience 64 bit kernel has more bugs because it has traditionally seen less use - I've been bitten a number of times
[18:50] <gbledsoe> so I should pay closer attention in the future, aye?  :-)
[18:50] <apw> now that 32bit and 64bit arch support is merged, that is less likely and server side its the one we test now as its the only one
[18:51]  * apw runs 64 bit on everything that will run it
[18:51] <gbledsoe> ok, well that answers my question, thank you
[18:51] <apw> heh you cirtainly need to realise we are on a 6 month cycle and everything can change every six months
[18:51] <apw> gbledsoe, you can even run the 64bit kernel on 32 bit userspace in theory as a test
[18:52] <gbledsoe> true
[18:52] <apw> though you have to force the kernel to install
[18:56]  * cking calls it a day
[19:22] <ogasawara> bjf: on tangerine it doesn't look like the header files are installed in the lucid chroots?  but I just tested building lucid lbm on a local box and it passed after I installed linux-headers-server (already had linux-headers-generic installed)
[19:23] <bjf> ogasawara: ok, just rebuilt my lucid chroot locally, will install the headers and try again
[19:23] <bjf> ogasawara: thanks for looking
[19:23] <ogasawara> bjf: np
[19:23] <ogasawara> bjf: I was going to test on emerald, but it seems to be down for me at least
[19:24] <ogasawara> bjf: do you have sudo permissions on tangerine?
[19:24] <bjf> ogasawara: yes
[19:24] <ogasawara> bjf: to install the headers in the lucid chroot
[19:24] <ogasawara> bjf: I can then test it there to make sure it's working
[19:24] <bjf> ogasawara: ok, heading there now to install
[19:32] <bjf> ogasawara: i've installed the headers on tangerine and started my own test build, working better than before
[19:33] <bjf> ogasawara: i had installed the headers on my local build system but didn't on tangerine
[19:33] <bjf> ogasawara: in the past I've usually run into build-dependency issues which pointed at the headers, this time it was trying to build alsa and dying
[19:33] <bjf> ogasawara: anyway, its working better now, will see if everything builds
[19:34] <ogasawara> bjf: cool, let me know
[19:41] <bjf> ogasawara: ok, the build on tangerine worked just fine
[19:42] <ogasawara> bjf: nice
[20:10] <bjf> ogasawara: would you mind ack'ing my lucid lbm pull request?
[20:11] <ogasawara> bjf: sure
[20:34] <akgraner> apw can and will do - thanks - I leave for Ohio LinuxFest tomorrow afternoon  - I'll do my best to get back to you by this evening or early my time tomorrow
[20:42] <apw> akgraner, thanks
[22:07] <ilmari> any chance of getting https://patchwork.kernel.org/patch/119791/ into maverick?
[22:07] <ilmari> "Update battery information on notification 0x81" - fixes erroneous battery reading when unplugging A/C power on newer thinkpads
[22:56]  * jjohansen heads out to do some errands
[23:23] <bjf[afk]> JFo: where is your "buglist" that generates the top 50 list? i'm looking in your home dir on cranberry
[23:45] <[reed]> mjg59: ping?


[12:49] <Roguehorse2> today...do lab work and get on full MediCal...\o/....woo-hoo! Then get my SSDI papers in progress
[12:53] <Roguehorse2> should probably get more done on the book too while as lot of this is fresh in my mind
[18:50] <dimaa> general linux question. it is safe to store and run random nick nack scripts in /opt right?
[18:50] <ianorlin> dimaa: probably should not run them as root
[18:50] <ianorlin> hard to say without seeing the code
[18:51] <dimaa> oh i was assuming im running them as me not root
[18:51] <pleia2> I put my own scripts in a local bin/ in my home directory
[18:51] <ianorlin> if it messes with stuff in your home it might not be a good idea
[18:52] <pleia2> and /usr/local/bin is a good spot too (plus, automatically in your path!)
[18:52] <dimaa> ~/bin might be a good idea and yes pleia2 /usr/local/bin also. well i think that answer that for me
[18:52] <dimaa> hah
[18:53] <pleia2> it's "safe" to put them in /opt in that it won't delete them like in /tmp or something, but meh
[18:53] <dimaa> at work we have an EC2 instance for our team and they keep stuff in /opt so i was wondering
[18:53] <pleia2> I've never been the biggest fan of /opt :)
[18:54] <dimaa> well good to get perspectives :D
[18:55] <dimaa> basically i want to put scripts on my personal VPS in a place for the other users to use them. so I made a chmod 777 folder in /home for people
[18:55] <pleia2> use and edit?
[18:55] <dimaa> its a free for all. (we have a level of trust on my server)
[18:56]  * pleia2 nods
[18:56] <dimaa> and i like to keep it that way
[18:56] <pleia2> I'd put something like that in /usr/local/bin rather than one person's home
[18:56] <dimaa> they are my friends so i do trust them
[18:56] <dimaa> /usr/local/bin will allow them for other though iirc?
[18:57] <pleia2> hm?
[18:57] <dimaa> err i mean /usr/local/bin is not just for me?
[18:57] <dimaa> it is for everyone on the server
[18:58] <pleia2> yes
[18:58] <dimaa> ok
[18:58] <dimaa> :D
[18:58] <dimaa> i think i will move my things there then
[18:58] <dimaa> haha
[21:04] <philipballew> What would cause my external public ip address to not show up when I try to ping it or attempt to ssh through it?
[21:05] <philipballew> It seems like an odd situation, so I thought someone here might know
[22:29] <DonkeyHotei> what do you mean by not show up?
[23:58] <philipballew> DonkeyHotei, I mean I can not ping the ip remotelty?
[23:58] <philipballew> pleia2, pm?
[23:59] <pleia2> go for it


[09:01] <mvo> hey MacSlow!
[09:02] <mvo> and njpatel :)
[09:02] <njpatel> mvo: morning !
[09:10] <MacSlow> hey mvo
[09:47] <seb128> pitti: any idea about what to blame for bug #302191 (see the screenshot)
[09:49] <pitti> seb128: maybe no consolekit session?
[09:49] <pitti> seb128: please sub me, will followup with some questions
[09:49] <seb128> pitti: ok, thanks
[09:50] <pitti> sub'ing usually works fine
[09:50] <seb128> I'll reassign to gnome-mount which is nearer than gnomevfs
[09:50] <pitti> incidentally I'm just creating an UDS presentation about bug mail handling :)
[09:50] <seb128> ;-)
[09:50] <pitti> seb128: right
[09:50] <seb128> pitti: subscribed, thank you
[09:56] <seb128> mvo: hey
[09:56] <seb128> mvo: bug #301971, is that something you could filter out since that's not really a bug?
[10:13] <mvo> seb128: sure, adding it now
[10:14] <seb128> mvo: thank you
[10:15] <mvo> seb128: in bzr now
[10:16] <seb128> mvo: you rock ;-)
[10:24] <andreasn> mpt: ping
[10:26] <mvo> mpt: hello! I got your mail, sorry that I haven't replied yet
[10:54] <mpt> mvo, ok
[12:36] <hggdh> seb128, hi -- bug 205999 -- do you want to add the patch to evo stable?
[13:49] <mvo> seb128: https://wiki.ubuntu.com/FoundationsTeam/Specs/JauntyCodecInstall feel free to subscribe/add your own items
[13:49] <seb128> mvo: ok thank you
[13:49] <mvo> seb128: I didn't manage to get results with gnome-codecs-install from experimental
[13:50] <mvo> not sure if that is just a issue with my system
[13:50] <mvo> or with the version in experimental
[13:50] <seb128> not sure either, you can try asking slomo when he's around though
[13:53] <mvo> ok, I will try the same when I see him
[16:14] <ember> mvo metacity branched, fixes amd64 ftbfs
[16:14] <mvo> ember: excellent, thanks a lot!
[16:14] <mvo> ember: will merge in a bit (#ubuntu-meeinting)
[16:14] <ember> okidoki, thanks
[18:29] <ottoshmidt> what is this chat room for, specifically?
[18:30] <dobey> ubuntu desktop development
[18:31] <ottoshmidt> most of participants are developers?
[23:08] <pochu> if anybody feels like taking the eclipse merge, I won't complain :-)
[23:10] <pochu> -EWRONGCHAN