[02:18] <pleia2> adding the dmb post to fridge
[03:01] <akgraner> pleia2, thanks!
[07:45] <dholbach> good morning


[00:01] <Socah> https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/392671
[00:01] <ubot4> Launchpad bug 392671 in rhythmbox "volume control in program affects main " [Low,Fix released]
[00:05] <virtuald> it's a feature :(
[00:07] <Socah> feature? lol
[00:08] <virtuald> seems like it's fixed upstream so fix should be in karmic soon
[00:08] <Socah> ok, thank you for information
[00:08] <Socah> I'm pretty new in this whole bug-reporting-things
[00:12] <virtuald> me too but i think i'm getting the hang of it (if that's the expression)
[02:21] <Socah> Hello. Is there any reason that after removing pulseaudio and reloading alsa GNOME can't detect any audio device, but mocp (music on console player) is playing well?
[02:21] <Socah> Or should I report it as bug
[18:40] <Socah> Hello. Is there any way to control sound level without pulseaudio via gnome? gnome-volume-control and applets are not visible (they try to connect to sound server, but can't?). The only way that I can control sound atm is alsamixer
[18:43] <shrift> I just installed a fresh kubuntu karmic daily.... Anything I can help test?


[12:29] <vladanian> I've got an upstart question -- I'd been running it on edgy for a few weeks and it was working fine, but for the past couple weeks I've gotten hung up at boot on, "upstart: Error reading control message: Invalid message received."  Anyone encounter this?
[12:30] <johnnybuoy> why is upstart good for me?
[12:32] <johnnybuoy> hmm
[12:45] <vladanian> In case anyone's interested, I've filed a bug: https://launchpad.net/products/upstart/+bug/61322
[12:46] <johnnybuoy> this is kewl! init IS a bit old
[12:47] <johnnybuoy> the problem: so is *nix :(
[12:47] <johnnybuoy> the whole net thing in *nix is a hack
[12:47] <johnnybuoy> prtty good hack, but still a hack
[12:47] <johnnybuoy> but GO upstart
[12:59] <mjg59> 23:47 < johnnybuoy> the whole net thing in *nix is a hack
[12:59] <mjg59> ?
[01:00] <johnnybuoy> hmm
[01:00] <johnnybuoy> makers of UNIX admitted this, I fell on it when exploring a novel OS from them (the authors of UNIX): plan9
[01:01] <johnnybuoy> UNIX was not designed with networks in mind, networks came later
[01:03] <mjg59> I think it's hard to say it's a hack, given how well it works
[01:04] <johnnybuoy> good hack
[01:04] <johnnybuoy> but hack
[01:04] <johnnybuoy> it *does* work well
[01:05] <johnnybuoy> but it wrks beter in plan9 :)
[01:05] <mjg59> In what ways?
[01:11] <johnnybuoy> well, for egzample it only has one protocol for everything, but I'd think #plan9 would be a better place for this discussion
[12:29] <che> the topic isnt accurate anymore... 0.2.7 is up
[02:14] <johnnybuoy> hello! how do I know if a service is started or not? with upstart I don't get the scrolling stuff when starting the pc.
[02:14] <_ion> Upstart jobs: status jobname
[02:15] <_ion> init.d scripts: /var/log/boot
[02:15] <johnnybuoy> ok, thanks! Oh and great job all! my pc starts a *lot* faster now with upstart
[02:29] <mbiebl> johnnybuoy: probably a placebo effect. atm upstart should be appox. the same speed as sysvinit.
[02:30] <johnnybuoy> :D
[02:30] <johnnybuoy> okok
[02:30] <mbiebl> None of the init scripts was converted to upstart jobs yet, the boot procedure is basically the same (maybe the missing output makes it abit faster)
[02:30] <johnnybuoy> tha problem is I do status fbsplash, and it doesn't know
[02:31] <mbiebl> If you want comparable bootup times, install bootchart+bootchart-view
[02:32] <johnnybuoy> what is that?
[02:33] <mbiebl> bootchart - Boot process performance analyser
[02:33] <johnnybuoy> ah ok.
[02:33] <johnnybuoy> but now I don't have init...
[02:33] <johnnybuoy> I can't compare :)
[02:34] <johnnybuoy> I think it must be a little faster...
[02:34] <mbiebl> If you are happy with upstart, that's all that matters ;-)
[02:34] <johnnybuoy> or maybe that upgrade last night ..
[02:34] <johnnybuoy> :)
[02:34] <johnnybuoy> yes, very.
[02:34] <mbiebl> Md: ping
[02:34] <johnnybuoy> I'd like to know what jobs are started tho
[02:34] <johnnybuoy> status don't work
[02:35] <mbiebl> initctl list
[02:35] <johnnybuoy> ahh
[02:35] <johnnybuoy> maybe
[02:36] <johnnybuoy> I don't get it
[02:36] <johnnybuoy> this is not it
[02:37] <mbiebl> You probably want to read /var/log/boot or remove "quiet" from the boot options.
[02:37] <johnnybuoy> ah ok!
[02:38] <johnnybuoy> that might be it
[02:38] <Md> mbiebl: pong
[02:38] <johnnybuoy> /var/log/boot: (Nothing has been logged yet.)
[02:38] <johnnybuoy> :(
[02:39] <mbiebl> Got a problem with one of your udev rules in /etc/udev/udev.rules
[02:39] <mbiebl> Specifically the dm rule that prevents /dev/dm-X from being created.
[02:39] <mbiebl> This breaks gnome-mount when used with luks encrypted partitions.
[02:40] <mbiebl> johnnybuoy: Install upstart-logd
[02:40] <Md> mbiebl: discuss this with the maintainers involved in dm. feel free to Cc me
[02:40] <johnnybuoy> it's doing it right now, i think
[02:40] <johnnybuoy> ok, thanks
[02:41] <mbiebl> I talked to the hal dev (davidz and kay) and the said there is no good reason not to have /dev/dm-x
[02:42] <mbiebl> I asked you, because /etc/udev/udev.rules is part of the udev package.
[02:42] <Md> mbiebl: yes, but I do not know how dm works. I am sure that I added that rules for a reason (and every other distribution did too), so I will not remove it unless somebody can explain with authority why it's not needed anymore
[02:43] <mbiebl> Redhat does not.
[02:44] <Md> ok. still, I will not change the package in a way I do not understand so please look for a rationale
[02:45] <mbiebl> The rational is, that cryptsetup itself does not need /dev/dm-*
[02:45] <mbiebl> So it was removed with this udev rules.
[02:45] <mbiebl> But 3rd party apps, like gnome-mount, rely on /dev/dm-*.
[02:46] <Md> I think there was much more than cryptsetup
[02:46] <Md> are you really positively sure that having udev create the devices will not break other dm components?
[02:47] <mbiebl> According to kay and davidz it should not hurt (otherwise redhat would be busted anyway)
[02:47] <mbiebl> I can ask the dm maintainer first if you prefer that.
[02:47] <Md> ok, I will change this in the next upload today or tomorrow
[02:47] <Md> yes, please ask him as well. just to be sure
[02:47] <mbiebl> Ok, will do.
[02:48] <Md> I added that rule may 30. I think there was a reason, but I really cannot remember it
[08:23] <_ion> keybuk: grep respawn /etc/event.d/logd
[08:25] <Keybuk> the // thing?
[08:26] <_ion> Yep. :-) Not that it really matters.
[08:28] <Keybuk> yeah, common side-effect of --exec-prefix=/
[10:02] <maro_> hi :)
[10:03] <maro_> do you know if upstart is supposed to completely replace sysvinit, or is it a long-term solution to depend on sysvinit-utils?
[10:03] <Keybuk> maro: the things in sysvutils/sysvinit-utils are things that aren't really part of init
[10:03] <Keybuk> so there's no particular reason for upstart to provide its own implementation of them
[10:04] <maro_> hm, true :)
[10:06] <maro_> are there examples of no-rc-compat setups yet?
[10:08] <Keybuk> not yet
[10:09] <Keybuk> we're doing the "release early and release often" thing, we're still at "early" :p
[10:09] <Keybuk> the idea of doing the rc-compat stuff is that it proves the daemon works, while still letting us revert to sysvinit at a moment's notice if it doesn't
[10:09] <maro_> ok, perhaps I can be the first then ;)
[10:09] <Keybuk> go for it :)
[10:10] <maro_> already did a full minit migration once, still have a graph somewhere
[10:12] <maro_> minit is one-way depedency based though, so this will probably be a bit harder... anyway: http://borkware.net/~mark/minit.png :)
[10:16] <Keybuk> heh, cute
[10:19] <maro_> doesn't look that complex on a graph, but imagine every service being a directory containing a symlink to the executable, a file for parameters, optional (empty) "respawn" and "sync" files...
[10:20] <maro_> running 'tree' in there gives me 63 directories and 211 files ;)
[10:20] <Keybuk> yeah, djb-style config sucks :p
[10:21] <maro_> djb-style does in general ;)
[10:21] <Keybuk> *shrug* I still use qmail
[10:24] <maro_> I wonder how hard it will be to make scripts for upstart ala the one I did to draw the graph
[10:25] <maro_> (100 lines of sh)
[10:25] <Keybuk> quite easy I should think
[10:25] <maro_> we'll see :)
[10:26] <maro_> anyway, need to get some sleep - sleep tight when the moon hits your timezone :)
[10:29] <maro_> ah, just saw your reply on the list - sounds good :) - off now
[10:31] <Keybuk> I tend to sleep when the sun is up :p


 Hi, has Tomboy Notes been removed from 20.04 repos?
 And is there an alternative that can work with my existing tomboy notes data?
[06:57] <lordievader> Good morning
[08:48] <Maik> @abhishekbatra looks like it. Kubuntu has a Notes widget iirc, maybe that works for you?
[08:48] <Maik> it's called KNotes
 @Maik, Not sure if it is compatible with tomboy notes data
[08:52] <Maik> @abhishekbatra seems there's a Tomboy-NG since development on Tomboy halted: https://github.com/tomboy-notes/tomboy-ng
[08:53] <Maik> you could search and see if tomboy data is compatible with Knotes :)
 @Maik, Couldn't find any references to it, I guess it isn't :-)
 Gnotes seems like a good alternative for now
 Hello, everyone  … I've set up a  l2tp vpn connection but  when I try to connect a notification says Missing VPN plugin  … ?
