[02:06] <DarkMageZ> hmm, how do i go about debugging firefox if it has frozen.
[02:07] <DarkMageZ> generating debugging information so someone else can fix the problem*
[08:38] <saivann> asac : If you're there, can I ask you a question?
[12:10] <asac> saivann: go ahead
[12:10] <asac> (no need to ask to ask) :)
[12:18] <asac> hmmm ... bugzilla is down for mwe
[12:34] <armin76> you broke it
[12:35] <armin76> asac: did you fix cairo? :P
[12:35] <asac> armin76: yeah ...  :P
[19:17] <Ubulette> yes
[19:18] <armin76> guess i'll try that patch again
[20:07] <armin76> hrm
[20:07] <armin76> Ubulette: it work
[20:07] <armin76> s
[20:08] <armin76> wonder why it didn't before
[20:19] <Ubulette> good
[20:33] <[reed]> armin76: pong
[20:59] <armin76> [reed]: was nspr-4.6.8 released?
[20:59] <[reed]> I don't think so
[20:59]  * [reed] looks
[20:59]  * Ubulette wants 4.7.0
[21:04] <armin76> just asking because the cvs tag NSPR_4_6_8_RTM                  (revision: <IP_ADDRESS>) it's been there since mid-nov
[21:23] <[reed]> dunno
[21:23] <[reed]> ask wtc?
[21:40]  * asac reboot
[21:57] <asac> mozilla bug 176810
[21:57] <ubotu> Mozilla bug 176810 in Java: OJI "clicking a link on a page after descending a page causes hang with spinning disk" [Normal,Resolved: worksforme] http://bugzilla.mozilla.org/show_bug.cgi?id=176810
[21:58] <asac> bug 176810
[21:58] <ubotu> Launchpad bug 176810 in firefox "ZOrder: Flash video obscures javascript menus" [Undecided,New] https://launchpad.net/bugs/176810
[22:00] <asac> bug 177193
[22:00] <ubotu> Launchpad bug 177193 in firefox "pb with photo display. It remains hiden in the back screen" [Undecided,New] https://launchpad.net/bugs/177193
[22:00] <[reed]> all sounds like flash needs to implement support for mozilla bug 137189 already
[22:00] <ubotu> Mozilla bug 137189 in Plug-ins "Windowless plug-in support for X (WMODE)" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=137189
[22:13] <asac> yes
[22:13] <asac> i just needed the urls ... those are dupes
[22:14] <asac> so lets wait till flash 12 :)
[23:53] <asac> jimmy_: back from holidays?


