[00:24] <koolhead17> hi all
[01:21] <erichammond> Attention needed from Canonical folks running EC2 repositories: https://forums.aws.amazon.com/thread.jspa?messageID=349163
[01:31] <lifeless> erichammond: we think its fixed, if they could try again?
[01:31] <lifeless> erichammond: a good place to ask such questions is #ubuntu-mirrors
[01:46] <erichammond> lifeless: It would probably be a good idea to post a response on the AWS forum as well as in this thread for the folks who are following the issue: https://groups.google.com/forum/?fromgroups#!topic/ec2ubuntu/gQJWyEP1ABY
[01:46] <lifeless> erichammond: I'm just acting as middle-man, I'll pass that on
[02:07] <ChmEarl> anyone got vfb objects working in xen dom0 on 12.04?
[02:07] <ChmEarl> the xen dom0 boots fine and I can create paravirtual domU fine without vfb
[02:23] <ChmEarl> nm - fixed it - cd /usr/share;ln -s qemu-linaro/ qemu
[02:23] <ChmEarl> xen looks for keymaps under qemu, not qemu-linaro
[02:50] <zul> adam_g: for which?
[08:18] <jefimenko> does anyone know how to get a consistent MAC address for a active-backup bond in 12.04?
[08:18] <jefimenko> since upgrading to 12.04, sometimes the system takes eth0 MAC at boot, other times it's eth1
[08:18] <jefimenko> i need consistency for DHCP
[08:20] <jefimenko> http://ubuntuforums.org/showthread.php?t=1967987
[08:24] <Jeeves_> afaik, it always takes the 'lowest' mac-address
[08:24] <jefimenko> this is my network configuration: http://paste.ubuntu.com/1012761/
[08:24] <jefimenko> i'm trying to force the hwaddress to the MAC of eth0
[08:25] <jefimenko> just like the poster in that thread
[08:25] <jefimenko> it doesn't seem to work either
[08:25] <jefimenko> Jeeves_: it's not taking the lowest. it's random
[08:25] <jefimenko> sometimes it's the eth0 hwaddr (lower), other times it's the eth1 hwaddr (higher)
[08:25] <jefimenko> every time i reboot i don't know if the system will come up on the network :(
[09:12] <qbitza> Hello, I have a weird RAID issue
[09:12] <qbitza> dmraid -s returns: ERROR: isw: wrong number of devices in RAID set "isw_biaeibhcac_RIAD1" [1/2] on /dev/sdb
[09:13] <qbitza> but cat /proc/mdstat says the device is fine
[09:13] <qbitza> It is correct in reporting that there are more than 2 devices in that array, should be three
[09:28] <lynxman> morning o/
[09:28] <RoyK> morning o\
[09:29] <qbitza> morning \o
[10:04] <qbitza> Anyone here know RAID?
[10:17] <rbasak> !anyone | qbitza
[10:25] <qbitza> I have a weird RAID issue: dmraid -s returns: ERROR: isw: wrong number of devices in RAID set "isw_biaeibhcac_RIAD1" [1/2] on /dev/sdb, but cat /proc/mdstat says the device is fine - It is correct in reporting that there are more than 2 devices in that array, should be 3
[10:29] <ogra_> rbasak, i see you are diswcussiong highbank flash-kernel support, please note that we'll remove the current (forked) flash-kernel in ubuntu and will switch to the rewritten one in debian, your coding üplans should probably take that into account
[10:29] <ogra_> s/in debian/from debian/
[10:29] <ogra_> i'll send an emauil this week to ubuntu-devel about that, just wanted to warn you in advance
[10:30] <rbasak> ogra_: thanks. I had thought that there was no plan to do this! How will we converge board support for everything?
[10:30] <rbasak> ogra_: see also bug 642855 - no point in fixing that then?
[10:32] <ogra_> rbasak, all arches we currently support are also supported in the new flash-kernel (omap, omap4, ac100, mx5), highbank and armadaxp will have to be added thoough
[10:33] <rbasak> ogra_: when do you expect that we will switch?
[10:33] <ogra_> rbasak, we wanted to do that since three releases, but postponed it for after LTS (was discussed at every UDS) ... the new flash-kernel keeps HW data distinct from code and will be far easier to maintain
[10:33] <ogra_> i would like to switch before we start building A1, there the fallout will be least harmful
[10:34] <ogra_> but i'm not sure i'll manage snice we also switch all images to livefs'es
[10:34] <ogra_> (alternate will be dropped across the board)
[10:35] <rbasak> netinst images will remain though, right?
[10:36] <ogra_> yep
[10:36] <rbasak> great, just checking
[10:36] <ogra_> and the server live image will still use d-i
[10:37] <ogra_> just not a package pool on the image
[10:37] <ogra_> (and use a squashfs instead)
[10:40] <rbasak> ogra_: is there a relevant blueprint on this? I think we need work items on porting armadaxp and highbank support.
[10:41] <ogra_> rbasak, nope, no blueprint (that would onl have "sync from debian, notify people that maintain hacked scripts to port them)
[10:42] <rbasak> ogra_: I appreciate the advance warning. It will be a severe regression for us. Not a big deal to port, but we will need to do it and retest etc, and I'd like to track this somewhere. What would be the best way to track it?
[10:43] <ogra_> well, add a spec for eilt ?
[10:44] <rbasak> I suppose. I'll stick it in the ARM server deployment spec I suppose
[10:44] <ogra_> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-hwpack-integration has a Wi for it if ou need a dependenc
[10:44] <ogra_> y
[10:45]  * ogra_ wonders why his Y seems to not print 
[10:46] <rbasak> Do you mind if I stick work items for armadaxp and highbank under your flash-kernel merge work item? It makes more sense to me to put them in there.
[10:46] <ogra_> hmm, the dont really fit into that spec
[10:46] <ogra_> *they
[10:47] <rbasak> I think it's a sub-item of the merge job, since the merge introduces a regression which will need to be fixed
[10:48] <ogra_> does it ? do we have highbank support in the current flash-kernel already ?
[10:48] <ogra_> (thats why i wanted to do it early, to actually not have it in before we move)
[10:48] <rbasak> Just about. There have been uploads. It's buggy currently. I had a non-buggy merge request, but it conflicts with NCommander's latest changes.
[10:49] <rbasak> So as soon as I've discussed it with NCommander we will have.
[10:49] <ogra_> (i also would have expected NCommander to actually make sure it gets into the new f-k since he knows about the plans since three releases)
[10:49] <rbasak> And armadaxp is already in the current flahs-kernel of course
[10:49] <NCommander> rbasak: ogra_ the current f-k didn't support what was needed
[10:49] <ogra_> NCommander, oh, you are up already
[10:50] <NCommander> ogra_: yes, I've been waiting three releases for it. If it actually gets uploaded, then I'll worry about it.
[10:50] <rbasak> NCommander: hello!
[10:50] <rbasak> NCommander: can we chat about getting highbank support in flash-kernel and d-i?
[10:50] <NCommander> rbasak: its already in the f-k that's in archive.
[10:50] <ogra_> NCommander, awesome, i would like to sync it pre-A1 or shortly after (depending on the live-image move)
[10:50] <rbasak> NCommander: we have all the pieces - I'd really like to get this resolved asap so that I can focus on maas
[10:50] <rbasak> NCommander: it doesn't work. Did you get my email?
[10:50] <NCommander> d-i was waiting on the kernel
[10:51] <NCommander> rbasak: Monday was a US holiday, I haven't even checked my inbox yet
[10:51]  * NCommander kicks thunderbird
[10:52] <ogra_> yeah, half the world has a holiday yesterday
[10:52] <ogra_> *had
[10:52] <rbasak> NCommander: ok sorry, let me know when you're ready
[10:52] <ogra_> (germany too ... whitmonday)
[10:52] <NCommander> rbasak: oh I see it
[10:52] <rbasak> ogra_, NCommander: once we have highbank working in d-i, I'd really like to not break it with a flash-kernel merge. Can we work to getting highbank in and tested to the new flash-kernel before we replace the existing one?
[10:52] <NCommander> the d-i stub wasn't tested fully
[10:53] <ogra_> rbasak, feel free, we will sync from unstable
[10:53] <NCommander> rbasak: so the f-k stub works properly if f-k.conf has all the necessary bits in it. I flubbed up the bit of f-k-i that has that code.
[10:53] <ogra_> and split out the DB data into an arch all package so it can be used without having to install f-k itself
[10:53] <NCommander> ogra_: sync?
[10:53] <NCommander> Oh
[10:53] <ogra_> NCommander, yeah, just a sync and dropping all our hacks
[10:54] <ogra_> thats why i want to notify everyone in advance :)
[10:54] <NCommander> ogra_: the hw database is a separate package then?
[10:54] <ogra_> loics rewrite has support for all arches we support except for the two new server arches ...
[10:55]  * NCommander hasn't looked at the new f-k in two cycles.
[10:55] <ogra_> its not in debian, it will be in ubuntu
[10:55] <NCommander> so f-k will get blacklisted?
[10:55] <NCommander> (on the sync list)
[10:55] <ogra_> so we can use tehe DB in chroots even if we dont use f-k
[10:55] <ogra_> no, it will be a normal merged from then on
[10:55] <NCommander> right, I remember the discussion, I was waiting for the implementatoin :-)
[10:55] <ogra_> with (hopefully) just minor packaging tweaks
[10:56]  * NCommander looks to see if highbank kernel landed
[10:56] <ogra_> so it would be good to get armadaxp and highbank into debian too :)
[10:57] <rbasak> ogra_: would a drop-in flash-kernel replacement from debian work today? ie. can I test this in advance easily?
[10:57] <ogra_> rbasak, theoretically it should just work, yeah
[10:57] <ogra_> (for arches debian and ubuntu both support indeed)
[11:00] <rbasak> ogra_: ok, thanks. I think our approach should be to get either debian flash-kernel ready and tested with highbank and armadaxp support first, or an ubuntu delta prepared, before we update quantal. Not sure who'll do that - I'll discuss with the team.
[11:00] <ogra_> rbasak, then it will have to wait until A2 or A3 ...
[11:00] <ogra_> which means a *lot* less testing
[11:01] <rbasak> why would it have to wait until A2 or A3?
[11:01] <ogra_> the new arches need to be added anyway, the switch will have to happen anyway, so we want it as early as possible in the cycle to have most testing
[11:02] <ogra_> well, it definitely would have to wait until after A1
[11:03] <ogra_> since we do the livefs switch too and i'm currently the only one working on arm stuff (the rest is at connect)
[11:03] <ogra_> that would make us lose one miletone for testing, which isnt good
[11:04] <ogra_> (note that A1 arm image installability  runs under the "nice to have" tag)
[11:05] <ogra_> (buildability is the focus for them)
[11:08] <rbasak> ogra_: when exactly were you planning to sync from debian? And are you saying it will miss A1 because you'll be waiting for the armadaxp and highbank work?
[11:09] <ogra_> rbasak, no, we planned to release only images that are installable, but there is no pressure from the release team that they "all have to work"
[11:09] <ogra_> i.e. we planned to make the switch and see what works ootb ... then release that
[11:10] <ogra_> so we have a window to fix the remaining issues until A2
[11:10] <ogra_> (omap3/4, ac100 and mx5 should just work without touching any code)
[11:11] <ogra_> (if they dont, they'll drop off the shelve for A1)
[11:11] <rbasak> ogra_: sorry, I don't follow you. I want to avoid a regression in flash-kernel since that will block my MAAS enablement work and much of our automated testing which relies on netinst d-i in quantal working on armadaxp too. So I'd like to get flash-kernel fixed before upload. You seem to be saying that if we fix flash-kernel first, then this change would miss A1. Why? What are the deadlines for getting flash-kernel prepared in advance in order to n
[11:11] <rbasak> ot miss A1?
[11:12] <ogra_> this week
[11:12] <rbasak> So you'll be syncing flash-kernel from Debian this week? When exactly this week?
[11:12]  * ogra_ checks the release schedule ... i think A1 was planned for next thu
[11:13] <ogra_> june 7th is A1 ... archive will freeze on monday (at least it usually did, not sure that policy changed)
[11:13] <ogra_> that ,eans it has to be in by june 1st i think
[11:13] <ogra_> *means
[11:15] <LyonJT> Anyone know how to manipulate vspftpd so that when i upload a file it automatically changes the user?
[11:16] <ogra_> (or latest at june 3rd if you like to work on weekends)
[11:17] <rbasak> ok, thanks. I understand the situation now, and I'll ask the relevant managers about resourcing in today's meeting. Who did you have in mind to do the armadaxp and highbank work?
[11:18] <ogra_> rbasak, well, someone with access to the HW :)
[11:20] <ogra_> i.e. whoever does HWE in eilt
[11:20] <rbasak> OK
[11:31] <aljosa> how can i get numer of all active threads on system? something like lsof for file descriptors but something to check if i'm close to /proc/sys/kernel/threads-max
[11:50] <yolanda> hi, i have a question about security on a package, can i get some help?
[11:51] <rbasak> !ask | yolanda
[11:52] <yolanda> i had one packaged reviewed last week, openerp-desktop, and i had rejected with some bugs. One of them is about security, so i need some advice on it
[11:53] <yolanda> this is the problem i had reported: debian/openerp-desktop.postinst sets the openerp database password in
[11:53] <yolanda>    an insecure manner which allows other users to see it via /proc.
[11:53] <yolanda>    Both the 'psql' and the 'sed' command have this problem.
[11:57] <freakabcd> hi all
[11:58] <freakabcd> I am running ubuntu server 1204 in virtualbox.. everything was working fine, so I saved this vm as  the base. then I cloned it.
[11:59] <freakabcd> now in the clone (the mac address ofcourse changed), /etc/udev/rules.d/70-persistent-net.rules has eth0 as the old mac and the new mac is assigned to the1
[12:00] <freakabcd> I could correct this manually in 70-persistent-net.rules but I want the file to be generated automatically
[12:00] <freakabcd> so i delete the file and simply restart udev and nothing happens!
[12:00] <freakabcd> i.e. the file is not regenerated as it says in the comment right on top of the file itself
[12:04] <ogra_> it says it is generated by persistent-net-generator.rules
[12:04] <ogra_> do you have this ?
[12:04] <freakabcd> ogra_, I know for sure the file will be regenerated if i reboot the machine
[12:04] <ogra_> (elsde i would just run the mentioned binary by hand or an initial start script)
[12:04] <freakabcd> but i ofcourse do not want to reboot :)
[12:05] <freakabcd> yes, the binary that is run is /lib/udev/write_net_rules
[12:05] <freakabcd> this binary is automatically called when udev processes the /lib/udev/rules.d/75-persistent-net-generator.rules file
[12:06] <freakabcd> but if i call the binary with sudo /lib/udev/write_net_rules    it simply says:  missing $INTERFACE
[12:07] <freakabcd> restarting udev does not seem to regenerate the /etc/udev/rules.d/70-persistent-net.rules file
[12:08] <Jeeves_> You probably need to set some environment variables
[12:08] <Jeeves_> which are present at boottime, i assume
[12:08] <freakabcd> oh ok..
[12:08] <freakabcd> nice.. i will try it
[12:08] <freakabcd> when it said missing $INTERFACE I assumes it to be an arg for the program
[12:08] <Jeeves_> A reboot will probably fix the file.
[12:08] <freakabcd> it looks like it might be an env var
[12:08] <freakabcd> i'll try now
[12:08] <freakabcd> no, i don;t want to reboot :D
[12:09] <Jeeves_> Why did you completely remove the file?
[12:09] <Jeeves_> Why didn't you just edit it? :)
[12:10] <freakabcd> i have massaged this file many times when cloning VMs
[12:10] <freakabcd> just wanted to see it actually regenerated the file without doing a reboot
[12:10] <freakabcd> it says that it is regenerated automatically.
[12:10] <freakabcd> and rebooting linux machines and VMs, i dont like :D
[12:11] <ogra_> well, there are certain things you have to reboot for :)
[12:11] <ogra_> even on linux
[12:11] <freakabcd> no way..
[12:12] <freakabcd> bringing a dev up for an existing iface does not need a reboot
[12:12] <freakabcd> it was present on boot and was detected fine.
[12:12] <ogra_> bootloader, kernel, the initsystem and udev changes surely fall under "you need to reboot to make it work if you want the daemon to pick it up" ... for udev thats surely a blurry area though
[12:13] <ogra_> since it lives half in userspace and half in kernel space
[12:23] <ogra_> rbasak, oh, looking at flash-kernel in teh archive it seems that infinity actually invested some time to clean up the mess with highbank
[12:24] <rbasak> ogra_: he did, but I don't think it works. I'm doing more testing now.
[12:24] <smb> smoser, utlemming, When Ben said the thing about no kernels in cloud images I realized that you might get bitten by the reduction of flavours quite a bit. Not sure it is possible to make a fallback to generic if no virtual is present in order to work with older and newer releases...
[12:28] <jolaren> How do I move files from a folder to back from that folder?
[12:28] <ogra_> rbasak, not to be sarcastic, but did yu guys think about peer reviewing code before uploading it ? :)
[12:28] <jolaren> now I have a folder called teamspeak in /home/teamspeak/teamspeak/
[12:29] <rbasak> ogra_: don't look at me. I don't have upload rights. Everything I do gets reviewed.
[12:29] <smoser> smb, its under control. we'll fix it.
[12:29] <ogra_> rbasak, yeah i didnt mean you :)
[12:30] <smoser> utlemming's merge proposal is too simplistic as it is, because we know a range of -generic kernels that do not work (we can't just white list them all)
[12:30] <smoser> and we need to change som eof the build scripts, but it is what it is.
[12:30]  * rbasak had a merge proposal that he actually tested and does work
[12:30] <freakabcd> ogra_, Jeeves_ sudo INTERFACE=eth0 MATCHADDR="08:00:27:98:16:c3" MATCHDEVID="0x0" MATCHIFTYPE1 /lib/udev/write_net_rules
[12:30] <smoser> smb, unless you're going to change -virtual package to contain a file named
[12:30] <smoser> '-virtual'.
[12:30] <freakabcd> regenerated the file :D
[12:30] <smoser> which may or may not be useful.
[12:30] <smoser> does -virtual currently (quantal) conflict with -generic?
[12:31] <smb> smoser, Ok. Yeah it probably needs to check the PAE in the related config for i386. I would rather think not (that about the file)
[12:32] <smb> smoser, And similar, when there are virtual kernels those likely want to be sorted first... which may be a pain depedning on how the cfg ist created
[12:33] <smb> (given that I seem to have issues already how I sort the letters in my words...)
[12:36] <smb> smoser, Btw, the problem is that there is no real virtual package anymore. There are virtual meta packages and those pull in the generic kernel packages. Just like it is now with -server
[12:36] <smb> real virtual... doh!
[12:39] <smoser> smb, the code i have correctly sorts
[12:40] <smoser> or, we can make it do that (it woudl currently favor X-generic over X-virtual except X-generic is blacklisted. so we would have to make it blakclist certiain -generic. that may be suitable).
[12:42] <smoser> smb, i understood the problem (regarding the meta package). i was suggesting that it would be possible to re-architect kernel packages to build -virtual and -generic that did not conflict (even though they were binary content the same, except for path names)... if you could muck with the uname string.
[12:42] <smoser> anyway.
[12:42] <smoser> i dont htink tha tis necessary
[12:44] <smb> smoser, The desire is to rather have less that same number of packages (while the actual gain is build time, but the packaging has grown rather complicated). But yeah, I think it should be solvable without. If it just picks up any kernel but places virtual first, then as long as the default index of 0 is not changed I would think it would work in all cases.
[13:38] <szikael> I have problem with setting sshd_config  ,  the point 2 comp ubuntu 12.04  when i'm ussing ssh with out ListenAdress i am able to connect whan i'm adding ip (good one ) connectin refused
[13:38] <szikael> how ever it is only whan i connect from comp 1 to 2 , the other way all is working corect
[14:13] <tash> 've got a mysldump script that ran fine in Debian, but in Ubuntu 12.04 it seems like my defaults file ( .my.cnf ) in /root/ is not being read.  In my script I'm setting MYSQL_HOME="/root/" but when I run the script to dump db's I get denied for root@localhost
[14:13] <tash> if I specify the password in the script on the line of the mysqldump ... --password="password" it works
[14:14] <tash> so def seems like the defaults file is not being read
[14:15] <tash> interesting, I removed the MYSQL_HOME variable from the script and it works now.
[14:15] <tash> can someone explain that?
[14:16] <jcastro> SpamapS: you were right wrt. my mdadm
[14:16] <jcastro> a drive was kicked out and it just flipped out.
[14:16] <jcastro> so instead of the drive being marked as not part of /dev/md1 it just put it in /dev/md1_d1 or somesuch
[14:46] <SpamapS> jcastro: so were you able to --force it back in?
[14:47] <jcastro> yep
[14:47] <jcastro> rebuilt with "assume-clean" or some other very scary flag
[15:05] <SpamapS> jcastro: I think I'm ready to say that btrfs disk pools or even the wacky FUSE based ZFS are better than ye-olde-RAID ;)
[15:10] <jcastro> SpamapS: I'll let you know when my disks get here today. :)
[15:46] <Gallomimia> i had this problem when running apt-get upgrade on my server today: http://pastebin.com/Rr7bW58V
[15:50] <rbasak> Gallomimia: looks like an issue on your machine, but I can't tell for sure from that message. Do you have enough memory? Any runaway processes? Could the hardware be faulty?
[15:51] <Gallomimia> i think it's ram. we downgraded and i've not seen how much is left
[15:51] <Gallomimia> doesn't change what shows in top when i run more or less servers
[15:52] <rbasak> Perhaps adding swap will help?
[15:52] <Gallomimia> i think it will yes. we want to avoid swapping like the plague tho
[15:52] <rbasak> You could always add more memory :)
[15:53] <Gallomimia> default config is of course without swap cause most people will let it swap hard without noticing what's going on, and what it does to neighboring server's performance
[15:53] <rbasak> Any idea how much you're short by? Is this operation requiring more memory than it should?
[15:53] <Gallomimia> yes i think that's a better idea rbasak
[15:53] <Gallomimia> 3gigs was enough to do what i want. but we went for one less cpu
[15:53] <Gallomimia> think i'll just setting for what i can do on 2 for now
[15:54] <rbasak> an apt-get upgrade really shouldn't need anywhere near that order of magnitude
[15:54] <Gallomimia> well, i was super full
[15:55] <Gallomimia> i dropped two servers and it's fine
[15:55] <rbasak> I see. So not an issue with Ubuntu then?
[15:55] <Gallomimia> when i get that particular flavor more configured properly, i'll use it more
[15:55] <Gallomimia> no... it appears to be pebkac
[15:55] <Gallomimia> which is what irc channels are best at telling you
[15:55] <rbasak> OK, np :)
[15:56] <Gallomimia> thanks :) good morning by the way
[16:19] <FunnyLookinHat> Anyone here have experience with setting a TMPTIME in /etc/default/rcS ?  I just realized it's 0 by default which means my server ( which is never rebooted ) will just continue to float more and more data in there...
[16:19] <FunnyLookinHat> I was thinking setting it to 1 ?  Would there be any big issue with doing os ?
[16:19] <FunnyLookinHat> *so
[16:20] <rbasak> m_3: can I give you the charm testing on ARM work item please? Does it still look feasible?
[16:21] <m_3> rbasak: sure... I can reassign if necessary
[16:21] <rbasak> thanks!
[16:21] <m_3> rbasak: won't be able to start looking at it until next week tho
[16:21] <rbasak> m_3: no problem!
[16:22] <m_3> rbasak: note no hw (qemu only) if you need to split the item up
[16:22] <rbasak> m_3: noted, thanks
[16:31] <FunnyLookinHat> Or can I count on /tmp being cleaned when it reaches a certain size?
[16:42] <rbasak> zul: any chance you could review https://code.launchpad.net/~racb/ubuntu/quantal/apache2/988819/+merge/106934 for me please? You were the last uploader...I asked for review from ~ubuntu-server as well, or should I put it in the normal sponsorship queue? I thought a server team member would make more sense.
[16:44] <zul> rbasak: sure right after i poke my eye out with this thing im trying to fix
[16:44] <rbasak> ok, no problem
[16:51] <smb> zul, fixing pointy objects is dangerous
[16:51] <zul> smb: my eye it is
[16:52] <smb> Just good that we wear glasses...
[17:04] <hallyn> stgraber: I'm thinking that lxc-net may need to just not run if dnsmasq is installed
[17:05] <stgraber> hallyn: well, then containers won't get IPs, that doesn't sound like what we want
[17:05] <hallyn> stgraber: they won't get ips anyway, becaue lxc-net will fail
[17:06] <hallyn> all right i'll wait on that :)
[17:06] <stgraber> hallyn: I think we probably should have a LXC_NET_NO_DNS option (using a better name obviously) that users can set to have lxc-net start but not bind :53
[17:07] <stgraber> hallyn: that won't make it just work by default, because it's awfuly tricky to know how's the system wide dnsmasq configured but that'll at least give the user the option to fix their setup (and have lxc's dnsmasq only act as a dhcp server instead of dhcp+dns)
[17:07] <hallyn> wil their base dnsmasq then answer dhcp requests for lxcbr0?
[17:07] <xclusive585> heres a noob one: I cannot get apt-get to just show me what packages WOULD be upgraded. even the -u switch seems to do nothing if you dont actually install updates
[17:08] <stgraber> hallyn: no it won't, that's why we'd probably want to only disable the dns part of dnsmasq, not the dhcp one
[17:08] <stgraber> hallyn: AFAIK the system wide dnsmasq doesn't act as dhcp server by default, so we shouldn't get a port conflict on the dhcp port, only the dns port is the problem
[17:09] <stgraber> we could probably have lxc-net automatically start in dhcp-only mode if it detects that something is already bound on 0.0.0.0:53 but we can't solely rely on that as it's racy
[17:10] <stgraber> so having the configuration variable + fallback to dhcp-only if 0.0.0.0:53 is bound, sounds like the easiest way to solve ~80% of the current cases :)
[17:12] <hallyn> sounds good.  but do you think we can have postinst choose automatically
[17:13] <stgraber> we could, but I wouldn't do that until /etc/default/lxc is completely managed by debconf or people will get confusing upgrade prompts
[17:16] <hallyn> ok
[17:17] <stgraber> I'm starting to wonder if it wouldn't just be best if we patched dnsmasq to only bind the loopback address :)
[17:17] <stgraber> then whoever wants it to listen on something else will have to deal with the consequences
[17:17] <stgraber> (and hopefully will be clever enough not to set it to 0.0.0.0)
[17:24] <hallyn> stgraber: well that's what i've watned, but it seems some people (more knowledgeable than i on these matters) think that's a bad idea
[17:34] <streulma> Hi all
[17:34] <streulma> does Java and Tomcat run on a Virtual Private Server with ony 1 gigabyte of memory ?
[17:35] <stgraber> hallyn: another thought, can't we have lxc dump "bind-interfaces\nexcept-interface=lxcbr0" into /etc/dnsmasq.d/lxc and restart dnsmasq in the postinst (if /etc/init.d/dnsmasq exists)?
[17:35] <stgraber> hallyn: so basically shipping our own dnsmasq configuration file for their .d directory that configures the system wide dnsmasq not to mess with lxc
[17:35] <stgraber> AFAIK that's even policy-compliant :)
[17:43] <hallyn> stgraber: i think that's been suggested (and nacked) somewere in one of the bugs for dnsmasq+libvirt+lxc
[17:43] <hallyn> stgraber: what would then happen if they removed dnsmasq?
[17:44] <stgraber> nothing
[17:44] <hallyn> do we just have lxc-net check if dnsmasq is installed before starting its own dnsmasq ?
[17:45] <hallyn> all right maybe i'll see if i can understand all you've suggested tomorrow.  i have some reading to do
[17:45] <hallyn> stgraber: thanks
[17:46] <stgraber> depends what solution you're talking about :) I'm starting to think that shipping /etc/dnsmasq.d/lxc is the cleanest option as it uses the dnsmasq.d directory that's meant for that, makes lxc's dnsmasq do its usual job and doesn't change user behaviour for the system dnsmasq
[17:46] <stgraber> sounds all win to me :)
[17:48] <hallyn> stgraber: sounds good to me.  I'll play tomorrow (unless you want to)
[17:48] <stgraber> hallyn: I'll have a debdiff in a few minutes for you to look at
[17:48] <hallyn> heh
[17:48] <stgraber> I already have it working in a container here, just trying to make it look nice
[17:49] <hallyn> and any reason we couldn't do the same thing for libvirt then?
[17:49] <stgraber> the same would work with libvirt, yes
[17:51] <adam_g> zul: i had to fix a patch to tthe swift tests in glance so tests will pass outside of buildds. not sure how that fits into the SRU
[17:51] <hallyn> stgraber: out for lunch, bbl
[17:51] <zul> adam_g: should be ok
[17:52] <adam_g> zul: should i open a bug so we have something to reference in the changelog ?
[17:52] <zul> reference it in the changelog, "rediffed due to x y z"
[17:54] <stgraber> hallyn: http://paste.ubuntu.com/1013392/
[18:01] <hallyn> stgraber: oh, i see. inverse of what i was thinking :)
[18:02] <hallyn> looks good to me
[18:02] <hallyn> that makes 3 fixes for q (two are staged in bzr), probably worth a release
[18:03] <stgraber> sounds good. We'll probably want to get the dnsmasq one through SRU once the current gets into -updates
[18:04] <hallyn> agreed
[18:04] <hallyn> do you want me to push it, or do you want to?  (for q)
[18:05] <hallyn> we can probably combine a bunch of the 'lxc-net failed to start' bugs (dup them i mean) and make them one high prio bug
[18:05] <hallyn> addressed by both the fix for /bin/sh->bash and your dnsmasq one
[18:06] <stgraber> I'll do a PPA build of the current bzr branch, see if it works as expected
[18:06] <stgraber> merging the dnsmasq bugs would be nice, we'll need that if we want to SRU it anyway
[18:06] <hallyn> great, thx
[18:06] <stgraber> I also need to check that we can safely dump more than one of these overrides in dnsmasq.d so libvirt can do the same (and possibly network-manager too)
[18:07] <hallyn> one should effing hope so :)
[18:07] <hallyn> stgraber: but do you think we need two bugs for lxc-net not starting, or can i combine them all?
[18:08] <stgraber> they sound like different issues. wasn't the bash one fixed a while ago?
[18:12] <hallyn> i think that fix is still staged in bzr
[18:12] <hallyn> maybe not
[18:14] <hallyn> but i suspect there was only one bug that was due to sh->bash.  anyway, some are marked transitively as dups, but all are now related through dups :)
[18:14] <hallyn> 4 or 5 of them
[18:14] <hallyn> stgraber: we sill one day need to talk about syslog ns :)
[18:15] <hallyn> but not today - gotta go (lunch for real now) bbl
[18:15] <stgraber> hallyn: yeah... the current corruption mess is annoying :)
[18:15] <stgraber> enjoy!
[18:32] <Altbair5> http://j.gs/11yg --see the important movie
[18:40] <zul> SpamapS:  ping
[18:44] <SpamapS> zul: pong
[18:44] <zul> SpamapS: are you doing an SRU run
[18:44] <SpamapS> zul: yeah, training w/ bdmurray
[18:45] <SpamapS> zul: he'll send you a reason for the rejection of python-webob :)
[18:45] <zul> SpamapS: ok i was wondering :)
[18:45] <SpamapS> zul: hint.. bug#'s are required
[18:45] <zul> SpamapS: k ill have another look at it
[18:47] <SpamapS> zul: also, adding quilt in an SRU is a no-no
[18:48] <skrite> hey all
[18:48] <stgraber> SpamapS: also, why was python-webob in the precise-updates queue and not in precise-proposed?
[18:50] <SpamapS> stgraber: oh yeah, that too
[18:50] <SpamapS> zul: ^^ wrong pocket
[18:53] <zul> adam_g: do we have any fixes we need in horizon?
[18:55] <adam_g> zul: none that i know of
[18:55] <zul> adam_g: ok
[19:22] <axisys> I have this redhat init script http://paste.ubuntu.com/1013541/ .. need to convert it to ubuntu
[19:22] <axisys> what do I replace this with?
[19:22] <axisys> . /etc/init.d/functions
[19:23] <axisys> with this one may be? . /lib/lsb/init-functions
[19:24] <axisys> ok what is ``killproc'' equivalent ?
[19:27] <skrite> i would like to ask a couple of questions about mysql-cluster, anyone with any experience setting this up ?
[19:39] <hallyn> zul: share some wisdom with me
[19:40] <hallyn> zul: merging debian's qemu-kvm,
[19:40] <zul> hallyn: thanks for making me feel old
[19:40] <hallyn> they are right now copying files in debian/rules instead of using packagename.links / packagename.install
[19:40] <hallyn> i have to pick different packagenames for most of those anyway, so they can't stay the same,
[19:41] <hallyn> so should i keep the manual copies in debian/rules, or keep our qemu-common.install etc
[19:41] <zul> i would do what debian does, less headaches in the long run
[19:41] <hallyn> all right, will do, thanks
[19:41] <hallyn> (ideally i'd switch to their package names, but the fact that we split some stuff with qemu-linaro makes that impossible)
[19:42] <zul> yeah
[19:43]  * zul go gets his walker
[19:45] <hallyn> man the deeper i get into this the more i wonder if it was a wise move
[19:54] <Daviey> zul: wassup?
[19:55] <zul> Daviey: hmm?
[19:55] <Daviey> * zul go gets his walker
[19:55] <zul> Daviey: heh...different context
[19:55] <Daviey> hallyn: make sure you check to se if you need Breaks (& Replaces)
[19:56] <hallyn> Daviey: near as I can tell all the old ones pre-date lucid and can actually be dropped
[19:56] <hallyn> and i'm not changing any package names, so other than ipxe-kvm vs ipxe-qemu and such, all should be good
[19:56] <Daviey> hallyn: hmm.. think we are talking about different things
[19:57] <Daviey> ah
[19:57] <Daviey> ok
[19:57] <Daviey> i'm sure you've got it covered
[19:57] <hallyn> we'll see.  my worry at this point is that i'm still doing so much slicing-n-dicing that it may not be worth it in the end
[19:58] <hallyn> i may be better off just basing off of the same release+patches they use, but using our packaging otherwise
[20:22] <stgraber> hallyn: the dnsmasq.d trick works with multiple packages providing the same kind of configuration, so will be fine to have something similar in libvirt and network-manager
[20:22] <hallyn> awesome
[20:22] <stgraber> oh, and quantal's kernel seems to be happy with lxc now, no more kernel oops
[20:23] <hallyn> and if someone does apt-get purge dnsmasq, /etc/dnsmasq.d won't get removed (along with .../lxc), then after re-isntall we lose the fix?
[20:23] <stgraber> hallyn: do you know the reason for the manual rm calls in debian/lxc.postrm? I can see how they might make sense in the remove) target, but in purge) it seems pretty weird
[20:24] <stgraber> hallyn: I didn't test this, but removing a full .d directory that contains files on removal/purge would be against policy
[20:24] <stgraber> right, /etc/dnsmasq.d/lxc doesn't get removed on removal/purge of dnsmasq
[20:24] <hallyn> stgraber: i'm pretty sure i did that.  you're talking about the apparmor ones?
[20:25] <stgraber> hallyn: yeah
[20:25] <stgraber> hallyn: I can see why they'd make sense under remove) but under purge) I don't see the point
[20:25] <stgraber> hallyn: because when you purge the package it's going to remove these anyway
[20:25] <stgraber> if the idea is to ensure we get rid of the apparmor jobs when lxc is installed, they should be moved to remove)
[20:26] <hallyn> yeah no, they probably should just be removed
[20:26] <hallyn> the rms that is :)
[20:26] <stgraber> is it a problem if the apparmor rules are there after lxc is removed?
[20:27] <stgraber> if it's, we need to keep the rm calls but move them to remove), otherwise we can just remove the rm calls
[20:27] <stgraber> (for example I'm removing /etc/dnsmasq.d/lxc in remove) as I don't want our dnsmasq override to exist after the removal of lxc)
[20:28] <zul> rbasak: whats the url for the merge?
[20:41] <rbasak> zul: https://code.launchpad.net/~racb/ubuntu/quantal/apache2/988819/+merge/106934
[20:42] <zul> rbasak: thanks
[20:47] <hallyn> stgraber: no i don't think it's a problem
[20:47] <hallyn> if the rules are there after lxc is removed
[20:47] <hallyn> i obviously was thinking it might be, but i can't think of any reason for it
[20:52] <stgraber> ok, I'll remove that from the postrm in quantal then
[20:53] <osmosis> why is munin-node-configure not suggesting the 'memory' graph on 12.04?
[20:57] <stgraber> hallyn: lxc uploaded to qunatal
[20:57] <stgraber> *quantal
[20:58] <hallyn> yay
[20:58] <hallyn> now if only i could say the same about qemu-kvm
[21:54] <jMCg> Hello happy people o/~
[21:54] <jMCg> I'm looking for *sane* OpenLDAP package.
[21:55] <jMCg> I found a PPA here: https://launchpad.net/~christian-roessner-net/+archive/openldap but it's not available (for Precise)
[22:14] <Skaag> I have the 10.04 LTS, I run do-release-upgrade and it doesn't find the latest LTS. Any ideas why?
[22:15] <Skaag> never mind… the -d switch does it
[22:31] <jMCg> \o/
[22:32] <jMCg> I have found the error. It was a missing certificate in /etc/ssl/certs/ca-certificates.crt -- Of course GnuTLS wouldn't tell me that. I had to recompile OpenLDAP so that OpenSSL would give me a sane error.
[22:44] <axisys> how do I find out all the pkgs I installed after the server install .. I think we installed this server almost year ago and now I need to find out all the pkgs that are installed since then
[22:47] <ScottK> axisys: Try dpkg --get-selections
[22:47] <ScottK> That will show you all the installed packages.
[22:48] <axisys> ScottK: right.. but is there a way find out the diff?
[22:48] <axisys> I only installed openssh and basic ubuntu server during install
[22:48] <axisys> and the rest after wards
[22:49] <ScottK> Not sure.
[22:49] <axisys> /var/log/apt/term.log has only log from june last year earliest
[22:50] <ScottK> How about /dpkg.log*
[22:51] <ScottK> axisys: /var/log/installer/initial-status.gz may be of use too.
[22:53] <RoyK> zcat /var/log/installer/initial-status.gz | awk '/Package:/ { print $2 }'
[22:58] <axisys> so initial-status is for the pkgs that came duing install.. correct?
[22:58] <axisys> during*
[22:59] <RoyK> axisys: iirc yes, just check the file's date
[22:59] <axisys> doh! .. thanks 2010
[23:00] <RoyK> axisys: then make a list over installed packages with something like 'dpkg -l|awk '/^ii/ { print $2 }'"
[23:01] <RoyK> "dpkg -l|awk '/^ii/ { print $2 }'"
[23:01] <RoyK> and you have something diff might eat ;)
[23:02] <axisys> RoyK: thanks a lot
[23:02] <RoyK> ;)
[23:09] <pdtpatrick> Question - anyone witness this problem with apt-get  (when updating or installing a package), It starts off fine and then gradually gets slow and eventually just times out
[23:10] <pdtpatrick> I'm using the following sources list: http://pastie.org/3991893
[23:10] <RoyK> nope - tried downloading the packages manually? might be something bad with your connection
[23:10] <pdtpatrick> tried downloading it manually, it takes just as long
[23:10] <RoyK> then try another country ;)
[23:11] <RoyK> if in the us, perhaps .ca might be better?
[23:11] <pdtpatrick> ca.archive.ubuntu.com ?
[23:11] <RoyK> yeah
[23:12] <pdtpatrick> same deal
[23:12] <pdtpatrick> 5MB file takes 15mins. wtf -- going to hit up the network guy again.
[23:13] <RoyK> what if you try something far off? .de? .no?
[23:13]  * RoyK is in .no and time is well past bedtime - nite
[23:15] <axisys> nealmcb: nite
[23:15] <axisys> oops
[23:15] <axisys> RoyK: nite