[10:31] <PanikAndi> Hey Guys! After installation a new kubuntu my wired connection does not work
[10:31] <PanikAndi> can anyboby help me?
[10:48] <PanikAndi> can anybody here please help me for a workaround with my wired-connection that does not work after update my kubuntu yesterday. today my network does not work anymore... the wired connection does not get an ip-adress from my dhcp-avm-standard-router.
[11:37] <BluesKaj> Hi all
[13:11] <eeos> I still have the problem with xorg that does not recognize the correct modes for an external monitor (Thinvision P32 u10) connected by HDMI. The computer is kubuntu 20.04.1.
[13:12] <eeos> Graphic card is Intel HDA 620.
[13:17] <BluesKaj> eeos, I have to ask the obvious first, have you checked system-settings>hardware>driver manager ?
[13:21] <eeos> BluesKaj: :-D yes I have .... I have been breaking my head on this for a few days, and googling it to he point wher eI have worn the keyboard!
[13:37] <BluesKaj> eeos, run this to make sure the correct video gpu is listed, sudo lshw -C video
[13:39] <BluesKaj> probly something like UHD Graphics 6XX
[13:44] <BluesKaj> also try, lspci | grep VGA
[13:48] <eeos> BluesKaj: yes I have done that is why I said Intel HD 620
[13:48] <eeos> BluesKaj: usual driver i915
[13:54] <eeos> back BluesKaj
[13:55] <lordievader> eeos: Did you check the edid info the monitor sends out?
[13:56] <BluesKaj> lordievader, he left again
[13:58] <eeos> driver manage says that there are no drivers available for my laptop, and that there are none in use, so no hope in that BluesKaj
[14:07] <BluesKaj> eeos, run this, sudo get-edid | parse-edid, it should show you monitor edid info, as lordievader suggested. After that we can start searching for a solution.
[14:08] <eeos> BluesKaj: sorry, I was offline did not see lordievader suggestion.
[14:09] <BluesKaj> np
[14:14] <eeos> it says it is missing some modes .... the most important ones
[14:16] <eeos> if you would like to look at it as well https://paste.ubuntu.com/p/wBvpkpGZzS/ BluesKaj lordievader
[14:17] <lordievader> Which mode are you looking for?
[14:18] <eeos> 2560 x 1440 x 60hz .... but the issue is more general. Why does xorg not recognise the correct modes by HMDI but it does so by Thunderbolt?
[14:19] <eeos> lordievader: I thoroughly hate aving unexplained  behaviours on the systems I manage (unexplained behaviour = security breach possible)
[14:19] <lordievader> Because the edid does not report them as being supported.
[14:20] <lordievader> This is not xorg at fault, or a driver.
[14:21] <lordievader> If this works for you, I'd turn that into a script: https://www.linuxjournal.com/content/guerrilla-tactics-force-screen-mode-ubuntu
[14:22] <lordievader> But is it connected to a receiver, rather than a TV/monitor directly?
[14:22] <eeos> lordievader: I did not say it was the driver or xorg fault, I am only interested in pinning down the problem .... understanding why the same system recognises the correct modes when onnected by thunderbolt, but not by HDMI.
[14:23] <eeos> lordievader: yes, at the moment, but you ave the same when connected directly
[14:24] <eeos> lordievader: I looked at the linux journal article, it suggests to use xrandr, but I can already do that .... What I miss is understanding wat is happening (in other words, where is the bug)
[14:25] <lordievader> You're bypassing the incorrect edid info.
[14:25] <eeos> lordievader: I do not understand ....
[14:25] <lordievader> The "bug" is your TV not correctly reporting the supported modes.
[14:26] <lordievader> So you ignore it and tell xorg to send a particular resolution anyways.
[14:26] <eeos> lordievader: if that were true, then Ms Windows would have the same problem, but that is not the case.
[14:27] <eeos> lordievader: if the problem was the EDID info ....
[14:29] <lordievader> Perhaps they have a better EDID parser?
[14:31] <eeos> lordievader: I guess you are correct, the problem is in the parser .... it is very strange that it parses orrectly when the monitor is connected trough Thunderbolt though .... the parser should be the same!
[14:32] <lordievader> I don't know if Thunderbolt uses edid, might use something else to communicate the supported modes.
[14:34] <eeos> lordievader: I thought so, but I may be wrong
[16:36] <wojtek_> ;)
 Hello, everyone  … I've set up a  l2tp vpn connection but  when I try to connect a notification says Missing VPN plugin  … ?
 Hello everybody. Epson ecotank is a go or no go? Thanks a lot
[18:26] <user217_> hello. is anyway to use "+" spoler in cate for some code blocks ?
[18:26] <user217_> *cate=kate
 @Max, This review says it's worth it. … https://www.gadgetreview.com/epson-ecotank-review
 Thanks Matt. Seems great. No one using epson ecotank on *ubuntu?
[18:54] <invitado> ola
[19:02] <mustafa_> türkce bilen varmı
 20:59 < lavendereyes> minor oops, Kubuntu 20.10 is listed as LTS on kubuntu.org … 20:59 < lavendereyes> https://kubuntu.org/alternative-downloads … 20:59 < lavendereyes> very minor oops ;)
[19:03] <mustafa_> do you speak türkish
[19:03] <krytarik> !tr
[20:27] <viewer|69> Does someone have the same problem as me that the analog audio channels are missing but the cards are there? This error occurs on my desktop and laptop (ALC1150 analog and renoir audio) after i updated both from kubuntu 20.04 to 20.10, both got the same error "Failed to load module" module-alsa-card "". A workarout is to reinstall pulse audio until
[20:27] <viewer|69> the next restart.
[20:54] <valorie> viewer|69: I've also been experiencing sound probs in 20.10
[20:54] <valorie> hoping the updates installing right now will improve that
[21:05] <Dragnslcr> Kubuntu 20.20?
[21:07] <valorie> good lord
[21:18] <Dragnslcr> I thought maybe someone decided to make a clever name for this release
[22:10] <Mamarok> Dragnslcr: and why should we do "clever" naming for the sake of confusion?


[10:12] <ion_> Pretty. And it only takes a kilobyte. http://pouet.net/prod.php?which=32194
[10:15] <Keybuk> what is it?
[10:16] <ion_> An intro. There’s a link to a video capture on the page.
[10:19] <ion_> http://heh.fi/heroes/heroes-scrape/pipeline.png
[10:20] <Keybuk> heh
[12:03]  * Keybuk finally discovers the fuck-up
[12:03] <Keybuk> parse_job () will free the old job with the same name
[12:03] <Keybuk> yet so will conf_item_destroy ()
[12:03] <Keybuk> the difference being that parse_job () frees the job without freeing the ConfItem for it
[12:03] <Keybuk> which means that job_change_state () must do the same!
[12:04]  * Jc2k is somewhat baffled but nods and smiles
[12:04] <Keybuk> this bug must have always been present, the newer code happens to tickle it more
[12:04]  * Keybuk tries to think how you'd replicate it
[12:07] <Keybuk> job of the same name in two different directories
[12:07] <Keybuk> then reload
[12:07] <Keybuk> that'd cause older code to core dump
[13:38]  * Keybuk frowns
[13:39]  * Jc2k bounces
[14:12]  * Keybuk almost hacks it
[14:26] <Keybuk> hurrah
[14:27] <Jc2k> :O
[14:27] <Jc2k> victoreh?
[14:30] <Keybuk> not quiet
[14:31] <Jc2k> :(
[14:31] <Keybuk> I'm tempted to ignore the problem and move on
[14:31] <Keybuk> since it's in code I intend to completely rewrite
[14:31] <Jc2k> sounds like a plan :O
[15:12] <Keybuk> odd, I made the bug go away
[15:12] <Keybuk> la la la
[15:38] <Keybuk>  woo, only test_job left to fix
[16:41] <Keybuk> all 5,300 lines of it :-/
[16:42] <Jc2k> woah
[16:42] <Jc2k> large test then?
[16:42] <Keybuk> yeah
[18:52] <kelsin> Hey, is there a way to specify a start script/ stop script and then set the PID directly for jobs? Basically have a service that comes with a normal "script start/stop/status" as the way to start it, didn't want to have to work a lot with it if possible
[18:53] <kelsin> actually might have answered my own question by finding the wait command :) I'll ask again if this doesn't work


[16:52] <Guest84727> Hi, I'm running with ubuntu mate raspberry version . I'm wondering if it's possible to make update of it , because when I want to install the upgrade a pop up opens with "not enough memory" despite of 12Go available on the SD card. does someone has ever met this problem ?
[17:08] <Guest30016> Hi again , you can forget my question . I made a command line sudo apt-get upgrade and it works .
[17:10] <nkl> hello there! i have ubuntu mate 16.04 and when i look at: /usr/lib i dont have 'lib64 only 'lib32
[17:12] <nkl> pls help someone? i also have issue with nvidia ERROR: Cannot create report: [Errno 17] File exists: '/var/crash/nvidia-304.0.crash


[12:11] <mup> PR snapd#12745 opened: seed/seedwriter: fix issue that base snaps set in option will be ignored <Created by AristoChen> <https://github.com/snapcore/snapd/pull/12745>
[13:46] <mup> PR snapcraft#4102 opened: spread: bump storage for Google 22.04 spread hosts <Created by lengau> <https://github.com/snapcore/snapcraft/pull/4102>


