[00:00] <SpamapS> smoser: I think we should try to fix both then.
[00:00] <SpamapS> smoser: seems nova-volume is the only thing that rdeps on tgt
[00:00] <smoser> interesting.
[00:01] <smoser> i wonder if it starts tgt
[02:56] <smoser> SpamapS, if you want to review: https://code.launchpad.net/~smoser/ubuntu/precise/tgt/lp977621-start-on-install/+merge/101321
[02:56] <smoser> and feel free to fix the other open bug there also with a better upstart job if you'd like
[04:33] <smoser> SpamapS, tomorrow perhaps i need your upstart genious help a bit
[04:33] <smoser> cloud-init seems to be slow to start if networking is up before root filesystem mount (iscsi root)
[06:04] <brando753> you know I have always manually installed my server files, though using tasksel seems alot easier, is there any reason not to use tasksel? I always have heard its better to install packages manually so Ive never really used it.
[06:06] <mgw> can anyone point me the right direction as to how to apply a patch while buidling a .deb? Specifically, it needs to be done after configure is called.
[06:07] <twb> mgw: why after configure is called
[06:08] <twb> If the answer is "because it edits the makefile", the right solution is to patch makefile.am or configure.ac instead
[06:12] <mgw> twb, i was asking on behalf of another developer, I think he figured it out
[06:12] <mgw> ty
[06:13] <twb> I bet "figured it out" means the wrong way
[06:13] <mgw> he's applying a patch before configure — it's not our source, so we want to apply minimal patches
[06:16] <twb> Good
[06:16] <brando753> you know I have always manually installed my server files, though using tasksel seems alot easier, is there any reason not to use tasksel? I always have heard its better to install packages manually so Ive never really used it.
[06:18] <twb> tasksel is for noobs
[06:19] <twb> There is absolutely no reason to use it if you are familiar with apt
[06:20] <mgw> what's it for? installing collections of packages?
[06:21] <twb> Basically it's for people who go "can haz mail?" instead of "I need postfix and dovecot please"
[06:21] <mgw> ok, no wonder i never noticed it
[06:21] <brando753> ok, but is there a reason not to use it?
[06:21] <brando753> it can take a while to setup all the packages
[06:22] <mgw> how many systems are you setting up?
[06:22] <brando753> and I wonder if it just does the same things automatic
[06:22] <mgw> if you're setting up more than a few, you'll want to automate it anyway
[06:23] <mgw> or even if you're setting up one and expect to need to rebuild it anytime soon in a predictable way
[06:39] <twb> mgw: there is a tasksel prompt at install time
[06:40] <twb> brando753: all tasksel does is associated a list of packages with a convenient name, like "LAMP server"
[06:40] <brando753> so why wouldnt somone use it?
[06:40] <twb> brando753: if you know what underlying packages you want, there is no need for tasksel.  There should not be any harm, either, except maybe it will e.g. install postfix when you wanted exim
[06:40] <twb> Or install stuff you didn't want at all
[06:40] <brando753> is it bloated?
[06:41] <twb> I've just explained to you exactly what it is.
[07:26] <mgw> any way to install dpkg-scanpackages without the whole dpkg-dev system?
[07:36] <twb> dpkg-dev isn't that bloated, surely
[07:36] <twb> Also no
[07:37] <mgw> yeah, i figure dit out
[07:37] <mgw> all that's needed is the perl script itself and libdpkg-perl
[07:37] <mgw> this is for a production system, don't want the developer toolchain on it
[07:38] <twb> dpkg-dev isn't a developer toolchain
[07:38] <twb> That's build-essential (i.e. gcc, g++, cpp, etc)
[07:38] <mgw> it installs gcc
[07:38] <mgw> The following extra packages will be installed:
[07:38] <mgw>   build-essential fakeroot g++ g++-4.6 libalgorithm-diff-perl
[07:38] <mgw>   libalgorithm-diff-xs-perl libalgorithm-merge-perl libstdc++6-4.6-dev
[07:38] <twb> Recommends: gcc | c-compiler, build-essential, fakeroot, gnupg, gpgv, libalgorithm-merge-perl
[07:38] <twb> Opt out of it
[07:39] <mgw> how?
[07:39] <twb> aptitude -R or apt-get --no-install-recommends
[07:39] <twb> Or to opt out of specific cases, aptitude install foo bar- baz-
[07:40] <twb> Actually bar: baz: would be better; otherwise it might uninstall an already-installed bar and baz
[07:40] <linocisco> hi all
[07:43] <linocisco> how do you all think about zentyal server?
[07:44] <mgw> twb: thanks for that tip
[07:44] <mgw> it works
[08:21] <lynxman> morning o/
[08:26] <mgw> lynxman: morning
[08:26] <lynxman> mgw: morning!
[08:27] <mgw> I hope you're in europe
[08:27] <mgw> or somewhere in a similar timezone
[08:28] <koolhead11> hi lynxman
[08:28] <lynxman> koolhead11: hey :)
[08:29] <koolhead11> lynxman, :(
[09:15] <koolhead11> adam_g, jamespage around?
[09:16] <koolhead11> when i do sync_db user/tenant gets created, what is the pwd for admin user :P
[09:16] <koolhead11> *keystone i meant
[09:17] <sw> what's the best system to use with mirroring users around servers, ldap or ...?
[09:18]  * koolhead11 modifys user-pwd then :(
[09:20] <Daviey> sw: ldap is pretty well supported.
[09:22] <sw> Daviey: I'll give that a shot
[09:31]  * koolhead11 scratches his head
[09:32] <koolhead11> adam_g, jamespage am i hitting a bug? why should db_sync create user/role/endpoints
[09:32] <koolhead11> isn`t it supposed to simply add DB schema
[09:33] <koolhead11> am i doing something wrong with keystone ?
[09:33] <koolhead11> gsssssssss
[10:00] <koolhead11> facepalm
[10:04] <Geron> Ubuntu and iSCSI. When (if?!) will Ubuntu support multiple initators on a single target?!
[10:05] <Daviey> Geron: Are you using tgt?
[10:05] <Geron> tgt?
[10:08] <koolhead11> sorry guys i had connected wrong db in my keystone.conf and it was already populated with certain tenant/user.
[10:08] <Daviey> Geron: iscsi?
[10:09] <Geron> Daviey: yes, iSCSI..
[10:09] <Geron> I have one machine acting as a target, "sharing" a large drive.
[10:09] <Daviey> Geron: okay.. i'll come back when you can tell me if you are using tgt.
[10:10] <Geron> sigh...
[10:12] <Geron> Cant tell right now (no access to the target machine)
[10:12] <Geron> But previously when configuring two initiators to use the same target. Only one got read/write access. The other machine got a broken kind of "read only"
[10:13] <Geron> And I later noticed the "MaxConnections" stuff in /etc/ietd.conf
[10:13] <Daviey> Geron: Ah, using iscsitarget.. try tgt
[10:13] <Geron> Which must be set to 1, and to my understanding. This limits the number of initiators per target to 1...
[10:14] <Geron> Aaah, ok. Will investigate... Using tgt might fix my problem here then?
[10:22] <Daviey> Geron: We think it's a better target.
[10:52] <lynxman> Daviey: would it be wise to try to upgrade a production server now to precise? It's my personal one so I don't really mind if something breaks :)
[10:56] <Daviey> lynxman: yep!  Testing appreciated
[10:57] <lynxman> Daviey: cool! will do then :)
[11:04]  * koolhead11 says hi to Daviey :)
[11:08] <ludo89> Hello, does anyone knows freeradius ?
[11:08] <ludo89> i need to install it on a wired lan.
[11:08] <ludo89> without NAS.
[11:09] <ludo89> can my transparent proxy be the NAS (my transparent proxy intercept port 80 connexions).
[11:55] <zul> Daviey: do you want a FFE, debdiff, changelog in  a bug report for swift?
[12:00] <Daviey> zul: all of the above please.
[12:02] <zul> Daviey: ack
[12:41] <phaidros> is it possible to have chrooted sftp/scp users (openssh) editing cronjobs/their crontab? a symlink is obviously useless, but is there a way?
[12:41] <zul> good morning
[12:42] <rbasak> phaidros: run a chrooted cron. otherwise you might as well not bother chrooting, since a user can enter a cron entry that will run outside the chroot.
[12:43] <phaidros> rbasak: right ..
[12:43] <phaidros> thx
[12:48] <rbasak> smoser: I've been doing some investigation into squid-deb-proxy. I think I get what's going on but it's a bit complicated. Got time to sync?
[12:49] <smoser> hm..
[12:49] <smoser> do i have time ? no.
[12:49] <smoser> do i want to to? yes.
[12:49] <smoser> give me 5 minutes ? you want to set up a hangout?
[12:50] <rbasak> OK I'll set one up
[12:54] <rbasak> smoser: invite sent
[13:05] <gary_poster> hallyn, morning.  When you've started work...
[13:05] <gary_poster> My squad is talking about adding a script for ourselves, and we're wondering whether it would be good to have in the general lxc package.  The idea is an "lxc-ip" command.  "lxc-ip NAME_OF_CONTAINER" would return the ip address of the container, so you could do things like "ssh `lxc-ip NAME_OF_CONTAINER`".  The implementation would be exactly like what is in lxc-start-ephemeral right now (looking at the dhcp leases)
[13:05] <gary_poster> .  This would be an alternative easy way to connect to a container if hooking up the local nameserver is not desired (or even broken--it's been unreliable for us, or at least our setup of it has been).  What do you think?
[13:18] <SpamapS> gary_poster: tell me again why you're not focusing on improving juju for this?
[13:19] <SpamapS> gary_poster: juju has juju status for this kind of stuff.. :)
[13:25] <gary_poster> SpamapS, we are using lxc alone, in addition to using it with juju
[13:27] <SpamapS> gary_poster: we were talking the other day about adding ephemeral support to the local provider
[13:29] <gary_poster> SpamapS, cool.  hallyn has some thoughts on refactoring/rewriting lxc-start-ephemeral for 12.10, so maybe that would be a good opportunity to sync up and make sure that the lower-level lxc bits can be usable for juju too
[14:39] <hallyn> jdstrand: drat, tried to push my changes to qa-regression-testing, but got http://paste.ubuntu.com/923384/
[14:41] <jdstrand> hallyn: weird. can you just give me a diff for now?
[14:42] <hallyn> jdstrand: http://people.canonical.com/~serge/qrt-libvirt-precise-fix.patch
[14:44] <jdstrand> hallyn: thanks. why the two calls to _destroy_vm()?
[14:45] <hallyn> d'oh
[14:45] <hallyn> because i mis-handapplied the patch
[14:45] <hallyn> (i blame the instance i was working on which had about a minute lag-time to keystrokes)
[14:45] <hallyn> (cause it can't be *my* fault)
[14:46] <hazmat> utlemming, thanks
[14:47] <hallyn> jdstrand: i was considering putting that into the same original function, but it's so much shorter...
[14:49] <hazmat> utlemming, one more for you if you've got time.. at this point its not critical for precise.. but cloud-init's config doesn't end up running in the cloud-image container due to rsyslog's failure to start in the container
[15:00] <lynxman> just updated to precise, there's a process that is self executing and sleeping almost eating one of my CPUs http://pastebin.ubuntu.com/923408/
[15:00] <lynxman> any idea where to start looking at?
[15:02] <acicula> lynxman: the 0.0 would suggest its not using cpu at all?
[15:04] <zul> lynxman: fuser?
[15:04] <ikonia> lynxman: why do you think that's eating your cpu
[15:05] <lynxman> zul: hmm could be
[15:06] <ikonia> could be ???????
[15:06] <ikonia> lynxman: why do you think that is easting your cpu
[15:06] <lynxman> ikonia: a machine that was 0.05 is now solidly on the 1.00 after reboot
[15:06] <ikonia> 0.05 where ?
[15:06] <ikonia> what are you using to measure
[15:06] <lynxman> zul: any suggestions where to look at?
[15:07] <lynxman> zul: I reckon this is one of those upstart scripts gone wrong bug
[15:07] <zul> lynxman:  no idea i would start stracing
[15:07] <lynxman> zul: the process lasts a second, I'll try to capture one
[15:07] <ikonia> how can it be eating your cpu if it only lasts a second
[15:07] <lynxman> ikonia: it's a fork bomb, a slow one though :)
[15:07] <ikonia> what ?
[15:08] <ikonia> it's a fork bomb in an init script....please
[15:08] <ikonia> lynxman: 1.) why do you think this is eating your cpu
[15:08] <lynxman> ikonia: you clearly don't understand what I'm looking at, stop being so agressive please
[15:08] <ikonia> 2.) how can something that spikes for a second be "eating your cpu"
[15:08] <ikonia> lynxman: just explain yourself then
[15:08] <ikonia> then we can work out what's going on
[15:08] <lynxman> ikonia: chillax ;)
[15:09] <ikonia> I am chilled
[15:09] <ikonia> I'm just asking you for information
[15:09] <lynxman> ikonia: that is not relevant to the problem
[15:09] <ikonia> it is
[15:09] <ikonia> 2.) what are you doing to measure/show this
[15:09] <ikonia> lynxman: 1.) why do you think this is "eating your cpu"
[15:09] <ikonia> 3.) how are you rationalising something that's spiking a cpu for a second as "eating" your cpu
[15:09] <ikonia> then we can understand the problem and move forward
[15:10] <lynxman> ikonia: no need for your help, thanks
[15:10] <ikonia> lynxman: then don't ask for help if you can't give basic information to help get it resolved
[15:11] <lynxman> ikonia: again, stop being so agressive, thank you very much
[15:11] <lynxman> zul: it's the mysql post-script respawning like crazy
[15:11] <lynxman> zul: acording to strace
[15:11] <ikonia> I'm not being agressive, stop wasting peoples time, if you ask for help then refuse to give information to help get it resolved
[15:11] <zul> SpamapS: ^^^
[15:12] <lynxman> zul, SpamapS: http://pastebin.ubuntu.com/923424/ (the script) http://pastebin.ubuntu.com/923425/ (the strace)
[15:12] <hallyn> jdstrand: gah!  as i'd feared, on a diff machine the 'info block' output through json is ordered differently
[15:13] <lynxman> ikonia: go have a tea and come back later when you acept not jumping to conclusions ;)
[15:13] <hallyn> so i'll make some more changes to go through piece by piece.  do you happen to know whether you cared about every one of those pieces?
[15:13] <lynxman> jdstrand: oh btw, I wanted to talk with you re puppet
[15:13] <ikonia> I'm not jumping to any conculsions, I'm asking for information
[15:13] <ikonia> lynxman: provide the information
[15:13]  * lynxman ignores ikonia for the time being
[15:14] <hazmat> hallyn, is /dev/log containerized.. i was noticing that the app armor profile prevents rsyslog from starting in an lxc container, but it appears to work okay if i disable the profile (no container messages in host)
[15:14] <zul> ikonia: seriosly?
[15:14] <hazmat> ikonia, that's a bit over the top
[15:14] <lynxman> ikonia: abusing power now, great
[15:15] <ikonia> lynxman: it's really simple, I'm asking you for information, if you don't want to give it that,s fine, just say "I don't know how to give it/don't want to give it" rather than coming up with nonsense about me jumping to conculsions and talking about fork bombs in init scripts
[15:15] <ikonia> lynxman: if you want help - ask for it and give information, to help people get it resolved
[15:16] <lynxman> ikonia: and zul has seen my issue and was already helping me solve this one while you were abusing me verbally, with all due respect
[15:16] <lynxman> zul, SpamapS: This could be the issue I reckon http://pastebin.ubuntu.com/923432/ looks like the upgrade from 5.1 to 5.5 was rocky
[15:16] <ikonia> lynxman: that's great, so all you need to say is "I think zul has it"
[15:16] <ikonia> lynxman: I'm not abusing you in the slightest, all I have done is asked you for information
[15:16]  * zul gets his popcorn out
[15:17] <zul> ikonia: and then you kicked him from the channel is not abuse at all
[15:17] <jdstrand> hallyn: bummer. not to hard to fix though with a for loop and search (the test-libvirt.py script should have examples, but others in qrt do too)
[15:17] <lynxman> ikonia: by not abusing you mean "kicking me out"
[15:17] <hazmat> hallyn, nm.. it looks like its just the app armor profiel that's causing the issue
[15:17] <ikonia> lynxman: then stop wasting peoples time
[15:17] <zul> ikonia: he wasnt thats the point sheesh
[15:17] <hallyn> jdstrand: yup, i'm looping
[15:18] <lynxman> ikonia: Was I wasting anyones time? I don't think I have, and I've been active in this channel for the last 1+ years
[15:18] <SpamapS> sorry what did I miss about the mysql post-start ?
[15:18] <ikonia> lynxman: the time you've spent active doesn't change anything
[15:18] <zul> SpamapS: seems to be eating up cpu cycles
[15:19] <SpamapS> ikonia: kick was over the top. Period.
[15:19] <lynxman> SpamapS: it cycles over and over and shows itself as a sh proc/self with a sleep 1
[15:19] <ikonia> SpamapS: you're welcome to your opinion
[15:19] <zul> ikonia: seriously dude it was very very over the top
[15:19] <lynxman> SpamapS: also looks like the mysql-server-5.1 package didn't finish deinstalling itself
[15:19] <ikonia> zul: that's great, thanks
[15:19] <SpamapS> ikonia: http://www.ubuntu.com/project/about-ubuntu/conduct "When we disagree, we consult others."
[15:19] <SpamapS> we don't kick them out of the channel.
[15:20] <ikonia> SpamapS: I wasn't disagreeing
[15:20] <zul> ikonia: you were being an ass
[15:20] <ikonia> zul that is uncalled for
[15:20] <SpamapS> lynxman: oh? mysql-server-5.5 breaks and replaces it, so apt should have fully removed it
[15:20] <zul> ikonia: well you were
[15:20] <ikonia> zul: do not insult people
[15:20] <lynxman> SpamapS: mysql-server-5.1 shows as rc
[15:21] <hallyn> hamzat: sorry, i missed your q
[15:21] <SpamapS> lynxman: probably a conffile that wasn't replaced by mysql-server-5.5
[15:21] <hallyn> hazmat: no, it is not.
[15:21] <zul> anyways im done with this
[15:21] <SpamapS> lynxman: can you pastebin dpkg -L of it?
[15:21] <lynxman> SpamapS: hmm let me try to stop and start the process again then, see where it stands, get some more logging
[15:21] <koolhead11> ikonia, kick was uncalled
[15:21] <lynxman> SpamapS: sure
[15:21] <hallyn> hazmat: rsyslogd running int he container will catch syslog(2) calls from userspace,
[15:21] <ikonia> koolhead11: I suggest you drop it
[15:21] <hallyn> hazmat: but the syslog system call is not containerized.  yet.  unfortunately
[15:22] <lynxman> SpamapS: http://pastebin.ubuntu.com/923442/
[15:22] <hazmat> hallyn, ic, thanks
[15:22] <hallyn> hamzat: how mcuh of a problem is that for you?
[15:23] <SpamapS> lynxman: whoa, lots more than I would have expected..
[15:23] <SpamapS> lynxman: looks though like the logcheck dir is a problem
[15:26] <lynxman> SpamapS: I can try to run the procedure again and see what it complains about
[15:26] <SpamapS> lynxman: still /etc/init/mysql.conf should belong to mysql-server-5.5 so thats not "the problem"
[15:26] <lynxman> SpamapS: yeah that's a secondary one, I do agree
[15:28] <lynxman> SpamapS: mysqld process won't stop either, it's stuck in the script :/
[15:28] <SpamapS> lynxman: I do see where the mysql upstart job needs to check for -x on mysqld and exit gracefully if its not there for the 'rc' state .. but you say mysql-server-5.5 is installed?
[15:28] <lynxman> SpamapS: yes, definitely installed
[15:28] <SpamapS> lynxman: mysqld may be in a state of flushing to disk...
[15:29] <SpamapS> that can take a long time
[15:29] <SpamapS> lynxman: what does 'status mysql' show ?
[15:29] <lynxman> SpamapS: ah yes finally it did :)
[15:29] <lynxman> SpamapS: just starting again, as soon as it's started I'll get you the status
[15:30] <SpamapS> lynxman: the post-start should only run once per respawn.. and if it respawns even remotely fast, upstart should give up on it because of the limit of 2 times in 5 seconds
[15:30] <hazmat> hallyn, well in this context it prevents juju from just using the ubuntu-cloud template as is so we can ditch our libvirt network usage and container customization shell script.. in particular because rsyslog fails to start in the container, cloud-init's config doesn't run, and juju relies on cloud-init to get the container initialized with juju... there's probably valid work arounds though including just leaving the implementation as is or adjusting
[15:30] <hazmat> the app armor profile.. i'm not terribly concerned with  the host isolation from the container as a result, as effectively this is already an issue.
[15:30] <lynxman> SpamapS: mysqld started and it's working, but upstart is not returning to prompt and again in the loop
[15:31] <SpamapS> lynxman: is mysqladmin --ping not working?
[15:31] <lynxman> SpamapS: nope :/ you reckon it's a permission problem?
[15:32] <SpamapS> its running as root, so no
[15:32] <SpamapS> unless
[15:32] <SpamapS> you removed the debian-sys-maint user
[15:33] <SpamapS> that will force mysqladmin ping to fail 30 times and then just give up with exit 1
[15:33] <hallyn> hamzat: rsyslog shouldn't fail to start ina container i don't think
[15:33] <hallyn> hazmat: are you running it in libvirt-lxc, or lxc-start?
[15:34] <lynxman> SpamapS: The user doesn't exist (debian-sys-maint) but never did on my system
[15:34] <lynxman> SpamapS: this is an upgrade straight from an oneiric default one
[15:34] <lynxman> SpamapS: doesn't create /var/run/mysqld/mysqld.sock I reckon that's the problem
[15:37] <hazmat> hallyn, lxc-start
[15:38] <hazmat> hazmat, if we could use the cloud template (which i think we could if we can get past this) there would be no more libvirt usage by juju.. we currently just use that for ancillary functionality to setup the network, which lxc precise already does atm
[15:39] <hallyn> hazmat: so just 'lxc-create -t ubuntu-cloud -n p1' should reproduce this?
[15:40] <hallyn> utlemming: ^ ring any bells?  (I will test as soon as i'm done with qrt)
[15:41] <utlemming> hallyn: I've confirmed yesterday that cloud-config doesn't start under lxc.
[15:42] <hallyn> utlemming: well fooi.  it used to.  wonder if apparmor is involved.
[15:43] <utlemming> hallyn: I was leaning towards apparmor as the cause yesterday, but I ran out of time to dig on it
[15:43] <hallyn> utlemming: ok, thanks for confirming.
[15:43] <utlemming> hallyn: apparmor is generally unhappy about a couple of things, like dhcp
[15:43] <hallyn> hazmat: do you mind opening a bug, mark it high or critical prio and confirmed?
[15:44] <hazmat> hallyn, sure
[15:46] <hazmat> hallyn, i reproduce with.. lxc-create -n cloud-unit-x -t ubuntu-cloud -- -r precise -S ~/.ssh/id_dsa.pub -u cloud_init.txt  .. but that's testing the end goal of cloud-init working, the cli invocation you had should reproduce the rsyslog issue, there's another bug that utlemming addressed with the cloud-template itself that needs a fix to be able to run -u..
[15:46] <hallyn> jdstrand: http://people.canonical.com/~serge/qrt-libvirt-precise-v2.patch just passed for me.
[15:47] <jdstrand> \o/
[15:47] <hallyn> but i still can't check it in :)
[15:48] <jdstrand> hallyn: you still have the _destroy_vm() in there. is that intended? if so, can you comment in the patch why it is needed?
[15:51] <hallyn> jdstrand: it's there bc self._run_qemu_command_and_kill_vm does it for us in teh other branch, so we need to
[15:51] <SpamapS> lynxman: debian-sys-maint is created on installation
[15:51] <SpamapS> lynxman: the socket is created when mysqld starts
[15:51] <SpamapS> lynxman: unless you change /etc/mysql/my.cnf
[15:52] <jdstrand> hallyn: in the other branch? you mean yours that you can't commit? can you give me one big patch to get this working for you?
[15:52] <hallyn> jdstrand: no,
[15:52] <hallyn> jdstrand: I mean if release < 12.04,
[15:53] <hallyn> if release > 12.04, we manually talk tot he monitor then kill the vm;  otherwise we call _run_qemu_command_and_kill_vm.  either way the tests expect the vm killed afterward
[15:53] <hallyn> so we have to kill it manually if release < 12.04
[15:53] <hallyn> uh, > 12.04
[15:53] <hallyn> i'll add a comment, then post v3, one sec
[15:54] <jdstrand> thanks
[15:54]  * jdstrand was just reading the diff
[15:54] <lynxman> SpamapS: hmm I'll see what I can do to fix, since my my.cnf has changed a bit I reckon this is not an issue that should be bug reportable then
[15:55] <hallyn> jdstrand: http://people.canonical.com/~serge/qrt-libvirt-precise-v3.patch
[15:58] <jdstrand> hallyn: thanks! committed
[15:59] <jdstrand> hallyn: not sure about the bzr issue-- we have usually kept our trees compatible with earlier releases, which might be a clue if you upgraded your side
[16:01] <adam_g> koolhead11: im not sure what keystone packages your using, ours do not create any of that stuff
[16:01] <koolhead11> adam_g, it was my fault. i realized that.
[16:01] <hallyn> jdstrand: upgraded which?  it's a new precise install (hd crash) if that's what you mean.  i didn't do anything to the bzr tree on purpose
[16:02] <hallyn> maybe i shou'dve tried in a lucid chroot
[16:02] <zul> Daviey: swift uploaded
[16:03] <jdstrand> hallyn: upgraded the tree. I'm using precise with the tree. I am not a bzr expert. I do know that bzr will sometimes ask you to upgrade to improve performance, etc. I was merely suggesting that if you did that, maybe that was the cause
[16:03] <hallyn> jdstrand: yeah i've seen that q before, but it didn't ask me that (and it's a fresh checkout).  <shrug>
[16:03] <jdstrand> hallyn: maybe just redownloading the tree would work, or asking in #bzr (iirc)
[16:03] <hallyn> jdstrand: thanks for pushing it!
[16:04] <jdstrand> np :)
[16:04] <jdstrand> hallyn: thanks for working on it :)
[16:04] <hallyn> jdstrand: oh!  maybe it's bc i did "bzr init-repo qrt; cd qrt; bzr branch lp:qa-regression-testing"
[16:04] <hallyn> maybe that forces the new format

[16:16] <hallyn> hazmat: thx for opening that bug
[16:28] <hallyn> hazmat: utlemming: stgraber: d'oh!  rsyslog isn't starting bc of /lib/init/apparmor-profile-load usr.sbin.rsyslogd in pre-start
[16:31] <lynxman> SpamapS: I think I found it, the debian-sys-maintainer user wasn't created because I had already some other users created and the dist-upgrade process, this looks like it stoped the mysql package from creating the debian sys maintainer user
[16:33] <SpamapS> lynxman: I hope to revamp the mysql packages entirely over the next 2 cycles. They're kind of ridiculously old fashioned and weird.
[16:33] <zul> SpamapS: im shocked that you called them old fashioned
[16:34] <roaksoax> smoser: do you have any fix to cobbler in a branch to be merged?
[16:34] <SpamapS> zul: sorry, "Old school"
[16:34] <roaksoax> smoser: or can I just go ahead and upload the fix for the tfpt bug
[16:34] <SpamapS> zul: or would you prefer "ridiculously out of date with modern packaging" ?
[16:34] <smoser> roaksoax, i just uploaded yesterday.
[16:34] <zul> SpamapS: back in my day we used magnest for packaging
[16:35] <roaksoax> smoser: ok ;)
[16:37] <SpamapS> zul: and speling?
[16:37] <zul> SpamapS: spelling wasnt taken into account
[16:48] <siert> on oneiric I have the issue that IPv6 stops working after about two minutes after the boot. I do have autoconf & ra disabled for 'default,all,eth0,lo' ... what could be the cause or what whould be a good starting point for research?
[16:53] <roaksoax> smoser: so distro-info --supported will also list the development release?
[16:53] <smoser> yes.
[16:53] <smoser> strangely
[16:53] <smoser> :)
[16:53] <roaksoax> smoser: hehe ok :)
[16:53] <smoser> it will do that in all of the 6 implementations available.
[16:54] <roaksoax> smoser: right, but I just wanna make sure that as soon as Q is out, it will automatically detect it
[16:54] <roaksoax> when doing --suppoerted
[16:57] <smoser> it shoudl, yes.
[16:57] <smoser> your maas-improt-isos logic...
[16:57] <smoser> you should look at that.
[16:57] <smoser> i'm kind of ocncerned about it failing and starting to use the development release... well, i didnt' really read it, but just be careful ther.e
[16:58] <ivoks> am i mistaken, or maas doesn't support multiple interfaces yet? it assumes it's running on eth0, right?
[16:58] <itgeo> hello guys, when i m trying to send email
[16:59] <itgeo> hello guys, when i m trying to send email from my webserver, its always failling. I can receive and send to people outside of my network
[17:00] <ivoks> itgeo: have you looked at the logs at all?
[17:01] <itgeo> ivoks: not yet but i have the undelivery message with me
[17:02] <ivoks> itgeo: then check the logs; you also haven't said which MTA you are using
[17:03] <itgeo> ivoks: I am using iRedMail give me 2min i have to connect to my server I am not at home
[17:04] <ivoks> i have no idea what iredmail is
[17:04] <ivoks> and it's not in the archives; not sure how to help you
[17:06] <itgeo> ivoks: its Postfix, Dovecot, Apache, MySQL, Amavisd, ROundcube, Awstats and Fail2ban
[17:07] <itgeo> ivoks: http://www.iredmail.org/
[17:07] <ivoks> what was wrong with mail-stack-delivery from ubuntu?
[17:09] <itgeo> ivoks: well here is what i received after 24h that i sent my mail from my gmail account http://paste.ubuntu.com/923611/
[17:10] <itgeo> and this one when i send a mail from my webserver to my gmail http://paste.ubuntu.com/923620/
[17:12] <hallyn> jdstrand: have you seen http://paste.ubuntu.com/923623/ with test-qemu.py?
[17:12] <hallyn> (trying reverting to older qemu-kvm to make sure...)
[17:13] <ivoks> itgeo: this is cause by your mail server configuration
[17:13] <ivoks> caused
[17:14] <itgeo> do you have any idea, because when i send<EMAIL_ADDRESS>to<EMAIL_ADDRESS>its working
[17:17] <ivoks> aliases probaby is broken
[17:17] <ivoks> so it doesn't know how to get username from<EMAIL_ADDRESS>[17:18] <gary_poster> hallyn, hey.  did you see my question from today, before you started, about us putting together a small "lxc-ip" script for the lxc package?
[17:20] <hallyn> gary_poster: no, i did not.
[17:20] <hallyn> is that to insert an ip into the container?
[17:20] <gary_poster> hallyn, no, to get the ip of a container.  it would extract the dhcp bit from lxc-start-ephemeral
[17:20] <hallyn> please feel free to open a bug.  do you have a patch by chance? :)
[17:20] <hallyn> hm
[17:21] <hallyn> gary_poster: is there any way you can do this another way, i.e. by querying yoru dhcp server?
[17:21] <hallyn> or preallocaing mac->ip in the dhcp server
[17:23] <gary_poster> hallyn, well, querying: I don't know of a way other than what we're doing, but I can investigate.  preallocating: the intent of the tool would be to help with arbitrary jobs on a container...a developer tool.  preallocating would be more constraining than what we're looing for
[17:23] <gary_poster> looking
[17:23] <gary_poster> the intent would be to abstract the querying question
[17:23] <gary_poster> we could implement it with the ugly grep now
[17:24] <gary_poster> and convert it to a query later
[17:24] <gary_poster> but being able to sat
[17:24] <gary_poster> say
[17:24] <gary_poster> "ssh `lxc-ip NAME`
[17:24] <gary_poster> "
[17:24] <gary_poster> is an example of the kind of convenience we are interested in
[17:25] <hallyn> gary_poster: I'm not opposed.  Perhaps we should ask stgraber (as the creator of our current dns setup in precise :) for ideas too
[17:26] <gary_poster> hallyn, cool.
[17:26] <hallyn> gary_poster: note that if we add '-q' to lxc's dnsmasq then we can get the ip addr from syslog
[17:26] <hallyn> but i don't see any way to send just the mapping to a file under /var/run/lxc
[17:26] <hallyn> gary_poster: I also don't know if it's too late to get this into precise.  did you want it there?
[17:26] <hallyn> (pretty sure it is, as it's a feature)
[17:27] <gary_poster> hallyn, yeah, I was wondering about that
[17:27] <hallyn> do you need it in precise?
[17:27] <gary_poster> it would be convenient, not necessary
[17:27] <gary_poster> we can add it to our own packages
[17:27] <hallyn> jdstrand: re-running got past those errors.  Now only a usb one.  I asssume taht's what you'd filed a bug for before?
[17:28] <hallyn> gary_poster: cool, thanks.  Yeah please open a bug.  Would be nice to "do it right".  WOudl be useful for non-ephemeral containers too.
[17:28] <hallyn> gary_poster: btw did you ever look at teh lxc server guide?
[17:29] <hallyn> it's only in the bzr branch so far as precise one hasn't been posted afaik
[17:29] <gary_poster> hallyn, cool.  useful for non-ephemeral: agree.  lxc server guide: no, I hadn't seen it.  http://people.canonical.com/~serge/lxc.serverguide.pdf ?
[17:30] <hallyn> gary_poster: it's merged into lp:serverguide.
[17:30] <gary_poster> hallyn, cool, will look at it.  thanks for pointer.
[17:30] <hallyn> (the one on p.c.c is probably out of date)
[17:31] <gary_poster> ack
[17:31] <hallyn> cool, I suspect you may have some helpful comments on better ways to do things.  thanks.
[17:33] <rbasak> SpamapS: bug 968753 please!
[17:34] <hallyn> that sounds bad
[17:37] <SpamapS> rbasak: so this is just an upload of openssl, not openssh, right?
[17:37] <rbasak> SpamapS: yes
[17:38] <rbasak> SpamapS: I wasn't sure what to do with the openssh bug task. I thought it might help people not file dupes
[17:38] <jdstrand> hallyn: sorry, was in a meeting. I have not seen that-- but it shouldn't happen unless a vm was still running in the bg
[17:38] <SpamapS> rbasak: sure, I thinkw e can mark that as Invalid though
[17:38] <rbasak> SpamapS: sure
[17:38] <hallyn> jdstrand: so you get 0 failures?
[17:38] <rbasak> SpamapS: or should I have changed the existing bug task to openssl instead, rather than adding a new one?
[17:39] <hallyn> re-running right now, but i think it was usb camera that caused the error?
[17:39] <jdstrand> well, let me try. I haven't done it in a long time (haven't prepared an qemu uploads)
[17:39] <SpamapS> rbasak: no its cool to show the Invalid to make it clear that openssh is a red herring
[17:39] <jdstrand> virsh list
[17:40] <jdstrand> heh
[17:41] <rbasak> SpamapS: ok, thanks!
[18:33] <hallyn> jjohansen: stgraber: any input on bug 978147?  should we just allow the transition?  or ask rsyslog to not do it in a container?  or create a container-rsyslog domain and ask it to enter that?
[18:36] <jjohansen> hallyn: hrmmm, for this cycle, I would try to keep the diff down so probably just ignore.
[18:37] <stgraber> hallyn: is there any good reason to prevent rsyslog from starting when apparmor fails to load the profile?
[18:37] <stgraber> hallyn: if not, I'd drop the pre-start, move the apparmor-profile-load to script and add a || true after it
[18:37] <jdstrand> rsyslog should not have an enforcing profile
[18:37] <stgraber> hallyn: that'll even save an extra fork from upstart (as it won't need a pre-start then)
[18:38] <hallyn> hm
[18:38] <hallyn> jdstrand: oh?
[18:38] <jdstrand> stgraber, hallyn: it is supposed to be disabled on boot since /etc/apparmor.d/disable/usr.sbin.rsyslog should exist
[18:39] <hallyn> interesting
[18:39] <hallyn> jdstrand: ok so there's probably a bug that prevented that link being made (i'll check) but meanwhile,
[18:39] <hallyn> what straber suggests is even more useful in that case then right?
[18:39] <jjohansen> jdstrand: hrmm, I have it loading here, in complain mode
[18:40] <jdstrand> jjohansen: it doesn't load in a vm here
[18:40] <hallyn> my laptop has it unconfined
[18:40] <hallyn> wonder if postinst does anything "interesting"
[18:40] <jdstrand> /var/lib/dpkg/info/rsyslog.postinst
[18:42] <jdstrand> $ sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd ; echo $?
[18:42] <jdstrand> Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
[18:42] <jdstrand> 0
[18:42] <jdstrand> but that is postinst, not /lib/init/apparmor-profile-load
[18:43] <hallyn> jdstrand: so what should be setting the disalbed link?  i don't see it in the package (rules/postinst)
[18:43] <jdstrand> the upstart job was modified to use /lib/init/apparmor-profile-load (like we normally do) in case the user wanted to enable it
[18:43] <hallyn> oh preinst
[18:45] <jdstrand> (that is standard procedure)
[18:47] <hallyn> jjohansen: /etc/apparmor.d/disable/usr.sbin.rsyslogd exists.  here is the console output from start: http://paste.ubuntu.com/923775/
[18:48] <jdstrand> fyi:
[18:48] <jdstrand> $ sudo /lib/init/apparmor-profile-load usr.sbin.rsyslogd  ; echo $?
[18:48] <jdstrand> Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
[18:48] <jdstrand> 0
[18:48] <hallyn> there are complaints about inability to write to /sys/kernel/security/apparmor/.replace
[18:49] <hallyn> jdstrand: jjohansen: http://paste.ubuntu.com/923780/
[18:49] <hallyn> (in a container)
[18:49] <sbeattie> hallyn: yes, rsyslog gets skipped correctly, but tcpdump and and dhclient are failing due to permissions.
[18:49] <jdstrand> it is the tcpdump profile that is the problem
[18:49] <jdstrand> (and dhclient, like sbeattie said)
[18:49] <jjohansen> yep
[18:49] <hallyn> they are a problem, see http://paste.ubuntu.com/923780
[18:49] <jdstrand> we ship default enforcing profiles for those
[18:49] <hallyn> s/,/, but/
[18:50] <jdstrand> hallyn: can you sudo sh -x /lib/init/apparmor-profile-load usr.sbin.rsyslogd
[18:50] <jdstrand> it is probably failing on this line:
[18:50] <jdstrand> [ -w $aafs/.load ]           || exit 1 # fail if cannot load profiles
[18:51] <hallyn> jdstrand: http://paste.ubuntu.com/923785/
[18:51] <jdstrand> ah, the next one down
[18:51] <hallyn> hm.  that shouldn't be -eperm
[18:52] <jdstrand> that translates to /sys/module/apparmor/parameters/enabled
[18:52] <hallyn> ok, our profile has
[18:52] <hallyn>   deny @{PROC}/sys/kernel/** wklx,
[18:52] <hallyn> but i'd think read would be allowed.  do we need x?
[18:53] <jjohansen> hallyn: no
[18:53] <jjohansen> hallyn: err, no read shouldn't need x, and directory traversal x is different than apparmor x
[18:54] <hallyn> do i need CAP_MAC_ADMIN for that?
[18:54] <hallyn> i can't read any files under /sys/module/apparmor/parameters
[18:54] <hallyn> nothing in syslog
[18:55] <jjohansen> hallyn: CAP_MAC_ADMIN should not be needed for enabled, but is needed for some of the other files
[18:56] <hallyn> i suspect it just has to do with my hacky /sys/fs/cgroup set of deny's
[18:56] <hallyn> but i don't understand why
[18:56] <jjohansen> hallyn: if you suspect apparmor is denying it set audit to noquiet
[18:57] <B14CKB0X> Can someone help me? How to do to keep MAC address after a reboot of ubuntu server 11.04?
[18:57] <jjohansen>   echo -n "noquiet" > /sys/modules/apparmor/parameteres/audit
[18:57] <jjohansen> err make that /sys/module/apparmor/parameters/audit
[18:57] <hallyn> will do - but can i suggest that apparmor-parser-load should return success if a prfile is disabled, even if it can't check apparmor's enabled status? :)
[18:58] <jjohansen> hallyn: yeah that does sound reasonable, jdstrand^
[18:58] <patdk-wk> B14CKB0X, how did you *loose* the mac address?
[18:59] <hallyn> jjohansen: still no audit msgs, so maybe it's not apparmor!
[18:59] <B14CKB0X> just need to replace it with a certain order to use Internet
[18:59] <hallyn> GAH!  jsut powered off the instance istead of the container
[18:59] <jjohansen> hallyn: well barring bugs any way :/
[19:00] <hallyn> jjohansen: going to try with all capabilities
[19:00] <B14CKB0X> and then restart each time you need to switch to an internet
[19:00] <jdstrand> jjohansen: so we short-circuit /lib/init/apparmor-profile-load right after '[ -z "$1" ]'?
[19:00] <hallyn> eah that did it
[19:00] <jjohansen> jdstrand: yeah I think so
[19:01] <hallyn> jjohansen: either cap_mac_admin or cap_sys_module is needed
[19:01] <jdstrand> jjohansen: seems reasonable to me. sbeattie-- can you add that to your list of things to do for the next apparmor upload
[19:01] <jjohansen> hallyn: okay, that is a bug then :(
[19:01] <jdstrand> hallyn: can you file a bug and assign it to sbeattie?
[19:01] <jjohansen> hallyn: release critical?
[19:01] <jdstrand> hallyn: the bug I am referring to is for the short-circuiting
[19:02] <jjohansen> hallyn: I might be able to sneak a release critical kernel patch in today, otherwise we are waiting for the post release sru
[19:02] <hallyn> sys_module is needed
[19:02] <jjohansen> hallyn: the userspace portion can go in today
[19:02] <hallyn> jjohansen: i think so.
[19:02] <hallyn> jdstrand: oh
[19:02] <jdstrand> jjohansen: is the userspace portion even needed with your kernel side fix?
[19:02] <hallyn> jdstrand: ok, will do
[19:03] <jdstrand> hallyn: well, hold on
[19:03] <hallyn> jdstrand: not needed for this particular problem.
[19:03] <hallyn> though seems sensible...
[19:03] <jdstrand> well-- maybe
[19:03] <hallyn> but, under time crunch, ... i'll hold off :)
[19:03] <jdstrand> it mean it does exit 0
[19:03] <jdstrand> s/^it/I/
[19:04] <jdstrand> and would with the kernel fix
[19:04] <jjohansen> jdstrand: hrmm, well no, iff and thats a big if I can get the patch in, as kt already asked me if I had release critical kernel patches and I said no
[19:04] <jdstrand> jjohansen: well, this would only fix rsyslog-- there is still dhclient and tcpdump
[19:04] <jdstrand> jjohansen: so seems the kernel side is the real fix, no?
[19:04] <jjohansen> jdstrand: but the userspace change should go in regardless because there are other reasons that access may be blocked
[19:05] <hallyn> jdstrand: those will need package updates.  different problem
[19:05] <jjohansen> jdstrand: uh, those failing to load won't be fixed
[19:05] <jdstrand> jjohansen: yeah, but the userspace side only fixes disabled profiles...
[19:05] <hallyn> right.  but if the package insists it needs an enabled profile, then there is no fix we can do in precise for it
[19:05] <jjohansen> jdstrand: they can't load because there is no CAP_MAC_ADMIN granted, because the container can not load policy
[19:05] <hallyn> i'm about to open bugs for dhclient and tcpdump btw
[19:06] <jdstrand> I'm wondering why this was only noticed just now?
[19:06] <jjohansen> hallyn: right we need a fix for that, but the only thing the kernel could do would be silently fail profile loads, which isn't good either
[19:07] <jdstrand> hallyn: you could file those, been then you would have to for everything that ships a profile, no?
[19:07] <hallyn> jjohansen: or lxc could be allowed to transition
[19:07] <jdstrand> tcpdump does not use /lib/init/apparmor-profile-load
[19:07] <hallyn> to those
[19:07] <hallyn> jdstrand: yup
[19:07] <jdstrand> it is loaded by the initscript
[19:08] <jdstrand> this seems incredibly late to be changing 15+ packages
[19:08] <jjohansen> hallyn: lxc could be allowed to transition?
[19:08] <hallyn> jjohansen: to dhclient profile, yes
[19:09] <jjohansen> hallyn: sure it could be allowed to transition, by adding that in the profile but I thought the problem was the other profiles failing to load.
[19:09] <jdstrand> hallyn: does 'sudo /etc/init.d/apparmor start' exit non-zero?
[19:10] <hallyn> jdstrand: http://paste.ubuntu.com/923819/
[19:10] <hallyn> jjohansen: well, actually, it's not a problem.  dhclient runs fine :)
[19:10] <hallyn> so let's forget about that and just focus on rsyslog/disabled
[19:10] <hallyn> (sorry)
[19:11] <hallyn> jjohansen: jdstrand: so sorry, should i open a bug for the kernel piece?  or is that handled?
[19:11] <jdstrand> wouldn't it be better to have something in /lib/init/apparmor-profile-load and /etc/init.d/apparmor to exit 0 if it is running under lxc?
[19:11] <hallyn> should i be on #ubuntu-harded for this?
[19:12] <hallyn> jdstrand: we could do that for now, but eventually of course we'll want to re-enable it
[19:12] <jjohansen> hallyn: I haven't opened a bug yet, I was thinking of opening one with a kernel and userspace component
[19:12] <hallyn> when we have stacked profiles
[19:12] <jdstrand> hallyn: well, eventually containers will be able to load profiles, iiuc
[19:12] <hallyn> right
[19:12] <jdstrand> yeah, so this is just for precise
[19:13] <hallyn> if we do that for precise,
[19:13] <hallyn> and we fix the kernel for disabled profiles,
[19:13] <hallyn> will rsyslog still fail to start then bc now the profile is unknown?
[19:13] <hallyn> or will it check the disabled file inuserspace first
[19:13] <jdstrand> I guess rsyslog is failing because /lib/init/apparmor-profile-load is exiting non-zero
[19:14] <hallyn> right, which right nwo is bc it can't check if apparmor is enforcing,
[19:14] <jdstrand> if we adjsut /lib/init/apparmor-profile-load to exit 0 if in lxc, then it should work fine
[19:14] <hallyn> yes
[19:14] <jdstrand> /etc/init.d/apparmor would fail later
[19:14] <hallyn> ok.  should i open a bug for /etc/init.d/apparmor to do nothing in lxc?
[19:14] <hallyn> (and submit a patch)?
[19:14] <jdstrand> and anything upstartified with an apparmor profile would fail
[19:15] <hallyn> more than it does now?
[19:15] <hallyn> we knew there would be thinkgs we couldn't do in precise w/out stacked profiles, but the point was that things can run contained by container profile, and not by their own profile
[19:16] <jdstrand> hallyn: well, it depends on the upstart job. but if the upstart job doesn't have '|| true' after apparmor-profile-load <foo>, then yeah, it would fail exactly like rsyslog
[19:16] <hallyn> unless we disable the profile
[19:16] <jdstrand> hallyn: you mean lxc just adds the symlinks automatically?
[19:17] <hallyn> no not really :)  just thinkin
[19:17] <hallyn> i prefer to have apparmor-profile-load do nthing in container
[19:18] <jdstrand> jjohansen, sbeattie: what do you think of apparmor-profile-load and /etc/init.d/apparmor exiting 0 if inside a container for now? it seems to make sense since apparmor doesn't do profiles in a container well now anyway. this would be removed when apparmor does support that
[19:18] <hallyn> and then we'd need no other fixes at all in precise?
[19:19] <jjohansen> right now that looks like the best solution
[19:19] <hallyn> Note I expect other things to break due to the inability to read /sys/module/apparmor/**
[19:20] <hallyn> but at least ubuntu-cloud containers should work then
[19:20] <sbeattie> jdstrand: yes, that should be okay, I think.
[19:21] <jdstrand> hallyn: if we change apparmor-profile-load and /etc/init.d/apparmor, I would be surprised if anything else broke-- nothing should be fiddling around in /sys/module/apparmor/** typically
[19:21] <jdstrand> sbeattie: would you be able to incorporate tested patches from hallyn in your next upload?
[19:22] <jjohansen> jdstrand: we can do that if we delay the upload to tomorrow
[19:22]  * jdstrand doesn't particular care when the upload happens, so long as it is before final freeze
[19:22] <hallyn> note i'm ducking out soon for kid's practice
[19:22] <jjohansen> jdstrand: okay, lets plan for tomorrow and I can test tonight
[19:22] <hallyn> ok
[19:23] <jdstrand> hallyn: ok, can you file a bug, then supply tested patches updating apparmor-profile-load and /etc/init.d/apparmor?
[19:23] <mistica> holaaaaaaaa
[19:23] <jdstrand> jjohansen: well, I was hoping hallyn would do most of the testing :)
[19:23] <mistica> ;)
[19:23] <jdstrand> but whatever you guys decide
[19:23] <hallyn> jdstrand: should i re-use bug 978147 and mark it affecting apparmor?
[19:23] <hallyn> or do you prefer a new bug?
[19:24] <jdstrand> hallyn: that seems fine. I think you might want to make the title more general
[19:24] <mistica> bye
[19:24] <mistica> ¡¡
[19:24] <hallyn> ok.  thanks.  will hop to.  ttyl :)
[19:25] <jjohansen> jdstrand: well sure if hallyn can do testing great but /me and still need some time and I would like to give it at least a once over in both a container and outside, just to make sure we didn't break something
[19:25] <jdstrand> jjohansen: absolutely :)
[19:25] <hallyn> hm, i'll create a new bug
[19:28] <hallyn> hm, one q
[19:28] <hallyn> jdstrand: jjohansen: note that users can have containers run unconfined and with CAP_MAC_ADMIN
[19:29] <hallyn> do we accomodate that with complicated checks, or just say "if in a container, no apparmor loads' ?
[19:29] <jjohansen> hallyn: for now I am think just if in a container, no apparmor loads
[19:31] <hallyn> ok thanks
[19:32] <hallyn> opened bug 978297
[19:32] <hallyn> Daviey: can you add release tags to that?
[19:35] <balachmar> I am trying to setup postfix using gmail relay. Following this guide: https://help.ubuntu.com/community/GmailPostfixFetchmail
[19:35] <balachmar> echo 'test mail' | mail -s 'testing this'<EMAIL_ADDRESS>works fine, however, sendmail -bv<EMAIL_ADDRESS>does not
[19:36] <guntbert> balachmar: in what ways does it not work? What do the logs tell you?
[19:38] <balachmar> guntbert: It seems to be creating the connection  setting up TLS connection to smtp.gmail.com[<IP_ADDRESS>]:587
[19:38] <balachmar> status=deliverable (250 2.1.5 OK m55sm1243768eei.1)
[19:39] <balachmar> uberNAS postfix/local[4554]: 7191354CF8: to=<myUserName@localhost>, relay=local, delay=0.45, delays=0.11/0/0/0.34, dsn=2.0.0, status=sent (delivered to mailbox)
[19:39] <guntbert> balachmar: mind you, I have no great knowledge about this configuration (and my last mail sever was configured severl years ago...)
[19:40] <balachmar> So it seems that it (also) delivers something (other id?) to the local mailbox
[19:40] <balachmar> No worries, any help or thinking is appreciated
[19:41] <guntbert> balachmar: the "delay" is an over all value ( if I remember correctly )
[19:41] <balachmar> yeah, put I don't think that is a problem. as long is it is not 0.45 hours :)
[19:42] <guntbert> balachmar: in my experience it doesn't pay to obfuscate account names and the lot in a support dialog
[19:43] <balachmar> point taken :)
[19:43] <balachmar> but aren't these logs also logged somewhere?
[19:44] <guntbert> !logs
[19:45] <guntbert> but still - 1) there is the extra effort  2) we cannot know if you hide just the crucial error :)
[19:48] <hallyn> stgraber: can you remind me, did we decide that inuserspace it's ok to just [-f /run/container_type ], or that we should use /bin/running-in-container?
[19:50] <stgraber> hallyn: I think it's more likely for us to keep running-in-container in the few next releases than /run/container_type, so running-in-container is safer
[19:50] <hallyn> stgraber: too bad, was hoping to reduce forking :)
[19:50] <hallyn> ok thanks, will do that
[19:50] <hallyn> actually hopefully this hack will be dropped after precise, but still
[19:51] <balachmar> guntbert: Well I now found out some more. It just seems to be a problem with checking if it should be delivered locally or externally. logcheck is now able to send mails successfully
[19:51] <balachmar> guntbert: And that was my main goal :)
[19:52] <stgraber> hallyn: you could use the horribly ugly:
[19:52] <stgraber> exit() { echo $*; }
[19:52] <stgraber> . /bin/running-in-container
[19:52] <stgraber> saves the fork ;)
[19:52] <guntbert> balachmar: fine - so sometimes a few questions from a "helper" can lead to the right answers from yourself - congrats
[19:53] <hallyn> stgraber: hm.  pass, thanks :)
[19:53] <balachmar> guntbert: Yes, that is what I meant with thinking :)
[19:53] <hallyn> dash messes me up enough as it is
[19:54] <gary_poster> zul or adam_g are you around for a question about openstack dns names?
[19:55] <zul> kind of
[19:57] <gary_poster> zul, thanks.  In canonistack, it would be great to have dns names reported as *.canonistack.  IS changed nova.network.linux_net's dhcp_domain value (/etc/nova/nova.conf:--dhcp_domain=canonistack), which did part of the job it seems.  However, publicDnsName and privateDnsName now have no suffix at all.
[19:58] <gary_poster> (as opposed to, say, *.novalocal)
[19:58] <gary_poster> we need the *.canonistack to be reported properly in the dns names.
[19:58] <zul> gary_poster: right i think it might be something to do with dnsmasq, you might want to talk to canonical-is people
[19:59] <gary_poster> zul, they did not know and sent me out to do research.  Any other ideas on people to ask?
[20:00] <zul> gary_poster: i think it might be openstack specific but ill have a look
[20:00] <gary_poster> thanks
[20:08] <TylerWhitney> Someone feel like helping me with pptp server?
[20:09] <RoyK> TylerWhitney: server? why do you use it for?
[20:09] <RoyK> !ask
[20:11] <TylerWhitney> Using Ubuntu and install pptp vpn server; mainly to connect to a samba share/internal site on it; works great for those purposes, but cannot connect to the internet through the vpnm
[20:12] <TylerWhitney> tried iptables -t nat -A POSTROUTING -s <IP_ADDRESS>/24 -j SNAT --to-source P.P.P.P where P is my public IP and <IP_ADDRESS> is the network of IPs the pptp gives out via dhcp
[20:12] <TylerWhitney> no avail
[20:14] <TylerWhitney> oh, also, fwiw I also tried editing /etc/ppp/pptp-config and uncommenting ms-dns and giving it a dns server there as well
[20:30] <hallyn> jjohansen: i'm about to run out, but i'm having success in containers with
[20:30] <hallyn> lp:~serge-hallyn/ubuntu/precise/apparmor/apparmor-apparmor-container/
[20:30] <hallyn> and
[20:30] <hallyn> lp:~serge-hallyn/ubuntu/precise/upstart/upstart-apparmor-container/
[20:30] <hallyn> bbl
[20:30] <jjohansen> hallyn: okay thanks
[21:23] <itgeo> hello guys, i need help to set my webserver. I m using iRedmail (its Postfix, Dovecot, apache, mysql, Amavisd, ROundcube, Awstat Fail2ban). In Intranet its working but its not working outside of my network. I cant send email to my gmail account and I cant receive mails on my gmail account from my mailserver
[21:38] <itgeo> hello guys, i need help to set my webserver. I m using iRedmail (its Postfix, Dovecot, apache, mysql, Amavisd, ROundcube, Awstat Fail2ban). In Intranet its working but its not working outside of my network. I cant send email to my gmail account and I cant receive mails on my gmail account from my mailserver
[21:40] <patdk-wk> itgeo, what is your domain?
[21:41] <itgeo> patdk-wk, itgeo.info
[21:42] <patdk-wk> not good
[21:42] <patdk-wk> ubuntu.itgeo.info doesn't exist
[21:42] <patdk-wk> therefor, no email :)
[21:42] <itgeo> ubuntu.itgeo.info is my hostname
[21:42] <patdk-wk> that doesn't matter at all
[21:42] <patdk-wk> I am unable to locate it
[21:43] <patdk-wk> therefor the internet is unable to locate it
[21:43] <patdk-wk> therefor no one can send email to you
[21:43] <patdk-wk> fix your dns
[21:43] <patdk-wk> what ip address should it be? and I can keep looking for more issues
[21:44] <itgeo> patdk-wk <IP_ADDRESS>
[21:45] <itgeo> its because i set ubuntu.itgeo.info as cname, now i set it as dns host
[21:45] <patdk-wk> ya, cname isn't valid to be reused in other dns entries
[21:46] <patdk-wk> next issue would be your isp
[21:46] <patdk-wk> they block incoming port 25
[21:47] <itgeo> patdk-wk oh ok ok :S i unlocked it from my modem it surprise me
[21:47] <patdk-wk> lots of isp's block it
[21:47] <patdk-wk> normally cause they are blocking outgoing port 25
[21:47] <patdk-wk> but sometimes they actually do mean to block incoming too
[21:48] <patdk-wk> or maybe they aren't and something else is
[21:48] <itgeo> oh ok ok
[21:48] <patdk-wk> but I can't connect to you on port 25
[21:48] <patdk-wk> so either your isp is blocking it
[21:48] <patdk-wk> or your firewall or postfix isn't working right
[21:48] <itgeo> I didnt set a postfix policyd is it because of that ^
[21:49] <itgeo> i dont have the file /etc/postfix-policyd.conf
[21:49] <patdk-wk> heh? that is a totally different program
[21:49] <patdk-wk> that isn't related to postfix
[21:50] <itgeo> oh ok ok
[21:51] <itgeo> i though it would be because of that because i even dont know how to turn off the greylist
[21:54] <RoyK> http://lwn.net/Articles/491516/ <-- oops
[21:54] <RoyK> any idea if there's a fix available for that yet?
[21:54] <patdk-wk> royk, making the channel rounds? :)
[21:54] <RoyK> patdk-wk: had to ask here...
[21:54] <patdk-wk> I haven't seen anything yet
[21:55] <RoyK> patdk-wk: I have rather a lot of ubuntu servers
[21:55] <RoyK> not too many with samba, though
[21:55] <RoyK> but that crappy old s10 machine with samba from the bronze age may need an upgrade...
[22:00] <patdk-wk> royk, nothing about it in launchpad yet, so that includes ppa's too
[22:01] <patdk-wk> probably be done tomorrow would be my guess
[22:01] <patdk-wk> kind of late for eu today
[22:01] <RoyK> well, it just turned wednesday...
[22:02] <RoyK> I doubt a samba root exploit will make me stay awake
[22:02] <patdk-wk> heh, I have 1 samba server
[22:02] <patdk-wk> and if someone gets root, they won't get anything they don't already have
[22:03] <patdk-wk> nothing on that server except samba
[22:04] <RoyK> nite
[22:09] <itgeo> the port 421 is smtp+ssh right ?
[22:10] <patdk-wk> nope
[22:11] <patdk-wk> mail only uses two ports, port 25 for incoming email
[22:11] <patdk-wk> and port 587, for user submitted email
[22:13] <itgeo> ok so i guess i have to use 2525 for smtp
[22:14] <itgeo> i have a timeout exceeded when i use telnet on my domain
[22:15] <itgeo> and the port is blocked by my isp even if i have the option to unlock it from my modem
[22:20] <itgeo> patdk-wk my isp is not blocking 587, do you think i can use it instead of 25 ^
[22:20] <adam_g> zul: did swift get accepted?
[22:48] <Patrickdk> itgeo, for incoming email? from that use a domain other than yours? no
[22:51] <zul> adam_g: not yet...daviey hasnt accepted it yet
[22:52] <itgeo> I m sent a mail from my gmail account to my domain mail and its the same, i didnt receive it Patrickdk
[22:52] <Patrickdk> well, is gmail you? therefor it REQUIRES port 25
[22:53] <itgeo> well my webserver is itgeo.info<EMAIL_ADDRESS>to<EMAIL_ADDRESS>its working. but<EMAIL_ADDRESS>to<EMAIL_ADDRESS>is not working :S
[22:53] <Patrickdk> like I said
[22:54] <Patrickdk> IF the email is coming from someone OTHER than your domain, it won't work, without port 25
[22:54] <Patrickdk> fix port 25, or no email :)
[22:54] <Patrickdk> port 25 is REQUIRED for email to work, port 587 is OPTIONAL
[22:55] <itgeo> i uncommented the line submission inet n       -       -       -       -       smtpd
[22:55] <itgeo>  in /etc/postfix/master.cf to make it work on 587 but looks like its not working
[22:56] <Patrickdk> like what isn't working?
[22:56] <Patrickdk> I can connect to it fine
[22:56] <zul> adam_g: accepted now
[22:56] <itgeo> the port is open but i have a time out
[22:56] <Patrickdk> but that port, submission/587 is only for use by YOU, not anyone else
[22:57] <itgeo> oh
[22:57] <Patrickdk> only people with mail accounts on YOUR mailserver will ever use that port
[22:57] <itgeo> oh ok ok
[22:57] <Patrickdk> for people OTHER than your and your users, port 25 is required
[22:58] <itgeo> so the port 25 MUST be open
[22:58] <Patrickdk> to receive email, yes
[22:58] <itgeo> is there a way i can change it for another port or make a port redirect ^
[22:58] <Patrickdk> no
[22:58] <Patrickdk> if you did, it wouldn't be port 25
[22:59] <itgeo> ok, so i have to get mailbox option in a compagny or a vps to make it work ?
[23:03] <Patrickdk> pretty much
[23:03] <Patrickdk> or find someone that will forward the email to you
[23:03] <itgeo> what do you think about mail reflector from no-ip http://www.no-ip.com/support/guides/email/blocked_port_25.html
[23:05] <itgeo> sorry here is the right link http://www.no-ip.com/services/managed_mail/inbound_port_25_unblock.html


[01:00] <vex> can anyone help me understand why this upload failed? https://launchpadlibrarian.net/136200636/upload_4468458_log.txt
[01:01] <StevenK> What's your Component line in your control file?
[01:02] <vex> :/ I don't have a Component line
[01:02] <wgrant> It's part of the Section line
[01:02] <wgrant> It looks like you have "Section: 9.0/something"
[01:02] <StevenK> Which is bong
[01:02] <wgrant> Oh
[01:02] <wgrant> That's parsing a changes file
[01:02] <vex> 9.0/libdevel
[01:02] <StevenK> vex: Yes, don't do that.
[01:02] <wgrant> vex: What's that 9.0 doing therE?
[01:02] <vex> for.. the dev package.
[01:03] <vex> right
[01:03] <StevenK> wgrant: Yeah, dpkg will helpfully just put whatever you have in the .changes
[01:03] <wgrant> 9.0 is a version, not a component
[01:03] <wgrant> Usually you'd omit the component from the control file
[01:03] <StevenK> Soyuz is strict about it
[01:03] <wgrant> So just "Section: libdevel"
[01:03] <vex> idk why it's there. I'll remove it.
[01:03] <vex> thanks :)
[04:41] <TheLordOfTime> can someone provide me a sample dput.cf entry for PPAs?  my dput.cf went and poofed itself into nonexistence.
[04:48] <wgrant> TheLordOfTime: The default Ubuntu dput.cf has everything you need
[04:48] <tsimpson> TheLordOfTime: you can just use a ppa url with dput ppa:<lp_username>/<ppa>
[04:48] <wgrant> dput ppa:USER/PPA whatever.changes
[04:49]  * TheLordOfTime shrugs
[09:59] <wgrant> Launchpad's about to go offline for a minute or so for a database upgrade.
[10:03] <wgrant> And it's all back.
[10:14] <chrisccoulson> i guess that is what caused the upload failure here? https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/4469127
[10:22] <wgrant> chrisccoulson: Hm, indeed. I guess the timing must have been terrible, since the DB was back by the time it tried to record the error.
[10:22] <wgrant> A retry will work.
[10:45] <zequence> wgrant: Sure it's back? We're unable to login here..
[10:47] <wgrant> zequence: An unrelated issue with Ubuntu SSO has just sprung up, it seems. It's being fixed.
[10:47] <smartboyhw> wgrant, thanks
[10:47] <czajkowski> SSO != Launchpad
[10:48] <zequence> I see
[10:48] <smartboyhw> czajkowski, well we don't know whether the sso is a problem to Launchpad...
[10:48] <wgrant> Well
[10:48] <wgrant> SSO is used to log into Launchpad
[10:48] <smartboyhw> Anyway, thanks for the notice:)
[10:48] <wgrant> So if you're not already logged in, it needs to be up :)
[10:48] <czajkowski> it's also used to log into a lot of things
[10:48] <smartboyhw> wgrant, czajkowski is there a channel to ask about SSO
[10:48] <smartboyhw> ?
[10:48] <czajkowski>  #canonical-isd
[10:49] <wgrant> Sysadmins are on it already
[10:49] <smartboyhw> czajkowski, :)
[10:49] <smartboyhw> wgrant, wow thanks
[10:52] <wgrant> smartboyhw, zequence: Should be fixed.
[10:53] <smartboyhw> wgrant, yeah
[10:54] <smartboyhw> OK confirming that it works now
[10:54] <smartboyhw> Thanks wgrant and czajkowski
[18:57] <bac> BjornT_: i just reviewed your last branch.  Thanks for all of the contributions!
[19:06] <czajkowski> oh bac how are things
[19:18] <bac> czajkowski: good.  i suspect you don't want to hear about the weather.  :)
[19:22] <czajkowski> bac: would you believe it's warmer in ireland than it is in the UK am frozen to the bone here since I got back last night
[19:22] <czajkowski> bac: not seen dog shots in ages, please fix :)
[19:22] <bac> czajkowski: yes, i think i'd believe that.
[19:22] <bac> czajkowski: weimphotos?  that i can do.
[19:23] <czajkowski> \o/
[19:23] <czajkowski> I'm dealing with chickens here, they are not the same
[19:23] <czajkowski> noisy beggers
[19:28] <bac> czajkowski: done
[19:29] <bac> czajkowski: and even one with giant attack chickens
[19:29] <czajkowski> oh nice
[19:29] <czajkowski> never seen such a grown dog stick it's tongue out before
[19:30] <czajkowski> it's like he's been told off for something and he's having non of it


[12:19] <bradb_> kiko: I do feel a certain urgency, I think, to moving events into the db, fwiw.
[12:20] <bradb_> considering that i just put xmlrpc up for review, etc.
[12:20] <bradb_> which is another client that publishes the event, and that's generally evil
[12:24] <kiko> my point exactly
[12:24] <bradb_> pastebin seems to be 404'ing, so i'll email the patch
[12:25] <kiko> sure
[12:25] <bradb_> sent
[12:26] <flacoste> nice week-end everybody!
[12:26] <bradb_> interestingly, this would also remove a huge amount of manual notify()'s from our tests as well
[12:27] <kiko> heh
[12:30] <kiko> bradb_, that assert is confusing.
[12:30] <kiko> and PQM is @#!@$! sandbagging me.
[12:30] <kiko> wtf is up with PQM
[12:30] <kiko> no failure
[12:30] <kiko> nothing
[12:31] <bradb_> kiko: it takes time sometimes
[12:31] <kiko> hmmm.
[12:31] <bradb_> though sometimes it doesn't :P
[12:31] <kiko> I think the merge is failing
[12:31] <kiko> http://pqm.launchpad.net/
[12:31] <bradb_> kiko: ok, so how can i improve the assert?
[12:31] <kiko> cleaning working directory
[12:31] <kiko> Executing star-merge sftp://chinstrap.ubuntu.com/home/warthogs/archives/kiko/launchpad/trivialities-xx/ at Fri Jul 14 23:10:33 2006
[12:31] <kiko> cleaning working directory
[12:31] <kiko> let me look at the code first
[12:32] <kiko> bradb_, okay, remove the assert, it's silly.
[12:32] <kiko> I was thinking something that obviously doesn't hold true in this situation
[12:33] <bradb_> removed!
[12:33] <kiko> yeah
[12:33] <kiko> patch is fine, r=kiko
[12:33] <kiko> nice work.
[12:33] <kiko> bradb_, can you land a patch that PQM refuses to merge for me?
[12:34] <kiko> it's the fix for bug 52934
[12:34] <Ubugtu> Malone bug 52934 in malone "bug comment ordering broken" [High,In progress]  http://launchpad.net/bugs/52934
[12:34] <bradb_> sure, but why would it merge for me if not you?
[12:34] <bradb_> kiko: thanks for the review, btw.
[12:34] <bradb_> why they heck is chinstrap asking me for a password
[12:34] <kiko> bradb_, I have no clue, but my branch may be broken and I don't have a lot of time left
[12:35] <kiko> bradb_, uhh same here
[12:35] <bradb_> kiko: they're dragging me out of the office too, but if you can tell me to do, i can do it when i get home
[12:35] <kiko>  merge from  sftp://chinstrap.ubuntu.com/home/warthogs/archives/kiko/launchpad/trivialities-xx/ to sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel
[12:35] <kiko> that's essentially it.
[12:35] <kiko> hmmm
[12:35] <kiko> what if the patch didn't get pushed?
[12:35] <kiko> I'll email you the patch, you know, JIC.
[12:36] <bradb_> kiko: emailing the patch would be easier actually, yeah
[12:37] <kiko> sure thing.
[12:38] <bradb_> +filebug, the DC, gah, what a friday evening
[12:39] <bradb_> kiko: is there any way into chinstrap then?
[12:39] <kiko> nope
[12:39] <kiko> see #canonical
[12:39] <bradb_> yeah, hmph
[12:40] <bradb_> oh well, i've done what i can here, i guess i'll check up on it tonight or tomorrow morning
[12:40] <kiko> sure thing
[12:41] <bradb_> kiko: I'll be looking for your patch in my Inbox too. /me heads off
[12:41] <bradb_> later all
[02:23] <Lord_Athur> hi all
[02:23] <Lord_Athur> in the page: https://launchpad.net/people/alejandro-leonvega/+editpgpkeys I could see the command: "gpg --send-key key-id", what does "key-id" meam?
[02:24] <Lord_Athur> :), I'll be absent for a while, I wait for the answer with respect. :)
[02:40] <Lord_Athur> I'm back
[02:44] <Lord_Athur> No one knows what to do?
[03:08] <Lord_Athur> in the context of a  launchapad webpage, what's karma?
[03:30] <Lord_Athur> I need some help
[03:35] <ruffneck> nice =)
[03:35] <ruffneck> karma? I dunno, sounds Indian
[03:36] <Lord_Athur> I've solved my problem, thanks anyway
[10:27] <Hobbsee> hi all.  i know we've changed the level of people who can set the status for a bug, but can we have a checkbox of "this is a wishlist", just like for security, and that changes the importance of the bug?
[10:48] <mpt_> Hobbsee, I doubt it
[10:48] <mpt_> If we make any changes to the Wishlist value, it'll probably be removing it
[10:48] <Hobbsee> mpt_: it is rather useful.  although the bugs are more useful filed upstream, i guess
[10:49] <mpt_> since there can be Major wishlist items (our competitor has this feature and we must have it too!), minor wishlist items, trivial wishlist items, etc
[10:49] <mpt_> so maybe a "This is a feature request, not a bug" checkbox
[10:52] <Hobbsee> mpt_: yeah, that's what i'm asking for.  set at the time of bugwriting.
[10:52] <mpt_> but I've found there is no reliable distinction between bugs and feature requests
[10:52] <mpt_> and Trac gets along fine without it
[10:52] <Hobbsee> mpt_: being a part of -qa myself, i dont really mind, but i know some of the other kde devs are finding it a problem, when they cant set anything as a wishlist, etc
[10:52] <mpt_> Why can't they?
[10:52] <mpt_> Are they not a member of the appropriate team?
[10:55] <spiv> I guess you could use specs for this, but specs are rather heavy-weight for a casual user to use to make a feature request.
[10:56] <mpt_> spiv, can I get an rs= on making all Launchpad's  elements valid XHTML? Very boring and safe, but touches 19 files
[10:57] <spiv> mpt_: what's an example of the change?
[10:57] <Hobbsee> mpt_: yeah, they're not part of ubuntu-qa, and they're keeping ubuntu-qa pretty small.
[10:57] <mpt_> spiv:
[10:58] <mpt_> -
[10:58] <mpt_> +
[10:58] <ivoks> src, instead of srce :)
[10:58] <mpt_> src, yes
[10:58] <mpt_> (that was not copied and pasted :-P )
[10:59] <ivoks> excuses, excuses... :)
[10:59] <ivoks> i'm having big problems with rosetta for couple of weeks now
[10:59] <spiv> So just ensuring they have an alt attribute, basically?  rs=spiv, sure.
[10:59] <mpt_> spiv, and the /> instead of >
[10:59] <mpt_> thanks
[10:59] <ivoks> it refuses to import anything i upload
[11:00] <ivoks> actually, it says it's uploaded, but never gets in import queue or it gets, but stays in "Needs review" state
[11:00] <ivoks> any idea? :/
[11:00] <mpt_> ivoks, you need to prod jordi or carlos
[11:01] <ivoks> ok
[11:01] <mpt_> they're the people who handle the import queue
[11:20] <mpt_> spiv, I can't access chinstrap any more
[11:20] <elmo> mpt: /topic in chinstrap - I'm working on it
[11:20] <elmo> blah
[11:20] <elmo> I suck
[11:20] <mpt_> oh
[11:20] <elmo>  /topic in #canonical even
[11:20] <elmo> is what I meant to say
[11:21] <mpt_> thanks elmo
[11:21] <elmo> someone restore the topic in here?  I don't have it in history
[11:22] <elmo> thanks
[03:16] <elmo> LP is going offline for a couple of minutes for some necessary maintenance
[03:18] <elmo> (bakc)
[04:29] <omeow> Hi, how can I remove myself from launchpad and everything associated with it? I checked the FAQ and it's not described there.
[04:39] <danilos> omeow: you probably can't if you've authored anything in it (it would mean breaking referential integrity)
[04:40] <omeow> Ok.
[04:40] <omeow> Can you explain to me how the hide email address from other users feature is supposed to work?
[04:40] <omeow> I've got that enabled and clicking on my name points to https://launchpad.net/people/omega-blackcatgames
[04:41] <omeow> Anyone with a brain can figure out that the URL contains a partial email address.
[04:42] <danilos> omeow: at the risk of presenting myself as someone without a brain, I can't figure it out
[04:42] <lifeless> just change your name on https://launchpad.net/people/omega-blackcatgames/+edit
[04:42] <omeow> Ah I see.
[04:43] <omeow> danilos, well, my email address is<EMAIL_ADDRESS>[04:45] <omeow> Therefor I thought that the hide email address thingy wasn't working very well.
[04:46] <lifeless> btw, this channel is logged
[04:46] <lifeless> so if you wantted to keep that email address private.. :)
[04:47] <omeow> neat :)
[04:48] <LarstiQ> well, it is discoverable from the blackcatgames site anyway
[04:50] <omeow> How's that?
[04:51] <LarstiQ> http://www.blackcatgames.com/team.html
[04:52] <omeow> Hmhm.
[04:52] <LarstiQ> omeow: I'll wager any of those teammembers has a good chance of working as the local part
[04:53] <omeow> Yeah, anyway, I just figured that hiding it from launchpad would mean that by default, I wouldn't be able to see anything closely related to my email address if the option was switched on.
[04:55] <LarstiQ> pardon?
[04:56] <omeow> Sorry, I'm not a native english speaker so my sentences sometimes come out a little odd.
[04:57] <LarstiQ> Nederlands versta ik ook wel, maar de rest van het kanaal niet.
[04:57] <omeow> I thought that switching on the option "hide email address from other launchpad users" would mean that by default, it wouldn't show part of my email address in the link to my profile.
[04:58] <omeow> That make sense to you? :)
[04:58] <LarstiQ> omeow: Yes.
[04:59] <LarstiQ> omeow: However, the part after people is entirely your name, so that won't work :)
[06:37] <jordi> woah this has to be kidding me
[06:37] <jordi> the queue has 56K files for the distro branch
[06:46] <LarstiQ> what does that mean?
[09:02] <jenda> Am I mistaken or does LP give insane amounts of karma for specs?
[09:05] <LarstiQ> jenda: you're not mistaken
[09:06] <jenda> Indeed.
[09:06] <LarstiQ> jenda: iirc, this is because each area (specs, bugs, translations, etc) has the same amount of karma, divided over each contributor
[09:06] <LarstiQ> and since not a lot of people write specs, well.
[09:07] <jenda> BTW, my branch is up and running, up to 5 MiB now :)
[09:07] <jenda> I see, that makes sense.
[09:07] <jenda> Would that also explain why karma goes down by bits?
[09:10] <LarstiQ> no, I believe there is some decay mechanism for that
[09:10] <jenda> I see. OK, that's cool.
[09:10] <LarstiQ> but all this I've only gathered by hanging around here and on launchpad-users, for a definitive answer you should ask an lp dev
[09:11] <jenda> It's good enough for me - I'm just curious.
[09:11] <jenda> Would bzr pushes contribute to karma too?
[09:12] <LarstiQ> hmm, I don't think so
[09:13] <LarstiQ> most of my karma comes from bug management, and some from translations
[09:13] <LarstiQ> jenda: so no branches
[09:14] <jenda> OK
[09:17] <mdz> cprov: ping?
[09:17] <cprov> mdz: pong
[09:17] <mdz> cprov: this build seems like it might be wedged: https://launchpad.net/+builds/+build/225738
[09:17] <mdz> Date built:
[09:17] <mdz> 2006-07-14 06:15:17 PDT
[09:17] <mdz> the build log looks like it completed (failed)
[09:18] <mdz> but it still says Currently building, and the builder isn't taking any more packages
[09:18] <cprov> mdz: I see, something went wrong in the builddmaster
[09:20] <cprov> mdz: I'm running slavescanner by hand with debug
[09:21] <mdz> thanks
[09:23] <mdz> the other amd64 builder is busy with the kernel, so things are queueing up
[09:23] <cprov> mdz: crested seems to be building subversion
[09:23] <cprov> 2006/07/15 20:19 BST [-]  Build log: Running all tests in history_tests.py...success
[09:23] <mdz> cprov: oh, hmm.  the existing build log is from yellow
[09:23] <mdz> maybe someone reset it then?
[09:24] <cprov> mdz:  can I restart the build ?
[09:24] <cprov> mdz: alright
[09:24] <mdz> cprov: is the build stuck or is it actually going?
[09:24] <mdz> https://launchpad.net/distros/ubuntu/edgy/amd64/+builds?build_state=building&build_text= says Requested 2006-07-10 09:52:59 PDT in pocket RELEASE
[09:24] <mdz> which was of course 5 days ago
[09:25] <mdz> cprov: if you could kill it and just let it take the next builds in priority order, that would be best
[09:25] <mdz> there are more important builds than subversion in the queue
[09:25] <cprov> mdz: will do
[09:33] <cprov> mdz: things seem to fine now, I'll be around ping me if you need
[09:40] <mdz> cprov: thanks
[09:54] <mdz> yay, gnome-python-extras built
[09:54] <mdz> cprov: that should allow a lot of failed builds on i386/amd64/powerpc to finish
[09:55] <mdz> cprov: is there a way to retry them all?
[09:55] <cprov> mdz: not exactly, but we can retry each arch
[09:56] <mdz> I don't remember which builds were failing due to this packa7package
[09:56] <cprov> mdz: let me find them
[09:57] <cprov> mdz: amd64 & powerpc are ok
[09:58] <cprov> mdz: ia64 & sparc failed
[10:02] <cprov> mdz: https://launchpad.net/+builds/+build/226385 & https://launchpad.net/+builds/+build/226384, do you want me to retry them ?
[10:02] <mdz> cprov: I'm not concerned with ia64 or sparc right now, but want to get amd64 and powerpc back into shape for a milestone
[10:03] <mdz> I'll check totem/sparc and see if it's ready
[10:03] <mdz> cprov: totem/sparc built OK
[10:03] <mdz> cprov: so we can retry all release arches
[10:04] <mdz> that is, we should retry failed builds for other packages on amd64 and powerpc now, and sparc after gnome-python-extras builds
[10:04] <mdz> I reset gnome-python-extras/sparc already
[10:04] <cprov> mdz: we can't do massive retries yet :(
[10:05] <mdz> cprov: the buildd admins have some way to do it, maybe a script
[10:05] <cprov> mdz: psql ;)
[10:06] <mdz> probably
[10:13] <LarstiQ> spiv: did you get around to that bzr info -v patch yet?
[10:20] <mdke_> hi all
[10:21] <mdke_> if bzr get is giving me this error, it means that my version of bzr is too old right?
[10:21] <mdke_> bzr: ERROR: Knit header error: '# bzr knit index 8\n' unexpected
[10:21] <jenda> ouch...
[10:21] <jenda> Could the command i gave you be wrong?
[10:21] <LarstiQ> mdke_: yes
[10:22] <LarstiQ> mdke_: you are using either 0.7 or a 0.8 prerelease
[10:22] <LarstiQ> mdke_: you need 0.8 or higher
[10:22] <mdke_> I appear to have 0.8~200603240905
[10:22] <LarstiQ> right, ditch that asap :)
[10:22] <mdke_> I have deb  http://people.ubuntu.com/~jbailey/snapshot/bzr/ ./
[10:22] <mdke_> is that not up to date?
[10:23] <LarstiQ> apparently not, and the packaging of bzr is in transit from jeff to someone else also
[10:23] <LarstiQ> mdke_: why not use what is in dapper?
[10:23] <mdke_> LarstiQ: because it's a breezy machine
[10:23] <mdke_> the dapper package will work fine I guess?
[10:24] <LarstiQ> mdke_: not sure about dependencies, but in general, yes
[10:24] <mdke_> LarstiQ: is that my best option?
[10:25] <LarstiQ> mdke_: any chance you can upgrade the breezy machine?
[10:25] <mdke_> LarstiQ: it's on one of the external servers that canonical rents, apparently they have had some issues with dist-upgrading so I've been holding off
[10:26] <LarstiQ> mdke_: fair enough
[10:26] <mdke_> ok, I'll try the dapper package
[10:27] <mdke_> oh, some python dependencies
[10:27] <mdke_> thanks
[10:28] <mdke_> who's doing the packaging now?
[10:28] <LarstiQ> mdke_: I personally run bzr from source everywhere
[10:28] <LarstiQ> mdke_: hmm, Etienne I think?
[10:28] <LarstiQ> me neither
[10:30] <mdke_> ok, works. Thanks!
[10:31] <LarstiQ> glad to be of help
[10:35] <mdz> cprov: https://launchpad.net/+builds/+build/227962 says that gnome-applets <IP_ADDRESS>-0ubuntu2 built for powerpc on 2006-07-13, but it isn't in the archive. any idea what happened?
[10:37] <mdz> cprov: locate doesn't find the binaries anywhere on drescher
[10:40] <cprov> mdz: possible a side-effect of bug #36468
[10:40] <Ubugtu> Malone bug 36468 in launchpad-buildd "builddmaster appears to batch process by accident?" [Medium,Fix committed]  http://launchpad.net/bugs/36468
[10:45] <mdz> cprov: if I reset the build, will that fix it?
[10:45] <mdz> cprov: or do I need to upload new source?
[10:46] <cprov> mdz: we can't reset fullybuilt builds, we can rescue the builds with SQL black-magic, another source would fix it easily
[10:47] <mdz> cprov: ok, that will take an extra hour but I can do it
[10:47] <cprov> mdz: I mean, not this build, but the archive absence
[10:47] <mdz> hmm, that will also desync the other architectures though
[10:47] <mdz> cprov: how black is the magic?
[10:47] <cprov> mdz: not much, let me see
[10:58] <cprov> mdz: https://launchpad.net/+builds/+build/227962 fixed
[10:59] <mdz> cprov: so it should be in this publisher run?
[10:59] <cprov> mdz: no, it would require re-publication
[11:04] <mdz> cprov: do i need to do something, or just wait another hour?
[11:07] <cprov> mdz: It won't work without a surgery in publication system, give one sec to find the right records
[11:22] <cprov> mdz: you need to re-upload the package, there publishing records acuse they are removed, some mees with domination of empty publications
[11:23] <mdz> cprov: if some of the builds on non-powerpc fail, this will be a big pain for us
[11:23] <mdz> we're trying to get things installable for a milestone and this is the last remaining blocker for amd64/i386/powerpc
[11:24] <cprov> mdz: no, the bug I pointed you is fixed
[11:24] <mdz> cprov: I'm not talking about the bug; edgy is churning a lot right now and we have spent several days unraveling these dependency problems
[11:26] <cprov> mdz: new source should work fine
[11:26] <mdz> I will upload a new source but will have to leave for my flight before it could be published
[11:37] <cprov> mdz: I can keep my eyes on it