[07:34]  * apw yawns
[07:36] <cooloney> morning, folks
[07:40] <apw> cooloney, yo
[07:56]  * cking waves to cooloney
[07:56] <smb> cooloney, Morning
[07:56] <smb> cooloney, Hows the lxc tests thing going?
[07:56] <cooloney> smb: it got some testing error on both panda and my desktop
[07:57] <smb> Nice, problems with the test code or the containers? If you can already tell...
[07:57] <cooloney> smb: did you try that before?
[07:58] <cooloney> smb: the testcase form serge
[07:58] <cooloney> lp:~serge-hallyn/+junk/lxc-test
[07:58] <smb> cooloney, No, did not hear of them before UDS
[07:59] <smb> calling the ppa that way does not really give an impression of quality
[08:00] <cooloney> smb: yeah, did you get serge's email.
[08:01] <cooloney> namespace attach (setns) patches
[08:01] <smb> cooloney, I believe that was to the mailing list so yes
[08:02] <smb> (not that I can remember the contents) But any way... it would be good to talk to Serge about it in some way. Given your distance from each other it may need to be email...
[08:03] <cooloney> smb: yeah, i plan to email out, heh
[08:03] <cooloney> smb: or maybe ping him later tonight
[08:03] <smb> cooloney, can you keep me on cc on any emails. then I can follow a bit along
[08:04] <cooloney> smb: sure, np.
[08:05] <cooloney> smb: from serge's email, those ns patches from Eric is quite old but still out of mainline
[08:05] <smb> cooloney, Yeah he said he wanted to submit some for -next into 3.5. Though that sounded a bit over-optimistic
[08:07] <cooloney> smb: ok, got it. if they can 3.5, that's good for us
[08:07] <cooloney> ppisati: moring, man
[08:07] <apw> smb, bear in mind if its not in there already _now_ its too late
[08:07] <smb> cooloney, I would not hold my breath for it
[08:08] <apw> smb, as the merge window is already open and things coming in
[08:08] <smb> apw, I do bear that in mind a lot
[08:10] <cooloney> apw: yeah, after 2 weeks later, we will know the status of 3.5
[08:10] <ppisati> cooloney: ciao :)
[08:18] <smb> cooloney, Hm, ok, there seem to be some patches for userns on linux-next right now...
[08:23] <cooloney> smb: that's good
[08:23] <cooloney> ppisati: any omap3/omap4 related bug, you need me to take a look?
[08:25] <ppisati> cooloney: well, nothing special
[08:25] <ppisati> cooloney: there's one bug that IMO is a user problem (either hw or power supply problem)
[08:26] <ppisati> cooloney: and then there's another one that's related to the cpu/freq scaling and if i would be in you, i would stay away from that
[08:29] <ppisati> bug 971091
[08:29] <ubot2> Launchpad bug 971091 in linux-ti-omap4 "Pandaboard ES freezes with the default CPU scaling governor ondemand" [Medium,Confirmed] https://launchpad.net/bugs/971091
[08:29] <ppisati> and
[08:29] <ppisati> bug 994368
[08:29] <ubot2> Launchpad bug 994368 in linux-ti-omap4 "linux-ti-omap4 kernel panics on pandaboard ES" [Undecided,Incomplete] https://launchpad.net/bugs/994368
[08:30] <ppisati> if you want to take a look
[08:30] <ppisati> cooloney: ^
[08:48] <cooloney> ppisati: thx, looks like it's a long story
[09:06] <ppisati> cooloney: yep :)
[10:01] <apw> apw@dm:~/git2/ubuntu-lucid$ cat /etc/dpkg/dpkg.cfg.d/multiarch
[10:01] <apw> foreign-architecture i386
[11:39] <ma1> Hi
[11:39] <ma1> #uname -r: 3.1.0-1282-omap4
[11:40] <ma1> I want to compile the ubuntu kernel for the above version on my pandaboard es
[11:40] <ma1> any step by step guide/tutorial available?
[11:43] <ppisati> ma1: https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile
[11:44] <ppisati> ma1: btw, that's not an ubuntu kernel
[11:45]  * ppisati -> lunch
[11:46] <ma1> ppisati: Thanks...but i want to build the kernel natively
[11:46] <ma1> http://www.omappedia.com/wiki/Ubuntu_kernel_for_OMAP4
[11:46] <ma1> what about this link???
[12:55]  * henrix is going out for a drink later today to enjoy the sun!!!
[13:11] <cking> henrix, that makes me feel thirsty
[13:12] <henrix> cking: i'm afraid there's only one thing to do...
[13:12] <cking> buy a beer?
[13:13] <henrix> :)
[13:13] <tgardner> you guys gotta stop talking like that. I've barely started my work day.
[13:13] <henrix> tgardner: heh! it's just that we *do* have sun here, which is something rather unusual :)
[13:14] <tgardner> my weather is gonna suck for the next few days, but it was nice yesterday.
[14:35] <tgardner> ogasawara, apw: I see  a new version of kernel-wedge just got uploaded. we'd better try a Quantal rebuild as soon as it propagates in the archive.
[14:35] <apw> tgardner, sigh
[14:35] <ogasawara> tgardner: ack
[14:37] <ogasawara> tgardner: I also uploaded meta, so we should be good to start also uploading to the backports PPA
[14:37] <tgardner> ogasawara, I saw that
[14:38] <tgardner> ogasawara, starting a precise backports meta package is on my todo list for the day
[14:38] <tgardner> or maybe just use the master package and add something...
[14:39] <ogasawara> hrm, armhf chroot problem.  I've never seen that error before...https://launchpadlibrarian.net/105801887/buildlog_ubuntu-quantal-armhf.linux-meta_<IP_ADDRESS>.3_CHROOTWAIT.txt.gz
[14:40]  * ogasawara will investigate more in 20min
[14:44] <tgardner> ppisati, just pushed Quantal ti-omap4 Ubuntu-3.4.0-201.2. Y'all should prolly have a look before I upload to make sure I didn't screw the pooch.
[14:44] <tgardner> perhaps build it and make it still boot.
[14:44] <tgardner> make sure it still boots*
[14:45] <jsalisbury> apw, Speaking of builds, is it possible to get the 3.4 and newer mainline builds to use the Quantal kernel config instead of Precise?  If it's something I can learn to do, I'd be more than happy to take it on.
[14:45] <jsalisbury> apw, it will help with bug 996075
[14:45] <ubot2> Launchpad bug 996075 in linux "Enable CONFIG_DVB_USB_AZ6007" [Medium,Confirmed] https://launchpad.net/bugs/996075
[14:46] <jsalisbury> apw, When I say mainline builds, I'm referring to the ones at: http://kernel.ubuntu.com/~kernel-ppa/mainline/
[14:53] <apw> jsalisbury, ahh yes, thats on my todo, perhaps now is a good time as any
[14:54] <jsalisbury> apw, no rush if your busy with other stuff
[14:57] <apw> jsalisbury, its an easy chan ge
[14:57] <apw> i presume we want to build everything p and later in precise chroots too
[14:58] <jsalisbury> apw, even q?  in precise chroots?
[14:59] <apw> we build l->o in lucid chroots cause you might want to test them back to there
[14:59] <apw> makes the deps simpler when shoveing them on to do bisects on older releases
[15:06] <apw> jsalisbury, probabally we should be making them actually in both the right release and the lts to which they apply too
[15:06] <jsalisbury> apw, ah oh.
[15:07] <jsalisbury> s/oh/ok/
[15:32] <apw> jsalisbury, ok i have just updated the mainline poop to do things 'right' for quantal (i hope), i have kicked a v3.4 off with the new quantal/precise combo to see what happens, you may wish to see if it resolves that bug when it pops out the other end
[15:33] <jsalisbury> apw, awesome.  thanks for the help, andy!
[15:36] <apw> jsalisbury, np
[15:36] <ogasawara> jsalisbury: for the meeting today, can we add back the section where I nag about work items :)
[15:37] <jsalisbury> ogasawara, ack
[15:47] <jsalisbury> ogasawara, Is this the right page to add to the meeting agenda for work items:
[15:47] <jsalisbury> http://status.ubuntu.com/ubuntu-quantal/milestones.html
[15:48] <ogasawara> jsalisbury: I'd actually suggest status.ubuntu.com/ubuntu-quantal/canonical-kernel-distro-team
[15:48] <ogasawara> jsalisbury: it's more specific to our team
[15:48] <jsalisbury> ogasawara, ok, I'll make the change
[15:51] <jsalisbury> ogasawara, What would you like for the Quantal equivilent page for https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Precise
[15:51] <jsalisbury> ogasawara, this:
[15:51] <jsalisbury> https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Quantal
[15:51] <ogasawara> jsalisbury: yah use that, I'll make the page right now
[15:52] <jsalisbury> ogasawara, cool, thanks
[16:09] <kees> sweet, sweet API stability. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=259e5e6c75a910f3b5e656151dc602f53f9d7548 upstream PR_SET_NO_NEW_PRIVS will, in fact, continue to match what is in 12.04. *whew*
[16:12]  * ppisati -> brb
[16:28] <ogasawara> infinity: we're seeing buildd chroot problems with nihal, eg -> https://launchpad.net/ubuntu/+source/linux-ti-omap4/3.4.0-201.2/+build/3509520/+files/buildlog_ubuntu-quantal-armhf.linux-ti-omap4_3.4.0-201.2_CHROOTWAIT.txt.gz
[16:29] <ogasawara> infinity: we've seen this twice now
[16:43] <jsalisbury> https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&
[16:43] <jsalisbury> field.subscriber=&field.tag=quantal&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.upstream_target=&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_n
[16:43] <jsalisbury> o_blueprints=on
[16:54] <jsalisbury> **
[16:54] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:54] <jsalisbury> **
[17:08]  * ppisati run to the gym
[17:15] <ogasawara> smb: http://status.ubuntu.com/ubuntu-quantal/canonical-kernel-distro-team-quantal-alpha-1.html
[17:16] <cking> kinda handy to recall what I had to do :-)
[17:17] <ogasawara> smb: I think I missed it when I did my copy and paste for the meeting
[17:17] <smb> cking, Yeah, exactly the reason I wanted to look at it
[17:18] <smb> ogasawara, Ah! /me already feared starting blindness
[17:18] <cking> burndown is hopefully not a synonym for burnout
[17:23] <cking> somtimes the only east way to fix a problem is with a screwdriver..
[17:24] <dantti> Hi, I've manually downloaded and installed 3.4 kernel from some mainline url, I have made a patch that went into rc7 but it's not working on the 3.4, is there better place to get new packaged kernels?
[17:26] <dantti> Iǜe also tried the xorg-edgers package but weirdly that doesn`t recognize any kind of hw I have even keyboard...
[17:34] <dantti> ogasawara: hay you tried your last kernel update? built just finished I installed and nothing worked :P
[17:35] <ogasawara> dantti: can you be more specific?  I've got it running here just fine.
[17:35] <ogasawara> dantti: did you make sure you installed the extra's package?
[17:36] <dantti> ogasawara: hmm sorry, all I saw was some amd microcode errors.. should I install the extra package?
[17:37] <ogasawara> dantti: with the latest 3.4.0-3.7 upload, the extra's package is necessary
[17:37] <dantti> I didn't installed those for the 3.4.0-2 package and it worked
[17:37] <dantti> ah right that's why the -2 worked
[17:37] <dantti> I'll install that then, thanks :)
[17:39]  * henrix is going to enjoy the sun for an hour or so. will be back later...
[17:39] <ogasawara> henrix: I think you should enjoy the sun for more than an hour and don't come back till tomorrow
[17:40] <henrix> ogasawara: yeah, but i have only an hour left of sunshine :)
[17:59]  * cking follows henrix idea
[18:07] <infinity> ogasawara: Thanks for the heads-up.
[18:09] <ogasawara> infinity: wasn't sure if it was a known issue.  retrying the builds till they landed elsewhere seems to work around it.
[18:10] <infinity> ogasawara: It's a known issue.  Machine needs to be rebooted and tidied up.  Unsure precisely what's breaking it, and not keen on debugging it, since they're running natty...
[18:27] <dantti_laptop> ogasawara: using extra did make the boot detect stuff, but still my patch isn't available there  if I don't see HID_BATTERY_STRENGTH on the /boot/config it means it disabled?
[18:29] <ogasawara> dantti_laptop: which patch?  and yes, HID_BATTERY_STRENGTH looks to be disabled
[18:29] <ogasawara> ubuntu-quantal/debian.master/config$ grep -rn "HID_BATTERY_STRENGTH" *
[18:29] <ogasawara> config.common.ubuntu:2055:# CONFIG_HID_BATTERY_STRENGTH is not set
[18:29] <dantti_laptop> ogasawara: I've made a patch that probes the battery of hid devices it's upstream since 3.4-r7... can you enable it then?
[18:30] <dantti_laptop> I thought default would be y
[18:30] <ogasawara> dantti_laptop: can you file me a quick bug in lp for it and I'll get it on the todo list
[18:30] <dantti_laptop> ogasawara: ok, thanks :)
[18:31] <ogasawara> dantti_laptop: looks like the default was n
[18:31] <ogasawara> config HID_BATTERY_STRENGTH
[18:31] <ogasawara>         bool
[18:31] <ogasawara>         depends on HID && POWER_SUPPLY && HID = POWER_SUPPLY
[18:31] <ogasawara>         default n
[18:32] <dantti_laptop> hmm right, I'll poke people if it should be y
[18:32] <ogasawara> dantti_laptop: what's it provide exactly?  not much of a description in the Kconfig
[18:33] <dantti_laptop> ogasawara: well for example I have an Apple keyboar and magic track pad, both blue tooth and battery operated, this patch provides a power_supply interface to know the battery strength
[18:33] <dantti_laptop> it should work for all HID devices that conform to the HID standard, but we already have quirks :P
[19:13] <ogasawara> tgardner: hrm, I think we were a little too aggressive by completely removing the generic-pae meta package.  we still need it, but just need to have it redirect to the generic meta package.  without it we've completely orphaned generic-pae users in Precise from upgrading.
[19:20] <dantti_laptop> ogasawara: I'm always lost on launchpad, where do I report a new bug? :P
[19:21] <tgardner> ogasawara,  think thats where update-manager comes into play. we orphaned the -pae flavour on purpose.
[19:21] <tgardner> ogasawara, I'm still awaiting a response from Michael Vogt. I'll bug him on IRC in the morning.
[19:22] <ogasawara> tgardner: I though update-manager-core was only handling the package reaping?
[19:22] <tgardner> ogasawara, nope, the archive handles reaping. update-manager handles upgrades from release to release.
[19:23] <tgardner> ogasawara, now that you've uploaded the Quantal meta package I can experiment with upgrades from Precise to Quantal.
[19:23] <ogasawara> tgardner: ack
[19:23] <tgardner> using the upgrade-manager
[19:24] <ogasawara> dantti_laptop: run ubuntu-bug linux from a terminal, or alternatively bugs.launchpad.net/ubuntu/+source/linux/+filebug
[19:25] <ogasawara> dantti_laptop: that's for kernel specific bugs
[19:28] <dantti_laptop> thanks
[19:42] <dantti_laptop> ogasawara: done https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1003090
[19:42] <ubot2> Launchpad bug 1003090 in linux "Please enable HID_BATTERY_STRENGTH on xorg-edgers and quantal packages" [Undecided,New]
[19:43] <dantti_laptop> the cmd line tool complained about the package not being official...
[19:53] <infinity> tgardner: We don't want logic like this in update-manager, if we can avoid it.
[19:53] <infinity> tgardner: generic-pae should depend on generic until the next LTS, IMO.
[19:54] <infinity> tgardner: Special logic in update manager should be seen as a way to work around packaging bugs, not an excuse to not have packages upgrade cleanly.
[19:55] <tgardner> infinity, what will change at the next LTS ? AFAICT the update-manager will (by default) install the default kernel in the installer iff there is no valid kernel choice.
[19:56] <infinity> tgardner: Nothing changes at the next LTS, except that we get to reset the upgrade paths we support.
[19:56] <tgardner> infinity, well, we still have to support LTS->LTS upgrades, and I'd still have the problem of upgrading generic-pae to generic.
[19:56] <infinity> tgardner: The goal should be for "apt-get dist-upgrade" to actually function.  update-manager/do-release-upgrade can have workarounds for when that's not true, but we shouldn't *expect* to clean up in update-manager when there's a perfectly viable solution at the packaging level.
[19:57] <tgardner> infinity, everything I've read suggests that the recommended upgrade mechanism is via the upgrade-manager
[19:57] <infinity> tgardner: Err, yes, which is why I said "until the next LTS".  As in, up to and including 14.04, generic-pae should depend on generic, for smooth upgrades.
[19:57] <infinity> tgardner: It's the recommended way to upgrade, that doesn't mean ignoring package relationships.
[19:58] <infinity> tgardner: The less smart update-manager needs to be, the better off we all are.
[19:58] <tgardner> infinity, lemme experiment with what it actually does.
[19:58] <infinity> tgardner: I'd rather you experiment with what apt-get does.
[19:58] <ohsix> upgrade-manager didn't account for the netbook remix upgrades on my netbook a few releases ago, and i only just realized last night that is why it's broken now :P
[19:59] <tgardner> infinity, I already know what apt-get does.
[19:59] <infinity> tgardner: Ultimately, update-manager is a thin wrapper around apt, with hacks and workaround for when we screw up.  If we don't screw up, we don't need workarounds.
[20:00] <infinity> Let me put it differently.  I'll ship a linux-generic-pae-meta myself to smooth the upgrade process if you don't. :P
[20:00] <infinity> Cause that's saner than upgrade hacks.
[20:01] <tgardner> infinity, there has to be an elegant way to orphan a package.
[20:01] <infinity> tgardner: Yes, and in our case, it's on LTS boundaries.
[20:01] <infinity> tgardner: The kernel isn't a special snowflake here.
[20:02] <infinity> (We did the same thing with openoffice->libreoffice, with metapackages that lived to upgrade from A to B until precise)
[20:02] <infinity> Besides, it's only a transitional meta package.  You *are* orphaning the actual kernels.
[20:02] <tgardner> infinity, I don't see what the LTS boundary has to do with it. I'm still stuck with generic-pae when 14.04 releases.
[20:03] <infinity> Eh?
[20:03] <tgardner> the generic-pae meta package still exists. I'm trying to reduce the number of them.
[20:03] <infinity> No, you have each of linux-*-generic-pae depending on linux-*-generic, and you make all the linux-generic-pae stuff be labelled as transitional packages.
[20:04] <infinity> You're no longer stuck with the kernel.  You might be stuck with an empty package, but that's a big who cares.
[20:04] <infinity> (We also have tools that can deal with this, including update-manager itself)
[20:05] <tgardner> infinity, well, lemme see how transitional works.
[20:07] <ohsix> from what i understand of how package names are changed, it's basically what infinity is saying, at least in debian
[20:08] <apw> infinity, a transitional package is just a normal meta type package deping on the replacement, with the text saying its transitional, right?  there is nothing speicial about them is there?
[20:08] <ohsix> right
[20:09] <ohsix> and it generally stays there for a "long" time, between the largest expected upgrade distance (like across one release or 3)
[20:10] <infinity> apw: That's it, yes.  And, in Debian (and we should pick up this convention), they also now live in Section: metapackages, I believe.
[20:10] <infinity> apw: The key is that they need to exist (in Debian) from stable to stable, and (in Ubuntu) from LTS to LTS.
[20:10] <infinity> Then you drop 'em like a hot potato, and no one cares.
[20:12] <infinity> apw: Oh, and the real reason I popped my head in here wasn't to have a hissy fit about metapackages.  It was to ask what's up with the weird diff for -24.39 in your PPA.
[20:12] <apw> infinity, point me at it
[20:12] <infinity> apw: AIUI, linux-3.2.0/drivers/ata/ata_piix.c is meant to be the only change, I'm trying to sort out if I should care about what the diff says about linux-3.2.0/arch/x86/kernel/reboot.c, or if that's just some bogon.
[20:12] <infinity> apw: https://launchpadlibrarian.net/105734948/linux_3.2.0-24.38_3.2.0-24.39.diff.gz
[20:13] <tgardner> infinity, so, if you have this transitional meta package in 14.04, how can you get away with orphaning it in 14.10? don't you create the same apt upgrade issue as we have currently ?
[20:13] <apw> infinity, i think we should be not expecting that diff indeed
[20:14]  * apw will poke as i didn't see it in the git diff
[20:14] <ohsix> in 14.04 it would install the other package, and in 14.10 it would cease to exist
[20:14] <infinity> tgardner: No, cause of linux-image-generic-pae depends on linux-image-generic (note, it's the meta depending on the meta), then dropping generic-pae post-14.04 harms nothing, the user is upgraded.
[20:14] <infinity> s/of/if/
[20:14] <apw> tgardner, by making linux-image-generic-pae depend on linux-image-generic, we know they have linux-image-generic on their system
[20:14] <apw> tgardner, so they are good going forward
[20:15] <tgardner> apw, doh. that makes sense
[20:15] <apw> tgardner, we likely can do something clever in 14.10 to make linux-image-generic-pae uninstall itself, a Conflicts: or something
[20:15] <tgardner> ok, I'll update Quantal meta
[20:16] <apw>  debian.master/changelog                            |   14 +
[20:16] <apw>  drivers/ata/ata_piix.c                             |    7 +
[20:16] <ohsix> you could do a conflict, but generally kernels are left behind (there are exclusions in aptitude and stuff for "important" base packages too)
[20:16] <infinity> apw: The conflict really isn't necessary, but you could do so, if the metapackage really offends you.
[20:16] <apw> infinity, ^^ ok thats the diff between the two at the git tag level ... wtf
[20:17] <infinity> apw: Weird.  Could just be debdiff doing something silly.  I can unpack source A and source B and compare the actual files.
[20:17] <apw> infinity, if you don't mind ... its very odd to my eye
[20:18] <infinity> (That said, we should have a certain amount of auto-tidying for things that claim to be transitional anyway.  And if that's not working, we should fix it... But either way, it's a few wasted bytes for a smooth upgrade, not a huge deal)
[20:19] <infinity> apw: Yeah, let me grab the original sources here and see if debdiff's just being brain-dead.
[20:19] <apw> interdiff impossible; taking evasive action
[20:20] <apw> any idea what the heck that means in the diff ^^ infinity
[20:20] <infinity> Yeah.  Whatever "evasive action" means.
[20:20] <infinity> I'm as puzzled as you. ;)
[20:21] <apw> infinity, also does kernel-wedge use random hash order for the control file?  the diff there seems mad too
[20:21] <infinity> If I had to guess, I'd say maybe your origs don't match, which would mean your diffs don't either.  But I'd like to think you're more careful than that. ;)
[20:21]  * infinity is checking anyway.
[20:21] <apw> infinity, you can (no longer) upload with bad orig's can you ?
[20:21] <infinity> apw: k-w, the way you guys run it, ends up pretty system-dependent.
[20:22] <infinity> apw: Okay, so the origs are the same.  Weird.  Checking the sources now.
[20:22] <apw> infinity, i know we managed it in 2.6.24 but only there cause there really were two orig's in the launchpad database by then already
[20:22] <apw> infinity, and i know smoke poured out of several heads until they editied the db by hand to fix it
[20:23] <apw> but i thought now it was no longer possible, and we'd even tripped the error on it
[20:23] <infinity> apw: You can upload to a PPA with any orig you want.
[20:23] <infinity> apw: Which is where the PPA->archive thing can be a bit of a headache.
[20:24] <infinity> (In this case, though, it's the correct orig, so I dunno what debdiff is on about)
[20:24] <infinity> Has the same conniption locally, though.
[20:27]  * infinity falls asleep waiting for diff -urN.
[20:27] <infinity> apw: Okay, a proper diff is clean.  This is clearly a bug in debdiff. :P
[20:28] <apw> infinity, well spotted anyhow
[20:28] <infinity> apw: Crisis averted.  I'll be accepting this into -proposed for you in a bit, and seeing about fast-tracking the process.
[20:29] <infinity> apw: Oh, and someone went and created tracking bugs for rebasing derivatives.  That may not be necessary for, say, ARM machines that don't (I'd go so far as to say can't) use that driver. :P
[20:30] <infinity> s/bugs/tasks/
[20:30] <apw> infinity, indeed, the derivative people are meant to use their noggings and close them 'invalid' when its not needed
[20:30] <infinity> Oh.  I didn't realise you expected noggin use.  That's just crazy talk.
[20:30] <apw> ikepanhc, ppisati, you likely have rebase requests for precise which don't need doing, as its an x86 only fix ... do check before doing it
[20:47] <infinity> bjf: Let the QA machine roll on that precise SRU.  I'm prepared to fast-track it once some minimal verification and sanity checking is done; see the tracking bug.
[20:57] <tgardner> ogasawara, please review pushed ubuntu-quantal-meta. infinity convinced me I had my head up my ass.
[20:57] <ogasawara> tgardner: hehe, ack
[21:04] <vanhoof> apw: would these have hit armadaxp as well?
[21:09] <tgardner> ogasawara, I checked that all of the amd64 packages are installable. If you're happy then I think you should package up Quantal meta and upload.
[21:09] <bjf> apw, infinity would like confirmation that the one commit on the precise kernel in -proposed does indeed do what you expect (don't need to test it tonight)
[21:09] <ogasawara> tgardner: yep, it looks good here.  I'll get it uploaded.
[21:10] <infinity> tgardner: Except, weren't the changes to i386 packages? ;)
[21:10] <infinity> apw: bjf would like you to know that I'm incapable of talking to you directly (I didn't realise you'd be QAing your own upload)
[21:11] <tgardner> infinity, they were. I suppose I should do the whole test. grumble,
[21:11] <ogasawara> tgardner: I was gonna test for you.  but if you want to, I won't fight you over it :)
[21:11] <infinity> tgardner: Eh, if Leann says it looks sane, I believe her.  She's smarter than us.
[21:12] <tgardner> ogasawara, I;vev got it built. gimme 5 min
[21:12] <ogasawara> tgardner: ack
[21:22] <tgardner> ogasawara, tested i386 packages, packaged and uploaded. now I'm really EOD.
[21:23] <ogasawara> tgardner: sweet, thanks
[21:23] <apw> infinity, bjf, ok queued for first thing in the am
[21:23] <bjf> apw, thanks


[00:48] <xu-irc13w> Hello everyone, I have never used IRC before. Do you all read this?
[00:52] <Bashing-om> xu-irc13w: Yup - looking good :D
[00:53] <xu-irc13w> Super!
[00:54] <xu-irc13w> I am wondering if I could get advice on a config issue...
[00:55] <Bashing-om> xu-irc13w: Procedure is just to ask an xubuntu question - and await a response.
[00:56] <xu-irc13w> Okay cool thank you.
[00:57] <xu-irc13w> I have an old macbook air loaded with xubuntu. I would like the default behavior of the function keys to not control system stuff like volume or screen brightness. Any ideas how to accomplish this?
[01:05] <Bashing-om> xu-irc13w: See: https://askubuntu.com/questions/90513/how-do-i-change-my-keyboard-shortcuts-in-xubuntu .
[01:15] <xu-irc13w> This didn't help, there is no keyboard shortcut for toggling the function keys.
[01:17] <xu-irc13w> I may be able to do something kinda hacky and have the volume button remap to f11 etc...
[01:18] <Bashing-om> xu-irc13w: Sorry no experience - others here can advise the better.
[04:38] <xu-irc13w> Hello, this was the person earlier asking about the fn key on an apple keyboard. I found a resolution to this issue here https://help.ubuntu.com/community/AppleKeyboard under the change function key section. Now I understand a bit more... if you get the question again you could send them here.
[05:06] <xu-irc43w> Just installed xubuntu 21.04 and facing issues in configuring openconnect VPN in NetworkManager
[05:06] <xu-irc43w> it is working in 20.04 in my other laptop
[05:08] <xu-irc43w> edit settings for VPN profiles in NetworkManager GUI does not show any fields related to VPN configuration
[05:13] <xu-irc43w>  network-manager-openconnect-gnome package was missing
[11:47] <nullray>  Hey guys, I just installed Xubuntu 21.04 and I noticed that some keyboard shortcuts don't work correctly, even after changing them from the appropriate settings application. I wanted to see if this is a know issue or where to report it
[11:48] <Unit193> I believe the release notes mention that may happen if xfsettingsd isn't running.
[11:49] <nullray> If i try to get the status of that service I get: Unit xfsettingsd.service could not be found.
[11:49] <nullray> I tried replacing xfce4-keyboard-shortcuts.xml with the one from Xubuntu 20.04 and I don't have the problem anymore
[11:51] <nullray> To be more specific, the shortcut for tiling_right (Super + Right) does not work with the default config file, even thought tiling_left works just fine
[11:51] <nullray> If I go to Window Manager > Keyboard and I set the tiling_right shortcut again, it works for a few minutes and then it stops working again
[11:54] <nullray> On the release page of 21.04 I see some mentions about changes to keyboard shortcuts so I think the issue is Xubuntu specific
[16:34] <Yo44> Hi so i just installed xubuntu on virtual box and restarted and now it says please remove the installation media how would i do that
[16:37] <diogenes_> Yo44, in virtualbox settings.
[16:38] <Yo44> I can do that whilst the vm is running
[16:41] <diogenes_> vm settings > storage and remove ISO
[16:41] <Yo44> Thank you very much
[16:42] <diogenes_> you're welcome
[18:40] <xubuntu70i> hello
[18:40] <xubuntu70i> does this work?
[18:43] <genii> it did
[18:55] <Maik> fly by


[02:17] <wgrant> Ooh.
[02:17] <wgrant> The new bug listings are mostly nice.
[02:28] <wallyworld_> StevenK: you working on 884217?
[02:30] <StevenK> wallyworld_: I have a branch for it
[02:31] <wallyworld_> StevenK: the reason for asking is that i am thinking about implementing a security adaptor such that if the logged in user can view the context undet which team name visibility is required, they can see the team name
[02:31] <wallyworld_> so if the team name needs to be displayed because the team is a bug subscriber, then the context would be the bug
[02:32] <wallyworld_> these rules would replace any current security adaptor for private team visibility
[02:32] <StevenK> I think we only have the TAL formatter
[02:32] <wallyworld_> StevenK: so i wanted to be sure that we weren't going to do the same thing etc
[02:33] <StevenK> Which returns <hidden> and soft OOPSes a MixedVisibilityError
[02:33] <wallyworld_> i'll need to dig around and see what needs to be done
[02:33] <wallyworld_> to fix it
[02:34] <wallyworld_> but i think the above sounds ok?
[02:58] <jtv1> StevenK: [BS]PPH.{binary,source}packagename have been fully populated now?
[02:59] <bac> hi, lifeless, sorry i had to run
[02:59] <StevenK> jtv: Not even close.
[02:59] <jtv> Oh.
[02:59] <jtv> Damn Raphaël and his clever ideas.
[02:59] <bac> lifeless: the tests that actually failed are those that use the helper, such as testBadUrlBzrSshCaught
[03:00] <jtv> StevenK: I guess you'll add not-null constraints when done.
[03:00] <bac> and they do pass on their own.  they only fail if run after the new test i introduced, which makes me think i've done something Bad(tm) in that test
[03:00] <jtv> hi bac :)
[03:00] <bac> hi jtv
[03:00] <StevenK> jtv: It is being blocked by long running transactions from the publisher, and if that isn't running, then it's the backups.
[03:00] <lifeless> bac: thats very unusual then isn't it!
[03:01] <bac> lifeless: yeppers
[03:01] <lifeless> bac: uhm, I'm not entirely here today; can you drop me a mail and I will look first thing tomorrow ?
[03:01] <jtv> StevenK: ironic, since I was also hoping to use the column to speed up the publisher.
[03:01] <bac> lifeless: sure.  thanks.
[03:01] <bac> jtv: staying dry?
[03:02] <jtv> bac: moving around to do so, but yes.  In the house, last we know is it got up to just below the kitchen counter-top.
[03:02] <jtv> The hip new word is revacuee.
[03:41] <jtv> StevenK: perhaps there's more we can do to break up those long-running publisher transactions?
[03:47] <StevenK> Fixing the dominator would be one, I think.
[03:50] <jtv> Catch 22.
[03:51] <jtv> StevenK: the updater code looks like it's probably slower than necessary.
[03:52] <StevenK> jtv: You need my denorm work to make the dominator faster?
[03:53] <jtv> It'd help, yes.  I've got about 5 branches waiting for rollout, and those will probably help, but it's getting close to the end of the low-hanging fruit.
[03:54] <jtv> Some things that I think would speed up the updater:
[03:54] <jtv>  * Don't order by id.
[03:54] <jtv>  * Bulk-load the [BS]PRs.
[03:55] <jtv>  * Don't load the [BS]PNs at all—all you need is their ids.
[03:55] <jtv>  * More radical: don't load anything, just let the DB do the work.
[03:57] <poolie> is this change to block reopening fixreleased bugs new?
[03:58] <jtv> poolie: EWIN?
[03:58] <poolie> no
[03:58] <wgrant> poolie: It's at least several months old.
[03:58] <wgrant> Maybe even a year now.
[03:58] <poolie> perhaps i just never hit it
[03:59] <wgrant> poolie: The reporter and bug supervisor can reopen.
[03:59] <wgrant> But not eg. the assignee.
[03:59] <poolie> hm
[04:00] <poolie> i guess i'm not a supervisor for bzr-svn
[04:00] <poolie> :/
[04:01] <wgrant> Indeed.
[04:01] <wgrant> That's ~bzr-svn, which has only three real members.
[04:02] <poolie> ffs
[04:04] <poolie> i see, i thought it changed recently because robert just answered a year-old question about it
[04:17] <poolie> wgrant, StevenK, lifeless, what are we going to do with https://code.launchpad.net/~vorlon/launchpad/sbuild-multiarch-syntax/+merge/81385 ?
[04:18] <wgrant> poolie: Land it.
[04:18] <poolie> *hug*
[04:22] <wgrant> poolie: Don't add [no-qa] to the commit message.
[04:22] <wgrant> Rather use bzr lp-land --no-qa
[04:22] <wgrant> Or ec2 land --no-qa
[04:22] <wgrant> That adds it automatically.
[04:22] <wgrant> And hopefully avoids confusing things.
[04:24] <poolie> ok
[04:24] <poolie> i wonder if there is a bug for it
[04:25] <wgrant> I don't think so. I've discussed it with various people in person, but I don't recall a bug.
[04:25] <poolie> not obviously
[04:25] <poolie> and it's out-of-band qa anyhow
[04:26] <micahg> poolie: I think we have security builds going for the next 9 hours
[04:27] <micahg> eh, semi-wrong channel, meh
[04:39] <wgrant> Hah.
[04:39] <wgrant> There's no UNIQUE bugsubscription(bug, person)
[04:40] <StevenK> The UI forbids it, though?
[04:41] <wgrant> Probably mostly.
[04:41] <wgrant> poolie: Not going to make that bug Critical+regression? :)
[04:41] <poolie> i guess i could
[04:42] <poolie> rebooting
[04:47] <nigelb> jamesh: Hi, around?
[04:54] <nigelb> Ah, its lunch time in Perth.
[05:02] <jamesh> nigelb: hi
[05:06] <nigelb> jamesh: Hey, are you the James listed as Uploader on PyPI for django-openid-auth? :)
[05:06] <jamesh> nigelb: yeah
[05:06] <nigelb> jamesh: Excellent, 0.4 was uploaded as django-openid-auth_0.4.tar.gz as opposed to -0.4 which leads to pip not finding it :(
[05:08] <nigelb> It was fun tracking that down, pip search django-openid-auth says 0.4 is latest, but installing doesn't work.
[05:08] <jamesh> nigelb: ah. I didn't actually roll the 0.4 release (achuni handled it, iirc)
[05:09] <nigelb> jamesh: ah. I couldn't find achuni on IRC, so I thought best to let you know :)
[05:09] <jamesh> nigelb: could you file a bug about it so we don't mess it up for 0.5?
[05:10] <nigelb> cool, will do.  Is there a way to fix 0.4?
[05:12] <jamesh> nigelb: I don't really use pip.  Where is the error occurring?
[05:12] <nigelb> jamesh: let me get you a pastebin
[05:14] <nigelb> jamesh: http://paste.ubuntu.com/732749/
[05:14] <nigelb> Hrm. I guess I could try installing _0.4
[05:15] <nigelb> Nope, didn't work.
[05:16] <jamesh> nigelb: anything relevant in the log file that paste mentions?
[05:16] <nigelb> yup
[05:16] <nigelb> sec
[05:18] <nigelb> jamesh: http://paste.ubuntu.com/732755/
[05:19] <jamesh> nigelb: that's weird: Could not fetch URL http://launchpad.net/django-openid-auth/trunk/0.4/+download/django-openid-auth_0.4.tar.gz (from http://pypi.python.org/simple/django-openid-auth/): HTTP Error 404: Not Found
[05:20] <jamesh> checking that here, I get "303 See Other" response pointing at the file in the librarian
[05:20] <nigelb> Oh.
[05:20] <nigelb> That is weird.
[05:22] <wgrant> stub1: around?
[05:25] <poolie> i think i will build a package of the buildd stuff now just to test
[05:25] <poolie> and then do an update after vorlon's stuff lands
[05:26] <wgrant> poolie: Sounds good.
[05:27] <nigelb> jamesh: I'm guessing the usual download is directly from PyPI which it can't find now.  Anyway, filed bug 887882
[05:27] <_mup_> Bug #887882: Can't install django-openid-auth 0.4 via pip <django-openid-auth:New> < https://launchpad.net/bugs/887882 >
[05:30] <huwshimi> wgrant: I saw you said something about the new bug columns earlier. Are they live somewhere or did you just see a mockup?
[05:30] <jamesh> nigelb: thanks
[05:31] <nigelb> :)
[05:31] <wgrant> huwshimi: Join https://qastaging.launchpad.net/~custom-buglisting-demo (it's Open) and you'll see them on qas.
[05:33] <nigelb> oooh.
[05:33] <poolie> hi nigelb
[05:34] <poolie> wgrant, only qas for now?
[05:34] <nigelb> Afternoon poolie :)
[05:34] <huwshimi> wgrant: Ah, perfect, thanks
[05:35] <stub1> wgrant: yo
[05:35] <wgrant> poolie: Yes.
[05:35] <nigelb> zomg. Can't wait. custom bug listings is *amazing*
[05:38] <wgrant> stub: It was suggested that I try the new schema without the denormalisation (so, adding policy to AccessPolicyArtifact, meaning that AccessPolicyGrant has either policy or artifact set, not both).  I managed to get the equivalent Ubuntu query down to only 10% slower than the denormed version on DF (~650ms), but for products it's around ~100ms, which is slower than the original.
[05:38] <wgrant> This seems to be because it always does a seq scan on accesspolicygrant.
[05:38] <wgrant> Rather than indexing into it.
[05:38] <wgrant> Can't work out why.
[05:38] <wgrant> http://paste.ubuntu.com/732768/ is the setup and some sample queries.
[05:40] <wgrant> The third query (one CTE and some subselects) is the fastest for Ubuntu. The others sit at 1-1.5s.
[05:40] <wgrant> But I can't get it to not seq scan apg.
[05:40] <poolie> that is nice
[05:40] <poolie> i wish the colors were better chosen though
[05:40] <wgrant> poolie: What in particular?
[05:41] <wgrant> I think Low should not be bold and black.
[05:41] <poolie> i agree
[05:41] <poolie> i would like the importance things to be on one spectrum, so their ordering is reflected in the colors
[05:41] <wgrant> Yeah.
[05:42] <poolie> and i think i would like them not to overlap with the status colors
[05:42] <wgrant> They're the same as they are now.
[05:42] <poolie> huwshimi, what do you think?
[05:42] <poolie> i like incremental changes
[05:42] <wgrant> Red/Orange/Yellow... Black/Blue
[05:42] <poolie> but for things like this it seems like it would be a shame not to make a better splash
[05:42] <wgrant> Hmm.
[05:42] <wgrant> Actually.
[05:42] <wgrant> They're the same as the current *text* colours.
[05:43] <wgrant> Which is Red/Orange/Green/Black/Blue.
[05:43] <huwshimi> wgrant, poolie: We actually have a set of colours that the design team use for statuses
[05:43] <poolie> i wonder if that icon next to the product name is really earning its keep
[05:43] <huwshimi> wgrant, poolie: I haven't seen this black before
[05:44] <wgrant> Rather than the icons, which are Red/Reddish/Orange/Yellow/Blue
[05:44] <wgrant> Which probably makes more sense.
[05:44] <wgrant> Except for Yellow being yellow.
[05:44] <wgrant> Which is a bit ew.
[05:45] <poolie> huwshimi, and are these colors on qas the official colors?
[05:45] <huwshimi> poolie: Nope
[05:45] <poolie> i guess specifically 'medium' has a very bold green which is more saturated (to my eye) than High
[05:45] <poolie> and Low even more so
[05:45] <poolie> and Wishlist too
[05:45] <poolie> :)
[05:45] <wgrant> Yeah, Medium and Low are really obvious.
[05:46] <huwshimi> poolie: I believe these are the same colours we used to have, with the exception of the black
[05:46] <poolie> i think that's true
[05:46] <wgrant> Particularly since High/Critical are the same colour as Triaged, which is the usual status for bugs with an importance.
[05:46] <wgrant> So there's no contrast.
[05:46] <huwshimi> wgrant: I had thought the status colours were going to be removed
[05:46] <wgrant> Hmm, interesting.
[05:47] <poolie> also the small caps importance next to the regular status is a little jarring
[05:47] <huwshimi> It's been a long time since I've seen this work and clearly I need to do a proper review
[05:47] <poolie> and they are oddly aligned
[05:47] <wgrant> There was a bug filed overnight about Fix Committed looking like an ajax link.
[05:47] <poolie> 'ajax link' :)
[05:47] <wgrant> Bug #887576
[05:47] <_mup_> Bug #887576: new bug listing importance is difficult to read <bug-columns> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/887576 >
[05:47] <wgrant> Bug #887575
[05:47] <_mup_> Bug #887575: fix released and fix committed status color in new bug listing look like ajax action links <bug-columns> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/887575 >
[05:48] <wgrant> Interestingly, the first bug's title mentions importance, but description says status.
[05:52] <wgrant> Hmm.
[05:52] <wgrant> GitHub's status styleing on the issue page itself is suspiciously similar to our new listings' importance styling.
[05:53] <poolie> wgrant, yeah, and unfortunately there is a bit more logic to them styling them that way
[05:53] <wgrant> Yes.
[05:53] <poolie> which is that they are tag-type things that can be dragged around
[05:57] <wgrant> Well, labels are separate, but all the category-related things seem to be styled like that.
[05:57] <wgrant> Labels, statuses, filters.
[05:58] <wgrant> And Google Code's issue tracker is just hilarious.
[05:59] <wgrant> huwshimi: Are the desired colours shown somewhere?
[05:59] <huwshimi> wgrant: Not that I know of
[06:00] <huwshimi> wgrant: I have some hex codes
[06:00] <wgrant> Do their values map reasonably well onto ours?
[06:01] <huwshimi> wgrant: Yeah, let me grab a screenshot
[06:02] <wgrant> poolie: What do you think of the general prominence of the importance?
[06:02] <wgrant> poolie: It seems like it's massively emphasised over the status.
[06:02] <wgrant> When the status is possibly more important.
[06:03] <poolie> i find the stacked layout kind of hard to scan
[06:03] <poolie> especially because the colors overlap
[06:03] <wgrant> Yeah, that's a worry.
[06:03] <huwshimi> wgrant: http://people.canonical.com/~huwshimi/status_colours.png
[06:03] <wgrant> But maybe that's less important once we have good sorting and filtering.
[06:03] <wgrant> huwshimi: Hmmmmmmmmm.
[06:03] <poolie> i think we ought to ask: why are we showing this at all
[06:03] <poolie> what kind of thing do people do with this information
[06:04] <poolie> ...
[06:04] <poolie> "oh, that's new/untriaged, i'll go and do it now"
[06:04] <wgrant> Entirely desaturating the status was not the solution I had in mind.
[06:04] <wgrant> Sort of the opposite :)
[06:04] <wgrant> The importance is really more like a tag, IME.
[06:04] <poolie> "of the bugs with this tag, 2 are in progress, 3 fixed, 3 triaged"
[06:04] <wgrant> An unimportant tag.
[06:05] <poolie> i think also whether projects accept it or not, there's "critical, high, other"
[06:05] <poolie> oh, and null
[06:05] <wgrant> Yep.
[06:05] <poolie> i do wonder if the scale should reflect that by having nonlinear differences in color - http://people.canonical.com/~huwshimi/status_colours.png is a bit better in that respect but not quite there
[06:06] <wgrant> Yeah.
[06:06] <wgrant> "Other" is split.
[06:06] <wgrant> But it's clearly separate from Critical and High.
[06:06] <wgrant> By being cooler.
[06:06] <poolie> so i would have eg "red, orange, yellow, faded yellow, dull yellow"
[06:06] <wgrant> The colours in that are much more subtle, too.
[06:06] <wgrant> Much better.
[06:07] <wgrant> The blocks of colour also look pretty odd next to our detailed icons, I think.
[06:08] <poolie> i do generally like the colors
[06:08] <poolie> i think
[06:08] <wgrant> It's all pretty simple and not busy, but then you get to these variously-coloured outlined detailed icons :(
[06:08] <poolie> the statuses are less jarring because they are not colored at all
[06:08]  * wgrant campaigns for monochrome icons.
[06:08] <wgrant> Yeah.
[06:09] <poolie> but it seems based on an assumption that the importance is much more salient than the status
[06:09] <poolie> which i don't think is true
[06:09] <wgrant> Indeed.
[06:09] <poolie> ... and again that should probably come out of a theory about what people use this information for
[06:09] <wgrant> Well.
[06:09] <wgrant> It really depends.
[06:09] <wgrant> Depending on the filter.
[06:09] <poolie> i don't think it's universally true
[06:09] <poolie> right
[06:09] <wgrant> eg. we by default filter to open bugs.
[06:09] <poolie> yeah
[06:10] <poolie> you know i'd really like the filters to start having an overridable opinion about what you're using that filter for
[06:10] <poolie> eg inprogress should show you to whom they're assigned
[06:10] <wgrant> But it's still useful to distinguish between those that are untriaged (although they would have NULL importance), those that can be worked on, and those that are being worked, and those that are fixed but not released.
[06:10] <wgrant> Yeah.
[06:10] <wgrant> So.
[06:10] <poolie> yes
[06:10] <wgrant> Really the status is just noise normally.
[06:10] <poolie> i think it at least some uses it'd be good to highlight "in play" statuses
[06:10] <wgrant> Everything can be distinguished from importance and assignee.
[06:11] <poolie> well, really just inprogress, and maybe fixcomitted
[06:11] <wgrant> New: unset importance
[06:11] <wgrant> Triaged: set importance
[06:11] <poolie> well, that too
[06:11] <wgrant> In progress: set assignee
[06:11] <poolie> get rid of a few statuses
[06:11] <wgrant> Incomplete... not sure
[06:11] <wgrant> Fix Committed: pointless
[06:11] <poolie> i think incomplete is an orthogonal bit
[06:11] <wgrant> Yeah.
[06:12] <poolie> "needs more input", ie developers can't work on it (and it will eventually expire) if an affected user doesn't provide more info
[06:12] <wgrant> I've thought about abolishing status for issuetracker.
[06:12] <poolie> i think this works pretty well  in answers
[06:12] <wgrant> invalid/wontfix/opinion are all one status
[06:13] <wgrant> fixcommitted is largely pointless
[06:13] <wgrant> incomplete can apply to most states, so should be separate
[06:13] <wgrant> new is implied by there being no importance
[06:13] <wgrant> inprogress is implied by there being an assignee
[06:13] <poolie> ... anyhow, one step at a time
[06:13] <wgrant> Heh
[06:13] <poolie> i think one good thing huw's retheme can hopefully do is provide a consistency about where color is used and how much
[06:13] <wgrant> Yeah.
[06:14] <wgrant> huwshimi: Do you have plans for our iconset?
[06:14] <poolie> i would hope it says it's used for important things
[06:14] <poolie> kill the goddamn pencil
[06:14] <huwshimi> wgrant: Yeah, I have plans to redesign it.
[06:14] <wgrant> The pencil was scheduled for demolition 2.5 years ago :)
[06:14] <wgrant> huwshimi: Excellent.
[06:15] <huwshimi> wgrant: I haven't done much work on it yet, but it's probably going to be monochrome
[06:15] <wgrant> Eeeexcellent.
[06:15] <huwshimi> wgrant: At least in the current mockups it has been
[06:15] <poolie> grey plus purple anyhow
[06:16] <micahg> ok, so I see the new delete task feature, but I'm not sure, if I delete a default task, does that remove the targetted tasks as well or do I have to target the devel release to delete the default task or is there still no way to delete the default task?
[06:17] <wgrant> micahg: You can delete any task individually, as long as at least one task is left on the bug.
[06:17] <wgrant> micahg: This does mean that you can have eg. a linux (Ubuntu Lucid) task without a linux (Ubuntu) task.
[06:17] <micahg> right, but like in bug 887339, I don't need the default tasks, but I need the targetted ones
[06:17] <_mup_> Bug #887339: Tracking bug for Firefox 8 transition <firefox (Ubuntu):Invalid> <mozvoikko (Ubuntu):Invalid> <ubufox (Ubuntu):Invalid> <firefox (Ubuntu Natty):Fix Committed by micahg> <mozvoikko (Ubuntu Natty):Fix Committed by micahg> <ubufox (Ubuntu Natty):Fix Committed by micahg> <firefox (Ubuntu Oneiric):Fix Committed by micahg> <mozvoikko (Ubuntu Oneiric):Fix Committed by micahg> <ubufox (Ubuntu Oneiric):Fix Committed by micahg> < https://la
[06:17] <wgrant> I would discourage deleting them.
[06:18] <wgrant> The parent target will still appear, see eg. bug #1234
[06:18] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[06:18] <wgrant> Er.
[06:18] <wgrant> Not that.
[06:18] <wgrant> Bug #43150
[06:18] <_mup_> Bug #43150: [SRU] maxima frontends fail to connect <wxmaxima (Ubuntu):Fix Released> <gcl (Ubuntu Dapper):Fix Released by wgrant> <maxima (Ubuntu Dapper):Fix Released> < https://launchpad.net/bugs/43150 >
[06:18] <wgrant> The parent targets without tasks are still shown in the table.
[06:19] <wgrant> Task deletion exists mostly to remove projects that shouldn't be on bugs.
[06:19] <wgrant> It's not intended for what you suggest, though it will mostly work.
[06:20] <micahg> right, that's what I'm thinking, to look something like that bug
[06:20] <micahg> but if it's not advised, I'll leave it
[06:20] <wgrant> (that bug was never intended to be like that, but it ended up being somewhat broken when series tasks were reworked in 2007)
[06:58] <jtv> StevenK: oh crap, completely forgot to OCR today.  I'll just join you.
[06:58] <StevenK> Or not join me
[06:59] <jtv> Well, replace you.
[06:59] <jtv> Or something.
[06:59] <StevenK> I sit replaced.
[07:25] <jtv> morning rvba
[07:25] <rvba> \o jtv!
[07:28] <poolie> hi rvba, jtv
[07:28] <rvba> Hello poolie.
[08:10] <poolie> so when launchpad runs its tests against the external buildd code
[08:10] <poolie> it will need a copy of that
[08:12] <wgrant> poolie: Probably best to put it in sourcecode/ for now.
[08:12] <poolie> ok
[08:13] <poolie> yeah it would be a bit weird to make it an egg
[08:17] <jtv> hi poolie — back from getting some stuff
[08:18] <jtv> wgrant: any objections to a dogfood update?
[08:18] <wgrant> jtv: Go ahead.
[08:18] <jtv> thx
[08:23] <poolie> package name 'launchpad_buildd' or 'launchpadbuildd' or 'lpbuildd'?
[08:23] <poolie> maybe the last
[08:37] <huwshimi> Just heading out, but a branch for someone who is generous enough: https://code.launchpad.net/~huwshimi/launchpad/tag-cloud-removal-709009/+merge/81689
[09:03] <danhg> Morning all
[09:04] <mrevell> Hello
[09:07] <adeuring> good morning
[09:10] <jtv> I think this is one of those rare cases where I need full tracebacks from test errors.  Anyone know how I get the full traceback instead of the normal abridged one?
[09:16] <jml> jtv: it's a bit tricky.
[09:17] <jml> jtv: try decorating the test with @run_test_with(FullStackRunTest)
[09:17] <jtv> That doesn't sound too tricky!
[09:17] <jml> jtv: from testtools import run_test_with; from testtools.tests.helpers import FullStackRunTest
[09:17] <jtv> Thanks.
[09:17] <jml> jtv: it won't give you the full stack though, it'll just reveal the testtools-specific stuff
[09:18] <jtv> We'll see how far it gets me.
[09:18] <jml> jtv: bug 881778 and bug 881780 have been filed already on testtools and are my next thing to do for it.
[09:18] <_mup_> Bug #881778: frame hiding cannot be disabled, interferes with debugging <regression> <traceback> <testtools:Triaged> < https://launchpad.net/bugs/881778 >
[09:18] <_mup_> Bug #881780: no way to transiently disable frame hiding <traceback> <testtools:Triaged> < https://launchpad.net/bugs/881780 >
[09:19] <jtv> Alas, it didn't do the trick.
[09:19] <jml> jtv: did it not work at all?
[09:19] <jtv> Actually, the "traceback" consists of _only_ the exception description.  I've been assuming that that was just because the abridgment eliminated the whole thing, but perhaps there's some other way that could happen?
[09:20] <jtv> Traceback (most recent call last):
[09:20] <jtv> DNSLookupError: DNS lookup failed: <etc.>
[09:20] <jtv> Just those two lines.
[09:35] <poolie> can someone have a squiz at https://code.launchpad.net/~mbp/launchpad-buildd/rename-package/+merge/81692
[09:36] <jtv> poolie: after my standup, sure
[10:29] <allenap> jtv: Little review? https://code.launchpad.net/~allenap/launchpad/bug-export-schema/+merge/81699
[10:31] <jtv> allenap: otp; would half an hour be OK?
[10:31] <allenap> jtv: Absolutely, it's not urgent.
[10:31] <allenap> Thanks.
[10:31] <jtv> cool
[10:56] <jml> hey, diffs seem to be taking a long time to generate.
[10:57] <jml> since posting my MP, I've gone downstairs & filled up a bottle of water, greeted the postman (not a euphemism), and then put a bunch of cardboard boxes in the loft. Still no diff.
[10:58] <lifeless> jml: single threaded, possibly behind something big.
[10:59] <bigjools> that would be a great euphemism though
[10:59] <lifeless> jml: your bug about reviews
[10:59] <lifeless> jml: isn't https://code.launchpad.net/~lifeless/+activereviews roughly the view you ask for ?
[11:02] <nigelb> ooh, it was jml  that asked for this at the launchpad session?
[11:02] <nigelb> lifeless: NICE!
[11:04] <nigelb> lifeless: I maybe seeing a regression. On the project page now it doesn't show the different categories "Reviews I'm waiting", "Reviews I can do", etc
[11:05] <lifeless> https://code.launchpad.net/launchpad-project/+activereviews
[11:05] <lifeless> does for me
[11:05] <nigelb> what the....
[11:05] <nigelb> it didn't work 2 minutes ago.
[11:07] <nigelb> It picks every review I'm associated with. Like.
[11:07] <lifeless> check the url
[11:07] <lifeless> bet you there is a difference
[11:07] <nigelb> Probably my mistake
[11:07] <nigelb> Anyway, this is nice :)
[11:07] <lifeless> e.g. +reviews vs +activereviews
[11:07] <lifeless> or something
[11:08] <jml> lifeless: no.
[11:09] <jml> lifeless: or rather, it's close, but I want reviews that aren't assigned to me to appear on it. If you submit an MP to, say, it won't show up on my page.
[11:10] <nigelb> "Reviews I *can* do"
[11:10] <jml> well
[11:10] <jml> yes. although there's a lot of those :)
[11:10] <nigelb> heh
[11:10] <jml> restricting it to projects I'm interested in would be nice.
[11:12] <jtv> allenap: you're done.
[11:12] <allenap> jtv: Thanks.
[11:16] <lifeless> jml: so, I think it just needs a way to say 'I may be a reviewer for X, but I don't care about it'.
[11:16] <lifeless> jml: one way is to not be in the reviewer team for X.
[11:16] <jml> uhh... no?
[11:16] <jml> well, depends on what "it" is there
[11:17] <lifeless> so, +activereviews shows reviews that aren't assigned to you. The heuristics is that they are on a branch you are in the review team for.
[11:17] <lifeless> what you said above was '00:09 < jml> lifeless: or rather, it's close, but I want reviews that aren't assigned to me to appear on it. If you submit an MP to, say, it won't show up on my page.
[11:17] <jml> lifeless: no, it doesn't.
[11:17] <lifeless> '
[11:17] <lifeless> and then '00:10 < jml> restricting it to projects I'm interested in would be nice.
[11:18] <lifeless> jml: are you saying you want proposals that you're not an authoritative reviewer for to show up as well?
[11:19] <jml> lifeless: "as well" is wrong. Person/+activereviews does not show reviews that aren't assigned to me. e.g. kampka's review on https://code.launchpad.net/testtools/+activereviews isn't shown on https://code.launchpad.net/~jml/+activereviews
[11:19] <lifeless> jml: ah, or are you saying that 'reviews I can do' doesn't show up on your ~ +activereviews?
[11:20] <lifeless> jml: This may be shallow. Thanks for helping me understand.
[11:20] <jml> lifeless: yes, that's what I'm saying. That was the intended behaviour of the page when thumper made it.
[11:20] <jml> tbh, if suddenly there was a "Reviews I can do" section, I'd want it grouped by project.
[11:20] <jml> lifeless: np
[11:23] <jml> another slow diff generation :\
[11:23] <lifeless> jml: naturally
[11:23] <lifeless> jml: would you care to note this in the bug ?
[11:30] <jml> lifeless: done
[11:34] <lifeless> thhanks
[12:09] <StevenK> jtv: Are you still OCR, or are you EOD?
[12:15] <jtv> StevenK: sort of eod tbh
[12:15] <jtv> But!
[12:16] <jtv> If your branch isn't too big I can trade you a speedup for the [BS]PPH.{source,binary}packagename populators.
[12:16] <StevenK> In the garbo job?
[12:16] <jtv> Yes
[12:16] <StevenK> jtv: Problem is, my branch isn't done yet.
[12:16] <jtv> Well that'd put a bit of a crimp on it.
[12:21] <StevenK> A bit, yes
[12:36] <jtv> bigjools: about a minute and a half — still seems to do the usual stuff though
[13:04] <StevenK> jtv: Are you still up for that MP swap?
[14:02] <deryck> Hi, all.
[14:12] <flacoste> hi deryck!
[14:30] <deryck> adeuring, ping for standup
[14:31] <adeuring> deryck: oops, starting mumble now. sorry
[14:31] <deryck> np
[14:45] <sinzui> I believe there are 3 private new bugs in Launchpad that no-one can see. This has been the case for a few months
[14:46]  * sinzui wonders if staging can show them
[14:49] <deryck> adeuring, are you working from this mockup for the beta banner?  http://people.canonical.com/~deryck/beta_banner.png
[14:50] <adeuring> deryck: yes
[14:50] <deryck> adeuring, ok.  And it's that blue on black that's hard to read?
[14:50] <adeuring> deryck: right
[14:50] <deryck> adeuring, do you have the transparency, too?
[14:50] <adeuring> deryck: yes
[14:51] <deryck> adeuring, ok, cool.  I'd say just keep that match and point huw at the issues you see then.
[14:52] <adeuring> deryck: ok. BTW, I suspect that the blue colour in the mockup is simply  not identical with the colour we use elsewhere for links
[14:52] <nigelb> Custom bug lists feature looks amazing btw
[14:52] <deryck> nigelb, thanks!
[14:52] <nigelb> :)
[14:53] <deryck> adeuring, that's what I was wondering.  let me open in gimp and get the exact color.
[14:53]  * deryck thinks the Oranga Mafia are becoming design gurus
[15:01] <deryck> adeuring, like the gray, it's hard to pin down from mockup, but I think it's #4884EF.
[15:01] <adeuring> deryck: ok, I'll try it
[15:25] <abentley> deryck:  could you please review https://code.launchpad.net/~abentley/launchpad/enable-anonymous-jsoncache/+merge/81741 ? (I'm the OCR)
[15:26] <deryck> abentley, I can.  Give me 15-20 minutes to wrap up some emails for the day, and then I'll start.
[15:26] <abentley> deryck: thanks.
[16:17] <deryck> abentley, your MP looks great.  No comments really.  r=me.
[16:18] <abentley> deryck: thanks.
[16:31] <deryck> abentley, adeuring, hey look there's rick_h :)
[16:31] <adeuring> rick_h: welcome!
[16:32] <rick_h> sorry, should have thought to look for -dev a while ago
[16:32] <abentley> rick_h: Hi!
[16:32] <rick_h> howdy all
[16:34] <deryck> rick_h will be new Orange Mafia next week, for those who don't know.
[16:35] <jelmer> rick_h: welcome :)
[16:36] <rick_h> thanks, looking forward to it
[16:36] <rvba> welcome rick_h!
[16:37] <nigelb> oooh! Hello rick_h!
[17:24] <timrc> danhg, welcome aboard and thanks for doing the usability sessions at UDS/P
[17:24] <danhg> hey, thanks tim
[17:25] <danhg> was great to hang out
[18:04] <abentley> deryck: back, forward and reload buttons now work.
[18:05] <deryck> abentley, nice!
[18:05] <deryck> abentley, well done.
[18:53] <lifeless> cr3: hi
[19:03] <cr3> lifeless: hola senor, what's up?
[19:06] <lifeless> sorry otp now ;)
[19:07] <cr3> lifeless: no worries, reping me when done
[19:26] <lifeless> cr3: hi
[19:26] <lifeless> cr3: wanted to touch base on the person access api we discussed
[19:28] <mrevell> night all
[19:35] <lifeless> cr3: however I have to run in a minute now - monthly allergy vaccine injection
[19:36] <lifeless> cr3: will try around this time tomorrow
[19:37] <cr3> lifeless: sure, looking forward to your ping tomorrow
[19:46] <lifeless> wallyworld_: add member should't need changing
[19:46] <lifeless> wallyworld_: non-open/delegated teams already prevent addition of open-delegated teams to the team.
[19:57] <thumper> lifeless: the reason behind avoiding having reviews I can do on the person review page was the potential amount of them
[20:27] <abentley> deryck: chat?
[20:27] <deryck> abentley, sure.
[20:28] <abentley> deryck: on mumble, I mean.
[20:31] <mwhudson> +                    report.get('value', 'No execption value'))
[20:31]  * mwhudson twitches
[20:36] <bac> hi mwhudson
[20:42] <bac> mwhudson: you afflicted by more than the typo?
[20:42] <mwhudson> bac: no, just the typo
[20:43] <mwhudson> bac: i guess i could just fix it myself, sorry
[20:43] <bac> mwhudson: ok -- i'll fix it.
[20:45] <bac> mwhudson: turns out 'execption' occurs in our code base three times!
[20:45] <mwhudson> bac: hahaha
[21:01] <Lifelrss> Statik: hi
[21:34] <mwhudson> jelmer: so if the recipe memory problems are fixed, has anyone tried a kernel build yet? :-)
[21:35] <jelmer> mwhudson: hmm, that'd be an interesting thing to try
[21:36] <mwhudson> jelmer: john rigby from linaro actually wanted to do it, too
[21:36] <mwhudson> ah, kernel imports don't scan correctly
[21:36] <mwhudson> is that going to be a problem?
[21:37] <jelmer> mwhudson: yeah, that might be a problem
[21:37] <jelmer> it seems like 2.6 imports fine though
[21:37] <mwhudson> ah, that's probably been around for long enough
[21:37] <jelmer> and I have some in-progress work to improve the scanner performance
[21:38] <jelmer> Branch.revision_history() is deprecated in bzr 2.5, which breaks lots of things in Launchpad, so that code will have to change anyway
[21:38] <mwhudson> i think it's some new-ish time restriction on how long scanner jobs run for that prevents new imports from scanning
[21:38] <jelmer> might as well use the new, fancy, APIs
[21:38] <mwhudson> jelmer: does it involve deleting BranchRevision?
[21:38] <jelmer> mwhudson: no
[21:38] <mwhudson> sad fave
[21:38] <mwhudson> *face
[21:39] <jelmer> branchrevision scares me
[21:39] <mwhudson> the things it does that aren't trivial to replace with bzr ops are ... i forget now
[21:39] <mwhudson> per project revision feeds?
[21:39] <mwhudson> revisioncache updates in general i guess
[21:40] <mwhudson> really we should have a microservice for things like "which revisions are unmerged in this mp" blah blah blah
[21:43] <mwhudson> jelmer: i remember that revision_history started to be bad news around when i started with canonical
[21:43] <mwhudson> jelmer: some things move slowly :-)
[21:46] <jelmer> mwhudson: the format moved away from it a long time ago
[21:46] <mwhudson> yeah
[21:46] <jelmer> mwhudson: but the API was still there
[21:46] <mwhudson> there was a version of knits with it and another without it?
[21:55] <wgrant> jelmer, mwhudson: I've had some luck with manually doing progressive scans of large new imports.
[22:20] <poolie> huwshimi, hi, there were a couple of things at the google event that i wanted to briefly mention with you
[22:20] <poolie> also thanks for fixing the tag cloud
[22:20] <huwshimi> poolie: :)]
[22:22] <StevenK> abentley: Hai, are you still up for reviewing a branch?
[22:24] <sinzui> wallyworld_, from canonical.launchpad.webapp.authorization import (
[22:24] <sinzui>     precache_permission_for_objects,
[22:24] <sinzui>     )
[22:30] <poolie> lifeless, re putting launchpad-buildd in an egg, that seemed a bit strange for something that's mostly not python, and has no python packaging at the moment
[22:31] <poolie> it feels more like it should be a dpkg dependency
[22:33] <jelmer> wgrant: that's by pushing the branch 10k or so revisions at a time?
[22:34] <wgrant> jelmer: Yep.
[22:34] <wgrant> jelmer: Sometimes much less :/
[22:35] <abentley> StevenK: sorry.
[22:39] <lifeless> poolie: I want to reduce the number of dependency systems we are using
[22:39] <lifeless> poolie: for the forseeable future, eggs are needed, and so are dpkg packages.
[22:39] <lifeless> poolie: so either is fine IMO
[22:42] <poolie> i just need to make sure installing the package does not convert your machine into a buildd
[22:42] <poolie> though that might be kind of useful :)
[22:42] <poolie> especially leading up to the release
[22:42] <lifeless> well
[22:42] <lifeless> there are some options
[22:42] <lifeless> we could mandate having it run in a container
[22:43] <lifeless> for instance
[22:43] <lifeless> or you could create a test fake like that sketched on the SOA pages
[22:44] <poolie> i think eventually separating the tests along the interface will be good
[22:44] <poolie> for now i'm testing the whole thing because it's not very expensive and there is risk of integration breakage
[22:45] <poolie> do you know how hard it would be to run up a realistic buildd vm locally and do manual integration testing?
[22:45] <poolie> my impression is it's quite hard and unautomated
[22:45] <lifeless> https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally
[22:45] <wgrant> poolie: It's reasonably unautomated, but not exactly hard.
[22:46] <wgrant> It's also well-documented.
[22:46] <wgrant> Reasonably.
[22:46] <wgrant> I think people other than me have done it.
[22:46] <lifeless> ripe for improvement
[22:46] <mwhudson> i've set up an arm buildd
[22:46] <mwhudson> and used it with launchpad
[22:46] <mwhudson> .dev
[22:46] <mwhudson> it's fiddly, but not hard
[22:46] <poolie> thanks
[22:47] <wgrant> That page suggests installing it on your LP system, but that only really makes sense if your LP is running in a VM.
[22:47] <wgrant> Because it really shouldn't be running on a real machine.
[22:48] <poolie> i'm surprised that will work because it seems to have a hardcoded "if not under xen, abort" check
[22:49] <wgrant> poolie: Ah, for recipe builds, probably not.
[22:49] <wgrant> We have some thoroughly stupid checks.
[22:49] <wgrant> That I couldn't be bothered complaining about.
[22:49] <wgrant> (that one is new)
[22:52] <flacoste> iirc, it was a request from IS
[22:53] <flacoste> (the if not under xen, abort)
[22:53] <wgrant> Yes, and it was not a very sensible request :/
[22:53] <wgrant> Because recipe builds are the safe ones.
[22:53] <wgrant> Well, not safe.
[22:53] <wgrant> But safer than binary builds.
[22:53] <wgrant> If it's not running under Xen, we have far larger problem.s
[22:53] <flacoste> i have to admin, i forgot the rationale behind them asking this
[22:53] <flacoste> admit
[22:54] <poolie> i can easily change it to be on by default but disableable
[22:54] <poolie> if that's a word
[22:54] <wgrant> Hopefully lamont won't notice if we remove it.
[22:54] <wgrant> It's only very very slightly beneficial to security.
[22:55] <poolie> that actually seems like a nice place to use one of those TCB features
[22:55] <poolie> perhaps they're not in the stock kernel
[22:55] <poolie> but, limiting the machine to exec'ing only particular binaries
[22:55] <poolie> or for that matter just having some noexec filesystems
[22:55] <wgrant> poolie: Doesn't quite work for a buildd :)
[22:55] <StevenK> sinzui: I can't use celebrity_logged_in -- I need to pass the principal into the view.
[22:55] <poolie> wgrant, why?
[22:55] <StevenK> sinzui: I already thought of using it when I wrote the branch.
[22:56] <poolie> hm
[22:56] <wgrant> poolie: Because they construct unsigned binaries...
[22:56] <poolie> i guess you would need something that allowed execution inside the chroot but not outside
[22:56] <poolie> perhaps possible though
[22:56] <wgrant> And that's not useful.
[22:56] <wgrant> Because chroots are not secure.
[22:59] <poolie> so the point is to make sure arbitrary code does not run outside of the vm
[22:59] <poolie> perhaps the host outside of the vm should be more locked
[23:00] <wgrant> No.
[23:00] <wgrant> It's to make sure untrusted code doesn't run on the non-virt builders.
[23:01] <wgrant> But it's a failed attempt to do that.
[23:01] <wgrant> Because binary builds still work, and they're far easier to exploit.
[23:01] <lifeless> uhm
[23:01] <lifeless> so I'm not endorsing the check
[23:01] <lifeless> but failure to prevent attacks A *and* B doesn't make a solution to attack A valueless.
[23:01] <wgrant> No.
[23:02] <wgrant> But in this case it's really not very useful.
[23:02] <wgrant> And it's actively harmful to development.
[23:02] <wgrant> Not useful + harmful == kill
[23:03] <poolie> i'll do something about it so i can test
[23:03] <poolie> i can understand how they would want some protection against things running in the wrong place through operator error, even if it is not 100%
[23:03] <wgrant> It's not even 10%.
[23:42] <wgrant> lifeless: http://paste.ubuntu.com/732768/ is an attempt without the denormalisation (AccessPolicyArtifact.policy exists, and AccessPolicyGrant's policy and artifact columns are mutually exclusive).
[23:42] <wgrant> lifeless: It's about 10% slower for Ubuntu on DF.
[23:42] <wgrant> lifeless: But much slower for other projects.
[23:42] <wgrant> (the third form of the query seems to be the fastest)
[23:43] <wgrant> Because it does a seq scan on APG.
[23:43] <wgrant> Refuses to use the indices.
[23:43] <wgrant> Was wondering if you could poke a bit.
[23:54] <lifeless> sure, I need to have an urgent poke at a few other things first, but after that I will
[23:54] <lifeless> (running out of disk space on carob would be bad)
[23:54] <StevenK> Sure, not seeing 2,000 OOPSes would be so tragic.
[23:54] <StevenK> Won't someone think of the OOPSes


[02:15] <jpds> k1l: How can you have that giant whitespace taking up your screen's real estate?
[02:51] <phunyguy> ^
[11:30] <daftykins> hi folks, just a heads up that "pikapi" is one of those 'pretend volunteer' trolls that wastes peoples time with inappropriate 'advice' and direct googlings.
[11:31] <daftykins> nothing actionable i'm sure for now, but worth making a note of
[11:37] <Unit193> User is in a live system too (Don't think anyone is around right now, either.)
[11:38] <daftykins> yeah usually pretty dead :)
[11:45] <daftykins> there we go, first of many terrible pieces of advice
[11:45] <daftykins> ok i'm gonna part for now
[16:18] <not_phunyguy> someone mind keeping an eye on pikapi in #u-ot? I cannot pay enough attention right now.
[16:19] <not_phunyguy> nevermind.  They /quit
[18:51]  * phunyguy grumbles
[18:52] <phunyguy> anyone else care to step in?
[19:01] <FartZombie> !ops please unban me
[19:01] <FartZombie> I must carry out the apocalypse
[19:02] <phunyguy> hello FartZombie, which channel?
[19:11] <teward> Is someone watching #ubuntu and L0LFunny?  I think they're reaching the line of "disruptive"
[19:11] <Pici> we're always watching
[19:11] <teward> cool, wanted to check is all :)
[19:11] <teward> thanks
[23:55] <bazhang>  [sruli]<EMAIL_ADDRESS>[23:55] <bazhang> is sruli the new pikapi
[23:56] <Unit193> Using Pidgin, not a live ISO.
[23:56] <bazhang> seemingly giving advice, but mostly offtopic running commentary
[23:57] <k1l_> india vs england. but both are very chattery


[01:10] <LaserJock> good afternoon Edubunters!
[01:11] <boyam> Hi LaserJock :)
[01:13] <LaserJock> hi boyam
[01:38] <lns> Hey LaserJock
[01:40] <LaserJock> hi lns
[03:05] <eddiestone> Hello, does anybody knows a software that helps teachers on their activities?
[03:05] <Kamping_Kaiser> what actiivities
[03:05] <eddiestone> evaluations
[03:07] <eddiestone> I mean, registering tests results
[03:07] <Kamping_Kaiser> not sure. moodle perhaps?
[03:08] <eddiestone> surely
[03:08] <eddiestone> but I'd like a desktop software
[03:09] <eddiestone> I'll keeping looking for it :)
[03:10] <Kamping_Kaiser> good luck
[03:55] <sbalneav> LaserJock: You around?
[06:11] <LaserJock> sbalneav: pong
[06:11] <sbalneav> hey there.
[06:12] <sbalneav> Aything you'd like to see education-app related in the docs?
[06:13] <LaserJock> well
[06:14] <LaserJock> I've been thinking a little about that
[06:14] <LaserJock> traditionally the Doc team has not documented actual apps
[06:14] <LaserJock> as the apps should have their own help
[06:14] <LaserJock> but I think we should at least have a decent overview of apps
[06:15] <sbalneav> Yeah, I'd also like to have at least a small chapter on downloading the extra app cd, and what to do with it.
[06:15] <sbalneav> it seems to cause a lot of people confusion.
[06:16] <LaserJock> yes, I *do* want to document the Addon CD much better
[06:17] <sbalneav> Also, this squeek vm thing seems to generate a lot of interest.
[06:17] <LaserJock> argg
[06:17] <sbalneav> Who's maintaining squeek, or squeak
[06:17] <LaserJock> I wish I had gotten to that
[06:17] <LaserJock> I touched it most last
[06:17] <LaserJock> but we need to use completely different packaging
[06:17] <LaserJock> the stuff we have now is based on some packages for some spanish distro
[06:18] <sbalneav> hm
[06:18] <LaserJock> that'll be on the todo list for Hardy
[06:19] <sbalneav> Hmm, smalltalk
[06:19] <LaserJock> since it's a Multiverse package I haven't done a ton with it frankly
[06:19] <LaserJock> we're basically never going to be able to ship it
[06:19] <sbalneav> bad license?
[06:21] <LaserJock> yeah
[06:21] <LaserJock> some Apple license I think
[06:21] <LaserJock> and they can't really change it or something
[06:22] <LaserJock> but I'd love to see us doing more with Universe/Multiverse
[06:22] <sbalneav> Can we ship uni/multi packages on the addon cd?
[06:22] <LaserJock> there's a lot of educational apps out there that we just aren't going to be able to ship or officially support
[06:22] <LaserJock> not presently no
[06:22] <LaserJock> I have to do a MIR and get them into Main
[06:22] <LaserJock> we can make something like edubuntu-universe metapacakges though
[06:25] <sbalneav> Want me to document the addon cd?
[06:25] <LaserJock> I can do it
[06:26] <sbalneav> Sure?
[06:26] <sbalneav> You got time?
[06:26] <LaserJock> unless you feel the need
[06:26] <LaserJock> well, I kinda consider it a part of implementing my spec ;-)
[06:26] <LaserJock> I'm redoing About Edubuntu
[06:26] <sbalneav> I could use all the doc help I can get :)
[06:26] <LaserJock> I'm not going to touch LTSP and stuff
[06:26] <LaserJock> but I can do a bit here and there
[06:27] <LaserJock> did you see the commit I did yesterday?
[06:27] <sbalneav> Response to my missive has been, underwhelming, to say the least.
[06:27] <sbalneav> yeah, I included it in my update.
[06:27] <LaserJock> moquist proofread the intro
[06:28] <sbalneav> heh, got one other response. Non technical guy, didn't want to install anything, but if I'd MAIL him a printout of the docs, he'd be happy to check spelling :)
[06:29] <LaserJock> hmm
[06:29] <LaserJock> I can spell check in vim/emacs/gedit already
[06:30] <LaserJock> grammar check is nice though
[06:30] <sbalneav> Wasn't particularily wanting to produce hardcopy, and receive back a red-penciled printout, though :)
[06:31] <LaserJock> heh
[06:35] <sbalneav> Well, considering all my work to ltspfs stable enough to merge into my "upstream" branch.
[07:07] <LaserJock> moquist: up?
[07:56] <LaserJock> moquist: postgresql instal of moodle didn't work for me. something about not being able to create the user
[07:56] <LaserJock> moquist: I'll try to get you more info tomorrow
[08:04] <moquist> shoot; just missed him.
[10:59] <moquist> ogra: hey
[10:59] <ogra> yo
[11:00] <moquist> ogra: If I drop a new postinst into /var/lib/dpkg/info how can I test it? I think laserjock said 'dpkg -i moodle', but dpkg doesn't know about 'moodle'.
[11:01] <moquist> I ran 'apt-get install moodle' and it failed, so it's already been unpacked and everything. I'm assuming/hoping I can just change postinst in /var/lib/dpkg/info and test immediately...
[11:01] <ogra> you can drop all the files in a dir and execute the postinst manually
[11:01] <ogra> needs .template and .config iirc
[11:01] <ogra> ah, ok
[11:01] <ogra> dpkg-reconfigure moodle should do it
[11:02] <ogra> or just dpkg -i it manually
[11:02] <moquist> /usr/sbin/dpkg-reconfigure: moodle is broken or not fully installed
[11:02] <ogra> ah
[11:02] <ogra> well, then dpkg -i /var/cache/apt/archive/moodle*
[11:03] <moquist> ok...and it will use the modified postinst that's already in /var/lib/dpkg/info/ ?
[11:03] <ogra> no
[11:03] <moquist> :)
[11:04] <ogra> but you need to get it installed before you can play with the postinst via reconfigure
[11:04] <moquist> Do I need to rebuild the source package to test a new postinst? That's what I've been doing and it's slow.
[11:04] <moquist> OK; that makes sense.
[11:04] <ogra> well, as i said, i usually put postinst and .template in one dir and execute the postinst manually ... but then my postinst scripts arent very complax usually
[11:05] <ogra> *complex
[11:05] <ogra> if you are missing biuts, you probably need to comment stuff in the script to make it run
[11:05] <moquist> No, that should work here.
[11:05] <moquist> (a couple things just 'clicked' for me...I think)
[11:05] <moquist> biuts?
[11:10] <RichEd> hi ogra & moquist ...
[11:10] <moquist> RichEd: hey-a
[11:11] <RichEd> nice mail this morning from the US

[11:11] <RichEd> > A little more about the project...I have an eight year old daughter in a
[11:11] <RichEd> > private school near Seattle Washington. Parents are expected to contribute
[11:11] <RichEd> > time as well as money to the school. I opened my mouth about the virtues of
[11:11] <RichEd> > Ubantu and proposed a small thin client network for school.
[11:11] <ogra> bits :)
[11:11] <RichEd> >
[11:11] <RichEd> > Apparently someone decided it was a good idea for the entire chain of
[11:11] <RichEd> > seventy three schools across America. (Me and my big mouth.) The deployment
[11:11] <RichEd> > is about five thousand thin clients.

[11:11] <ogra> \o/
[11:11] <RichEd> indeed ... a seed school in many areas would be even better than a district
[11:12] <RichEd> and seeing as it is a private school chain, there is no "unilateral blocking decision" from above
[11:12] <moquist> nice!
[11:14] <highvoltage> RichEd: excellent!
[11:15] <RichEd> highvoltage: most excellent
[11:18] <highvoltage> I stand corrected
[11:18] <highvoltage> RichEd: most excellent!
[11:25] <Kamping_Kaiser> lol
[11:39] <moquist> ogra: bah. it is broken. I must sleep. I will work on it later today.
[11:39] <ogra> relax :)
[12:52] <rimakemp> Hi, I am new to open source. I am working at an independent school in canberra Australia, I want to find out about setting up edubuntu?
[12:53] <Kamping_Kaiser> rimakemp, hi mate :)
[12:54] <Kamping_Kaiser> rimakemp, what do you need to find out?
[12:54] <rimakemp> Hi how are you?
[12:54] <Kamping_Kaiser> good. distracting myself with IRC
[12:55] <rimakemp> is it worth while? how compatible is it with mainstream software? does it run in tandem etc. well?
[12:57] <Kamping_Kaiser> yes, very, i think so
[12:57] <Kamping_Kaiser> in that order ;)
[12:57] <Kamping_Kaiser> if you can be slightly more specific about your question, i might be able to give slightly better answers
[01:00] <Kamping_Kaiser> btw mate, theres an #ubuntu-au if you want to hang out with some more people in your timezone ;)
[01:02] <rimakemp> Our school has received funding for a new computer lab and we are constantly being donated old computers with no operating system. the funds for software are not freely available for OS purchase. We are currently running windows xp. Is it feasible to intergrate edubuntu with our existing network and will it mix smoothly? (a little tired of being at the whim of Microsoft)
[01:03] <Kamping_Kaiser> yes its feasable, how easy it is to integrate i cant really comment on, but it will be easy or hard depending on your existing network complexity
[01:03] <Kamping_Kaiser> i havent tried integrating it myself
[01:04] <rimakemp> how hard is it to learn the edubuntu OS?
[01:04] <Kamping_Kaiser> *shrug* depends how fast you learn (and how open minded you are about a new style of operating). after a few months you should know the basics pretty well
[01:04] <Kamping_Kaiser> and after that it gets easier as you go
[01:05] <Kamping_Kaiser> also i dont know what the new releases look like, they may be easier/harder then 6.06 (which was my last edubuntu system)
[01:05] <rimakemp> Great! where are you situated?
[01:06] <Kamping_Kaiser> Adelaide hills :)
[01:07] <Kamping_Kaiser> rimakemp, i seriously suggest you jump into #ubuntu-au and say hi
[01:08] <rimakemp> Thanks for your advice. I will research it further and I will check out #ubuntu-au now
[01:08] <Kamping_Kaiser> np
[03:23] <sbalneav> Morning all
[03:23] <Kamping_Kaiser> hi mate
[05:50] <RichEd> jillc has updated her artwork taking note of our comments:
[05:50] <RichEd> https://wiki.ubuntu.com/EdubuntuArtwork/Volunteer
[05:51] <RichEd> ogra ... take a look at the potential default [eduWorld.png]  and let me know if it's better
[05:51] <ogra> the logo needs to move up a bit (its covered by the panel)
[05:51] <ogra> and half the space between the logo and the right side would make it look better
[05:52] <ogra> (move it to the right 50%)
[05:52] <ogra> beyond that i'd take it as is :)
[05:52] <RichEd> ogra: with the new gentler logo ?
[05:52] <ogra> yeah
[05:52] <RichEd> okay ... i'll ask for the logo move
[05:52] <ogra> te panel covers the bottom spot of the logo here
[05:53] <ogra> s/bottom spot/half of the bottom spot/
[05:58] <RichEd> ogra: spiral also looks great now in earthtones
[05:58] <ogra> yup
[06:02] <ogra> oh, did you see the other one ?
[06:04] <RichEd> ogra: ? which other one ?
[06:05] <ogra> i see you added that ...
[06:05] <ogra> wiredubuntu.png
[06:05] <ogra> its nice
[06:05] <RichEd> that's from another dude who sent it via lisa alienvegas
[06:05] <RichEd> so we have 2 contributors
[06:05] <ogra> yeah
[06:06] <ogra> he seems to like dark backgrounds, could make a good usplash for us probably
[07:49] <moquist> ogra: when I execute the postinst standalone, it runs fine.
[07:49] <moquist> LaserJock: hey!
[07:49] <LaserJock> hi moquist
[07:50] <LaserJock> moquist: you are right, I didn't install postgresql first
[07:50] <moquist> LaserJock: I was just telling ogra that when I execute the postinst standalone, it works fine. But now I think I was wrong.
[07:50] <LaserJock> but I saw that a bunch of postgresql related packages being installed so I thought it would work
[07:51] <moquist> LaserJock: In the course of ditching 'sudo' in favor of 'su', I found a temporary-for-testing 'if false' in my postinst, and I've run into some other problem. 8-(
[07:51] <moquist> That's why we concluded that there should be a moodle-standalone metapackage.
[07:52] <LaserJock> it seemed weird to me because it looked to me like I had to install both mysql *and* postgresql to install moodle
[07:56] <LaserJock> moquist: are you working on the -standalone metapackage now?
[08:07] <moquist> LaserJock: not yet; i'm just working on the above problems for the regular package
[08:07] <LaserJock> moquist: do you know what deps specifically are needed?
[08:08] <moquist> well, probably exactly the same + either "postgres" or "mysql-server"
[08:08] <moquist> ...whichever one we want to support.
[08:09] <moquist> I know mysql doesn't have ACID, etc., but it's what the vast majority of moodle sites use, and it's easier (IMO) to use than postgres.
[08:09] <moquist> And these default moodle's we're putting in are only set up to be accessible as http://localhost/moodle, so we're obviously not targetting huge installations.
[08:09] <LaserJock> ogra: have you got an opinion on what DB should be default for a moodle-standalone package?
[08:14] <moquist> Oh, the package is "postgresql". But you knew that.
[08:23] <moquist> bah - createdb is working sudo and not working with su.
[08:24] <moquist> I wonder if it's related to the ROLE password for the database owner/user.
[08:29] <moquist> LaserJock: I'd like to create a [different]  package with an /etc/init.d/script and an /etc/default/config file. I looked at another package that has those (mpd) and it was non-obvious to me how they are handled. Can you give me any tips?
[08:30] <LaserJock> moquist: not much. you might check another similar package and talk to #ubuntu-motu
[08:30] <moquist> k; thx
[08:34] <moquist> LaserJock: are you guys looking for something to kill off leftover processes that hang around after sessions are terminated?
[08:35] <moquist> dtrask tells me so.
[08:35] <moquist> I was hoping to get my xterminator in at some point, but dtrask tells me ogra is looking for something now.
[08:35] <moquist> I'll plop it up on REVU, anyway. It's one of the packages for which I want an /etc/default/config file.
[08:35] <LaserJock> I don't know what's up for gutsy at least
[08:36] <LaserJock> David was emailing about it to -devel
[08:36] <moquist> yeah
[08:36] <moquist> it may be dtrask pushing to get it more than ogra ;)
[08:37] <LaserJock> obviously this isn't the tim to be feature planning though ;-)
[08:37] <moquist> I tried to get it into my PPA but I don't have that figured out yet. My source was rejected.
[08:37] <moquist> yeah, nk
[08:38] <LaserJock> moquist: are you a Launchpad Beta Tester?
[08:39] <moquist> that's why.
[08:39] <moquist> why did it even let me activate my PPA, then?
[08:41] <moquist> PPA says to me "Signer has no upload rights at all to this distribution"
[08:41] <LaserJock> I don't know, LP thing I guess
[08:42] <LaserJock> it's supposed to go live for everybody in a few weeks or so I think
[08:42] <LaserJock> moquist: join #launchpad real quick
[08:50] <moquist> LaserJock: I just uploaded 'xterminator' to my PPA so hopefully that'll show up now.
[10:28] <moquist> LaserJock: I've just uploaded a fixed moodle package to REVU, but it's not showing up yet.
[10:28] <moquist> I've also uploaded xterminator to my PPA, but I don't see that, yet, either.
[10:29] <LaserJock> it'll take some time for stuff in PPA to build
[10:29] <moquist> yep
[10:29] <LaserJock> it has to be put in the buildd queue
[10:30] <moquist> but does REVU have to build the package before http://revu.tauware.de/index.py shows the latest upload date?
[10:30] <LaserJock> no, REVU doesn't build a package at all
[10:30] <moquist> Didn't think so.
[10:30] <LaserJock> it just has a ~ 5min cron job
[10:30] <moquist> You mean I have to wait 5 WHOLE MINUTES?!? OK.
[10:32] <boyam> hehe
[10:32] <boyam> i couldnt resist
[10:33] <boyam> :-)
[10:35] <moquist> LaserJock: OK, REVU's cron job has now run. :)
[10:36] <LaserJock> good, the universe is saved
[10:36] <moquist> I thought the universe was frozen.
[10:36] <LaserJock> not MOTU Universe
[10:37] <LaserJock> I meant, *the* universe
[10:37] <LaserJock> my boss says that all the time
[10:37] <LaserJock> we'll be working out some crazy math
[10:38] <LaserJock> and in the end we get it to work out and he says "phew, the universe is preserved"
[10:39] <moquist> That's great.
[10:39] <moquist> Because math, you know, actually has something to do with the universe. Somehow...it's not really clear how, though. Hmm.
[10:40] <LaserJock> well, because our math is the fundamentals of why the universe is the way it is
[10:40] <LaserJock> if it was just math for math's sake sure ;-)
[10:40] <moquist> Sure is good we made up math, then! :-D
[10:40] <LaserJock> those imaginary numbers sure come in handy
[10:40] <moquist> Aren't they all imaginary?
[10:41] <moquist> I'm not looking to have a real discussion about Phil. of Math right now. I'm just playing. I'll stop b/c it's off-topic.
[10:44] <LaserJock> sorry, was afk
[10:44] <LaserJock> physically we see a difference between real and imaginary numbers
[10:44] <LaserJock> so the mental abstraction may be all imaginary, but the concrete physicality remains, IMO
[10:45] <moquist> sure
[10:45] <moquist> woohoo - my PPA built.
[10:46] <LaserJock> but it's always curious to me that the wavefunction, that describes any particle in the universe completely, is an imaginary function
[10:46] <LaserJock> but you square it to get a real function and that becomes the probability
[10:47] <moquist> Yeah. The more deeply you try to dive into anything like that (or into the philosophy behind the science), the more you realize that we have a lot of trouble trying to explain much of anything at such a level.
[10:48] <moquist> I'm going to test my PPA and then send a note out to the list(s) inviting people to test xterminator.
[10:49] <LaserJock> k