[00:15] <binarymutant> is ext4 still "unstable"?
[00:15] <binarymutant> or good to use
[00:16] <Unit193> That's the default, last I knew.
[00:16] <binarymutant> k
[00:26] <binarymutant> My laptop needs a hvac
[00:27] <wrst> binarymutant: maybe a big window fan?
[00:27] <binarymutant> Lol
[00:28] <binarymutant> A big window fan sitting right under the processor
[00:29] <wrst> yep with a block of ice?
[00:29] <binarymutant> Or gpu, whichever is on fire
[00:29] <binarymutant> Ya that liquid nitrogen stuff
[00:30] <wrst> there you go
[00:30] <wrst> fires are never good
[00:31] <binarymutant> Maybe I just need a tougher laptop
[00:50] <chris4585> my laptop can get up to 75c if it doesn't breath :|
[00:50] <chris4585> most of the time though I have it propped up
[00:52] <binarymutant> How do you prop it chris4585
[00:54] <chris4585> I did use a remote until my brother got me this thing designed for laptops
[00:54] <binarymutant> Oh
[00:54] <chris4585> now if I'm charging and watching youtube it gets like 50c
[00:56] <binarymutant> Its weird that the fan is on the bottom
[01:09] <cyberanger> netritious: I actually don't like vim, use it often, npt by choice though
[01:10] <binarymutant> Wut
[01:10] <binarymutant> !?
[01:13] <cyberanger> binarymutant: some servers and routers don't have anything else to use
[01:13] <cyberanger> hrm
[01:13] <binarymutant> vim is the best
[01:14] <cyberanger> binarymutant: some servers and routers don't have anything else to use, so vim it is
[01:14] <cyberanger> but I just don't like it
[01:14] <binarymutant> that's because some servers and routers know what the best is :P
[01:15] <cyberanger> think smartphones too for that matter
[01:15] <binarymutant> yes I have vim on my android
[01:19] <binarymutant> I've vim'd my firefox too
[01:20] <binarymutant> vim everything lol
[01:30] <binarymutant> vim crazy
[04:07] <binarymutant> 2 monitors, 2 Xservers, 1 machine, no vt switching: how?
[04:08] <RagnarokAngel> you're above my paygrade on video setup there binarymutant
[04:08] <binarymutant> paygrade?
[04:09] <RagnarokAngel> bad joke
[04:09] <RagnarokAngel> definitely above my level of expertise
[04:09] <binarymutant> I can get two xservers at the same time to work, but I have do vt switching: like ctrl+alt+f8
[04:09] <RagnarokAngel> yeah
[04:10] <RagnarokAngel> so you can only view one at a time?
[04:10] <binarymutant> yeah
[04:11] <RagnarokAngel> i mean you could build a chroot to run an X server but I think that creates more problems than it solves.
[04:11] <Unit193> xserver-xephyr?
[04:14] <RagnarokAngel> binarymutant: are you trying to have them both display the same thing?
[04:14] <binarymutant> RagnarokAngel, no
[04:15] <RagnarokAngel> then what's the point of two x sessions?
[04:15] <binarymutant> Unit193, what provides that?
[04:15] <binarymutant> idk
[04:15] <Unit193> That's the packagename.
[04:18] <RagnarokAngel> I'm interested if you get it working
[04:19] <binarymutant> brb
[04:38] <binarymutant> screw it
[05:08] <binarymutant> grah separate xscreens driving me nuts
[05:27] <binarymutant> figured it out
[05:30] <Unit193> Need to set a server password. :P
[05:34] <binarymutant> you?
[05:34] <binarymutant> me? no
[05:35] <binarymutant> using twinview
[05:37] <Unit193> IRC server pass that is.
[05:38] <binarymutant> just don't accept from anyone except <IP_ADDRESS>
[17:18] <RagnarokAngel1> are you guys all set up with ssd OS partitions?
[17:19] <RagnarokAngel1> well ssd os drives.
[17:19] <wrst> RagnarokAngel1: no, but I do have one at work running windows
[17:26] <RagnarokAngel1> I'm thinking of getting one instead of upgrading my laptop wrst
[17:28] <wrst> I LOVE the ssd at work
[17:29] <wrst> when i can afford it i plan on putting one in my laptop
[17:34] <RagnarokAngel1> newegg had some 120s on their shell shocker for $80
[17:35] <wrst> yep they are getting close i would like to be in the 320GB range
[17:35] <RagnarokAngel1> is there any reason ctrl+alt+f1 wouldn't drop me to a terminal?
[17:36] <RagnarokAngel1> and just return a black screen?
[17:36] <wrst> RagnarokAngel1: not that I know of generall y that will always send you to tty1 unless something has been tweaked
[17:37] <RagnarokAngel1> this thing gets through login and then seems to fail inexplicably
[17:37] <RagnarokAngel1> Maybe I should try logging into a non-graphical?
[17:38] <wrst> RagnarokAngel1: be a good plan i think
[17:39] <RagnarokAngel1> hmm
[17:39] <RagnarokAngel1> it's a gui login and I have no mouse from the touchpad? This is useful.
[17:40] <wrst> sounds like xorg is weird
[17:40] <Svpernova09> Let me introduce you to the tab key :_)
[17:40] <RagnarokAngel1> it defaults to the login and tab is working like enter Svpernova09
[17:41] <wrst> Svpernova09: :)
[17:41] <Svpernova09> Ouch, sounds like keyboard layout isn't correct.
[17:42] <RagnarokAngel1> I have a feeling linux mint just did something weird.
[17:42] <wrst> RagnarokAngel1: well.... thats what you get for running linux mint... sorry :)
[17:43] <Svpernova09> Mint takes quite a few liberties
[17:43] <RagnarokAngel> yeah, I'm not installing it for myself.
[17:43] <wrst> i know RagnarokAngel :)
[17:43] <Svpernova09> Is it odd / nonstandard hardware? that is Mint's shining spots.
[17:44] <RagnarokAngel> It wasn't working corrently with the 12.04 installer
[17:44] <RagnarokAngel> it failed to install grub
[17:45] <RagnarokAngel> and when I did install grub on it it didn't autodetect anything.
[17:45] <wrst> oh that one RagnarokAngel :|
[17:45] <RagnarokAngel> this thing loads all the way to the desktop and then I can't seem to interact with it at all.
[17:47] <RagnarokAngel> Welcome to linux mint. Everything you press on the keyboard or attempt to do with a mouse won't do anything.
[17:47] <RagnarokAngel> wait
[17:47] <RagnarokAngel> I've got a terminal!
[18:23] <wrst> RagnarokAngel: going better?
[18:23] <RagnarokAngel> not really
[18:23] <RagnarokAngel> I'm getting a fail install of dconf-tools and that seems to be my solution.
[18:24] <RagnarokAngel> gdm is failing and the main issue.
[18:25] <wrst> RagnarokAngel: is this a fresh install?
[18:27] <RagnarokAngel> yeah
[18:27] <wrst> wow
[18:27] <wrst> that's a pain!
[18:30] <RagnarokAngel> it seems mdm is screwing with it a bit?
[18:34] <wrst> RagnarokAngel: that's an odd one, what type of video card ?
[18:36] <RagnarokAngel> I think it's an ATI Radeon HD 4250
[18:36] <RagnarokAngel> which is the integrated whatever on this laptop
[18:40] <RagnarokAngel> and pretty crap according to phoronix
[18:44] <RagnarokAngel> gah
[18:44] <RagnarokAngel> cinnamon has it's own config program?
[18:56] <cyberanger> hey RagnarokAngel, long time no see
[19:07] <wrst> RagnarokAngel: oh my cinnamon
[19:07] <wrst> can you talk them into anything else?
[19:08] <chris4585> I think I have an radeon 4250 or close to it on my board, works on arch with the radeon driver
[19:10] <chris4585> yeah I have that
[19:10] <cyberanger> cinnamon seems decent, but intel chip and I didn't like it enough to switch from openbox
[19:10]  * chris4585 is currently using openbox
[19:29] <wrst> cyberanger: i just don't get what they are doing with cinnamon
[19:30] <wrst> they could have easily done everything they do with extensions to gnome shell cinnamon is totally useless
[19:30] <cyberanger> wrst: gnome 2 replacement, without the gnome shell clutter
[19:30] <Unit193> MATE is Gnome2.
[19:30] <wrst> cyberanger: its a fork of gnome 3 doesn't it use clutter?
[19:30] <cyberanger> that's the idea, seems like the original reason, they've gone beyond that now
[19:31] <wrst> better said its a fork of gnome-shell
[19:31] <wrst> its stupid
[19:31] <wrst> i can go to http://extensions.gnome.org and in a few minutes have nearly the same functionality and it doesn't constantly crash as I have heard cinnamon does
[19:32] <wrst> the linux mint guys could have focused on extensions and done a lot better job than trying to fork something
[19:32]  * wrst vents
[19:32] <wrst> sorry I just don't have much love at all for linux mint
[19:33] <Unit193> ^
[19:34] <Unit193> Though, LMDE+Xfce may get a short VM test, but I don't like that. :(
[19:35] <wrst> again Unit193, why not just use debian testing with xfce? the DE of mint doesn't do much as far as drivers etc
[19:36] <Unit193> wrst: I have set it up like that, it's pretty nice except no Xfce 4.10. ;/
[19:36] <wrst> weird why not Unit193?
[19:36] <wrst> is that not in the debian testing repos yet?
[19:36] <Unit193> Unstable doesn't either. :/
[19:37] <wrst> Unit193: it was in arch like a day after it was released
[19:53] <RagnarokAngel> wrst: the arch way.
[19:57] <wrst> yep the non-stale package way :)
[19:59]  * wrst notes that restarting windows services is a joke
[20:00] <wrst> wb netritious
[20:00] <RagnarokAngel> I think I'm just going to find a different distro.
[20:01] <wrst> RagnarokAngel: curious why not ubuntu?
[20:01] <RagnarokAngel> wrst: that installer fail happened twice.
[20:02] <wrst> ohh RagnarokAngel does have to be a more easy to use distro? thinking debian might be something worth trying
[20:02] <RagnarokAngel> wrst: installing grub manually is not on my to-do list
[20:02] <wrst> thats why i was thinking debian?
[20:10] <RagnarokAngel> I've never installed Debian, wrst.
[20:10] <wrst> RagnarokAngel: have you used the ubuntu  alternate installer?
[20:11] <RagnarokAngel> wrst: yeah I think so.
[20:11] <wrst> if you have, you have more or less used the debian installer i think the ubuntu alternate installer is pretty much a purple version :)
[20:11] <RagnarokAngel> ah, not too big of a deal.
[20:11] <RagnarokAngel> I could grab that image while I'm at it
[20:12] <RagnarokAngel> huh they even have live images now?
[20:12] <wrst> yeah don't know if they are official or not?
[20:13] <RagnarokAngel> I'm on debian.org and getting the mirrors
[20:13] <RagnarokAngel> I don't really want to deal with jigdo
[20:13] <chris4585> I think they are, but can't install from the live side or something like that
[20:14] <chris4585> maybe I'm thinking of a different distro
[20:14] <wrst> chris4585: i think there is something odd vs. most live cds
[20:15] <wrst> RagnarokAngel: i would suggest a net install image, less to download on the front end and you get the latest updates
[20:15] <wrst> if you are going debian stable it will be gnome2 which isn't bad either
[20:19] <chris4585> RagnarokAngel, do you know what part of the installer failed? have you tried an older version of ubuntu?
[20:21] <RagnarokAngel> chris4585: it was an error in the way it tried to install grub2. I'm unsure if an older version would fix
[20:22] <chris4585> very odd, but you never know
[20:23] <RagnarokAngel> I just feel bad handing someone unity...
[20:25] <wrst> RagnarokAngel: i really don't unity in 12.04 while not for me at all is a very good gui or at least i think so
[20:26] <RagnarokAngel> wrst: Yeah, you're probably right.
[20:26] <chris4585> oh, I would too in that case
[20:27] <chris4585> well there is fedora
[20:27] <wrst> oh me
[20:27] <wrst> :)
[20:27] <wrst> or something like opensuse with kde is nice
[20:28] <chris4585> mint kde 13 I heard was good.. if you could get it to install
[20:29] <RagnarokAngel> I have mint with cinnamon 13. This thing is a pain and I want to just scrap it.
[20:29] <RagnarokAngel> Also I'll probably be running point on any questions and I don't like KDE environments very much
[20:29] <RagnarokAngel> personal opinion
[20:30] <wrst> RagnarokAngel: can't argue there nothing wrong with kde either just not my thing
[20:30] <chris4585> I thought the laptop was for someone else or am I not understanding?
[20:30] <RagnarokAngel> it is
[20:30] <wrst> RagnarokAngel: what type of laptop is it?
[20:31] <RagnarokAngel> but it's someone who doesn't know a lot and will definitely ask me questions regarding it's misuse.
[20:31] <RagnarokAngel> Dell Inspiron M5030 wrst
[20:32] <RagnarokAngel> brb
[20:33] <chris4585> seems like linux isn't the answer here, just my opinion
[20:33] <chris4585> darn
[20:33] <wrst> chris4585: its one of those things that its not worth the effort if they are expecting windows some times
[20:34] <chris4585> yeah, I'd just put a boot leg xp or win7 on there and be done with it
[20:34] <chris4585> I mean, did I say that?
[20:35] <wrst> well it probably has a COA anyway but yeah i agree chris4585
[21:32] <wrst> wb... i think binarymutant :)
[21:32] <wrst> oh wait yep
[21:32] <binarymutant> ty ty
[21:32] <wrst> how are you doing binarymutant?
[21:33] <binarymutant> good, trying to figure out why some of these xbmc plugins segfault
[21:35] <binarymutant> and having wifi issues
[22:35] <netritious> thx wrst for the wb hours ago :P
[22:36] <netritious> how's everyone?
[22:58] <wrst> good netritious, how are you?
[22:58] <wrst> its irc, its timeless around here :)
[22:59] <netritious> true wrst. :)
[23:00] <wrst> netritious: had to add some much needed commas
[23:01] <netritious> lol
[23:04] <wrst> ok netritious this is totally off topic but everytime i check the news and see the entertainment section, which i have no clue why its news anyway, but its some star that we are supposed to care about let nude pics get away... you know if you don't went them to get out why do you take them?
[23:04]  * wrst feels sure that neither he nor netritious will have this problem
[23:06] <wrst> all that once again makes this seem more appealing than ever: http://mars-one.com/en/
[23:07] <netritious> it's just for publicity, you know that wrst
[23:07] <wrst> well of course thats why i let those pics out... no wait!!!
[23:08] <wrst> netritious: i just don't understand the general public's obsession with "stars"
[23:08] <wrst> i mean come on we are smarter and twice as sexy
[23:08] <netritious> lol
[23:08] <binarymutant> Theyre the american royalty
[23:08] <wrst> sorry netritious, long hot day i think i may have fried some brain cells
[23:09] <wrst> ohhh binarymutant don't get me started on the snooty royalty in the mother country :)
[23:09] <binarymutant> Lol
[23:10] <wrst> anyway binarymutant enough of my brain cell-less rattling how are you doing?
[23:10] <Unit193> "I don't want to live on this planet anymore"
[23:11] <wrst> Unit193: here you go: http://mars-one.com/en/
[23:11] <binarymutant> Lol
[23:12] <binarymutant> Id think the.moon would be first
[23:12] <Unit193> wrst: I saw that movie, didn't end well.
[23:12] <Unit193> Also, who knows where that quote is from?
[23:12] <binarymutant> Not me
[23:12] <wrst> i have no clue Unit193, i was just wanting to truck you off to mars
[23:13] <Unit193> Yeah, still not far enough for most people...
[23:14] <wrst> well Unit193 if it helps i want to go too
[23:14] <Unit193> Still too many people for me.
[23:15] <wrst> oh wow
[23:15] <wrst> :)
[23:15] <wrst> that hurt!
[23:17] <Unit193> Not you it didn't. :D
[23:18] <wrst> good point :) catch everyone later
[23:25] <netritious> cya wrst


