[12:43] <nvucinic> hi guys, one more question
[12:43] <nvucinic> when i dismount iso from nocloud
[12:43] <nvucinic> all settings get reverted also
[13:03] <smoser> nvucinic, that doesn't make much sense.
[13:03] <smoser> what is "dismount" ?
[13:04] <smoser> you mean eject cdrom ?
[13:04] <smoser> the next boot will look for another datasource, yes.
[13:04] <smoser> you can change that with
[13:04] <smoser>  manual_cache_clean: True
[13:04] <smoser> see doc/examples/cloud-config.txt
[13:05] <nvucinic> smoser: it was centos, not cloud-init
[13:06] <nvucinic> cloud-init works like a charm
[13:06] <nvucinic> gave a few bitchslaps to drones
[13:06] <nvucinic> everything is working fine now
[18:56] <devicenull> hmm
[18:56] <devicenull> I didn't realize I could just provide a user-data script via the ec2 metadata api
[18:56] <devicenull> rather then implmenting all the different parts of that api
[19:39] <harmw> RaginBajin: ping
[19:39] <RaginBajin> pong
[19:40] <harmw> ah
[19:40] <harmw> I was wondering if you've had a chance to checkout those packages yet :)
[19:40] <RaginBajin> I did.. I installed them. I just haven't gone through actually running anything with them
[19:40] <harmw> ah ok
[19:41] <RaginBajin> I did notice that they built the cloudinit python portion differently though
[19:41] <harmw> what do you mean?
[19:41] <RaginBajin> In the directory /usr/local/lib/python2.7/site-xxx/
[19:42] <RaginBajin> if you build it by hand you just get the cloud-init.xxxx.egg directory
[19:42] <RaginBajin> with yours I seemed to have both the egg and just a directory called cloud-init
[19:42] <RaginBajin> I can get the exact names if you need them
[19:42] <RaginBajin> I'm just trying to go off of memory
[19:42] <harmw> hmk
[19:43] <harmw> well, as long as it just works :) the port's Makefile doesn't do that many, and certainly not very special things
[19:44] <RaginBajin> gotcha. I'll check it out and let you know probably tomorrow.
[19:45] <harmw> great
[19:55] <devicenull> is there a way to pass per-instance scripts in via user-data?
[19:55] <devicenull> I see talk about executing them from directories, but that's not exactly what I want
[20:25] <devicenull> so, I'm writing a file to /var/lib/cloud/scripts/per-instance/ , but it never seems to get run
[20:25] <devicenull> I'm testing with "rm -rf /var/lib/cloud/instance/*; cloud-init --debug --force init"
[20:25] <devicenull> is there something else I need to be nuking to get this to work?
[20:27] <devicenull> ahh missing shebang
[20:34] <devicenull> works perfectly now :)


[20:26] <waltman> https://twitter.com/WPhillyTurkey/status/581915003428560896 # anyone seen WorkingTurkey lately?