[08:07] <ppisati> moin world
[09:16] <apw> moin moin
[09:16] <ppisati> apw: moin tech lead :)
[09:16] <smb> apw, No yawn (and bees)?
[09:18]  * smb feels like lead, too :-P
[09:20] <apw> ppisati, heh thanks :)
[09:20] <apw> smb, very droll, very droll ... and man i feel like lead more than anything
[10:02] <smb> apw, Oh btw, looking at  bug 1244176... (asked already on #ubuntu-devel but not sure it had been noticed) I think the reply there would be that Saucy images won't get re-spun. I have to figure out whether netboot mini-isos are. Otherwise do you have a howto for replacing kernels in isos?
[10:02] <ubot2> Launchpad bug 1244176 in linux (Ubuntu Trusty) "Server 13.10 Install Fails with USB Keyboard (Appears to Hang)" [High,Fix released] https://launchpad.net/bugs/1244176
[10:04] <ppisati> smb: well, after all, who is using usb keyboards nowadays?
[10:04] <ppisati> couldn't resist sorry... :P
[10:05] <smb> ppisati, Just about everyone... :-P But I guess the secret also is whether they are coming in through usb2 or 3... or actually i think there was ehci and ohci for usb1...
[10:05] <pkern> ppisati: People that use remote KVMs?
[10:06] <smb> Yeah those too
[10:06] <smb> But ppisati just "forgot" the sarcasm tags
[10:06] <ppisati> i was ironic dude...
[10:08] <pkern> I thought you'd argue that everybody installs within virtualization nowadays. :P
[10:11] <smb> It was unfortunately ambiguous. :) But true, I think it was a mix of reporters doing installs on physical hw with the "wrong" usb keyboard type and those doing remote kvm installs. Like I did but just was lucky that the remote just means basement to me and there the machine has a ps2 keyboard... :-P
[10:30] <smb> Ah, ok, not that it matters much but ohci and uhci where usb1 drivers... So that explains a bit why this was not hurting more people...
[10:31] <apw> i assume the simplest work around here is to install raring and upgrade to saucy instead
[10:35] <smb> Hm, yeah might be some other way... maybe not the most elegant but working
[11:14] <eagles0513875> apw: are you around? there was a post to bug #+
[11:14] <eagles0513875> whoops
[11:14] <eagles0513875> bug #967399
[11:14] <ubot2> Launchpad bug 967399 in linux (Ubuntu) "[11.10] Elantech trackpoint does not work Lenovo " [High,In progress] https://launchpad.net/bugs/967399
[11:15] <eagles0513875> another person was asking if this was going to get pushed to an SRU in terms of the kernel. Nobody else seems to have responded about this patch making it upstream
[11:16] <apw> eagles0513875, has anyone followed up on the upstream email thread do you know?
[11:17] <eagles0513875> apw: nobody that im aware of as nobody filed a comment on that bug
[11:17] <eagles0513875> is there an upstream bug filed for this issue?
[11:19] <apw> eagles0513875, mostly they just use the mailing lists as they 'issue tracker'
[11:20] <eagles0513875> im not subscribed there.
[11:20] <eagles0513875> can we at least get this backported and then for 14.04 have a push for it to be in mainline
[11:20] <apw> i have added some clarification on the position to the bug so everyone knows
[11:21] <eagles0513875> apw: thanks :) do you have any reference to what thread it was so i can revivie it or just start another one.
[11:22] <eagles0513875> apw: stupid question i cant seem to sign up wiht their mailing list
[11:23] <eagles0513875> http://vger.kernel.org/
[11:25] <eagles0513875> apw: what list should i subscribe to
[11:32] <apw> http://www.spinics.net/lists/linux-input/msg26869.html is the list it is on i think
[11:35] <eagles0513875> ok apw subscribed there. and will send an email to the mailing list
[11:36] <apw> eagles0513875, ask avout that specific patch
[11:36] <eagles0513875> will do
[11:40] <eagles0513875> apw: what is the address to send to the list
[11:41] <apw> its on the subscribe page i think
[11:42] <eagles0513875> http://vger.kernel.org/vger-lists.html  all im seeing are the links to archives
[13:00] <apw><EMAIL_ADDRESS>is the main list send, linux-input-request to join i thiknk
[13:16] <rtg> apw, I updated a Lenovo laptop yesterday with 3.13 and it now cannot find the SSD. Stupidly I did not have an alternate version to make sure it really isn't HW failure. I'm checking that out this morning.
[13:17] <rtg> a different laptop with the same SSD (although larger) works fine.
[13:20] <apw> rtg, well that is typical isn't it
[13:20] <smb> rtg, If that isn't one of these fastboot ones, you could check whether the ssd at least appears as a boot selection in the bios
[13:21] <rtg> smb, good idea.
[13:21] <apw> when you say canot find it, who says that?  the kernel
[13:21] <apw> ?
[13:21] <apw> if so you know bios and grub found it
[13:22] <rtg> yeah, the BIOS finds the drive 'cause grub loads and launches the kernel. it drops to busybox after awhile because it could not mount the rootfs
[13:22] <apw> ok then not completely gone
[13:22] <smb> apw, Typically it would be if it happened when we are traveling
[13:22] <apw> does dmesg have any indication of the device
[13:22] <smb> Yeah, better than my state last time
[13:22] <apw> smb, heh yeah
[13:23] <rtg> checking dmesg.
[13:24] <rtg> hmm, dmesg|grep sd shows nothing
[13:24] <apw> what version did you have before the update i wonder
[13:25] <rtg> 3.13.0-13 I think. what is the one I just uploaded ?
[13:25] <rtg> that is the one that isn't booting
[13:25] <apw> -0.15
[13:25] <smb> rtg, anything grepping for ata
[13:25] <apw> so i think that is -rc5 -> rc7
[13:26] <rtg> apw, nothing about ata except false positives.
[13:27] <smb> Interesting, so not even found the controller
[13:27] <rtg> I'll boot the daily as soon as  its done flashing.
[13:30] <rtg> it doesn't help that I left the charger 100 miles away. doh! hopefully I've still got enough battery.
[13:30] <apw> rtg, it is one of those days for sure
[13:31] <rtg> tuesday is the new monday
[13:32] <smb> It might be a bit far fetched but at some point there was some discussion/patch that partially reverted fiddling with some bus master bit (iirc) when not doing kexec. Not sure but maybe the good old, remove battery and wait a bit trick works here
[13:34] <rtg> smb: can't hurt to try
[13:40] <rtg> smb, no joy on pulling the battery
[13:40] <smb> smb, ok, so at least not that. hm
[13:41] <rtg> I'm just reinstalling from the daily first, then I'll get 3.13 on it.
[13:43] <smb> During the install you could check lspci -vvvnn and see which driver the SATA controller is attached to (I guess ahci)
[13:44] <smb> Not that we forgot some vital other driver in the initrd
[13:49] <eagles0513875> apw: their mailing list setup is so complex holy cow
[13:51] <eagles0513875> apw: how do i send it to the proper list once im subscribed?
[14:02] <apw><EMAIL_ADDRESS>is the main list send address
[14:40] <rtg> smb, apw: reinstalled from the daily, updated to 3.13-rc7. now everything works. wtf ?
[14:43] <apw> rtg, these things are sent to try us and no mistake
[14:44] <apw> rtg, oh do you have any dkms packages installed ?
[14:44] <rtg> apw, nope, it was pretty much stock
[14:44] <apw> rtg, as we have been ignoring abi on these kernels which has been causing me issues
[14:44] <apw> rtg, not even for testing?
[14:44] <apw> like vbox or similar
[14:44] <rtg> not on my travel laptop
[14:44] <apw> then it is a mystery indeed
[14:58] <smb> rtg, what driver does the disk use (I may have missed it)? I could only think of a case where initrd was misbuild
[14:58] <rtg> smb, checking
[15:02] <rtg> smb, [    2.765203] ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x215c bmdma 0x2060 irq 19
[15:02] <rtg> [    4.112147] ata1.01: failed to resume link (SControl 0)
[15:02] <rtg> [    4.268151] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[15:02] <rtg> [    4.268168] ata1.01: SATA link down (SStatus 0 SControl 0)
[15:02] <rtg> [    4.327579] ata1.00: ATA-8: TOSHIBA MK5065GSXF, GP006B, max UDMA/100
[15:02] <rtg> [    4.327599] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
[15:02] <rtg> [    4.332543] ata1.00: configured for UDMA/100
[15:03] <smb> rtg, looking in "lspci -vvvnn" for SATA should yield which module is used
[15:03] <smb> or driver
[15:05] <rtg> smb: oops, wrong dmesg. this one is 'ata1.00: ATA-9: Samsung SSD 840 EVO 120GB, EXT0BB0Q, max UDMA/133'. lspci says 'Kernel driver in use: ahci'
[15:07] <smb> Ah ok ahci then. I would think that one should be built-in
[15:07] <rtg> CONFIG_SATA_AHCI=m
[15:07] <smb> hm... ok not. :P
[15:07] <rtg> maybe it was just an initrd problem
[15:08] <infinity> It's been =m for ages.
[15:08] <infinity> But yeah, mismatched initrds or some other wonkiness would make that blow up.
[15:09] <rtg> its possible. we've been ignoring ABI changes
[15:52] <jsalisbury> **
[15:52] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:52] <jsalisbury> **
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:56] <jsalisbury> ##
[17:16] <xnox> \o/ 3.13 \o/
[17:16] <rtg> xnox, its coming. gimme a bit
[17:17] <xnox> rtg: as soon as it lands, i'd want some config changes to be ported to nexus kernels to match the distro configs ;-) maybe after some user testing / 3.13 landing in release pocket + some time.
[17:17] <rtg> dang, forgot the meeting
[17:17] <tseliot> rtg: I haven't updated the binary drivers yet, just FYI
[17:18] <rtg> tseliot, so you're kinda behind the eight ball
[17:18] <tseliot> right :)
[17:19] <rtg> tseliot, I imagine it'll take at least another day to propagate through the archive
[17:20] <tseliot> rtg: I'll try to finish fixing at least nvidia 331 tomorrow
[17:31]  * ppisati -> EOD
[18:32] <medberry> infinity, does the raring kernel in precise lose support on January 27th? linux-generic-lts-raring-eol-upgrade?
[18:33] <medberry> metadata in that package shows:
[18:33] <medberry> Supported: 18m
[18:34] <_bjf> medberry, no, we support it until 14.04.1
[18:34] <medberry> _bjf, cool Thanks.
[18:34] <medberry> https://wiki.ubuntu.com/Kernel/LTSEnablementStack says the same.
[18:34] <pkern> _bjf: Will there be any overlap for the saucy kernel where saucy and trusty are supported?
[18:35] <bjf> pkern, same deal .. the lts-backport-saucy kernel will be supported until 14.04.1
[18:35] <pkern> bjf: So that's a "no" then.
[18:35] <pkern> Annoying.
[18:36] <medberry> pkern, .1 comes after the dot nothing
[18:36] <medberry> so a bit of overlap
[18:36] <bjf> pkern, 14.04.1 is the first point release which is after 14.04
[18:36] <pkern> Hm.
[18:36] <bjf> pkern, so yes, there is overlap
[18:36] <pkern> So the trusty stack comes with a 12.04 point release.
[18:37] <pkern> How much later will the first trusty point release be?
[18:37] <bjf> pkern, one sec ..
[18:38] <bjf> pkern, it's about 3 mo. after the initial release
[18:39] <pkern> So the 12.04.x after 14.04 will come about 1 mo. later and saucy+trusty will be supported together for about 2 then?
[18:39] <pkern> Just to get the timeline straight.
[18:39] <pkern> Because the picture on LTS Enablement Stack is different and suggests a hard transition from saucy to trusty.
[18:41] <bjf> pkern, 14.04 (april 17)  14.04.1 (around end of aug.)  lts-backport-saucy will end support around end of aug. when 14.04.1 comes out
[18:41] <pkern> bjf: Thanks.
[18:41] <bjf> pkern, np
[18:42] <pkern> Oh hm. So no overlap then because it's only then when the trusty kernel hits precise?
[18:42] <pkern> Because August is also the line on that picture.
[18:43] <bjf> pkern, the lts-backport-trusty kernel for precise will be out about a week after 14.04 release
[18:44] <pkern> bjf: But without installer support?
[18:44] <bjf> pkern, if you mean that it there isn't a point release that has it as the default, you are correct
[18:45] <pkern> Well, it might as well miss the necessary installer bits in proposed.
[19:01] <xnox> pkern: we rebuild d-i shortly after lts-backport landing, and one has all installer bits / images in precise/daily generated.
[19:02] <xnox> pkern: although we will not cut .5 isos, there is no reason to not have d-i / netboot available with lts-backport-trusty kernel.
[19:04] <pkern> xnox: Ok, thanks, I guess that's something we can test, then.