[00:00] <rick_h_> wgrant: heh, ubikey
[00:00] <rick_h_> once in a while bump the dippy thing
[00:01] <StevenK> wgrant: Twitch.
[00:01] <StevenK> % grep -c 'pdb.set_trace' lib/lp/bugs/mail/bugnotificationrecipients.py
[00:01] <StevenK> 1
[00:02] <wgrant> StevenK: Bug #1024148
[00:02] <_mup_> Bug #1024148: Branch.transitionToInformationType breaks when making a subscriberless branch private <disclosure> <regression> <sharing> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1024148 >
[00:03] <wgrant> StevenK: Oh wow, that's nice.
[00:27] <rick_h_> StevenK: got a sec? I think I blew up buildbot, but my ec2 test run passed so wonder if you can help me figure out what the difference is and what I can do to fix
[00:29] <rick_h_> my understanding is that this runs a make check so if I make clean_buildout and make check locally and it works I should have been ok?
[00:39] <StevenK> rick_h_: make check will take ~ 5 hours
[00:39] <StevenK> rick_h_: Right, the buildbot slaves don't have convoy
[00:39] <rick_h_> StevenK: right but what I mean is that the buildbot fail is about convoy, but it's in the download cache
[00:40] <rick_h_> ah bah that's right...I forgot it's packaged
[00:40] <StevenK> Assuming convoy is available everywhere is a recipe for disaster
[00:40] <rick_h_> crap...ok...looking
[00:41] <wgrant> +jsbuild: $(PY) combobuild jsbuild_widget_css $(JS_OUT)
[00:41] <wgrant> jsbuild very deliberately didn't depend on combobuild before :)
[00:41] <rick_h_> right, but combo-rootdir drops the YUI code into the build dir now. Since it worked locally with make check I thought I was clear
[00:41] <rick_h_> I'll move the meta.js to make run and should fix it
[00:42] <wgrant> rick_h_: Why did you need to move combo-rootdir?
[00:42] <StevenK> rick_h_: So local has convoy, as does ec2. buildbot does not.
[00:43] <rick_h_> StevenK: right, gotcha.
[00:43] <rick_h_> wgrant: so with the policy of 'all things come from system packages or python packages' YUI is served from a python package now. I set the combo-rootdir to extract that out when it runs
[00:44] <rick_h_> and it needs to run before the launchpad.js generation now
[00:44] <wgrant> That policy is not sensible for non-Python things like YUI
[00:44] <rick_h_> where before yui was put into place by buildout
[00:44] <wgrant> Right
[00:44] <wgrant> Which is probably correct.
[00:44] <wgrant> lifeless: opinion pls
[00:44] <lifeless> hi
[00:44] <lifeless> 'sup ?
[00:45] <wgrant> Repackaging yui tarballs as a launchpad-yui egg seems pretty insane.
[00:45] <rick_h_> my understanding in talking with sinzui deryck and company that this was the preferred path.
[00:45] <wgrant> They might think they prefer it, but they don't.
[00:45] <rick_h_> that anything like the sourcedeps is to be deprecated and that all things much come from system or python packages
[00:46] <rick_h_> and since I need to be able to run multiple yui versions at once for testing, I setup a python package that dumps any contained YUI versions to the build dir
[00:46] <lifeless> sorry, whats the full story?
[00:46] <wgrant> Dumping multiple versions of yui into a custom tarball just to make it an egg is entirely crazy.
[00:46] <StevenK> rick_h_: source*code* is deprecated, sourcedeps is not
[00:46] <wgrant> lifeless: Yesterday we had a custom buildout rule which took a normal upstream YUI tarball and turned it into something Launchpadish
[00:47] <wgrant> lifeless: Today we instead have a Launchpad-specific egg with two versions of YUI unpacked within it
[00:47] <StevenK> Change utilities/sourcecode.conf == bad, change versions.cfg ==okay
[00:47] <wgrant> I don't see this as an improvement.
[00:47] <StevenK> Bah, I can't call BugNotificationRecipients.update() with a resultset. :-(
[00:47] <rick_h_> wgrant: the improvement is that this package has make commands to help auto extract only the build bits from the YUI download, etc
[00:48] <rick_h_> and then it dumps all versions it contains into the build dir without needing to update any list/config for them
[00:48] <wgrant> Right, a helper like that is sensible
[00:48] <rick_h_> and the only thing that matters is that build/js/yui is symlinked to the version in versions.cfg
[00:48] <wgrant> Embedding the YUI codebase is is not
[00:49] <rick_h_> well based on conversations in pre-impl it was sort of based on the lazr.js model and some other 3rd party modules I found
[00:49] <lifeless> rick_h_: so, we want to reduce the number of dependency systems in use, that is correct.
[00:49] <rick_h_> http://pypi.python.org/pypi/launchpad_yui/0.1
[00:50] <wgrant> This doesn't reduce the number of dependency systems
[00:50] <wgrant> It adds a new one: embedding large third-party codebases in a Launchpad-specific public egg
[00:50] <lifeless> rick_h_: however, with current deployment logic and packaging tech, that means we'll end up with a) debian package for firefox, rabbit, pgsql etc; b) buildout versions.cfg entries for python packages and anything else that buildout can deliver.
[00:50] <wgrant> It happens to sit behind something like looks like one of our other dependency systems
[00:50] <wgrant> But it isn't.
[00:51] <rick_h_> right, well because JS doens't have a good dependency system in LP, so I shoe-horned my way into an existing one
[00:51] <StevenK> Which is terrible
[00:51] <lifeless> rick_h_: We've had some friction in the past using 'make YUI into an egg' approaches; can I ask what problem you were trying to solve ?
[00:51] <wgrant> We already had it fairly cleanly shoehorned, didn't we?
[00:51] <wgrant> I don't understand what was wrong with the old way.
[00:51] <lifeless> StevenK: wgrant: Can you guys chillax a little so we can understand whats going on?
[00:51] <rick_h_> lifeless: so the problem was 'how to more easily maintain/manage multiple yui versions in LP'
[00:55] <lifeless> rick_h_: can you expand on that a little? what was giving you grief, what do you want to be able to do (and how does this do it)
[00:55] <lifeless> rick_h_: I realise you've probably discusse that with deryck & sinzui already, but I can't really give an opinion till I get a handle on all the friction :)
[00:56] <rick_h_> ok so it's a couple parts of me not getting it initially (I realize now) and wanting to make installing/testing newer versions of yui easier.
[00:56] <rick_h_> the idea was that we need to be able to drop several versions of YUI into the build/js dir and use the feature flag to switch which one you use
[00:57] <rick_h_> we kind of had that, there's some buildout stuff to install 3 versions that are in the download-cache of yui which I didn't quite get until today
[00:57] <lifeless> we'll need that for production too
[00:57] <lifeless> otherwise race conditions galore happen.
[00:57] <rick_h_> and in discussions the 'idea' seems to be that things must either be a python package or a system package going forward
[00:58] <rick_h_> that seems to have been taking the idea too far from what I'm hearing now though. download-cache is still ok with non-python packages
[00:58] <rick_h_> so the yui zips in there would have been ok
[00:58] <lifeless> download-cache is just a holding place; the key thing is to get away from the 4! we have today.
[00:59] <rick_h_> so with the understanding that YUI has to come in via python package or system package, I thought a python package was easier to deliver multiple versions and setup http://pypi.python.org/pypi/launchpad_yui/0.1
[00:59] <lifeless> while we use buildout, and buildout can do more than just eggs, we're fine with zips in download-cache, yes.
[00:59] <rick_h_> today I landed changes to extract YUI from that package vs the buildout download cache, I did that in the current combo-rootdir bin script, and that needed to run now before launchpad.js is built for non-combo loader users
[01:00] <rick_h_> so I moved around the make deps so that jsbuild required combo biuld, which required convoy and the buildbot slaves don't have that, so I broke buildbot
[01:00] <lifeless> That pypi project is probably a great place for scripts to do things like download the latest zip and put it in download-cache, to live.
[01:01] <lifeless> rick_h_: thanks.
[01:01] <lifeless> so heres what I think: shovelling one package into another as a transport mechanism is necessary sometimes but usually at best somewhat unpleassant
[01:01] <rick_h_> so I'm trying to see 1) what to do to unfubar buildbot and 2) if I should be rethinking the changes all together.
[01:02] <lifeless> that strategy tends to run into several classes of headache: versioning is tricky if you want it to match at all; authentication of the transported thing is often hard or at the very least nontrivial
[01:02] <lifeless> and lastly its usually surprising for everyone that encounters it.
[01:03] <lifeless> rick_h_: do you have any ideas about how we manage syncing and using the gallery widgets going forward ?
[01:03] <lifeless> (this may seem like a non sequitor, but its very related :))
[01:03] <rick_h_> so that's a seperate issue at the moment. This is only for the base YUI library. I've started conversations with others on the syncing, but there's not currently an acceptable answer yet
[01:04] <rick_h_> honestly, my pitch to deryck was to run our own gallery.yui.com but js.canonical.com that could be https and shared modules for all teams. Since modules are versioned, they could be kept and updated in a single place so all could follow dev/what's available.
[01:04] <lifeless> It seems like the same problem to me: we have code in a different *space (language/name/dependency - everything), that we want to consume easily and reliably and upgrade from time to time, and possibly fork from time to time.
[01:04] <rick_h_> however, that's a BIG undertaking
[01:05] <rick_h_> since it required infrastructure and someone to shepard/manage things
[01:05] <lifeless> it also doesn't give any assistance towards offline development, offline testing and local forking
[01:05] <rick_h_> lifeless: you're right in that it is, but as I said, there's no 'great' answer yet so I admit that this python package setup was hackish, but kind of an the immediate means to the end
[01:06] <lifeless> sure, I'm not critiquing it [yet] :P :)
[01:06] <rick_h_> lifeless: well, the way the yui gallery works is that it's a single repo, anyone can checkout and serve
[01:06] <rick_h_> much as you checkout yui itself, and put it into a combo loader server
[01:07] <lifeless> by checkout, do you mean 'grab a tar' or 'git clone' ?
[01:07] <rick_h_> but yes, it's not perfectly worked through for sure. There's a balance on duplication of effort and visiblity of a central location vs the distribution of things to offline/individual running
[01:07] <rick_h_> git clone
[01:07] <lifeless> ok
[01:07] <rick_h_> https://github.com/yui/yui3 you clone that and get it all
[01:07] <rick_h_> and updates are done by forking their repo, adding your new module, and requesting they merge it back
[01:07] <lifeless> so, with all that in mind
[01:08] <lifeless> do you think we should handle widgets the same as base YUI ?
[01:09] <rick_h_> ideally, it would be nice
[01:09] <lifeless> are there any reasons to handle them differently ?
[01:10] <rick_h_> just beacuse the yui libary is not apt to change as often, and is a single part vs many modules
[01:10] <rick_h_> there's a manner of scale when you consider managing a couple of versions of one dep, vs couple of versions of many deps
[01:10] <rick_h_> and I don't have the same issues of making existing code visible to teams, updates sync'd, etc with YUI base as I do any modules
[01:11] <lifeless> I don't follow those issues; sorry to keep doing this - but can you expand on them please?
[01:12] <rick_h_> sure, so let's agree that everyone is using YUI and knows where it is. If they need JS, they know what to get and where to go get it
[01:12] <rick_h_> and it's a pull only use
[01:12] <rick_h_> if a new version comes out, they pull it down
[01:12] <lifeless> the base YUI ?
[01:12] <rick_h_> right
[01:12] <lifeless> why is it pull only? Is it bug free?
[01:13] <rick_h_> well, sure there are bugs, and you go through their system, get them updated, pull the new release. I've not seen us keep a patch against YUI anywhere so far
[01:13] <rick_h_> not saying it's not possible, but not something experienced in work so far
[01:14] <rick_h_> so for the base YUI it's "usually" a pull only of maybe 2 or 3 versions (current running, next version to test with, keeping an eye on a future preview release)
[01:15] <rick_h_> while wigets/gallery code needs to be made visible to teams. "Is there a module for this?", they need to be able to update those, push changes without breaking backward compatiblity for other users, and there's many more as teams develop new JS modules
[01:16] <lifeless> I don't get the difference
[01:16] <lifeless> when you say visible to teams, is YUI base not visible to teams?
[01:16] <rick_h_> and then there's infrastructure, we don't test YUI downloads, but we'd have to test and document gallery items/etc
[01:16] <rick_h_> YUI base is because they all know where to look
[01:16] <rick_h_> how many canonical teams know of the various YUI modules other teams have written
[01:17] <rick_h_> ?
[01:17] <rick_h_> this is the main reason I hope to one day get together a centralized area for YUI modules done like the kitchen code on the -tech mailing list recently
[01:18] <rick_h_> landscape mentioned a nice mock tool they use in testing, but I've got no idea that exists to be able to share/reuse that
[01:18] <wgrant> wallyworld: Could you find some time to review https://code.launchpad.net/~wgrant/launchpad/edit-stacked-information-type/+merge/114767?
[01:18] <wallyworld> sure
[01:18] <lifeless> rick_h_: I don't understand why modules we'd handle ourselves but base we'd handle by collaborating closely with upstream
[01:18] <lifeless> rick_h_: I'm sure there is a key thing I'm missing :(
[01:19] <rick_h_> I'd think it was purely that we're more hands on with modules, while 99% of the time hands off on YUI base
[01:19] <rick_h_> 99% of the time YUI base is r/o while modules we dev are very write heavy with docs/tests/sharing
[01:20] <lifeless> so you're saying that we can block a project waiting for a fix to yui base, but we want to run a local fork for changes to a module (whether we created the module or not)
[01:20] <rick_h_> you'd use memcache all the time for very read heavy uses, but would you stick your writes in there? :)
[01:20] <lifeless> rick_h_: thats called 'redis' :P
[01:20] <StevenK> wgrant: Bah, I keep distracted by my QA
[01:21] <rick_h_> well, I think we'd look at a system to carry a temporarity patch or else build a module that patched it for us
[01:21] <rick_h_> gallery-patch-bug1234 and then use that until the next YUI version came out with the fix
[01:21] <rick_h_> and then all of our teams would gain access to that patch module while we worked with upstream
[01:21] <wallyworld> wgrant: can you add a screenshot to the mp?
[01:22] <lifeless> rick_h_: so while I accept that it may happen *more often*, that seems like a reason to run the same system as yui base to me: so that there is no surprise for dealing with the time when yui base is the thing that needs fixing.
[01:23] <lifeless> rick_h_: by run the same system I mean the dep/deploy/dev story around yui modules/yui base.
[01:23] <rick_h_> lifeless: right, and that's fine. However, from my conversations, the dream of a shared JS area is so far away, I'm working around that for the time being
[01:23] <rick_h_> and trying to work within the current dev environment to get LP caught up to the latest YUI, make it easier to test new versions, and keep the gallery modules we've subsumed where they are for the moment
[01:24] <lifeless> sure
[01:24] <wgrant> wallyworld: It looks like https://code.qastaging.launchpad.net/~canonical-launchpad-branches/lp-production-configs/lalala/+edit but with fewer information type choices
[01:24] <lifeless> note that nothing you've said above speaks 'shared JS area' to me.
[01:24] <rick_h_> now, when we get to a good answer for the gallery code, I'm all for revisiting the YUI base story into that lifeless
[01:24] <wgrant> wallyworld: The UI hasn't changed. Just the set of choices
[01:24] <lifeless> so theres still at least some causal link you need to help me understand :)
[01:25] <wgrant> wallyworld: In general the only private stacked-on branches will be Proprietary in Proprietary projects, so there'll only ever be one choice.
[01:25] <rick_h_> lifeless: sure, so I don't see a good way to manage and expose modules built by different teams than having a shred JS setup of some sort. Right now I'm told we're to try to push stuff up to the YUI gallery, but as we can't use that to pull/download from at the moment, it's a push only setup
[01:25] <wallyworld> wgrant: ah right thanks. i had just read the covering letter and didn't quite grok the change
[01:25] <lifeless> rick_h_: why can't we use that to pull or download from ?
[01:26] <rick_h_> lifeless: well currently LP uses I think 2 gallery components, and we don't want to pull down all of hte gallery (size/complexity), and we need to be able to get whatever code into our download-cache, so it would be a pain to keep that up to date/in sync
[01:27] <lifeless> how big is all of the gallery (size on disk, git clone time)
[01:27] <rick_h_> lifeless: we also only want the build files, not the src/docs/etc.
[01:27] <wgrant> wallyworld: It both reduces the amount of code we have for this unlikely case, and allows users to fix conflicts if they arise (eg. because the stacked-on branch changes type)
[01:27] <rick_h_> lifeless: the git clone is approx 64MB
[01:28] <rick_h_> lifeless: the build directory of only production files is 21M
[01:28] <lifeless> rick_h_: you proposed cloning it al for a shared area, but that will also require devs to have a full copy etc, so I don't understand why you'd say we *don't want to pull...*
[01:28] <wallyworld> wgrant: i think though we decided to disallow a stacked on branch changing type to private if a public branch was stacked on it?
[01:28] <rick_h_> lifeless: right, as I said, we've not come to a satisfactory answer yet on that front
[01:29] <wgrant> wallyworld: Ah, yes, so that particular case probably can't happen.
[01:29] <rick_h_> lifeless: and while a dev can take a download hit, doing it for every build/etc seems something to avoid
[01:29] <lifeless> sure, but why would we do it on every build/etc ?
[01:29] <lifeless>  we don't bzr pull on every build/etc.
[01:29] <rick_h_> lifeless: but agreed, there's work to be done on that front which is why I'm putting it off :)
[01:29] <lifeless> I mean.
[01:29] <rick_h_> lifeless: true, I guess download-cache is updated, but not redownloaded
[01:29] <lifeless> You'd have to *write code* to pull etc on every build.
[01:30] <rick_h_> lifeless: so we'd have to have something like that for the gallery/JS code
[01:30] <wallyworld> wgrant: with the hidden types code, will the order of the radio buttons be messed up ie the (un)embargoed security choices come at the end
[01:30] <lifeless> here are the computed (vs root cause) constraints I know of that are imposed on us in this area:
[01:31] <wallyworld> wgrant: which would be inconsistent with elsewhere
[01:31] <lifeless>  - be able to build and deploy LP without internet access
[01:31] <lifeless>  - be able to do buildbot tests likewise
[01:31] <lifeless>  - be able to inspect all changes happening to code that we execute in trusted zones - e.g. js that runs in our browser windows, python on the sever etc.
[01:31] <wgrant> wallyworld: getInformationTypesToShow returns a set of allowed. setUpWidgets then iterates through the vocab, picking out items that are in the allowed set. So order is retained.
[01:32] <lifeless> I think pretty much everything else is up for grabs
[01:32] <wallyworld> wgrant: cool, thanks. just wanted to double check as i couldn't recall the exact implementation detail
[01:32] <rick_h_> lifeless: ok
[01:32] <wgrant> That implementation detail only landed three hours ago, so you're forgiven :)
[01:33] <wallyworld> wgrant: and the diff didn't really show the full picture
[01:33] <wallyworld> wgrant: are we missing a test?
[01:34] <wgrant> wallyworld: I think so. I couldn't find one for the checkbox override.
[01:34] <wgrant> ec2 will tell me for sure
[01:34] <wallyworld> to check that security is allowed branches linked to security bugs
[01:34] <wgrant> Oh
[01:34] <wgrant> There's one for that
[01:34]  * wgrant hunts
[01:34] <lifeless> rick_h_: how big is a tar of all of yui3 gallery (not base) ?
[01:34] <wallyworld> regardless of the stacked on type
[01:34] <rick_h_> lifeless: I'll pull together some notes on ideas and why don't we schedule a time to sit down and look it over.
[01:34] <wgrant>     def test_private_branch_with_security_bug(self):
[01:34] <wgrant>         # Branches on projects that allow private branches can use the
[01:34] <wgrant>         # Embargoed Security information type if they have a security
[01:34] <wgrant>         # bug linked.
[01:34] <rick_h_> lifeless: just the build or the whole thing?
[01:35] <lifeless> rick_h_: something suitable for devs to have, buildbot to have, and prod to have.
[01:35] <wallyworld> wgrant: ok, thanks. r=me
[01:36] <wgrant> wallyworld: Marvellous. Thanks.
[01:36] <lifeless> rick_h_: and is there a programmatic interface to do releases of individual yui modules? (are they separately versioned etc) ?
[01:37] <rick_h_> lifeless: yes, they use an ant based build system and do weekly releases that are served
[01:37] <rick_h_> so you can specify "load the gallery from date 2012-07-12"
[01:37] <rick_h_> in your yui config
[01:38] <lifeless> rick_h_: what granularity does that have ?
[01:38] <rick_h_> lifeless: only a weekly build
[01:38] <lifeless> not frequency, granularity :)
[01:38] <lifeless> is it all of gallery, or per-module ?
[01:38] <rick_h_> lifeless: it's all the repo
[01:38] <rick_h_> lifeless: all the gallery
[01:38] <rick_h_> lifeless: I'm not sure if you can specify it per module, you might be able to but not tried it
[01:38] <lifeless> ok
[01:39] <lifeless> so, here are some questions we might want to answer
[01:39] <lifeless> rick_h_: oh, how big was that allofgallery thing ? Are you finding out ?
[01:39] <lifeless>  - how big is allofgallery
[01:39] <rick_h_> lifeless: ah sorry, got distracted
[01:40] <lifeless>  -> would e.g. daily snapshots into the download cache be a significant burden?
[01:40] <lifeless> rick_h_: you said something earlier that each module has multiple versions, is that right? so you can ask for a specific one that is known to work ?
[01:41] <rick_h_> lifeless: so build tar/gz is 3.4M
[01:41] <rick_h_> lifeless: yes, when you write a module you specify a version string, but we've not used it so far
[01:41] <lifeless> so the weekly snapshot includes an unversioned tip of the module + all the prior still supported releases?
[01:42] <lifeless> (that yui host)
[01:42] <rick_h_> lifeless: so the weekly snapshot builds the tip of all modules, and serves it via a new url specific to that build date. Each build is a new url.
[01:42] <lifeless> ok, so you *can't* stick to an arbitrary old version trivially ?
[01:42] <rick_h_> I know and have used that to go back in time for the whole gallery, but not seen how to use that on a per-module basis
[01:43] <lifeless> righto.
[01:43] <rick_h_> lifeless: I don't know, will look into it
[01:43] <lifeless> indeed thats a question too
[01:43] <lifeless> I mean, if you only get snapshots-of-tip granularity, a shared JS area for all of Canonical would likely be not an improvement over working directly upstream
[01:44] <rick_h_> lifeless: true
[01:44] <lifeless> because you'd still have folk sitting on a known-good, and then upgrading many bits at once and dealing with the fallout.
[01:44] <lifeless> unless we engineer something special using introspection etc; but at that point we could do that upstream and then work upstream with less friction.
[01:45] <lifeless> I don't think we have quite enough knowledge yet to progress this further
[01:45] <lifeless> what other questions should we queue up
[01:45] <rick_h_> lifeless: right
[01:45] <lifeless>  - how do other YUI users deal with this?
[01:46] <rick_h_> well, the big questions are is this feasible? will teams work together and want to do so. How will it be managed, and how to get this setup for local dev.
[01:46] <lifeless>  - how often would we really be updating the gallery cop(ies) we have - assume we update to a) get bugfixes b) to work with a new YUI and c) to have newer versions of modules we're contributing to.
[01:46] <rick_h_> lifeless: honestly I'm not sure. While I know teams using it, I've not seen places doing a lot of cross-team work like we're looking at
[01:46] <lifeless> rick_h_: I haven't seen any need for cross-team stuff yet, in all that you've discussed.
[01:46] <lifeless> rick_h_: I've seen you propose it :)
[01:47] <lifeless> rick_h_: cross team work is super hard
[01:47] <rick_h_> lifeless: well that's the point. Is that with all of this, we're worried about a single gallery build breaking a team using an older version that missed something that changed
[01:47] <rick_h_> which would mean another team submitted a fix/update for a module that caused it to change
[01:48]  * rick_h_ is missing how this isn't cross team
[01:48] <lifeless> rick_h_: I think you have a hidden assumption somewhere.
[01:48] <lifeless> :)
[01:48] <rick_h_> lifeless: more than likely
[01:49] <lifeless> uhm, its not cross team because you can (naive, may need tuning): drop yui-gallery-XYZ.zip into download cache, pull that out like we were yui base-XYZ.zip, drop in additional single-module zips for things we fork (so they are visible)
[01:49] <lifeless> setup and document how to do it a way for folk like e.g. sinzui or wgrant or $anyone to do a new snapshot as needed.
[01:50] <lifeless> none of that implies shared cross team stuff; the place for collaboration is yui gallery upstream.
[01:50] <rick_h_> lifeless: sorry, but I really need to wrap up. It's late here and I'm hoping to unblock buildbot before bed
[01:50] <rick_h_> lifeless: ok, I see
[01:50] <lifeless> Ok, short term suggestion: revert it back to what it was before.
[01:50] <StevenK> A revert is the easiest.
[01:51] <rick_h_> lifeless: ok, I'm hoping to get the ok to push it with http://paste.mitechie.com/show/735/ as that moves the conflicting point out to where it really belongs
[01:51] <StevenK> rick_h_: I'm happy to revert your revision out if you want to crash.
[01:52] <rick_h_> StevenK: ok, if that's easiest will do then thanks. I'll revisit the buildout setup and adjust from there then and see if I can come up with a place for the helper code to assist in getting updates going
[01:52] <rick_h_> s/will do/to do
[01:52] <rick_h_> ugh
[01:53] <lifeless> rick_h_: From what I've heard so far the canonical specific shared area is entirely orthogonal to handling yui + gallery + odd forks of gallery modules effeciently for LP
[01:53] <rick_h_> thanks StevenK and wgrant for the help and lifeless for the discussion. I've got some tweaking to my long term vision to work on
[01:54] <rick_h_> lifeless: right, I'm just trying to start with the goal of updating YUI in LP and leaving the gallery/etc for a later date
[01:54] <lifeless> rick_h_: if LP can do it efficiently with a direct relationship with upstream, that provides a template for other Canonical projects to also work with it efficiently and collaborate with upstream
[01:54] <rick_h_> lifeless: agreed, and we've started that process. We have our first module inthe gallery yesterday, and I've been working to facilitate discussion with the PES team and their modules and upstream
[01:54] <lifeless> I think - I'm sure - that its easier to replicate a template of working with an established group that setting up a new group which would amongst other things have to broker with upstream.
[01:55] <rick_h_> lifeless: lifeless but as working with upstreeam doesn't help us at all in our deploy/serving area, I held out a vision of a single 'canonical-gallery' at some point in the future (loooong future)
[01:55] <lifeless> rick_h_: (discussion) - anytime. sorry I had to ask so many questions :)
[01:55] <lifeless> rick_h_: from the sounds of it though, a canonical gallery wouldn't help either.
[01:56] <rick_h_> lifeless: no it's good, it's going to focus me on thinking more of the tar/offline mode than I originally was
[01:56] <lifeless> rick_h_: also note that anything on a new domain name will make first-view loads for LP slower.
[01:56] <rick_h_> lifeless: right, it has weak spots as well
[01:56] <lifeless> rick_h_: about 3 seconds slower.
[01:56] <lifeless> rick_h_: (well, 3-10, but definitely 3).
[01:56] <rick_h_> ok, you know better than I on that front
[01:57] <lifeless> SSL :)
[01:57] <StevenK> rick_h_: Revert is landing.
[01:57] <rick_h_> 3s for a SSL handshake to a second domain?
[01:57] <lifeless> rick_h_: you can test - add a 300ms latency to your outbound packets, see the world the way the non-Europe folk do :)
[01:57] <rick_h_> StevenK: ty much sir
[01:57] <StevenK> rick_h_: Easily.
[01:57] <rick_h_> ok, I'm spoiled from my network/location :)
[01:57] <lifeless> rick_h_: http://wiki.bazaar.canonical.com/SmartPushAnalysis1.4#Network_connection
[01:58] <StevenK> rick_h_: Move to Sydney/Melbourne/Christchurch and use LP.
[01:58] <rick_h_> ok, so as I said, I need to refocus the long term goal for sure, but it is a bit different from the current issue of 3.5 on LP and making sure we don't spend a year getting to 3.6 after it's out in a month/two
[01:58] <lifeless> yah
[01:58] <lifeless> totally.
[01:59] <StevenK> BAH
[01:59]  * StevenK stabs PQM, and adds [testfix]
[01:59] <rick_h_> StevenK: heh, I asked deryck if anyone's complained on the combo loader and we decided if the aussies didn't raise a fuss it must be working out ok :)
[01:59] <lifeless> FWIW I'd use the current approach which handled the 3.4->3.5 OK AIUI, and look at rearranging as part of doing the gallery.
[01:59] <rick_h_> lifeless: rgr
[01:59] <lifeless> rick_h_: I haven't looked up your mail about combo loader stuff yet either, I've been sick this week
[01:59] <StevenK> rick_h_: I think the combo-loader needs to actually cache the files
[01:59] <lifeless> am only just on deck now.
[02:00] <rick_h_> lifeless: not a problem, I figure with it being Friday for me tomorrow I'd not turn on a FF then until next week anyway
[02:00] <lifeless> cool, I'll look for it monday
[02:00] <lifeless> rick_h_: is the combo loader oops enabled, and do we get perf information out of it ?
[02:00] <rick_h_> StevenK: oh, I thought webops copied over the way the apache cache/etc is setup from U1/Landscape. Not peeked at it tbh
[02:01] <StevenK> rick_h_: Revert landed as r15619
[02:01] <rick_h_> StevenK: ty
[02:01] <rick_h_> lifeless: no, convoy isn't oops enabled currently. I'd assume any perf info would be normal apache request/logging/etc
[02:01] <wgrant> StevenK: It's pretty aggressively cached already, I believe
[02:01] <wgrant> Yeah
[02:01] <wgrant> Cache-Control: public,max-age=5184000
[02:01] <StevenK> wgrant: Oh? I thought the caching was non-existant.
[02:02] <rick_h_> the only issue is that each deploy breaks the cache
[02:02] <StevenK> Like it should.
[02:02] <rick_h_> since the url changes for deploy purposes
[02:02] <wgrant> StevenK: It's probably done by the Apache config, as rick_h_ suggests
[02:02] <rick_h_> right, just saying that might make it seen less cached with frequent deploys going on
[02:02] <rick_h_> s/seen/seem
[02:02] <lifeless> btw
[02:03] <lifeless> this is a reason to have things like yui not part of lp's build area at all
[02:03] <lifeless> version them entirely independently
[02:03] <lifeless> may require some assembly.
[02:03] <rick_h_> lifeless: agree, but definitely some assembly
[02:04] <rick_h_> but again, perfect is the enemy of good
[02:04] <rick_h_> step by step
[02:04] <StevenK> wgrant: Join added. Now how to fix the other bug.
[02:04] <lifeless> totally ;)
[02:05] <rick_h_> ok, night all, thanks again and sorry to fubar buildbot on you guys
[02:05] <lifeless> man, this is ripe: http://arstechnica.com/tech-policy/2012/07/verizon-net-neutrality-violates-our-free-speech-rights/
[02:05] <lifeless> "Broadband networks are the modern-day microphone by which their owners [e.g. Verizon] engage in First Amendment speech"
[02:06]  * StevenK peers at buildbot
[02:06] <lifeless> uhm, nothing that my ISPs have *ever* said to me has been even slightly protected speech. Or would have been had I lived in the US.
[02:06] <StevenK> bzrlib.errors.InvalidHttpResponse: Invalid http response for https://xmlrpc.launchpad.net/bazaar/: Unable to handle http code 502: Bad Gateway
[02:06] <StevenK> Hmmm, at least its not my fault.
[02:07] <StevenK> lifeless: At least it isn't RIPE.
[02:12] <StevenK> wgrant: I can't say Branch.id IS IN () without toys being depramed, so what was your thought there?
[02:12] <lifeless> Branch.id.is_in(...)
[02:14] <StevenK> lifeless: Obviously. You're missing some context.
[02:33] <wgrant> StevenK: Hm, possibly just exclude the branch query entirely in that case, then.
[02:34] <StevenK> wgrant: But wasn't the bug query written in such a way that it would deal with no bug ids being passed, or am I on crack?
[02:35] <wgrant> StevenK: Yes.
[02:35] <wgrant> StevenK: Because in the case that no bug IDs were passed, it was correct behaviour to just operate on every bug.
[02:35] <wgrant> But that's not correct any more.
[02:35] <wgrant> Since you pass in a list of artifacts that you want to operate on.
[02:35] <wgrant> Not just a list of bugs.
[02:36] <wgrant> So if I pass in only bugs, it should only work on those bugs.
[02:36] <wgrant> If I pass in only branches, it should only work on those branches.
[02:36] <wgrant> If I pass in a few of each, it should work on those bugs and those branches.
[02:36] <wgrant> If I don't pass in a list of artifacts, it should work on all bugs and branches that satisfy the other filters.
[02:39] <StevenK> wgrant: But run() had if self.bug_ids <filter on bugs> else: every other filter
[02:40] <wgrant> StevenK: Yes. Is that odd?
[02:40] <wgrant> Because it didn't support branches before this, the logic was:
[02:41] <wgrant> If I pass in only bugs, it should only work on those bugs.
[02:41] <wgrant> If I don't pass in a list of artifacts, it should work on all bugs that satisfy the other filters.
[02:41] <wgrant> fin
[02:46] <StevenK> wgrant: Then just the join is needed
[02:46] <wgrant> StevenK: Howso?
[02:47] <wgrant> StevenK: Currently if I pass in a list of bugs, it will work on those bugs and *every* branch.
[02:47] <wgrant> Won't it?
[02:53] <StevenK> wgrant: http://pastebin.ubuntu.com/1089151/ but it's a bit messy
[02:54] <wgrant> StevenK: I'd invert those flags, but something like that, yeah
[02:54] <wgrant> StevenK: Alternatively, start bug_filters and branch_filters off empty, rather than with the visibility filter
[02:55] <wgrant> StevenK: Keep the branch_ids/bug_ids/else code the same.
[02:55] <wgrant> StevenK: Then wrap the two queries at the end in an 'if bug_filters' and 'if branch_filters', and insert the visibility clause there
[02:58] <StevenK> wgrant: http://pastebin.ubuntu.com/1089155/
[02:59] <wgrant> StevenK: You should probably put *_invisible_filter inside the conditional blocks, and maybe even inline them if they fit nicely.
[04:12] <StevenK> wgrant: http://pastebin.ubuntu.com/1089206/
[04:13] <wgrant> StevenK: Looks reasonable. Does it work?
[04:15] <StevenK> That's a seperate problem.
[04:15] <wgrant> Heh
[04:17] <StevenK> wgrant: Spot the glaring error in the branch query.
[04:17] <wgrant> StevenK: Hah
[04:17] <wgrant> Indeed
[04:18] <wgrant> findspec is in the wrong place
[04:18] <StevenK> And no .using()
[04:18] <wgrant> Yeah, but all the important bits are there :)
[04:18] <wgrant> Just not the syntax...
[04:22] <StevenK> wgrant: As an added bonus, http://pastebin.ubuntu.com/1089218/ passes tests.
[04:22] <wgrant> StevenK: Did you write new tests?
[04:23] <wgrant> To catch the issues?
[04:23] <StevenK> Nope
[04:23] <StevenK> Well, not yet.
[04:24] <StevenK> wgrant: A great deal of the tests just pass in bugs, so I'm not sure why they don't tickle what afflicted qas.
[04:25] <wgrant> StevenK: Because they don't check that the branch subscriptions survive
[04:25] <wgrant> Because they only care about bugs.
[04:25] <StevenK> wgrant: But the query was running for *ages*
[04:26] <StevenK> So why don't the bug tests show that ...
[04:27] <wgrant> StevenK: Because sampledata doesn't have hundreds of thousands of branches and millions of subscriptions
[04:27] <wgrant> So the query will take milliseconds.
[04:27] <StevenK> Oh. Right.
[04:28] <StevenK> wgrant: So we want to sprinkle in StormStatementRecorder or what do you want to do?
[04:29] <wgrant> StevenK: We want a test that tries to remove subscriptions from a set of bug IDs, and checks that those subscriptions are gone but other bug and branch subscriptions remain.
[04:29] <wgrant> And the same but for branch IDs.
[04:29] <wgrant> There are probably existing tests to whichyou can add a couple of lines to do this.
[04:40] <StevenK> wgrant: Right, http://pastebin.ubuntu.com/1089239/
[04:40] <StevenK> wgrant: I get two failures if I shelve the changes in sharingjob
[04:41] <wgrant> Great
[04:41] <StevenK> wgrant: Commit, push and force wallyworld to review it since we effectively wrote it together?
[04:42] <wgrant> Plus he's OCR
[04:43] <StevenK> % bzr log | head -n 8 | tail -n 2
[04:43] <StevenK>   Fix RASJ to deal with branches correctly without spawning a query that will
[04:43] <StevenK>   take approximately three eons to complete.
[04:43] <wgrant> (and do the wrong thing)
[04:45]  * StevenK stabs Firefox for crashing
[04:46] <wgrant> StevenK: Crashing, or the DnD hang that sprung up in the last major release?
[04:47] <StevenK> That looked like a crash, the window disappeared followed by the process
[04:47] <wgrant> Ah
[05:00] <StevenK> wallyworld: O HAI. https://code.launchpad.net/~stevenk/launchpad/fix-rasj-and-branches/+merge/114779
[05:08] <StevenK> wgrant: http://pastebin.ubuntu.com/1089253/ is that other thing I'm working on.
[05:20] <wgrant> Ah, I;ve solved commercial subscription expiry too.
[05:35] <StevenK> wgrant: Do you think I'm missing something from my branch?
[05:37] <wgrant> StevenK: Which one?
[05:39] <StevenK> wgrant: [15:08] < StevenK> wgrant: http://pastebin.ubuntu.com/1089253/ is that other thing I'm working on.
[05:51] <wgrant> StevenK: Rather hard to say. Does it work?
[05:51] <StevenK> wgrant: test_bugnotification works at least
[05:53] <wallyworld> StevenK: hi, just got back from school pickup
[05:53] <wallyworld> bad traffic today in the rain :-(
[05:53] <StevenK> Bright, sunny and 23degC here today
[05:55] <wallyworld> StevenK: we will conflict. i also have removed those unused imports, but yours will land first since i'm just completing the covering letter for mine
[05:55] <wgrant> Dreary, dismal and 12degC or so :)
[05:55] <StevenK> wgrant: So normal Melbourne weather then.
[05:55] <wgrant> Hey, from what I've heard SE QLD has been pretty similar for the last week...
[05:56] <wgrant> Although I guess warmer :)
[05:56] <StevenK> wgrant: Did the Victorian goverment write a stern letter asking for Melbourne's weather back?
[05:57] <wgrant> StevenK: No, that wouldn't involve building more jails or decomissioning educational institutions :)
[05:57] <StevenK> Haha
[05:57] <StevenK> Maybe your government needs to turn the educational institutions into jails.
[05:58] <wgrant> That approximates their current policy.
[05:58] <StevenK> Haha
[05:58] <wallyworld> StevenK: looks nice, r=me
[05:59] <StevenK> wallyworld: At least you weren't sobbing saying "RBSJ looked nice until you touched it inappropiately and renamed it." :-P
[06:00] <StevenK> steven@undermined:~% uptime
[06:00] <StevenK>  16:00:06 up 16:50,  4 users,  load average: 3.71, 3.23, 2.15
[06:00] <StevenK> Sigh
[06:00] <wallyworld> StevenK: nah, all good. i started out with a generic job but at the time it was messy so just got bugs working.
[06:01] <StevenK> test_sharingjob needs to good spring clean at some point
[06:01] <wgrant> Everything we've touched does :)
[06:01] <wgrant> A lot can be cleaned up once sharing is fully deployed
[06:01] <wallyworld> and some of the other sharing tests need XXXs removed and (likely) some branch tests added
[06:01] <StevenK> Apparently, reading from USB is *hard* or something.
[06:59]  * cjwatson celebrates his 100th LP branch landing
[06:59] <wgrant> :)
[06:59] <wgrant> Pre-LP me has competition :(
[07:00] <cjwatson> Yeah.  Little bit of a way to go yet.
[07:01] <nigelb> dammit
[07:02] <nigelb> wait
[07:02] <nigelb> cjwatson gets on a different list.
[07:02] <nigelb> wgrant: nah, you don't.
[07:02] <nigelb> unless I boot up my vm and start contributing.
[07:03] <wgrant> Heh
[07:49] <adeuring> good morning
[08:09] <jml> cjwatson: congratulations!
[08:10] <jml> cjwatson: how are you celebrating?
[08:23] <cjwatson> jml: coffee
[08:23] <cjwatson> and more branches :)
[08:24] <jml> cjwatson: coffee is fantastic, wonderful and slightly bitter. What better way to celebrate landing a hundred Launchpad branches?
[08:56] <jam> anyone have familiarity with buildout? I'm trying to do a bootstrap using python-2.7, and
[08:56] <jam>  it is telling me 'could not install pyinotify-0.9.3' but there is no other error, and I can see the .tar.gz available
[08:56] <mgz> ...the windows installers use it!
[08:57] <jam> mgz: yes, and we are super happy about it there :)
[08:57]  * mgz doesn't have familiarity of it either :)
[09:29] <czajkowski> wgrant: have you ever seen an error message like this when a user tries to log in. https://answers.launchpad.net/launchpad/+question/203032
[09:31] <wgrant> czajkowski: I reassigned that to SSO a couple of minutes back. It usually means they refuse to accept cookies
[09:31] <czajkowski> bah that will teach me to open my work in tabs and come back to things
[09:31] <czajkowski> wgrant: cheers
[10:41] <Tribaal> hi all
[13:43] <jam> jelmer: ping
[13:44] <jelmer> jam: pong
[13:54] <jam> jelmer: sorry for the delay, otp, but I'd like to have you pick up some of the 'get launchpad running on python-2.7 on Lucid'
[13:55] <jelmer> jam: sure, which things in particular?
[13:56] <jam> right now python-2.7 is segfaulting, and we probably need to bring in barry
[13:58] <jelmer> jam: okay
[14:00] <jam> jelmer: I guess the other option is doku, but I think barry has done more on that particular ppa
[14:00] <jelmer> jam: still no idea on what's causing the segfault?
[14:01] <jam> jelmer: 'import ctypes' seems to be a pretty common trigger
[14:01] <jam> it is failing right now trying to build pyinotify
[14:01] <jam> but I notice that there is a 'import ctypes' in there.
[14:01] <jam> I'm pinging barry in #canonical
[14:01] <jelmer> what do we use pyinotify for anyway?
[14:01] <jam> also, jelmer, mgz, vila: You probably want to keep in touch with eachother while I'm gone. I imagine at least doing the standup. (I realize vila is gone next week)
[14:02] <jam> jelmer: it doesn't really matter, ctypes gets imported at other times.
[14:02] <jam> bzrlib probably improts it, etc.
[14:04] <jam> jelmer: not sure if we have to have ctypes, but segfaulting regardless is bad :)
[14:07] <jelmer> jam: does that mean that even "python -c 'import ctypes'" segfaults?
[14:08] <jam> jelmer: yes
[14:08] <jam> I did just try that directly
[14:08] <mgz> we can do a jelmer/mgz standup on tuesday
[14:08] <mgz> perhaps at 9pm
[14:08] <jam> mgz: heh, whatever works for you :)
[14:09] <jam> you guys work all day long anyway, right?
[14:10] <mgz> at least some days I stop at 6 :)
[14:18] <mgz> I have lp on lucid up and working and the ctypes crash from the ppa,
[14:18] <mgz> so should be able to continue from where you are.
[14:21] <mgz> is there a neat way of getting gdb to look in the right place for src?
[14:21] <mgz> given it has paths like the following for ppas:
[14:21] <mgz> /build/buildd/python2.7-2.7.2/Modules/_ctypes/libffi/src/closures.c
[14:22] <cjwatson> based on the similar python3.2 failure a while back I suspect it's a pretty easy build fix.
[14:23] <mgz> sure, I'm leaving that to barry, just following along at home :)
[14:41] <czajkowski> jelmer: can you please follow up on the RT I gave you yesterday when you get a chance being poked for an update on the ppa
[15:00] <jelmer> czajkowski: ah, yes, sorry
[15:00]  * jelmer is having an unproductive day
[15:10] <czajkowski> :(
[15:11] <czajkowski> jelmer: need the link ?
[15:12] <jelmer> czajkowski: no, I still have it open here; thanks though
[15:12]  * mgz sends jelmer some cuddles
[15:20] <jelmer> thanks  mgz
[17:34] <bac> jcsackett: darn, someone beat me to it:  https://launchpad.net/jujube