[04:56] <hallyn> sforshee: stgraber: apw: so sadly with this trivial patch http://paste.ubuntu.com/6889340/ I can create an overlayfs container clone, and sort of start it, but I can't write to anything.
[04:57] <hallyn> oh wait
[04:57] <hallyn> heh i see why, being silly
[04:58] <hallyn> right, works fine.  o/  course then we have the memory limit concerns
[05:02] <hallyn> as for the mknod-if-devicens-restricted idea, that's not feasible without an explicit "this cgroup is now ok" blessing from root.
[07:33]  * apw yawns mightily
[08:04] <ppisati> Friday morning
[08:38] <apw> are you sure ?
[09:28] <eagles0513875_> hey apb1963
[09:28] <eagles0513875_> i mean apw
[09:29] <apw> hi
[10:01] <rbasak> smb: am I right in thinking that all our kernels support hotplugging on Xen (via xenbus and its block devices)? Is it OK to make it a requirement that our kernel will continue supporting this in the future?
[10:02] <rbasak> The background here is an attempt to establish a standard for interoperability between distros for VM images in the ARM world. So we want Ubuntu cloud images to work on some other distro's OpenStack deployment, for example, which might be Xen based.
[10:07] <smb> rbasak, Maybe you could explain a bit more what exactly you expect to work. Adding new devices after boot or unplugging to replace the emulated disks by paravirt ones
[10:10] <rbasak> Sorry, lost connection.
[10:10]  * rbasak tries again
[10:10] <rbasak> smb: am I right in thinking that all our kernels support hotplugging on Xen (via xenbus and its block devices)? Is it OK to make it a requirement that our kernel will continue supporting this in the future?
[10:10] <rbasak> The background here is an attempt to establish a standard for interoperability between distros for VM images in the ARM world. So we want Ubuntu cloud images to work on some other distro's OpenStack deployment, for example, which might be Xen based.
[10:11] <smb> rbasak, Maybe you could explain a bit more what exactly you expect to work. Adding new devices after boot or unplugging to replace the emulated disks by paravirt ones
[10:11]  * smb repeats re-question
[10:11] <rbasak> smb: AIUI, Cinder expects to be able to hotplug a block device
[10:12] <rbasak> So adding new devices after boot, I believe.
[10:12] <rbasak> BTW, my connection is flaky. I may go again :-/
[10:12] <smb> rbasak, I would have to try that with virsh directly. I think virt-manager refuses to try
[10:13] <rbasak> smb: this might not be with libvirt necessarily.
[10:13] <smb> rbasak, what other way would openstack have to talk to xen?
[10:14] <rbasak> I thought it had a more direct nova driver?
[10:14] <smb> rbasak, afaik there is none. There was that xapi stuff that basically is gone for the time being)
[10:15] <rbasak> Oh yes.
[10:15] <smb> So to my knowledge libvirt is what is used (according to jamespage)
[10:15] <rbasak> Hmm. I'm not thinking specifically about Ubuntu here though.
[10:16] <rbasak> It's more in theory for any distro, since the currently proposed spec mandates that guest kernels support both pci(-e?) and xenbus hotplug.
[10:17] <rbasak> I just wanted to make sure that we won't have an issue with that requirement.
[10:18] <smb> rbasak, To know whether the whole chain of things work you probably should ask someone from the server team. ;)
[10:19] <psivaa> jdstrand: bjf: precise kernel sru regression testing for 3.2.0-1630.42 on armadaxp is throwing failure for test_010_proc_maps in our run.
[10:19] <psivaa> would you mind taking a look: http://pastebin.ubuntu.com/6890443/
[10:19] <smb> rbasak, I can do some experiments with libvirt. Though I have not tried to do that before
[10:19] <fish_> any ideas how I can help fixing/debuggin this issue? https://bugs.launchpad.net/bugs/1275809
[10:19] <ubot2`> Launchpad bug 1275809 in linux (Ubuntu) "(docker/lxc) container restart causes kernel to lockup" [High,Triaged]
[10:19] <rbasak> smb: I'm just asking you about the kernel piece :)
[10:20] <rbasak> smb: am I right in thinking that we have relevant config options turned on?
[10:20] <fish_> since it's not trivial to reproduce I'm worried that anyone will pick it up :)
[10:22] <smb> rbasak, We have at least xenbus in there and if there is a way the managing entity can add things there (this would be xm/xl/virsh from dom0) the kernel handles hotplugging of disks in general
[10:22] <rbasak> smb: I think that's good enough for me - thanks. Assuming you won't want to drop xenbus in the future.
[10:22] <smb> rbasak, Not as long as upstream does not :)
[10:23] <rbasak> smb: OK. Thanks :)
[10:25] <apw> fish_, so you couldn't test 3.14, did you try a trusty 3.13 kernle (which would have aufs)
[10:25] <fish_> apw: good point, I'll try that
[10:30] <fish_> apw: should I try 3.13.2?
[10:31] <fish_> apw: btw, will trusty still contain aufs?
[10:35] <apw> the trusty kernels including the backports ones do yes, not the mainline kernels
[10:43] <fish_> looks like 3.13.2 doesn't include aufs
[10:44] <fish_> apw: hrm, so this one should have it, right? http://packages.ubuntu.com/trusty/amd64/linux-image-generic/download
[10:45] <fish_> eh, that's just a meta deb
[10:45] <fish_> http://packages.ubuntu.com/trusty/kernel/linux-image-3.13.0-7-generic <- this one, right?
[10:48] <fish_> well, I'll just try it
[10:49] <smb> fish_, You will need linux-headers (all), linux-headers (arch) and linux-image (arch) and linux-image-extra (arch)
[10:49] <smb> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-headers-3.13.0-7_3.13.0-7.26_all.deb
[10:50] <fish_> smb: hrm, but linux-image should be enough if I just need to boot it and see if I can reproduce my issue, right? I'm not building anything against the kernel headers
[10:50] <smb> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-headers-3.13.0-7-generic_3.13.0-7.26_amd64.deb
[10:50] <smb> if there are no dkms packages
[10:51] <fish_> no, no dkms
[10:51] <smb> but you need at least the -extra package too
[10:51] <fish_> for firmware and stuff?
[10:51] <smb> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-extra-3.13.0-7-generic_3.13.0-7.26_amd64.deb
[10:51] <smb> No for most other modules
[10:51] <fish_> ah okay
[11:36] <caribou> Is 3.13 still the target kernel version for Trusty ?
[11:42] <apw> caribou, yes
[11:42] <caribou> apw: ok, thanks
[11:49] <fish_> apw: looks pretty good so far
[11:50] <fish_> apw: system still hasn't crashed
[11:58] <apw> fish_, well that is encouraging, as that will be the latest LTS backports kernel after the next release
[13:35] <bjf> psivaa, you only see that on armadaxp?
[13:36] <psivaa> bjf: for precise, yes.  i have not tested that with pandaboard
[13:36] <psivaa> bjf: and this was not seen in the previous kernel on armadaxp
[13:38] <bjf> psivaa, jdstrand let me update my snapshot and put out a new release of the autotests. i know some work was done on that test recently
[13:39] <psivaa> bjf: just checked an amd64 precise run that just completed and the failure is seen there too
[13:40] <bjf> psivaa, ack, give me 30 min. to get you a new release
[13:40] <psivaa> bjf: ack
[14:23] <bjf> psiva, releae email sent. this updates all the QRT snapshots as well as fixes the issue with the results for the dashboard (i hope)
[14:35] <rtg> jjohansen, kamal, ppisati: rebooting tangerine for kernel update
[14:35] <jjohansen> rtg: ack
[14:40] <stgraber> hallyn: what kind of memory limit concerns for unprivileged overlayfs? does overlayfs actually keep that much stuff in memory instead of storing to the writable layer (which should respect memory quotas if it's a tmpfs)?
[14:40] <apw> open directory listings, other than that most things occur on the underlying filesystems which is kinda the point
[14:47] <hallyn> stgraber: that's why i was vague - i remember someone mentioning a concern last week, but couldn't remember exactly what it was
[14:48] <hallyn> Perhaps I'll send the patch to kernel-list for discussion
[14:49] <hallyn> really if it's a vfsmounts-in-kernmem concern, we already have that problem with unprivileged bind and tmpfs mounts
[14:49] <hallyn> in fact, tmpfs mounts are a bigger concern
[14:49] <stgraber> would be great. I'd very much like to have a final yes/no on this ASAP as we need to update upstream LXC to allow snapshotting and ephemeral containers if we can start using overlayfs unprivileged.
[14:49] <hallyn> ok will send it today.  all 5 lines :)
[14:59] <caribou> apw: want me to handle the SRU for bug 1259570 ?
[14:59] <ubot2`> Launchpad bug 1259570 in linux (Ubuntu Precise) "kexec should get a disabling sysctl" [Medium,New] https://launchpad.net/bugs/1259570
[15:07] <apw> caribou, tyhicks is working out which ones this is needed for
[15:08] <caribou> apw: ok, fine thanks
[15:51] <rtg> apw, I assume we can drop the trusty ppc64el branch now ?
[15:57] <apw> rtg, from the main repo?  ues
[15:57] <apw> yes
[15:57] <rtg> yup
[16:38] <apw> jsalisbury, one for your "keeping a vague eye on" list: 1277165
[17:06] <jsalisbury> apw, ack
[17:18] <rtg> apw, I've set annotations to 'CONFIG_CC_STACKPROTECTOR                       p policy<(arch amd64 i386 armhf &/ value y) | value n>', but I'm still getting enforcer errors.
[17:18] <rtg> apw, I've pushed unstable
[17:21] <infinity> rtg: Is this a workaround for toolchains that don't have SSP?
[17:21] <infinity> rtg: If so, ppc/ppc64el have SSP too, only arm64 doesn't...
[17:21] <infinity> (arm64 is almost there...)
[17:23] <rtg> infinity, not according to 3.14-rc1.
[17:23] <rtg> git grep HAVE_CC_STACKPROTECTOR arch
[17:23] <rtg> arch/Kconfig:config HAVE_CC_STACKPROTECTOR
[17:23] <rtg> arch/Kconfig:   depends on HAVE_CC_STACKPROTECTOR
[17:23] <rtg> arch/arm/Kconfig:       select HAVE_CC_STACKPROTECTOR
[17:23] <rtg> arch/mips/Kconfig:      select HAVE_CC_STACKPROTECTOR
[17:23] <rtg> arch/sh/Kconfig:        select HAVE_CC_STACKPROTECTOR
[17:23] <rtg> arch/x86/Kconfig:       select HAVE_CC_STACKPROTECTOR
[17:23] <rtg> perhaps more arches will get enabled throughout the series
[17:23] <infinity> Curious.
[17:24] <rtg> yeah, seems like a step back
[17:25] <apw> rtg, did you sort your enforcer errors or are they stull there
[17:25] <rtg> apw, they are still there. I don't understand that arcane language
[17:26] <rtg> I'm too stupid I guess
[17:27] <apw> rtg, ok i'll have a look shortly
[17:28] <rtg> apw, thanks
[17:36] <apw> rtg you were mixing annotations and enforcement, need to sort that split out
[17:36] <apw> rtg pushed something which workes for now
[17:36] <rtg> apw, hmm, ok
[17:37] <rtg> apw, are you working on grouper yama ?
[17:38] <rtg> apw, actually, you should be off drinking a beer by now. go away.
[18:01] <apw> rtg, grouper == 3.1 yes ?
[18:01] <rtg> apw, yup, just pushed it
[18:01] <apw> rtg, tyler was going to do it, but i am sure he won't mind if you have
[18:02] <rtg> apw, he sent patches on the mailing list
[18:02] <apw> oh ok, cool.  i am in the midst of uploading the others
[18:02] <apw> (to the PPA)
[18:02] <rtg> apw, there is also an interest patch proposal from hallyn on overlayfs that you ought to have a look at
[18:02] <apw> rsalveti was happy for them to be applied and pushed there
[18:02] <rtg> interesting*
[18:03] <apw> rtg, the usespace mount thing one?  i have been having discussions with security about it indeed
[18:03] <rtg> apw, I'll button up grouper and upload it to the PPA
[18:03] <apw> rtg, i have the others "in progress"
[18:03] <rtg> ok
[18:03] <apw> i'll do them shortly before chugging some beer
[18:17] <rtg> apw, grouper uploaded
[18:17] <apw> rtg, ack
[18:18] <rtg> apw, thats the only 3.1 kernel, right ?
[18:18] <apw> rtg, yep, maguro was 30
[18:18] <apw> 3.0
[18:19] <rtg> cool
[18:19] <apw> and i hope is dead
[19:15] <apw> rsalveti, i believe that is all of the touch kernels fixed up with the yama bits i was talking about, and all building/built in the CKT PPA; if you could let us know when you want something else done with them
[19:25] <rsalveti> apw: great, thanks
[19:53] <jsalisbury> apw, rtg Do you guys know of a way to get "git am" to format failures similar to when "git cherry-pick" fails?  For example, when git cherry-pick fails, the file it was modifying has a block with the HEAD and what the patch was trying to do.
[19:53] <jsalisbury> apw, rtg
[19:54] <jsalisbury> A git am failure leaves the file it was modifying unchanged and just lists the patch in .git/rebase-apply/patch
[19:54] <rtg> jsalisbury, when git am fails I usually just 'patch -p1 < 0*' and then fix it up by hand, then 'git am --resolved'
[19:54] <jsalisbury> Just looking for an easier way to do a diff to see why it failed
[19:55] <jsalisbury> rtg, hmm, yeah that sounds like it would help.  Let me give that a try
[19:57] <jsalisbury> rtg, does 'git am --continue' have the same effect as 'git am --resolved' ?  Seems like it from the man page but just wanted to check.
[19:58] <rtg> jsalisbury, it might I guess if you are importing multiple patches
[19:58] <rtg> you might have to --resolved first, then --continue
[19:58] <jsalisbury> rtg, cool, thanks.
[20:01] <jsalisbury> rtg, awesome, 'patch -p1 < patchname.patch' actually fixed the issue without me having to fix anything :-)  That's definitively the way I'll do it when I get a 'git am' failure from now on.
[20:02] <rtg> jsalisbury, patch is a little less anal about context, though you wanna look closely to make sure its done the right thing. you can likely get git am to be a little less restrictive too, but I've always just used patch
[20:02] <apw> git am -C1 gives you the same as patch
[20:03] <jsalisbury> rtg, apw, great, thanks!
[20:06] <bjf> jsalisbury, i do exactly what rtg does
[20:07] <jsalisbury> bjf, apw, rtg, for context, I'm just practicing turning the crank.  I'm applying the latest <IP_ADDRESS> patches from henrix's -review branch to a saucy tree.  I'm was just looking for the most efficient way to resolve a patch failure.
[20:18] <bjf> jsalisbury, i think there are upstream stable release, you could pick one and apply the commits, they all need to be processed
[20:21] <jsalisbury> bjf, is there a list or way to tell which ones have been done already?  For Saucy, do we wait until <IP_ADDRESS> goes from the linux-3.11.y-review branch to linux-3.11.y to apply them to saucy master-next?
[20:22] <bjf> jsalisbury, we don't apply them until they have been "released"
[20:22] <jsalisbury> bjf, ack
[20:22] <bjf> jsalisbury, you just go from stable branch/tree to stable branch/tree and see what has been applied in the related ubuntu tree
[20:23] <bjf> jsalisbury, sconklin and i are the only others that apply them so it's easy enough to know if someone is working on one already
[20:24] <bjf> jsalisbury, and if we know you are handling it, we'll just stand back and watch :-)
[20:24] <sconklin> waaay back :-)
[20:24] <jsalisbury> heh
[20:24] <sconklin> here, hold my beer
[20:25] <jsalisbury> bjf, sconklin, so how do I tell which stable release is ready?  Do you get that from one of the mailing lists?
[20:26] <sconklin> the maintainer announces, and there's also typically a release commit at the tip
[20:26] <jsalisbury> got it
[20:27] <jsalisbury> bjf, sconklin, Do you recommend which one I should start with?  I don't want to step on one you've already started.
[20:27] <bjf> jsalisbury, we're not working on any of them right now
[20:27] <sconklin> I don't have any in progress
[20:28] <bjf> jsalisbury, start with precise and work you way through saucy
[20:28] <jsalisbury> bjf, sconklin So there is nothing to do for Saucy yet, because <IP_ADDRESS> is still in review, correct
[20:28] <bjf> jsalisbury, that's what i normally do
[20:32] <sconklin> jsalisbury: you can always go ahead and apply to master-next. If a release gets held up or respun, everything has to be manually sorted and/or rebased anyway, and what's another few hundred patches, more or less? :-)
[20:32] <jsalisbury> bjf, sconklin Ok, I'll give precise a go.  I'll push what I do to my git location on zinc and send a pointer for you guys to review
[20:32] <sconklin> jsalisbury: perfect
[20:40] <jsalisbury> bjf, sconklin, It looks like the latest 3.2 stable kernel is 3.2.54.  Looking at the Precise master-next branch, it looks like it may have already been applied:
[20:40] <jsalisbury> e7ebafbdb203bed536102c184198bcf4f8f71d4f Linux 3.2.54
[20:40] <jsalisbury> I see a tracking bug as well: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1266546
[20:40] <ubot2`> Launchpad bug 1266546 in linux (Ubuntu Precise) "Precise update to 3.2.54 stable release" [Undecided,In progress]
[20:42] <bjf> jsalisbury, that's likely. upstream stable for that is benh and there's quite a period between upstream stable releases for 3.2
[20:44] <jsalisbury> bjf, should I give Quantal a try then?
[20:44] <bjf> jsalisbury, like i said, i just work through them all to check .. i'm looking at Q right now
[20:44] <jsalisbury> bjf, ack
[20:45] <Teduardo> Ah, there was no new netboot image put in for 12.04.4.. bummer
[20:46] <Teduardo> yes, build a 50,000 node cloud with no nic drivers =)
[20:46] <Teduardo> you win internets
[20:47] <Sarvatt> Teduardo: http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/saucy-netboot/
[20:47] <jsalisbury> bjf, So we apply all the latest upstream updates to master-next.  How do those updates then make it into all the various flavors, or does that all happen by the builder?
[20:49] <Teduardo> the saucy netboot will install precise?
[20:49] <Sarvatt> yep, its in precise, uses the saucy kernel just like 12.04.4 does
[20:50] <Sarvatt> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/raring-netboot/ for 12.04.3, etc
[20:50] <Teduardo> so if that works why not just make that the netboot image that comes up in the main precise thing
[20:54] <infinity> Teduardo: "the main precise thing"?
[20:55] <Teduardo> http://cdimage.ubuntu.com/netboot/ -> click on 12.04
[20:55] <Teduardo> wouldn't it make sense to put the one with the most driver support right there in front?
[20:56] <infinity> Teduardo: Right, I was just going to edit that today.  Though "12.04" will still point to the one with the 3.2 kernel, I'm just going to at the HWE kernel options at the bottom.
[20:56] <Teduardo> so people aren't like.. zomg why doesnt ubuntu support NICs that were released in 2012
[20:56] <infinity> s/at/add/ .. Brain/finger disconnect.
[20:58] <Teduardo> So just to be clear, the 'saucy-netboot' in the precise tree, doesn't actually install the 3.8 kernel on OS right? it just uses it during the install?
[20:58] <Teduardo> the actual kernel that is installed is the regular thing that comes with 12.04.4?
[20:58] <rtg> Teduardo, yes
[20:59] <Teduardo> cool, thanks for your help. i get to go home now!
[20:59] <Teduardo> wheeeeeeeeee....
[21:06] <infinity> Teduardo: It doesn't use a 3.8 kernel at all...
[21:06] <infinity> Teduardo: It both boots with and installs a 3.11 kernel.
[21:08] <infinity> I'm so renaming those images for trusty to be less confusing.
[21:08] <bjf> jsalisbury, yes, we just update master-next and building multiple arches/flavours from the same branch/repo makes it all work
[21:12] <antarus> qq, do signed kernel modules require secure boot?
[21:13] <antarus> or is the kernel using some other model of trust for them?
[21:18] <infinity> antarus: Not related to secure boot at all, no, it's the kernel that does the checking.
[21:20] <antarus> infinity: hrm
[21:20] <antarus> infinity: so for modules built with dkms...
[21:20] <antarus> signing seems...like it would be difficult?
[21:20] <antarus> although, building modules on the localhost seems insane if you don't trust localhost
[21:21] <antarus> so perhaps not so much ;p
[21:21] <infinity> It's a bit of an unsolved problem, yes.  We discussed this at plumbers a while ago and no one had any bright ideas.
[21:21] <antarus> well in my proposal users can only run specific kernels, so we could in theory precompile modules for them
[21:21] <antarus> and sign those
[21:21] <infinity> You'd need to update the keyring to include your signing key too.
[21:22] <infinity> Since the signing key we use for our kernel binaries is generated and thrown away during the build process.
[21:25] <antarus> yeah
[21:25] <antarus> we will probably be stuck building our own copy of your kernel sources anyway ;p
[21:25] <antarus> so might as well use our own keys to sign
[21:26] <infinity> I'd like to solve this more elegantly, so "just rebuild the kernel" isn't the go-to option.
[21:27] <infinity> But other than that one session at plumbers when we all agreed it was too hard and we'd think about it later, I've not put much thought into it.
[21:27] <antarus> this is all pie in teh sky stuff right now
[21:27] <antarus> we have a summit internally in a few weeks
[21:27] <antarus> and I'm trying to think up ideas that we could do
[21:28] <antarus> particularly if we started over
[21:28] <antarus> and aborted the legacy mess we had today ;p
[21:28]  * marrusl wanders in
[21:28] <infinity> marrusl: Shoo.
[21:28] <infinity> marrusl: Whenever you're around, it seems to generate work.
[21:30] <marrusl> infinity, only "seems"?
[21:31] <infinity> antarus: So, yes, in a nutshell, the dkms-on-localhost use-case assumes that you trust localhost once it's booted, so you use a local signing key and scream "la la la, this doesn't feel right".  It's the centrally-distributed extra modules use-case that's more interesting (as that can be better locked down), and I'd like to come up with a sane solution for that.
[21:39] <jsalisbury> bjf, sconklin Just did a bunch of clones to my home systems that I can --reference for future clones :-)
[21:39] <jsalisbury> sconklin, bjf, I see that Quantal only has up to <IP_ADDRESS>
[21:39] <jsalisbury> sconklin, bjf, So it looks like it needs <IP_ADDRESS> and <IP_ADDRESS> updates.  I can give that a go.
[21:40] <sconklin> jsalisbury: I generally reference Linus's upstream repo, as the vast majority of everything else is also in there
[21:46] <jsalisbury> sconklin, bjf Where there are two upstream releases to apply, do we do them one at a time, and create a seperate stable tracker bug for each?  Or can I apply all the patches from each in one shot?
[21:46] <bjf> jsalisbury, i do what sconklin said
[21:47] <sconklin> jsalisbury: apply the ones from the upstream maintainer's tree. I usually create a single tracking bug even if there are multiple upstream releases
[21:48] <sconklin> just make sure that the list of commits in the bug includes all the ones in both upstream updates, and that every commit in your branch has the bug id added
[21:48] <sconklin> jsalisbury: you know about maint-modify-patch, right?
[21:48] <jsalisbury> sconklin yes
[21:48] <bjf> jsalisbury, again i do the same as sconklin
[21:48] <jsalisbury> sconklin, that makes it easier to do them in one pass instead of two :-)
[21:49] <sconklin> good. You can expect it to throw errors on patches with unicode in people's names. This should really be fixed in the script but I have been just going back to verify that it did the right thing.
[21:50] <sconklin> and the way I do that is - say I was adding my SOB. I just "grep -v sconklin *patch" and it'll list any without my sob
[21:50] <sconklin> You'll know it if you see it :-)
[21:51] <jsalisbury> sconklin, looks like 200 patches for <IP_ADDRESS> and <IP_ADDRESS>:
[21:51] <jsalisbury> git log --pretty=oneline v<IP_ADDRESS>... | wc
[21:51] <jsalisbury>     200    1773   19309
[21:51] <sconklin> not surprising.
[21:51] <sconklin> builds character :-)
[21:51] <jsalisbury> heh :-)
[21:56] <jsalisbury> sconklin, do I add my sob when running the 'git format-patch' in the upstream tree, or does the maint-modify-patch do it for me?
[21:58] <sconklin> I just extract all the patches using "git format-patch -k tag.." and then add SOB and tracking bug number using maint-modify-patch
[21:58] <jsalisbury> sconklin, got it.  thanks!
[21:59] <jsalisbury> sconklin, Here's the tracking bug: https://bugs.launchpad.net/bugs/1277722  I'll add the subjects of all the patches.  Going to apply them now, and tackle the failures :-)
[21:59] <ubot2> Launchpad bug 1277722 in linux (Ubuntu Quantal) "Quantal update to v<IP_ADDRESS> stable release" [Undecided,New]
[22:00] <sconklin> cool.
[22:07] <jsalisbury> sconklin, what is the format for --sob when passing it to the maint-modify-patch script?
[22:07] <jsalisbury> sconklin, seems to fail for me.  I don't have an .kteam.rc file on my system.  Maybe I need one?
[22:09] <sconklin> yeah, you have to copy that rc file to your home dir and add your own name/email/nick
[22:10] <sconklin> you can add those to the kteam-tools sample version of that rc file, too if you want
[22:10] <jsalisbury> cool, thanks.  Looks like the script told me that, heh: ** Error: No aliases found, the required configuration file may be missing. Copy the file kteam-tools/maintscripts/doc/example_kteam.rc to ~/.kteam.rc.
[22:12] <sconklin> I think I added that error message in a rage one day
[22:14] <jsalisbury> sconklin, hmm, I get the unicode warning with the maint-modify-patch script:
[22:14] <jsalisbury> /home/jsalisbury/src/kteam-tools/maintscripts/maint-modify-patch:253: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
[22:14] <jsalisbury>   if expanded not in existing_sobs:
[22:15] <bjf> jsalisbury, just ignore it
[22:15] <sconklin> yeah, that's the one
[22:15] <jsalisbury> Ok
[22:15] <sconklin> you can verify that your SOB was applied to all the patches using grep -v, if you want to double check
[22:15] <jsalisbury> Yeah, looks like it did the right thing :-)
[22:19] <jsalisbury> sconklin, do you have a grep or something to pull the subject out of the patches, while dropping the "Subject" text, which I'll put in the bug tracker?  If not, I can figure one out.
[22:20] <sconklin> I generally concoct a line something like this in the upstream maintainer's tree:
[22:20] <sconklin> git log --oneline <tag>.. | cut -b 47- > patchlist.txt
[22:21] <sconklin> and then I edit that and prepend " * ", or whatever the line beginning should look like (can't remember atm)
[22:22] <sconklin> adjust the 47 to suit, and you may need other options to git log. Lemme see if I have that in a script
[22:23] <sconklin> jsalisbury: I apparently have not saved that anywhere
[22:24] <jsalisbury> sconklin, Ok, I can figure out some sort of grep/awk combo.
[22:24] <jsalisbury> sconklin, If a patch fails because it's already applied, and I skip it, do I still add it to the bug tracker?
[22:25] <sconklin> I don't worry about that too much. If I already have the list in the bug I don't bother removing it
[22:38] <jsalisbury> sconklin, sweet, only two patches failed, and that was because they were already applied :-)
[22:38] <sconklin> best case scenario.
[22:40] <sconklin> You're more likely to run into conflicts with older kernels, as there may be patches which conflict with the context because they aren't in the upstream stable tree. That's not common, but it happens, and most of the time, it's only context, and for things like PCI id's in a driver or lists like that
[22:48] <jsalisbury> sconklin, I came up with this to pull the subject out of all the patch files:
[22:48] <jsalisbury> cat * | grep Subject: | awk '{first = $1; $1 = ""; print $0}'
[22:48] <jsalisbury> sconklin, but it seems to drop some subject text if a subject has a carriage return in it
[22:49] <sconklin> jsalisbury: dunno, I take the text from a git log in the upstream maintainer's tree, not from the patch files
[22:49] <jsalisbury> sconklin, heh, yeah I guess I could make it easy and just get it from git
[22:59] <jsalisbury> sconklin, cool, looks like I just need --pretty=%s:
[22:59] <jsalisbury> git log --pretty=%s v<IP_ADDRESS>... > subjects
[22:59] <jsalisbury> sconklin, Thanks for all the help!
[23:00] <jsalisbury> sconklin, I'll finsh up the tracking bug, push to my tree on zinc and send an email with a pointer to you and bjf
[23:00] <sconklin> awesome! Yeah, git is your friend in a lot of ways, there are a ton of formatting options for logs
[23:02] <jsalisbury> sconklin, Thanks again!  Enjoy your weekend


[01:05] <mpt> Goooooooood afternoon Launchpadders!
[01:09] <thumper> mpt: afternoon
[01:10] <thumper> mpt: for dependancy graph that is shown on the spec pages, do you know where it is size constrained?
[01:10] <mpt> not offhand, no
[01:10] <mpt> though I probably increased it for the new layout
[01:14] <thumper> mpt: the max is too small
[01:15] <thumper> https://blueprints.beta.launchpad.net/launchpad-bazaar/+spec/ui-roadmap
[01:15] <Hobbsee> mpt: thanks!
[01:21] <mpt> Hobbsee, you're welcome
[01:21] <mpt> thanks for the feedback
[01:22] <Hobbsee> mpt: :)
[01:22] <Hobbsee> mpt: still going to reply back - sometime
[01:22] <mpt> thumper, I have a worse example than that
[01:25] <mpt> thumper, https://beta.launchpad.net/launchpad/+spec/1.0-web-interface
[01:25] <mpt> thumper, it's bug 66344
[01:25] <Ubugtu> Malone bug 66344 in blueprint "Dependency chart becomes unreadable with >12 dependencies" [Medium,Confirmed]  https://launchpad.net/bugs/66344 - Assigned to Steve Alexander (stevea)
[01:25] <mpt> and tweaking the width will only change the "12" in that bug to "14" or "16"
[02:53] <mpt> 144 KB for a translation page, ouch
[02:53] <mpt> and that's just the HTML
[02:54] <mpt> then 110 KB for MochiKit
[02:54] <ajmitch> for every page load?
[02:54] <mpt> 22.6 KB of other JavaScript
[02:54] <mpt> ajmitch, yes
[02:54] <mpt> well, this is just one particular translation page that has many suggestions
[02:54] <mpt> but the JavaScript is loaded on every page
[02:54] <mpt> across Launchpad
[02:55] <ajmitch> hence why I bookmark certain urls to avoid the pain of navigation & waiting
[02:55] <ajmitch> it does feel quite heavy at times
[02:56] <mpt> 348 KB altogether
[02:56] <mpt> wowser
[03:10] <Fujitsu> Can you do something like making the browser cache the JS, or split MochiKit up into smaller libraries, and only load the necessary ones?
[03:11] <ajmitch> caching+https don't always play nice
[03:11] <ajmitch> you should have seen the (pre-malone) ubuntu bugzilla
[03:11] <ajmitch> 1MB of javascript on each page load
[03:11] <lifeless> Fujitsu: its a browser isse
[03:11] <lifeless> *issue*
[03:31] <Ubugtu> New bug: #43893 in malone "Allow product-/package-specific bug-reporting guidelines" [High,Confirmed]  https://launchpad.net/bugs/43893
[04:01] <mpt> Fujitsu, it's mostly our fault for doing HTTPS, and partly browsers' fault for being too jittery about caching HTTPS stuff
[04:01] <mpt> and partly also our fault for sending the whole of MochiKit each time, yes
[04:02] <Fujitsu> It'd be nice if you could send the images/JS over HTTP without the browser complaining.
[04:21] <mpt> Fujitsu, that's easily done, just send the HTML over HTTP too :-)
[04:22] <mpt> I think probably we're greatly overusing HTTPS
[05:19] <jml> thumper: so, I just had a look on the NZ lenovo website. The Thinkpad X60 2.0GHz is 850 AUD cheaper in NZ.
[05:20] <thumper> jml: you wanting me to get it for you?
[05:21] <jml> thumper: I'm quite tempted to ask.
[05:21] <thumper> if I ship it to AU though, it'll get taxed
[05:21] <thumper> you'll have to come for a visit
[05:22] <thumper> jml: I registered 15 specs for lp-bzr this morning
[05:22] <jml> thumper: cool.
[05:22] <thumper> some of which jumped out at me saying "jml can do this"
[05:22] <jml> thumper: lots of reading for me tomorrow then?
[05:22] <jml> heh heh
[05:22] <thumper> none of them have wiki pages yet
[05:23] <thumper> just place holders for work that I've identified
[05:23] <thumper> or had been identified before and no one had written down
[05:25] <Fujitsu> thumper: I like the look of a lot of them :)
[05:26] <thumper> Fujitsu: something to work towards anyway
[05:27] <thumper> jml: my desktop just fubar'ed
[05:28] <jml> thumper: what happened?
[05:28] <thumper> jml: Stops at "Memory Testi" and nothing more :(
[05:28] <jml> thumper: ouch
[05:28] <thumper> things where hanging so I rebooted
[05:28] <thumper> and got that
[05:28] <thumper> so off to buy some clean memory tomorrow
[05:28] <thumper> I'm hoping that's all it is
[05:38] <Fujitsu> Can someone please take a look at OOPS-408C267? A timeout seems to occur when attempting to list branches for any product.
[05:38] <Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/408C267
[05:41] <Fujitsu> Indeed, any branch listing at all (even in a bug) fails.
[05:43] <thumper> Fujitsu: our dba is doing some maintenance which will be causing these timeouts
[05:44] <Fujitsu> OK, would be nice to have something nicer than timeout errors in such a situation.
[05:46] <thumper> yeah
[05:52] <spiv> Fujitsu: the maintenance is being done to fix some timeout errors.
[05:52] <Fujitsu> I note that the timeouts I mentioned are no longer, which is good.
[08:27] <mpt> Hobbsee, I found the "Indicate bug" button you were talking about, so I've updated bug 84339 to mention it
[08:27] <Ubugtu> Malone bug 84339 in malone "+choose-affected-product title and heading need rewriting" [Medium,Unconfirmed]  https://launchpad.net/bugs/84339 - Assigned to Matthew Paul Thomas (mpt)
[08:28] <Hobbsee> mpt: cool :)  that the "mark the bug as affecting upstream" section, whcih is unclear?
[08:28] <mpt> yes
[08:28] <Hobbsee> cool :)
[08:35] <ddaa> pfff
[08:35] <Ubugtu> New bug: #84674 in malone "Disappearance of /sbin/lrm-video" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84674
[08:37] <ddaa> not sure if bug 42480 isn't really about "hard to report a bug on a ubuntu package", rather than "hard to file bug on non-malone upstream"
[08:37] <Ubugtu> Malone bug 42480 in malone "Report a bug about product that doesn't use Malone should include link to product's official bug tracker" [High,Confirmed]  https://launchpad.net/bugs/42480 - Assigned to Christian Reis (kiko)
[08:38] <mpt> ddaa, that's indeed a possibility
[08:38] <mpt> foolswisdom might not even remember any more :-)
[08:46] <AMREENA> anyone here
[08:46] <thumper> AMREENA: heaps here
[08:47] <AMREENA> wat ?
[08:47] <AMREENA> u mean part the channel
[08:47] <thumper> AMREENA: many people here just waiting for your questions
[08:47] <thumper> :)
[08:48] <AMREENA> ok
[08:48] <AMREENA> i also want to know something about UBUNTU
[08:49] <thumper> AMREENA: probably best to ask on #ubuntu
[08:50] <AMREENA> ok thankyou
[09:44] <lifeless> review meeting in 16
[09:45] <Ubugtu> New bug: #84686 in launchpad-bazaar "run supermirror from "make run"" [Low,Unconfirmed]  https://launchpad.net/bugs/84686
[09:45] <spiv> lifeless: that's an hour early, isn't it?
[09:45] <lifeless> its been straight after the bzr meeting for $yonks
[09:45] <lifeless> unless that has moved ?
[09:46] <spiv> lifeless: the bzr meeting moved back an hour
[09:46] <lifeless> oh
[09:46] <lifeless> in 1hr16 then
[09:46] <lifeless> thanks!
[09:47] <spiv> You're welcome :)
[09:59] <mpt> mrevell, http://vulcano.mine.nu/blog/index.php/2007/02/11/launchpad-teams/
[09:59] <mrevell> mpt: thanks
[10:01] <mrevell> mpt: Hmm, if ever there were a "Dear Lazyweb..." post :)
[10:30] <mpt> mrevell, what do you mean?
[10:31] <mrevell> mpt: The post you gave me a link to basically says, "Will someone please explain x and y about Launchpad?" Rather than directly asking people who could answer, it's a broadcast question to the web. On a more serious note, that suggests it's not so easy to find out how to contact the Launchpad team.
[10:32] <Fujitsu> mrevell: There have been a few such posts lately (one from Christer Edwards, for example).
[10:33] <mpt> mrevell, it could mean several other things
[10:33] <mpt> e.g. thinking that the Launchpad team won't be responsive
[10:33] <mpt> or thinking that other people will provide better answers
[10:33] <mrevell> mpt: sure, so these are things I need to address on the team's behalf.
[10:34] <mrevell> Fujitsu: Yeah, it's all a good sign that we (the LP team) need to explain ourselves more effectively to the community.
[10:35] <mpt> The tours should help with that, I think
[10:37] <mpt> (Coincidentally, the most recent post on lazyweb.org is about Ubuntu)
[10:40] <mrevell> mpt: I think the tours will help give an overview of what Launchpad is for and how it can help people, certainly. I must ping static, as he's working on the content for the tours atm.
[10:57] <lifeless> review team meeting in 3 minutes
[11:00] <lifeless> review team meeting
[11:00] <lifeless> == Agenda ==
[11:00] <lifeless>  * Roll call
[11:00] <lifeless>  * Next meeting
[11:00] <lifeless>  * Queue status.
[11:01] <lifeless> spiv: ?
[11:01] <BjornT> hi
[11:01] <lifeless> BjornT: ?
[11:01] <lifeless> hi
[11:01] <lifeless> SteveA: ?
[11:01] <spiv> hi
[11:02] <lifeless> BjornT: you want to talk about the next meeting time /
[11:02] <lifeless> ?
[11:02] <BjornT> well, i was mainly wondering if you've considered changing the meeting time?
[11:03] <BjornT> given that currently two of the reviewers are never able to attend, it might be worth changing it
[11:03] <SteveA> lifeless: hi
[11:03] <lifeless> do you have a suggested time ?
[11:04] <lifeless> if I go later, I lose a days work due to being overly tired the next day
[11:04] <lifeless> personal thing: I *dont* sleep in unless actually ill
[11:04] <BjornT> even though it's not possible to find a time when everybody will be able to attend, it can be good to move the meeting from time to time
[11:04] <lifeless> we can consider rotating it
[11:04] <lifeless> like some ubuntu meetings do
[11:05] <BjornT> lifeless: no, i don't have any suggestion, i'm not sure when is suitable for everyone.
[11:05] <Ubugtu> New bug: #84694 in launchpad-bazaar "registering bzr upstream for series is difficult" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84694
[11:05] <SteveA> I have a suggestion
[11:05] <lifeless> so we have the details on the https://launchpad.canonical.com/ReviewerMeetingAgenda?action=raw page
[11:05] <SteveA> reviewing is very important to our processes
[11:05] <SteveA> and a review team meeting can be short
[11:05] <SteveA> so let's have two per week
[11:05] <lifeless> putting that into a calendar should give a feel for slots
[11:05] <SteveA> the main point of the meeting is to check reviewers are keeping up effectively
[11:05] <SteveA> if someone or some people can attend both
[11:05] <SteveA> that will be best
[11:06] <SteveA> and they will end up being shorter
[11:06] <SteveA> what do you think?
[11:06] <lifeless> well, they wont be shorter I think, but I'm happy with the time involved to do two meetings
[11:06] <SteveA> lifeless: you'd go to just one
[11:06] <lifeless> SteveA: I didn't mean to imply it was solely my time I was concerned about
[11:06] <BjornT> yeah, two meetings a week would work. the meetings are rather short anyway, so it wouldn't hurt.
[11:07] <lifeless> SteveA: I was meaning the time cost for whoever ended up being the gateway
[11:07] <lifeless> SteveA: that said, I can do the us evening time slot easily too, so it might be me
[11:08] <lifeless> tell you guys what, I'll put the windows we have into a calendar and see what drops out
[11:08] <SteveA> so, now that the lpbzr meeting is earlier
[11:08] <SteveA> how about we move this meeting 1hr earlier
[11:08] <SteveA> and then organise a later US-tz one
[11:09] <lifeless> fine by me
[11:09] <BjornT> works for me.
[11:09] <lifeless> but lets get the other one locked in before changing - its currently AIUI 0900 in sao carlos that this meeting occurs
[11:09] <lifeless> (1000 UTC, and they are one hour behind at the moment)
[11:10] <SteveA> lifeless: then, why are there no brazilians here
[11:10] <lifeless> SteveA: I don't know
[11:10] <BjornT> it's 0800 in sao carlos, isn't it?
[11:10] <SteveA> it is
[11:10] <SteveA> I just asked google
[11:11] <lifeless> SteveA: ah
[11:11] <lifeless> so, next, queue status
[11:12] <lifeless> its a pity jamesh isn't here, as hes lagging the most in review freshness
[11:12] <SteveA> he's sprinting
[11:12] <lifeless> when does he finish ?
[11:13] <lifeless> (he has 3 very small branches in his queue, pending for 14 to 59 days). I think that this is rather bad
[11:14] <SteveA> he ought to be able to do small branches this week
[11:16] <lifeless> I'll send him a nag mail
[11:16] <lifeless> if he can't, we have capacity to reallocate, but they need doing one way or the other
[11:16] <SteveA> ok.  cc kiko, so kiko can help manage his time commitments while he's in brasil
[11:17] <lifeless> sure
[11:17] <lifeless> other than that, the review queue is quite good.
[11:17] <lifeless> way down from its choke period a fortnight back
[11:17] <lifeless> GOOD WORK!
[11:18] <lifeless> theres four branches @ 3 days (compensating for the weekend). of those, two are conflicted
[11:18] <lifeless> so, only 2 can be reviewed, and those are small
[11:18] <lifeless> both with spiv
[11:18] <lifeless> spiv: you think you can get those knocked over tomorrow ?
[11:18] <spiv> lifeless: I'm sure I can.
[11:19] <lifeless> ok.
[11:19] <lifeless> any new business? you guys generally ok with review load at the moment ?
[11:20] <BjornT> i'm ok
[11:20] <spiv> Yeah, I'm ok.  Branches have been pretty small.
[11:21] <lifeless> cool, meeting over in 5
[11:21] <lifeless> 4
[11:21] <spiv> Branches under 300 lines are good, and should be encouraged :)
[11:21] <lifeless> 3
[11:21] <lifeless> 2
[11:22] <lifeless> 1
[11:22] <lifeless> 0
[11:22] <lifeless> danke for attending
[11:52] <carlos_> morning
[11:58] <Ubugtu> New bug: #84680 in launchpad "The "Working on" portlet shouldn't include duplicate bugs" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84680
[12:20] <cprov> good morning !
[12:25] <kiko> morning
[12:27] <Hobbsee> morning @ 10.27pm!
[12:55] <Ubugtu> New bug: #48771 in malone "It should be possible to delete attachments" [Medium,Confirmed]  https://launchpad.net/bugs/48771
[01:20] <Ubugtu> New bug: #84711 in malone "long words in bug titles make bug listings very wide" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84711
[01:35] <sabdfl> SteveA: new menu looks super - thanks!
[01:35] <sabdfl> mpt: any idea why the new flat app graphics aren't on beta.lp.n?
[01:35] <sabdfl> thumper: nice work on the code home page portlets
[01:36] <sabdfl> just need a branch icon for the listings
[01:36] <sabdfl> also, branches with titles should still include the product name
[01:36] <sabdfl> so you get:
[01:36] <sabdfl>  man-db: Development branch
[01:37] <sabdfl> rather than just: Development branch
[01:37] <sabdfl> this is only of course important if the product is not implicit in the context
[01:37] <sabdfl> so, for example, you don't need it in places where you a listing the branches for a particular product
[01:37] <sabdfl> but you do need it in general portlets
[01:38] <sabdfl> for example, on the code home page, where the portlets are describing branches from *all* products
[01:38] <sabdfl> will send this by email in case you don't read scrollback.
[02:26] <kiko> ahoy there
[02:27] <Hobbsee> hey kiko!
[02:27] <kiko> I am now an edgy person
[02:27] <seb128> kiko: you should be a feisty person ;)
[02:27] <kiko> soon!
[02:40] <Ubugtu> New bug: #84719 in malone "Live CD crashes/gets into an endlsess loop on shutdown" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84719
[03:05] <jenda> mrevell_: hey
[03:05] <mrevell_> hi jenda
[03:05] <jenda> PM?
[03:06] <mrevell_> jenda: sure
[05:27] <jam> greetings... What does it take to get a new upstream bugtracker registered?
[05:27] <tsmithe> hi
[05:28] <tsmithe> i'm trying to link the cinelerra-cv product to the upstream bugzilla tracker. when trying to choose, there is a list... but not cinelerra... is it not possible to have a generic "bugzilla" option, where you fill in the details yourself?
[05:48] <iwj> If I search for bugs `newest first', under what circumstances might the bug numbers not be strictly decreasing down the listing ?
[05:56] <seb128> iwj: I think there is some weirdness due to tasks there, like it might count the date when a new task has been opened
[05:56] <iwj> seb128: Hmm.
[06:19] <BjornT> jam, tsmithe: it's not easy to find, but you can register a new upstream bugtracker at https://launchpad.net/bugs/bugtrackers/+newbugtracker
[06:19] <BjornT> tsmithe: but i agree, it should be easier to register a new tracker while choosing one.
[06:20] <jamesh> iwj: when we've done bug imports, we've kept the old bug submission dates
[06:20] <jamesh> iwj: so for Ubuntu bugs, id order is not quite the same as datecreated order, since some bugs were filed in Launchpad before the bugzilla.ubuntu.com migration
[06:27] <jam> thanks for the heads up BjornT
[07:09] <iwj> jamesh: Mmm.  I think seb128's reply is to the point in this case though.  Thanks.
[07:19] <jamesh> iwj: yeah.  The "datecreated" orderby does sort on the bugtask's datecreated which is not the same as the bug's datecreated for subsequent bug tasks
[07:19] <jamesh> iwj: I agree that it'd be nicer if it sorted on the bug's date created though
[07:21] <iwj> I think it's OK, but it was just a bit confusing.
[07:51] <sabdfl> sudden flood of applications to join launchpad-beta-testers... anybody know why? is there a blog somewhere about it?
[07:52] <oojah> mrevell sent an email to launchpad-users
[07:53] <mrevell> sabdfl: SteveA and I had a call on Friday following your call and we agreed to invite subscribers to launchpad-users.
[07:53] <mrevell> sabdfl: Good response so far :)
[07:57] <sabdfl> mrevell: awesome :-)
[08:09] <mdke> og's blog post probably publicised it too
[08:10] <phanatic> and also joey's presentation
[08:16] <tsmithe> how can i get a new bug tracker registered in launchpad?
[08:18] <mdke> there are instructions on the bug tracker page iirc
[08:18] <tsmithe> oh... really?
[08:19] <mdke> "Register bug tracker"
[08:19] <mdke> https://bugs.launchpad.net/bugs/bugtrackers
[08:20] <tsmithe> ooh
[08:20] <tsmithe> cool
[08:20] <tsmithe> thanks
[08:25] <sabdfl> lotof bugs in that url
[08:26] <radix> crap, I didn't even know trac was supported
[08:28] <pygi> mrevell, poke
[08:46] <kiko> radix, it's only half supported. why don't you help me write support for it?
[08:47] <radix> kiko: is the same code used for migrations from trac?
[08:47] <kiko> radix, no.
[08:47] <radix> kiko: oh. then I guess I have less incentive :)
[08:47] <kiko> radix, what do you want to migrate over?
[08:47] <radix> kiko: Twisted :) (not to say that's going to happen any time soon)
[08:48] <kiko> if it's not happening any time soon, then maybe we should write support for it instead, first?
[09:17] <mrevell> pygi: Hey - sorry for the delay, been having dinner
[09:18] <pygi> mrevell, no problem at all :)
[09:18] <pygi> mrevell, I already planned to sign up for the list, just couldn't get the time
[09:19] <pygi> mrevell, did so now, and will post something in next couple of days
[09:19] <mrevell> pygi: cool :) Thanks. Don't feel any pressure to post, but if you do have feedback, I know the team would find it very useful
[09:20] <pygi> mrevell, yup, have some feedback (as always, hehe)
[09:20] <mrevell> pygi: cool, it's always welcome :)
[09:21] <pygi> feels fresh and much better to use
[09:23] <pygi> mrevell, I found that "THIS LIST IS NOT FOR REQUESTING CD'S" funny tho :)
[09:23] <tsmithe> yes haha /me too
[09:23] <mrevell> pygi: Yes, in the past a number of people have signed up to launchpad-users to request CDs. I think that in the future we should see less of that, though, as we make it easier to go through the ShipIt sign-up.
[09:24] <tsmithe> is the list moderated? or is it because i failed to sign up properly?
[09:24] <czajkowski> mrevell: just the person :)
[09:25] <mrevell> czajkowski: hello!
[09:25] <mrevell> Cillian: hello to you too :)
[09:25] <Cillian> :)
[09:25] <mrevell> wow, is this the, "Come meet Matthew in #launchpad" night? :)
[09:26] <Cillian> Yup
[09:26] <czajkowski> mrevell: if you look for me in #skycon... leaving a message works wonders :)
[09:26] <pygi> mrevell, :-D
[09:26] <czajkowski> mrevell: pretty much, you werent in lugradio
[09:26] <mrevell> czajkowski: Yes, sorry, I got distracted and left you with a ping but nothing else. Hang on, I'll take this to #skycon
[09:30] <pygi> mrevell, well thanks, I won't bug anymore
[09:30] <mrevell> pygi: Hey - you're not bugging me :)
[09:30] <mrevell> pygi: It's great to have your feedback, so if there's anything you need, let me know.
[09:32] <pygi> mrevell, there is, but no one will listen, so I'll be silent :)
[09:35] <tsmithe> hummm. i just killed launchpad (normal launchpad)
[09:36] <tsmithe> trying to register a spec where the name has been taken, firefox dies, go back to the product, notice the spec is there, try and edit details, launchpad integrityerror
[09:36] <pygi> :-D
[09:36] <tsmithe> seems reproducible...
[09:36] <tsmithe> oops :P
[09:36] <pygi> file a bug :P
[09:37] <tsmithe> sorry mrevell :)
[09:37] <mrevell> sorry, been afk
[09:37] <tsmithe> ^^
[09:43] <mrevell> tsmithe: ooh, right, yeha, if you could file a bug, that'd be great
[09:43] <tsmithe> ok :)
[09:43] <tsmithe> on the launchpad product?
[09:44] <mrevell> erm
[09:46] <matsubara> tsmithe: it's likely to be a known problem. if it's not it'll show up on the error logs tomorrow. thanks for the heads up anyway.
[09:47] <tsmithe> so should i file or not?
[09:48] <mrevell> matsubara: thanks
[09:49] <matsubara> tsmithe: what did you change when you tried to edit the details?
[09:49] <tsmithe> milestone
[09:51] <matsubara> tsmithe: was it a product spec that you tried to target against a ubuntu milestone?
[09:51] <tsmithe> hd
[09:51] <tsmithe> *yes
[09:51] <tsmithe> (stupid fingers)
[09:53] <matsubara> tsmithe: it's bug 59971 then
[09:53] <Ubugtu> Malone bug 59971 in blueprint "Target a product specification to a distribution milestone triggers a DB constraint" [Medium,Confirmed]  https://launchpad.net/bugs/59971 - Assigned to Mark Shuttleworth (sabdfl)
[09:53] <tsmithe> https://blueprints.launchpad.net/cinelerra-cv/+spec/cinelerra-review <- that spec already exists on ubuntustudio product. i was trying to set it to have milestone for feisty
[09:53] <tsmithe> hum
[09:53] <tsmithe> really?
[09:53] <tsmithe> i managed with the spec on ubuntustudio
[09:53] <tsmithe> wait no
[09:53] <sabdfl> thanks ubugtu :-)
[09:54] <matsubara> tsmithe: I'm pretty sure it is. the select box shouldn't display the ubuntu milestones as valid targets
[09:54] <tsmithe> yes - they are displayed. and although i thought it had succeeded in setting it, it appears that it hasn't
[09:54] <tsmithe> and when i try now, i get an integrityerror :)
[09:55] <tsmithe> so, yes, matsubara, thanks :_
[09:55] <tsmithe> *:)
[10:00] <matsubara> mrevell, tsmithe: you're welcome.
[10:03] <tsmithe> :)
[10:05] <lifeless> moin
[10:05] <pygi> hey lifeless
[10:09] <static> how do I make a team into a translation group?
[10:14] <pygi> static, ubuntu LoCo team?
[10:15] <pygi> if so, your team needs to get approved by a council (forgot which one, been a while since I was involved)
[10:15] <static> pygi: I just realized I probably don't need to do this. Was just trying to figure out how to allow a team to do translations for an upstream product
[10:15] <pygi> static, ah!
[10:15] <pygi> static, just upload a template (pot) and let people translate
[10:16] <static> pygi: thanks!
[10:16] <pygi> static, yw
[10:18] <carlos> static: hi
[10:18] <static> hey carlos
[10:18] <carlos> static: jamesh told me that you have some question about Rosetta and translation groups
[10:19] <static> carlos: yes, I was just confused about when a translation group was needed. I was trying to set up an upstream product to be able to do translations, and I'm a bit confused about the difference between a team and a translation group
[10:20] <carlos> static: translationgroup is a way to link teams with languages
[10:20] <static> carlos: aha! ok, I don't need one then
[10:22] <carlos> static: you only need it if you want more fine grained privileges (it's from danilo)
[10:23] <danilos> it's not from me
[10:23] <static> :)
[10:50] <radix> wow, is launchpad-users moderated even for subscribers?
[10:57] <tsmithe> radix, it appears so
[11:05] <sabdfl> kiko would know why - i seem to recall some discussion about this, and a lot of spam
[11:05] <sabdfl> might be possible to review it now that we have decent spam filtering
[11:06] <tsmithe> yes - that would be nice
[11:07] <tsmithe> i must say, the ubuntu lists have *very* good spam filters
[11:07] <tsmithe> i didn't appreciate it until i came across alsa-devel
[11:09] <Fujitsu> It was switched to first-post moderation around the end of November, AFAICR.
[11:09] <Fujitsu> (to stop all the `GIVE ME CDs' posts)
[11:09] <tsmithe> why to launchpad-users, though?
[11:09] <Fujitsu> Who knows.
[11:09] <Fujitsu> But there were lots of them.
[11:09] <tsmithe> what makes people choose that? it's crazy!
[11:09] <tsmithe> i'm sure
[11:10] <pygi> tsmithe, didn't you knew people are usually crazy? :)
[11:10] <tsmithe> but first post - that's ok. i've done mine now, so i'm happy :)
[11:10] <tsmithe> pygi, i did, actually. i'm probably included in that ;)
[11:17] <mpt> lifeless, PQM has apparently been processing the same branch for the past 13 hours or so
[11:18] <lifeless> stub disabled it
[11:18] <mpt> Is it re-enabled now?
[11:18] <lifeless> I have done so
[11:18] <mpt> ok, thanks
[11:18] <lifeless> np
[11:19] <mpt> Fujitsu, tsmithe, we also get many bugs reported about Launchpad which are actually about Ubuntu
[11:19] <Fujitsu> mpt: I noticed... Any idea why?
[11:19] <mpt> Work out why that happens, and I'll send you a chocolate fish
[11:20] <Fujitsu> Heh.
[11:20] <tsmithe> mpt, ah ok. i'd like that chocolate fish. better than normal fish, which i hate ;)
[11:25] <kiko> sabdfl, radix: that sounds like it's broken. it should be moderated for unsubscribed users, but not for subscribed ones.
[11:30] <tsmithe> kiko, ok. good to hear that it's known :)
[12:01] <mpt> Gooooooooooooooood afternoon Launchpadders!
[12:03] <Hobbsee> morning mpt!!!
[12:03] <LaserJock> hi mpt
[12:03] <mpt> Not enough hugs in this channel
[12:05] <mpt> http://newsimg.bbc.co.uk/media/images/41500000/jpg/_41500270_mrtickle.jpg
[12:05] <Hobbsee> hehe
[12:07] <mpt> SteveA, are you available to talk about brilliant branching?
[12:07] <mpt> hmm, I guess not
[12:11] <Ubugtu> New bug: #84800 in malone "no way to jump to a bug from frontpage of beta UI" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84800
[12:11] <Hobbsee> hehe
[12:15] <LarstiQ> brilliant branching?


[12:06] <guest777> Hello all)Donate me please a BitCoin adress 1Nuj3pwSaXn4GE2WoVEAiDKTaPozo4mpVX)sorry and thanks)
[12:06] <guest777> pls pls pls)
[17:16] <holstein> lol
[17:32] <holstein> http://wlos.com/news/local/bogus-parking-tickets-surface-in-downtown-asheville
[17:33] <holstein> also.. thats not "fraud"? or impersonating a governing body, or whatever?
[17:33] <holstein> littering? i think when/if that goes, if the person wants to bother, they can end up winning that case..


[00:00] <johnc4510> The new issue of the Ubuntu Weekly Newsletter #158 is now available:
[00:00] <johnc4510> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue158


[19:56] <LongLiveCHIEF> still no wifi connection from modifying the default network-config, however using `netplan apply` as the first script of `runcmd` in the final stage brings network online
[19:57] <LongLiveCHIEF> (groovy gorilla, yesterdays build)
[19:57] <LongLiveCHIEF> i have logs collected and can send wherever if anyone wants a look