[18:07] <jugmac00> jelmer: are you around? I had a look at https://bugs.launchpad.net/loggerhead/+bug/1966702 - would you accept PRs on GitHub or only to the bazaar repo on Launchpad? The github repo seems to be a couple of commits behind. The fix and a test seem straightforward. The problem only appears when the optional package pygments is installed. The whole highlighting/pygment thing is currently untested, at least pygments is not installed in the
[18:07] <jugmac00> tox env. So I'd need to install it via requirements.txt (and then whenever you'd like to test the case it is not installed you'd need to mock `sys.modules`). Are you ok with this?


[00:01] <MarkDude> Uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuubuuuuuuuuuuuuuntuuuuuuuuuuuuuu
[00:01] <MarkDude> A bit better jtatum ?
[00:01] <MarkDude> :)
[00:03] <jtatum> thanks MarkDude :) I knew I could count on you
[00:03] <MarkDude> Yep, one of my strengths
[02:21]  * pleia2 waves
[02:36]  * MarkDude heard a rumor they are making a podcast at DVLUG
[02:36] <MarkDude> Whats the deal there grantbow ?
[02:37] <pleia2> they released one a couple weeks ago
[02:38] <pleia2> http://sharethebytes.com/shows/episode-6-questions-about-open-source-2/
[02:38] <darthrobot> Title: [Share The Bytes » Episode 6 – Questions About Open Source]
[02:39] <MarkDude> Right on
[02:39]  * MarkDude listened to Ubuntu on air today
[02:50] <MarkDude> Was a really good show, dude from Dell talked about the Sputnik, and also secure boot
[04:17] <MarkDude> nhaines, great comment on Jono's post
[04:20] <nhaines> MarkDude: thanks.
[04:23] <bkerensa> pleia2: u did a muktware interview >.<
[04:23] <pleia2> bkerensa: indeed I did
[17:50] <pleia2> just so you know, you can paypal your money for sysadmin flowers to<EMAIL_ADDRESS>;)
[17:52] <scientes> syadmin flowers?
[17:52] <pleia2> it's sysadmin day :)
[17:58] <greg-g> pleia2: :)
[18:04] <greg-g> here you go, pleia2 :
[18:04] <greg-g>                  ,~.
[18:04] <greg-g>                 {;@;}
[18:04] <greg-g>           ,~.  ..`~' . *  ,~.
[18:04] <greg-g>          {;@;}  . ,~. ** {;@;}
[18:04] <greg-g>        *..`~'  * {;@;} .  `~'
[18:04] <greg-g>      ,~.   .. **  `~'  ** . ,~.
[18:04] <greg-g>     {;@;} * ,~.   * ... *  {;@;}
[18:04] <greg-g>      `~' ..{;@;} **  ,~. .. `~'
[18:04] <greg-g>       ,~. . `~'. .. {;@;}   *..  *
[18:04] <greg-g>      {;@;}  .. ,~. ..`~' **   ,~.
[18:04] <greg-g>       `~'. ** {;@;}  **   ** {;@;}
[18:04] <greg-g>         .. * . `~'  ** ,~. ...`~'
[18:04] <greg-g>          * ~~  ** ... {;@;} .
[18:04] <greg-g>        .____  ~ *  ~   `~'.~____.
[18:04] <greg-g>         \ \ \\  | ||| |  / / / /
[18:04] <greg-g>     ____ \___\\ || | || /,/___/ ____
[18:05] <greg-g>   ./___ \_____\\| |||||//______/ ___\.
[18:05] <greg-g>    \____/  ,___. | | | .___,   \____/
[18:05] <greg-g>           /     \,--. /`__/ \
[18:05] <greg-g>          |     \_\   /_      |
[18:05] <greg-g>           \ ,--, /`_'\ \    /
[18:05] <greg-g>            `____/  /  \____'
[18:05] <greg-g>                /  /|\  \\,
[18:05] <greg-g>               (  (|||\  \ \
[18:05] <greg-g>               /\  \||\\  \ \
[18:05] <greg-g>               //\  \|\\)  )
[18:05] <greg-g>                  )  ) \'`'
[18:05] <greg-g>                 `'`'
[18:05] <pleia2> thank you greg-g :)
[18:06] <greg-g> least I could do ;)
[18:19] <DonkeyHotei> akk: how do i convert a color image to grayscale?
[18:21] <akk> (why me specifically?) Easiest way is probably Image->Mode->greyscale
[18:21] <akk> though you can also use the hue-saturation dialog or lots of other methods
[18:21] <DonkeyHotei> thanx, didn't see that
[18:22] <DonkeyHotei> is there an integrated SANE frontend?
[18:23] <akk> There's the xsane plug-in -- not sure if that's what you're asking. It's what I use for scanning.
[18:24] <DonkeyHotei> which menu is that in?
[18:27] <DonkeyHotei> nvm, found it
[19:15] <scientes> greg-g, wow! i'm amazed that even worked with my sans font
[19:28] <greg-g> scientes: searching for ascii bouquet worked :)
[19:28]  * greg-g didn't make that
[19:32] <scientes>                 ...:::::::...        ...:::::::...
[19:32] <scientes>              .:::::::::::::::::. .::::::::::::::::::.
[19:32] <scientes>           .::::::::::::::::::::::::::::::::::::::::::::.
[19:32] <scientes>         .:::::::::::::::::::'.-=.-~, ':::::::::::::::::::.
[19:32] <scientes>       .:::::::::::::::::::' /{,_;--'},'::::::::::::::::::::.
[19:32] <scientes>      .:::::::::::::::::::: |  .=~`|//| :::::::::::::::::::::.
[19:33] <scientes>     .::::::::::::::::::::: | /   ; \ | :::' __, '::::::::::::.
[19:33] <scientes>    .:::::::::::::::::::::' ||    | | | :' .' \/\  ::::::::::::.
[19:33] <scientes>   .:::::::::::::::::::::: |\|    | | |\  / \ /_|  :::::::::::::.
[19:33] <scientes>   ::::::::::::::::::::::. \ |  | /|'/ / | \ /_ |  ::::::::::::::
[19:33] <scientes>   ::::::::::::::' ,_ '::: `\ \/|/ / /`.: \ /__/  :::::::::::::::
[19:33] <scientes>   :::::::::::::  /\/`'. ':. `\ `./.'/\ : /.--' .::::::::::::::::
[19:33] <scientes>   :::::::::::::  |_\ / \  ::. '. ,/|\/| //  ''''':::::::::::::::
[19:33] <scientes>   :::::::::::::  | _\ / | .::  | | \ \///  .""'-.  :::::::::::::
[19:33] <scientes>   ::::::::::::::  \__\ / .: .'/| |  `)`/__//_/_/_\  ::::::::::::
[19:33] <scientes>   '::::::::::::::  '--.\ : /\/_| |} /.---. \ \ \ /  :::::::::::'
[19:33] <scientes>    '::::::::::::''     \\ |\/_/| | //`  . `'...-'  :::::::::::'
[19:33] <scientes>     ::::::::::  .-""'.  \\\/ /{| |//  .:::::....::::::::::::::
[19:33] <scientes>      ':::::::  /_\_\_\\__\`(`  | '/  :::::::::::::::::::::::'
[19:33] <scientes>       '::::::  \ / / / .---.\  | |  :::::::::::::::::::::::'
[19:33] <scientes>        '::::::. '-..,'` .:.`\\ | |} ::::::::::::::::::::::'
[19:33] <scientes>          '::::::......:jgs:: \\| |  ::::::::::::::::::::'
[19:33] <scientes>           ':::::::::::::::::: \` |  ::::::::::::::::::'
[19:33] <scientes>             '::::::::::::::::  | |  ::::::::::::::::'
[19:33] <scientes>               ':::::::::::::: {| |  ::::::::::::::'
[19:33] <scientes>                 '::::::::::::  | |  ::::::::::::'
[19:33] <scientes>                   '::::::::::  | |  ::::::::::'
[19:33] <scientes>                     '::::::::  | |} ::::::::'
[19:33] <scientes>                       '::::::  | |  ::::::'
[19:33] <scientes>                        ':::::. |/  ::::::'
[19:33] <scientes>                          ':::.....:::::'
[19:33] <scientes>                            ':::::::::'
[19:33] <scientes>                              ':::::'
[19:33] <scientes>                                ':'
[19:34] <scientes> oh damn that one even has a watermark!
[19:39] <greg-g> haha
[19:40] <pleia2> thank you scientes!
[19:41] <bkerensa>      \\            //           \\
[19:41] <bkerensa>         lo> <<       <o\          <*l    //
[19:41] <bkerensa>         ll             \\          ll   <*l
[19:41] <bkerensa>         llama~         llama~  ^amall    ll
[19:41] <bkerensa>         || ||          \\ \\    || ||    llama~
[19:41] <bkerensa>         '' ''           '' ''   '' ''    // //
[19:41] <bkerensa>                                         '' ''
[19:41] <bkerensa>         \\        //           \\
[19:41] <bkerensa>         l'>       \'>     >>> <-l    //
[19:41] <bkerensa>         ll         \\          ll   <-l
[19:41] <bkerensa>         llama~     llama~  ^amall    ll
[19:41] <bkerensa>         || ||      \\ \\    || ||    llama~
[19:41] <bkerensa>         '' ''       '' ''   '' ''    zz zz
[19:42] <pleia2> hehe, llamas
[19:44] <bkerensa> ╭━━━━━━━━━╮╭┓......┏╮
[19:44] <bkerensa> ┃┈┈┈┈┈┈┈┈┈┃┃╰╮╭╯┃
[19:44] <bkerensa> ┃┈┈┈┈┈┈┈┈┈┃╰━┓┏━╯
[19:44] <bkerensa> ┃┈┈┈┈┈-●┈┈┈╰━━╯┃
[19:44] <bkerensa> ┣━━━━━━╯┈┈┈┈┈┈┃
[19:44] <bkerensa> ╰━━━━━━━━━━━━━
[22:31] <jyo> jtatum: http://shallowsky.com/blog/linux/ubuntu-default-browser.html
[22:31] <darthrobot> Title: [Setting the default browser when update-alternatives fails (Shallow Thoughts)]
[22:31] <jyo> i.e. akk actually knows update-alternatives syntax.
[22:33] <akk> I actually don't, had to muddle it out and be helped by pleia2 and maco :)
[22:34] <akk> and the syntax didn't seem to work anyway, as it turned out.
[23:01] <jtatum> we were trying to list all the alternatives last night
[23:01] <jtatum> i poked at that dumb command for a while before giving up and ls -l /etc/alternatives
[23:02] <jtatum> haha, awesome. you touch them directly too :)
[23:02] <akk> Yeah, that worked a lot better than the command.
[23:03] <jtatum> get-selections, eh? i was trying variations on --list —all
[23:03] <akk> It took me a long time to figure out --get-selections was what I needed.
[23:04] <akk> The man page is ... poor (choosing a more polite word than my first inclination).
[23:04] <jtatum> What a table-flippingly bad command
[23:04] <jtatum> the most complicated thing i tried to do with it before was change editor. i guess it was okay at that.


[04:37] <kelvinliu> wallyworld_: got this pr to fix the destroy-controller hanging issue, could u take a look? ty https://github.com/juju/juju/pull/12178
[06:47] <kelvinliu> wallyworld_: https://github.com/juju/juju/pull/12179 got this PR for fixing one of the error in migration tests, +1 plz ty
[08:45] <achilleasa> can I get a quick CR on a clean 2.8->develop merge: https://github.com/juju/juju/pull/12180
[09:00] <stickupkid> achilleasa, swap you https://github.com/juju/juju/pull/12181
[09:09] <elox> Look at the bottom of this official documentation: https://juju.is/docs/charm-writing/relations  (For a new user, its telling that there exist a single interface in the juju eco-system "mysql".
[09:09] <elox> A new user would think that juju is really not ready.
[09:10] <stickupkid> Probably should be "mysql" is another interface example
[09:11] <elox> I would really love some place where to find a more consistent and comprehensive place where to easily browse interfaces that exists.
[09:12] <elox> I had a hard time writing this tutorial and got this as a comment from a user. That he had no clue on where to find interfances that exists and how to use them. https://discourse.juju.is/t/tutorial-relations-with-juju/3632
[09:13] <elox> ... so I started to look, and realized that I couldn't find any information except in random places on github and launchpad etc. with little or no consistent documentation.
[09:13] <stickupkid> https://jaas.ai/search?provides=elasticsearch
[09:13] <stickupkid> that'll find everything that provides an elasticsearch interface
[09:13] <elox> A new user will hit a wall here.
[09:14] <stickupkid> that'll find everything that requires an elasticsearch interface https://jaas.ai/search?requires=elasticsearch
[09:14] <stickupkid> I really don't think we document that well at all and I agree
[09:15] <elox> Thats nice, but its not the way people would go ahead and find information and understand what is possible really.
[09:15] <stickupkid> I wonder if juju find (new command comming for searching charms) should offer that...
[09:16] <stickupkid> so is the problem understanding an interface or finding other charms that provide/require the interface?
[09:17] <stickupkid> I think we should do both better
[09:17] <elox> I think that juju needs some kind of inventory which has a consistent presentation for things like "interfaces" to that any two different interfaces can be understood equally. The format of that information needs to be defined and presented in such a way that it can be replicated easily.
[09:19] <elox> If every interface is "different", the level of repetition will be low and cumbersome. A user then needs to "re-learn" every relation from what ever documentation is available or most likely by studying someone elses code. This is a very user-unfriendly path forward learning and using relations.
[09:20] <stickupkid> elox, I really think this discourse or bug worthy, it's really valid criticism that I don't want to loose
[09:21] <elox> It might be enough for expert level programmers, but for casual programmers, such as myself - I'm hitting a hurdle I have a very hard time getting over and most likely will produce bad code from.
[09:22] <elox> @stupidkid what do you propose?
[09:23] <stickupkid> this discussion in discourse, explain what you've hit, what's wrong.
[09:37] <elox> stupidkid: https://discourse.juju.is/t/interfaces-relations-and-how-to-help-casual-users-implement-them-in-juju/3700
[10:01] <stickupkid> achilleasa, updated
[10:02] <oscar_0> how does juju use images from a cloud? is there a way to list all images available in a cloud?
[10:03] <stickupkid> oscar_0, all the images for the clouds http://cloud-images.ubuntu.com/releases/streams/v1/
[10:04] <oscar_0> stickupkid: thanks
[10:05] <stickupkid> oscar_0, do I know if there is an easy way to list all the images for a given cloud, I'm unsure
[10:06] <oscar_0> stickupkid: but how do I use that repository with juju?
[10:07] <stickupkid> oscar_0, that's the default fall back cloud images repository
[10:07] <stickupkid> oscar_0, let me phrase another way, what are you wanting to do?
[10:08] <oscar_0> stickupkid: we want to run a specific version of centos due to certain applications. we have a VMware cloud that is hooked up with juju. but so far it only plays with ubuntu
[10:09] <stickupkid> oscar_0, you need to run this plugin - juju metadata
[10:09] <stickupkid> https://github.com/juju/juju/tree/develop/cmd/plugins/juju-metadata
[10:09] <stickupkid> see here for more information, let me see if there is any documentation on this
[10:10] <oscar_0> stickupkid: thanks, I will explore that one
[10:10] <stickupkid> https://discourse.juju.is/t/new-feature-in-juju-2-8-add-custom-machine-images-with-the-juju-metadata-command/3171
[10:10] <stickupkid> and https://discourse.juju.is/t/cloud-image-metadata/1137
[10:11] <oscar_0> going to check those ones out
[11:07] <oscar_0> What kind of permissions does "juju metadata list-images" require? I'm getting "ERROR permission denied (unauthorized access)"
[11:07] <stickupkid> that I don't know
[11:08] <achilleasa> manadart: potential fix for flaky TestStatusAllFormats https://github.com/juju/juju/pull/12182. Cannot get it to fail locally though so I can't verify it will do the trick :-(
[11:09] <manadart> achilleasa: Will look in a mo'. In the k8s meeting.
[11:23] <stickupkid> oscar_0, by the looks of it (I could be wrong here), it only lists images that you've added
[11:28] <oscar_0> stickupkid: I resolved the error. I was not properly logged in as controller admin
[11:35] <oscar_0> this "image-id" thing in add-image, is that one provided by the cloud provider?
[14:09] <aluria> cory_fu: hi o/ - would you have ~5min for a Q about queue handlers in the reactive framework?
[14:14] <hml> stickupkid: with 12173, i get no password prompt on the qa - updated the pr
[14:14] <stickupkid> depends how snap is stalled maybe?
[14:15] <stickupkid> *installed
[14:16] <hml> stickupkid: just have classic confinment on the juju snap
[14:16] <stickupkid> snap requires sudo for me
[14:16] <stickupkid> no idea why
[14:16] <hml> me too for snap refresh snap info does not.
[14:16] <hml> but why doesn’t the test let me put in the password?
[14:17] <hml> oh, it expects the snap command to be run with sudo
[14:17] <stickupkid> yeah, I really don't want sudo in our tests, but may have too
[14:17] <stickupkid> grrr
[14:19] <hml> stickupkid: to test, i added sudo, didn’t fail imediately
[14:19] <hml> wondering how the test will run in the ci environments
[14:20] <stickupkid> so sudo is fine as we'll be in a container
[14:21] <petevg[m]> I wonder if there's a group that we can add a user to in order to manage snapd ...
[14:21] <petevg[m]> Though if we're in a container, I guess it doesn't matter.
[14:24] <hml> stickupkid: does the pr need to be rebased after the other pr landed?
[14:24] <hml>    | ==> Current juju version 2.8.5
[14:24] <hml>     | ERROR no matching agent versions available
[15:28] <stickupkid> hml, I added sudo and it worked for me
[15:28] <stickupkid> hml did you run make go-install after you downloaded the branch?
[15:29] <hml> stickupkid: i did
[15:41] <cory_fu> aluria: Hey, sorry I missed your ping earlier; I was out voting.  Do you still have a question?
[15:43] <aluria> cory_fu: hey, nw! yes, the Q is how the order in which handlers are triggered is decided - in  https://pastebin.ubuntu.com/p/Cs23QJrkKT/ -> a @hook("config-changed") function (line 14) removes a state and several handlers are queued (lines 24-30)... the "setup_grafana" handler should have been run before "configure_sources"... and so it is in focal and bionic, but the pastebin runs on xenial
[15:44] <aluria> I think it would be much safer on the side of the charm to trigger handlers one by one, in sequence, rather than in parallel... but I wanted to understand why the above was an issue in Xenial but not in Bionic nor Focal
[15:49] <cory_fu> aluria: Handlers are run one at a time, and there's a phase for @hook handlers to run before non-@hook handlers, but the specific order of hooks within a phase isn't well defined.  Specifically, it depends on file discovery, module attribute, and dict ordering.  The difference between series is probably due to the change in dict ordering stability in newer versions of Python (officially in 3.7, unofficially in CPython 3.5 and 3.6), but there is
[15:49] <cory_fu> still some potential for the order in which files are discovered to change it.
[15:50] <cory_fu> If a given handler needs to run after another one, you should have the earlier one set another flag that the later one can gate off of, or just call it directly.  Or, better yet, start using the new framework.  ;)
[15:51] <aluria> cory_fu: hehe, cheers very interesting. Where is the queuing of handlers defined in https://github.com/juju-solutions/charms.reactive/tree/master/charms/reactive ?
[15:52] <aluria> https://github.com/juju-solutions/charms.reactive/blob/master/charms/reactive/bus.py#L94
[15:53] <cory_fu> Yeah, that's where all the registered handlers are stored, and then dispatch function tests them and runs the one whose conditions match: https://github.com/juju-solutions/charms.reactive/blob/master/charms/reactive/bus.py#L384
[15:54] <aluria> ack, ty
[15:59] <cory_fu> aluria: Hrm.  Odd, though.  Xenial has 3.5, and even if the order of the registered handlers was unstable (the order in which the trace message for the handler being queued is logged ought to be the same as the order they are invoked, because by that point they're converted to a list: https://github.com/juju-solutions/charms.reactive/blob/master/charms/reactive/bus.py#L351
[16:03] <cory_fu> Still, I wouldn't recommend relying on any expected ordering of the handlers without enforcing it with an explicit flag condition.  In this case, it seems like the other handlers should explicitly gate on the grafana.configured flag
[16:05] <cory_fu> Or maybe config_changed should also clear grafana.started when it clears grafana.configured
[16:05] <aluria> cory_fu: /me nods - thx for the clarifications


[08:16] <jtv> wgrant: how does the self.home[1:] work?  Just strip off the leading slash to get a relative path?
[08:17] <wgrant> jtv: Right. There's probably a better way to do that, though.
[08:18] <jtv> wgrant: my first choice would probably have been re.sub, but I guess a key point is that there's nothing sensible to do in cases where it's a relative path.  So I'm thinking an assertion may be enough to turn weird "known path with missing letter" errors into clearer ones.
[08:19] <jtv> o-kayyyy... feature request for lucid: plug-n-play USB mouse support.
[08:19] <wgrant> jtv: It works. Restart X -- you probably had an incompatible evdev driver update.
[08:20] <wgrant> So it will have tried to dynamically load the driver, and failed.
[08:20] <jtv> I'll do without for now.  The macbook pro has a wonderful huge, buttonless touchpad.  Now if only the "disable touchpad while typing" worked a little more reliably.  :)
[08:23] <jtv> wgrant: there is a test for updateBuild_WAITING...  I'd guess that all it needs is a tarball to upload and you'll have an integration test that exercises the _uploadTarball fix.
[08:24] <wgrant> jtv: Oh, I forgot you actually had useful tests.
[08:24] <jtv> \o/
[08:24] <wgrant> Soyuz is rather deprived.
[08:24] <jtv> Rather.  :)
[08:25] <jtv> It's funny how that seems to be infectious.  Sometimes in Wellington I heard things like "we'll know when it breaks."  But me, I often find myself stumped by _how_ it breaks when it does.
[08:26] <jtv> Have a look at lib/lp/translations/tests/test_translationtemplatesbuildbehavior.py, test_updateBuild_WAITING
[08:27] <wgrant> jtv: That explicitly clobbers _uploadTarball.
[08:28] <wgrant> It sounds like I'm going to need to set up a real branch with translation-capable projects attached.
[08:29] <jtv> wgrant: hmm... yes, that sounds very true.
[08:30] <jtv> I don't know of any good way to inject "pretend this is the project we're looking for" into the utility.
[08:30]  * wgrant doesn't actually know how Rosetta works.
[08:30] <wgrant> It's the one part of LP that I remained completely ignorant of until Saturday.
[08:31] <jtv> wgrant: you could consider cross-breeding this test with an existing one for _uploadTarball.
[08:31] <jtv> wgrant: then welcome!
[08:31] <wgrant> jtv: Is there an existing one for _uploadTarball?
[08:31] <jtv> Has to be...
[08:32] <jtv> test_uploadTarball may be our baby; same file.
[08:32] <wgrant> Oh. That's conveniently short.
[08:32] <jtv> Most of the meat is in the setup.  :-)
[08:33] <wgrant> yeah.
[08:33] <wgrant> Any hints?
[08:33] <jtv> You need all of the setup.
[08:34] <jtv> Whereas the updateBuild_WAITING test does not rely on any implicit setup at all.
[08:35] <wgrant> Although it does need makeBehavior.
[08:35] <jtv> So I'd create the integration test by copying test_updateBuild_WAITING right behind the _uploadTarball test.
[08:35] <wgrant> Ah, but that's in the mixin.
[08:35] <wgrant> Didn't notice that.
[08:35] <wgrant> That's easy, then.
[08:35] <jtv> yay for mixins  :)
[08:36] <jtv> It's already in the ancestry of the test class we're looking to extend, I believe.
[08:36] <wgrant> Exactly.
[08:37] <jtv> So you can copy test_updateBuild_WAITING in there, remove all the assertions, and tack on the final paragraph from test_uploadTarball.
[08:38] <wgrant> Yep.
[09:09] <noodles775> stub: Do you know if there is any performance benefit to using CREATE TABLE AS SELECT... to create and populate a table from *lots* of existing data, as opposed to the normal method of create table, then a migration function to iterate and insert lots of data?
[09:09] <wgrant> Pfft, it's only 1.6 million rows.
[09:10] <noodles775> Just interested :)
[09:10] <stub> inserting rows one at a time is slower. Inserting them in bulk is faster. Building the indexes after populating the table with data is a win.
[09:10] <noodles775> Thanks.
[09:12] <stub> CREATE TABLE AS SELECT is the same as CREATE TABLE; INSERT INTO [...]
[09:13] <noodles775> stub: except that the indexes are added afterwards right? (and the INSERT INTO is * 1.6 million for the data migration).
[09:13] <noodles775> stub: here's a very early WIP that I was toying with: https://code.edge.launchpad.net/~michael.nelson/launchpad/db-build-generalisation-db-changes/+merge/22527
[09:13] <stub> Indexes are created when you create them. You might create them as part of the CREATE TABLE statement, or you might create them after.
[09:13] <noodles775> Right.
[09:15] <noodles775> stub: OK, so there's no difference between the above create table as select... and the equiv. create table, followed by a function that does 1.6 million inserts into those tables, as long as the indexes are created afterwards in both cases?
[09:15] <noodles775> s/tables/table
[09:15] <stub> Yup. But 1.6 million doesn't take long anyway unless the rows are particularly wide.
[09:16] <noodles775> Yep. Thanks for the info!
[09:25] <noodles775> jtv: I know it should be the other way around, but do you mind r or rs'ing a trivial testfix for the db-devel failure: https://code.edge.launchpad.net/~michael.nelson/launchpad/db-test-fix-timebomb/+merge/22595
[09:25] <jtv> noodles775: hadn't noticed the failure, but hang on, I'm looking
[09:26] <noodles775> Thanks. It's what's holding up devel being re-synced after the rollout.
[09:26] <jtv> noodles775: when you say it should be the other way around, do you mean I/we broke it?
[09:26] <noodles775> jtv: no, I should be reviewing right now :/
[09:26] <noodles775> But there's just been a whole bunch of un-expected things, so I haven't started yet.
[09:26] <jtv> noodles775: well you couldn't have reviewed your own, and I don't recommend sitting around waiting for someone else to fix it either.  :)
[09:26] <jtv> same here
[09:27] <jtv> noodles775: one question: doesn't this risk undermining the test?  A ... could be hiding an entire line of output.
[09:28] <noodles775> Yes, if an extra line suddenly appeared in the output, it would be swallowed.
[09:28] <noodles775> Any other easy fixes?
[09:31] <jtv> Either leaving the date out of the output altogether, I guess, or replacing it with a yes/no
[09:31] <noodles775> OK, doing so now.
[09:33] <jtv> thanks for bearing with me.
[09:42] <jtv> wgrant: any luck with that test?
[09:43] <wgrant> jtv: Sorry, got distracted.
[09:43] <wgrant> Yes, it works.
[09:43] <jtv> cool!
[09:44]  * jtv always feels a warm glow whenever integration-testing of the build farm in the test suite is extended
[09:44] <jtv> wgrant: not showing up in the diff yet though
[09:45] <wgrant> jtv: No, just pushed now.
[09:45] <wgrant> I wrote it, fired off the tests, and forgot.
[09:45] <jtv> wgrant: you're just not pushy enough :P
[09:46] <wgrant> Heh.
[09:46] <jtv> (I assume there's an implicit "committed" in that story)
[09:46] <wgrant> Yes.
[09:46] <jtv> Just being pedantic, never mind me anyway
[09:49] <wgrant> jtv: Can you think of a way to test the slave change?
[09:50] <wgrant> I'm not sure of what tests you have around there.
[09:50] <jtv> wgrant: maybe you could do a test where you fake addWaitingFile, and see that it gets a sensible path?
[09:51] <jtv> Feel free to extend FakeMethod to record its last args and kwargs.
[09:51] <wgrant> jtv: I was hoping there was existing infrastructure around there.
[09:52]  * jtv searches
[09:53] <jtv> Not really infrastructure, but if you extend FakeMethod in this way, then lib/canonical/buildd/tests/test_translationtemplatesbuildmanager.py already fakes gatherResults for testing—should provide a usable base.
[10:10] <noodles775> jtv: I'm push the changes, but the MP hasn't updated yet.
[10:10] <jtv> noodles775: thanks
[10:11] <noodles775> jtv: http://pastebin.ubuntu.com/407482/
[10:11] <noodles775> That's the incremental.
[10:13] <jtv> noodles775: approved.
[10:13] <noodles775> jtv: Thanks.
[11:46] <mrevell> Hello. I have a fairly simple text change branch, if anyone would like to review it! https://code.edge.launchpad.net/~matthew.revell/launchpad/maintenance-notice
[11:47] <noodles775> Sure! Just add it to the queue pls.
[11:56] <noodles775> wgrant: would you have time to go over a review I'm doing and adding any comments (I'll be finished in a minute, but I'd like a second opinion from someone more familiar with germination etc.)
[11:56] <noodles775> s/adding/add
[11:56] <noodles775> And it doesn't need to be today.
[11:57] <wgrant> noodles775: Sure. mvo's?
[11:57] <noodles775> wgrant: thanks, yep. I'll be finished soon and will add you as a reviewer.
[12:03] <ctrlsoft> hmm, this is my third week of reviews and so far I've only done soyuz reviews for some reason :-)
[12:04] <noodles775> ctrlsoft: yeah, and active reviews is all soyuz stuff too!
[12:05] <ctrlsoft> wgrant: do you need me to land move-lots-of-buildd-master-to-queuebuilder ?
[12:05] <noodles775> wgrant: ok, I've posted my comments and requested a review from you.
[12:06] <wgrant> ctrlsoft: When PQM opens, that would be lovely.
[12:06] <wgrant> For now, maybe just mark it Approved so it drops off +activereviews.
[12:06] <wgrant> Thanks.
[12:06] <wgrant> Ah, you already have.
[12:39] <wgrant> noodles775: I don't like the way it uses python-apt when it could just use internal LP APIs, but I guess that's reasonable given that it's not really part of LP.
[12:39] <wgrant> Otherwise it's fine.
[12:56] <cjwatson> noodles775: I'd like to work on fixing bug 294846, since it's annoying me.  Do you have a moment for a pre-impl chat?
[12:56] <mup> Bug #294846: Setting to Won't Fix is ACLed but unsetting it isn't <ubuntu-qa> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/294846>
[12:57] <wgrant> Is it actually desirable? It's unprecedented.
[12:58] <cjwatson> How so?  We have existing ACLs
[12:58] <wgrant> Nothing that prevents users from rectifying triage mistakes and reopening bugs.
[12:58] <wgrant> (there's of course the obvious problem that that sometimes isn't wanted, but...)
[12:59] <cjwatson> The current pattern is: developer says they don't intend to fix a bug, and rather than trying to persuade them that they're wrong in comments, the user just slams it back to New
[12:59] <cjwatson> repeat until very bored
[12:59] <wgrant> Well, there's discussion about introducing a new status for that, which looks less obviously closed.
[12:59] <wgrant> So users will hopefully not try to reopen it.
[12:59] <cjwatson> That seems like a silly workaround to me
[12:59] <wgrant> Unless Mark starts Won't Fixing my bugs without comment again :P
[12:59] <cjwatson> users will sooner or later figure out that it means closed, and then we're back where we started
[13:00] <wgrant> Hmm.
[13:00] <cjwatson> reopening bugs rather than engaging in discussion with the developer is a community anti-pattern
[13:01] <wgrant> Indeed.
[13:01] <cjwatson> the Debian BTS even says in the mail you get when a bug is closed that if you think it's wrong you should discuss it with the developer, who'll reopen if needed
[13:02] <cjwatson> that said I don't think people should be prevented from reopening Fix Released - Won't Fix is different because it's generally the result of a genuine difference of opinion, in which case simply reopening it is unlikely to be useful
[13:04] <cjwatson> still, if it's controversial, then I suppose a pre-impl chat is premature
[13:04] <wgrant> https://dev.launchpad.net/LEP/CloseBugsLeaveDiscussionsOpen
[13:04] <cjwatson> aha
[13:04] <cjwatson> bizarre summary though.  Discussion remains open on Won't Fix bugs too.
[13:05] <cjwatson> I'll just link to that from the bug, then
[13:05] <wgrant> Yes, I thought that a little odd too.
[13:06] <cjwatson> distinction between socially open and technically open, I suppose
[13:07] <cjwatson> While I'm here, is it reasonable/acceptable/common to submit Launchpad patches having run *only* EC2 tests, not local tests?  I find that I don't have the resources at the moment to keep enough local infrastructure for running Launchpad tests, since I do it only occasionally
[13:09] <wgrant> Not common, but if it passes EC2 then it's fine... but that sounds like an inefficient way of running tests unless your change is tiny and you're really sure.
[13:12] <cjwatson> mm, it tends to take me at least an hour to clear enough space for Launchpad tests, update all the dependencies and such, and then I'm less efficient at whatever else I'm meant to be doing
[13:12] <cjwatson> if I were doing it all the time then that would be different
[13:13] <wgrant> Yeah.
[13:29] <noodles775> cjwatson: is it worth updating that LEP or chatting with jml regarding the bug? (at least so the LEP indicates why the decision has been made to allow unsetting from Wont Fix or similar)?
[13:29]  * noodles775 can't see a comment related to it there.
[13:34] <jml> we hadn't even thought of ACLs for the status change
[13:34]  * jml makes a note
[13:49] <jml> wgrant, cjwatson, I've just commented on the bug. I think the ACL on wontfix is separate from the OPINION status discussion.
[13:51] <deryck> interesting discussion.
[13:51]  * deryck looks at bugs....
[13:51] <jml> deryck, oh yeah :) I was surprised to find a discussion like this on #launchpad-reviews
[13:51] <deryck> yeah, I don't watch this channel unless pinged ;)
[13:52] <jml> but I'm firmly stuck in my "fewer channels" heresy
[13:53] <jml> deryck, the keyword highlight on "bug" not working out for you so well? :P
[13:53] <deryck> So I fall in the camp of bdmurray and cjwatson on this.  The ACL is pointless when unset.  I didn't realize we had this bug even.  Sorry.
[13:53] <deryck> jml, I droped that after 4 hours ;)
[13:53] <jml> it's been pleasing to me watching my "package branch" keyword watch become increasingly useless as people use them more.
[13:54] <deryck> heh
[13:54] <deryck> jml, I take it you favor the ACL on unsetting WONTFIX as well?
[13:55] <jml> deryck, yep.
[13:55] <cjwatson> I was working on http://paste.ubuntu.com/407546/, but then it occurred to me that I probably ought to talk about it with somebody, and I hadn't got close to testing it yet
[13:55] <jml> deryck, wgrant has a good point that it makes it gardening mistakes harder
[13:56] <cjwatson> just means you have to find somebody minimally competent to fix it for you ...
[13:56] <jml> deryck, I can't think of how to resolve that tension though.
[13:56] <jml> cjwatson, for Ubuntu, sure.
[13:56] <cjwatson> mm, true
[13:56] <cjwatson> (I wouldn't have brought it up in this channel if I'd realised it was controversial, sorry)
[13:57] <cjwatson> do many other LP pillars have Ubuntu's problem of simply being unable to keep up with bug mail?
[13:57] <deryck> jml, yes, I definitely see wgrant's point.  but it's a "mistake" of semantics, though.  Do bug supervisors regularly accidentally set something to WONTFIX?
[13:58] <deryck> or is it a matter of "no, you're wrong, this should be fixed." :-)
[13:58] <jml> cjwatson, too much in LP is controversial. some strange alchemy makes them less controversial once they are done though.
[13:58] <deryck> cjwatson, I don't think anyone has the level of problem Ubuntu has.  Both others certainly complain about the mail.
[13:59] <jml> deryck, you mean "LP cannot be expected to tell the difference between an accidental status change and a genuine difference of opinion"?
[13:59] <deryck> jml, exactly.
[14:00] <jml> deryck, I'd agree. How do users discover who has bug-triaging powers for a given pillar?
[14:00] <cjwatson> if accidental setting to WONTFIX is a concern, then leave it out of the AJAX thing?
[14:00] <cjwatson> (not that that wouldn't be confusing in other ways ... but most of the accidental changes seem to be AJAX mis-clicking)
[14:00] <jml> cjwatson, tbh, I don't think it's a major concern.
[14:01] <deryck> cjwatson, I'm also suggesting that I don't think there is much if any accidental setting of WONTFIX.  bug supervisors aren't generally careless.
[14:01] <deryck> jml, ^^
[14:01] <jml> agreed.
[14:01] <jml> ok, I'll drop it.
[14:01] <deryck> I think if a user disagrees and we have this ACL preventing unsetting, then a user should add a comment:  "hey, you dofus this should be fixed." :-)
[14:01] <deryck> hyperbole, but you get the idea.
[14:02] <cjwatson> deryck: while I'm generally in your camp, there's quite a lot of bug triager carelessness in Ubuntu, unfortunately
[14:02] <cjwatson> (but this is a problem we should fix!)
[14:02] <deryck> cjwatson, ah, true.  You have a large group of people doing this.
[14:03] <cjwatson> and a social misdesign in which triage is marketed as something that's an easy way to start helping out Ubuntu
[14:03] <deryck> agreed!
[14:03] <cjwatson> but I could rant about this for hours
[14:03] <deryck> every project does that.  and it's sooooo bad.
[14:04] <deryck> I wonder, too, if it's not self correcting, i.e. once people realize they can't easily unset it if bug traigers become more careful.
[14:04] <jml> hmm
[14:04] <jml> that's given me a completely irrelevant idea
[14:07] <deryck> cjwatson, so I would welcome the branch here for this.  I don't think you need the BUG_SUPERVISOR_OLD_BUGTASK_STATUSES, though.
[14:07] <deryck> just self.status not in BUG_SUPERVISOR_BUGTASK_STATUSES and new_status not in BUG_SUPERVISOR_BUGTASK_STATUSES, right?
[14:07] <cjwatson> deryck: I felt that it should be OK to set status away from Triaged
[14:08] <deryck> ah, right
[14:08] <cjwatson> this is just a gut feel
[14:08] <cjwatson> if you disagree I don't feel strongly
[14:08] <deryck> cjwatson, what do people normally transition to from triaged?
[14:08] <cjwatson> but it seemed to me that we might want those to be independently controllable
[14:09] <cjwatson> either in-progress etc. (developer) or something like "oh, hang on, this isn't clear after all" incomplete (not sure)
[14:09] <deryck> right
[14:09] <cjwatson> it just didn't seem as obviously final as wontfix is meant to be
[14:09] <deryck> I agree with you on this.  it's just the CONSTANT for WONTFIX that I'm not crazy about.
[14:09] <cjwatson> CONSTANT?
[14:09] <deryck> maybe just `self.status is not BugTaskStatus.WONTFIX`
[14:10] <cjwatson> oh right
[14:10] <cjwatson> if you like, sure
[14:10] <deryck> instead of adding BUG_SUPERVISOR_OLD_BUGTASK_STATUSES
[14:10] <deryck> keep someone from chasing down what that is later :-)
[14:11] <deryck> cjwatson, now one issue that will complicate this...
[14:12] <deryck> cjwatson, if it's in WONTFIX, I think the AJAX widget should not allow selecting any other statuses.  and I'm not sure how the js code consults canTransitionToStatus
[14:12] <cjwatson> I think it excludes anything for which that returns False
[14:13] <cjwatson> browser/bugtask.py:status_widget_items
[14:15] <deryck> yes, good spot.
[14:15] <deryck> cjwatson, so when you're ready, I'll happily review this for you. :-)  many thanks for the fix!  jml -- are you ok with this?  Or further discussion is required?
[14:15] <jml> not from me.
[14:15] <deryck> excellent.
[14:17] <cjwatson> I'll need to set up ec2test, so ... see you in a bit ;-)
[14:22] <deryck> ok :-)
[15:51] <jml> salgado, why the 'tee' change?
[15:52] <salgado> jml, to use sudo, I guess
[15:52] <salgado> before that command was executed as root
[15:52] <jml> oh, duh. I should have seen that :)
[15:52] <salgado> not it's as ubuntu
[15:52] <jml> *nod*
[15:52] <jml> salgado, r=me
[15:53] <salgado> thanks jml!
[21:14] <rockstar> bac, can I have you do a quick review for me?
[21:15] <bac> rockstar: for you?  sure!
[21:16] <rockstar> bac, https://code.edge.launchpad.net/~rockstar/launchpad/code-js-move/+merge/22656
[21:19] <bac> rockstar: :(
[21:19] <bac> your rename of the code js directory is going to break branches that sinzui and i have in progress
[21:20] <bac> rockstar:  so, lp-deps.py is meant to be general purpose, right?  each app will have to add themselves to JS_DIRSET?
[21:21] <rockstar> bac, yes.
[21:24] <bac> rockstar: can i get you to talk to sinzui tomorrow before landing this?  i want to ensure his changes to discover JS tests will still work.
[21:24] <rockstar> bac, well, we talked about it at the UI meeting, but yes.
[21:24] <bac> we may have to move our js too.
[21:24] <bac> thanks.
[21:24] <rockstar> In fact, I think I'm going to have to move everyone's javascript is moved soon.
[21:24] <rockstar> bac, does that me r=you then?  :)
[21:24] <bac> yeah, that makes sense
[21:25] <bac> rockstar: yeah, r=bac but chat with curtis
[21:25] <bac> he won't say not to land it but may need to coordinate some stuff
[21:25] <rockstar> Yeah, I suspected as much.
[21:26] <rockstar> bac, although I bet he's tired of that branch.  :)
[21:26] <bac> yes
[21:26] <bac> we all are
[22:08] <cjwatson> should I be expecting to get a mail from<EMAIL_ADDRESS>about going over a limit on volume of sent e-mail after a full ec2test run?
[22:14] <salgado> I've never got one
[22:15] <cjwatson> seems odd for it to be sending any mail out of the instance
[22:16] <salgado> indeed; on test runs we use the stub mailer
[22:16] <ctrlsoft> I've never had one either; it shouldn't be sending email other than the success/failure email and email to PQM
[22:16] <mwhudson> it certainly shouldn't
[22:52] <wgrant> bac: Can you please re-approve https://code.edge.launchpad.net/~wgrant/launchpad/refactor-slavestatus/+merge/22285?
[22:53] <bac> wgrant: it looks fine
[22:54] <bac> wgrant: do you want me to send it off to ec2 and land now?
[22:55] <wgrant> bac: Ah, I didn't realise it had reopened. Yes please!
[22:55] <wgrant> Thanks.
[23:04] <wgrant> Can someone please also send https://code.edge.launchpad.net/~wgrant/launchpad/move-lots-of-builddmaster-to-queuebuilder/+merge/22009, https://code.edge.launchpad.net/~wgrant/launchpad/bug-540819-fix-builder-list-icons/+merge/22288 and https://code.edge.launchpad.net/~wgrant/launchpad/filter-apt_pkg-deprecationwarnings/+merge/22317 off to EC2?
[23:05] <bac> wgrant: off she goes.  let me know if you don't get an email in 4-5 hours
[23:05] <wgrant> bac: Thansks.
[23:05] <bac> wgrant: ask rockstar about those others.  part of ocr, you know.
[23:05] <wgrant> bac: Hm, true. rockstar ^^
[23:21] <jpds> bac: Can you send: https://code.edge.launchpad.net/~jpds/launchpad/fix_361650_model_changes/+merge/20785 ?
[23:28] <jpds> bac: Actually, I should probably let sinzui re-review.