[06:18] <dholbach> good morning
[16:47] <davmor2> guys can you check something out for me please.  I wrote a bug about the user not having /usr/games in their path.  I think I know why now.  By default xephyr sets you up as user root this user doesn't have /usr/bin in their path however user ume does which is why I think you guys get it but xephyr people don't
[16:48] <lool> davmor2: I personally run Xephyr as ume, not as root and it's much saner; but the current Xephyr approach is a big hack, we should move away from this
[16:48] <lool> davmor2: One option is to use vms; mvo started a script to create such vms
[16:48] <lool> brz branch lp:~mvo/ubuntu-mobile/simple-image-builder
[16:49] <davmor2> lool: Yeah I know now I hadn't bothered looking before :)
[16:50] <agoliveira> Not only a hack but Xephyr, in it's current form, is becoming a problem. Me davmor2 and cgregan spent quite some time figuring out that bunch of "false" icons and associated bugs.
[16:51] <lool> Please don't use Xephyr; I stopped doing so a while ago; it really sucks too much
[16:51] <lool> It's extremely time consuming to set it up properly
[16:52] <davmor2> agoliveira: you got a device haven't you?
[16:52] <agoliveira> davmor2: Yes I do and I know that you don't so currently is the only way for you to test.
[16:53] <agoliveira> davmor2: Well, I have a Q1 only, no CB boards.
[16:54] <davmor2> agoliveira: No I was going to ask you if you have tried out Ekiga yet.  cgregan just tried he could hear me but I couldn't get hear him so looks like there might be an issue there
[16:55] <agoliveira> davmor2: Oh, I just looked at the camera issue but didn't actually used for anything.
[16:56] <agoliveira> davmor2: Did he check the micrpophone levels? Did the initial test worked?
[16:56] <davmor2> agoliveira: Camera apart you switch that off
[16:57] <agoliveira> davmor2: I beg your pardon?
[16:58] <davmor2> agoliveira: Sorry not good English.  I mean you can ignore the camera it can be switched off.
[16:58] <davmor2> agoliveira: I'll ask cgregan after if he uped the volume on the mic.  But I would guess he did.
[16:59] <agoliveira> davmor2: Yes it can. I meant that there was a bug that the camera didn't work and I saw it does on Q1 at least - I mean, an external camera. There's no driver for Q1's
[16:59] <davmor2> agoliveira: Ah right
[16:59] <agoliveira> davmor2: There's a test that ekiga does that let you loop back the mic and phones so you can hear yourself.
[17:00] <davmor2> agoliveira: Yes loop back test<EMAIL_ADDRESS>That's how I set mine up correctly.
[17:01] <davmor2> agoliveira: However it doesn't work at all in xephyr no mic no speaker.  So I was just using my standard Ekiga on my desktop.
[17:02] <agoliveira> davmor2: I see. Well, in this case he has to test on the device as well and se if there's no problem on his side.
[17:02] <agoliveira> cgregan: ^^^^^
[17:02] <stgraber> davmor2: I guess you would have to kill pulseaudio before you can get ekiga to work with Xephyr
[17:02] <stgraber> davmor2: the ekiga running in the chroot can't access the local pulseaudio which is probably locking the mic/speaker
[17:03] <davmor2> stgraber: no it works on my desktop.  I have never had sound in xephyr
[17:05] <davmor2> agoliveira: On a plus side most of the apps are working correctly.
[17:05] <agoliveira> davmor2: Nice :) Thanks for the help, BTW.
[17:06] <davmor2> Even though I'm needing to start them from command line :)
[17:09] <Zic> lool: hello, I know I already asked about this, but I need more info about "switching to another engine" on UME : you told me to take a look at /etc/hildon-desktop, but what can I modify in this directory to switch to another engine ?
[17:10] <lool> /etc/hildon-desktop/home-layout.conf points to /usr/share/applications/hildon-home/mobile-basic-home.desktop for example
[17:10] <lool> Zic: Start by reading desktop.conf, it describes which plugins to load
[17:11] <Zic> ok, thanks :)
[17:43] <davmor2> agoliveira: Just a quicky this is probably another issue with xephyr.  On doc reader I select a doc to open and I get another window popup infront but there are no buttons on it etc so I can't close it.  Do you get that on the device at all?
[17:44] <agoliveira> davmor2: Can you send me the document you're trying to see. Maybe it's a conversion bug.
[17:44] <cgregan> agoliveira: Hey..you caught me during lunch
[17:45] <davmor2> agoliveira: I created one by doing ls /usr/bin > app-list.txt
[17:45] <agoliveira> davmor2: Ah, makes sense. You're not using treb 0.9 are you?
[17:46] <agoliveira> davmor2: Does the interface have a combo to select the file type?
[17:49] <davmor2> It's okay I think I know why it's bleedin' evince opening up.
[17:50] <davmor2> so treb is the office reader thing is it?
[17:50] <davmor2> agoliveira:
[17:50] <Zic> lool: ok, I understood how it works, by default, there is no other engine installed, do you know if the engine which works with Clutter is available on repository ?
[17:51] <davmor2> agoliveira: oh it is that one after all.
[17:51] <davmor2> agoliveira: thought I was going mad
[17:52] <davmor2> brb tea
[17:52] <agoliveira> davmor2: Exactly. Treb is a laucnher that uses OO to convert MS office documents into PDFs and pass them to evince to display.
[17:52] <agoliveira> (or "for displaying"? Hmmm...)
[17:54] <lool> Zic: It is available from multiple places, the ppa to start with
[17:55] <lool> moblin-clutter-home
[17:55] <Zic> Yes, I have just finded the correct name of the package, "moblin-clutter-home"
[17:55] <Zic> thanks :)
[18:13] <Zic> hmm, I can load it with desktop-launcher -w, but not as an applet into UME like mobile basic ui
[18:25] <Zic> I want something like this : http://www.ubuntu.com/files/u1/clutter-small.jpg, but I can't add home clutter applet via home_ap_view>home_me_select_applet
[18:25] <davmor2> agoliveira: back right what the command to get the version number for treb
[18:25] <Zic> or, like in the screenshot, via menu on the top panel
[18:31] <Zic> an other question (sorry :)) : https://wiki.ubuntu.com/MobileAndEmbedded/EmailUI are these just mockup ?
[18:32] <agoliveira> davmor2: apt-cache show treb
[18:33] <agoliveira> Zic: Yes, they are
[18:33] <Zic> is there any plan to work on UI of claws-mail ?
[18:34] <agoliveira> Zic: Nothing specific but UDS is coming so we may discuss that.
[18:35] <Zic> ok, thanks
[18:36] <Zic> because, for now to me, apps on UME are like apps on Maemo Platform : they seems not finger playable
[18:36] <Zic> just computer apps (and, in reality, it just what it is on Embedded platform based on GMAE actually)
[18:36] <Zic> except for the browser, nice work on both side :)
[18:37] <agoliveira> Zic: Yes, for now it's what they look like. We still have a lot of work to do on that.
[18:38] <Zic> I am sad not to be familiarized with integration GTK / Hildon sometimes:)
[18:39] <Zic> (to play with UI integration of embedded devices)
[18:40] <Zic> I must to leave, bye, and thanks for your help
[18:44] <davmor2> agoliveira: yes it's treb 0.9
[18:45] <agoliveira> davmor2: And you're able to open any files? Did I add a * filter by mistake? :P
[18:46] <davmor2> agoliveira: no I created a txt file and I get a blank window in front of it want a screen shot to make it easier to understand
[18:48] <agoliveira> davmor2: It's not I'm asking about. I modified treb so you can't open any files that are not MS office's they should not show up into treb's interface that's why I'm asking how did you select it.
[18:48] <agoliveira> davmor2: Let me make a test, hold on, please.
[18:48] <agoliveira> do a test, actually...
[18:48]  * agoliveira is tired...
[18:49] <davmor2> agoliveira: do what I did ls /usr/bin > app-list.txt
[18:49] <davmor2> quick easy text file
[18:50] <davmor2> http://www.davmor2.pwp.blueyonder.co.uk/weird1.png
[18:50] <agoliveira> davmor2: No need. I know what I've done
[18:50] <davmor2> okay cool
[18:51] <agoliveira> davmor2: As I suspected, I added a "all files" filter as well (which actually means no filter at all) and you're trying to open a .txt which messes with openoofice's conversion process.
[18:51] <agoliveira> davmor2: I'll open a bug to modify this.
[18:55] <davmor2> agoliveira: No Prabs happy to help :)
[18:56] <agoliveira> davmor2: Sure and thanks!
[18:56] <davmor2> agoliveira: out of curiosity what app is being used for .txt files and the like?#
[18:57] <agoliveira> davmor2: Well, one can use the mousepad but there's no file association AFAIK.
[18:58] <davmor2> agoliveira: okay no probs
[19:00] <davmor2> agoliveira: is the pim stuff in place and should it work against the clock/calendar?
[19:00] <agoliveira> davmor2: For now it's standalone, not integrated with the clock applet.
[19:01] <davmor2> so the pim includes contacts and tasks anything else?
[19:14] <davmor2> agoliveira: can you try something for me.  I just tried running claws-mail from cli and nothing happened but it will run from desktop icon.  Bit concerning
[19:17] <agoliveira> davmor2: Hold on.
[19:19] <agoliveira> davmor2: Looks like a permission problem when trying to bind on /tmp but, anyway, no program is supposed to be run from the console so it's not a problem actually.
[19:19] <davmor2> agoliveira: okay No probs
[19:24] <davmor2> agoliveira: is gnash not plugged into the midbrowser by default?
[19:26] <agoliveira> davmor2: I dont think so.
[19:30] <davmor2> agoliveira: right so no flash on xephyr it dies trying to install
[19:31] <agoliveira> davmor2: Have you tried adobe's plugin?
[19:31] <davmor2> yes just jotting down the error message for you now :)
[19:35] <davmor2> agoliveira: Error reads.  MidBrowser could not install this item because "install-ccx..rdf" (provided by the item) is not well formed or does not exist.  Please contact the author about this problem.
[19:36] <agoliveira> davmor2: I have no idea what that means. Maybe asac can help?
[19:36] <davmor2> asac: ping
[19:36] <asac> yes?
[19:37] <asac> yeah ... its adobes fault (i assume its installing flash)
[19:37] <asac> use ubufox ;)
[19:37] <davmor2> asac: It is indeed not up to me or I would :)
[19:38] <asac> story is that the .xpi installer provided on adobe website uses a really old mechanism that predates firefox
[19:38] <davmor2> asac: mind you when I saw that gnash was installed I'd of thought that the plugin would of been in too so you got youtube working at least :)
[19:39] <asac> huh? so gnash isn't working?
[19:39] <davmor2> asac: That's friggin' useful then :)
[19:40] <davmor2> asac: when I click on a youtube vid it says plugin missing across the top at which point it tries to install flash from adobe
[19:42] <asac> with gnash installed?
[19:42] <asac> do you see gnash in about:plugins
[19:42] <asac> ?
[19:44] <davmor2> asac: http://www.davmor2.pwp.blueyonder.co.uk/plugins.png
[19:52] <asac> davmor2: yeah ... about:plugins?
[19:52] <asac> not there as well?
[19:52] <asac> is gnash installed?
[19:52] <davmor2> asac: ah right sorry with you
[19:52] <davmor2> hang on
[19:53] <asac> update-alternatives --list xulrunner-addons-flashplugin
[19:53] <asac> and update-alternatives --config xulrunner-addons-flashplugin
[19:53] <asac> if you are sure gnash is the current alternative ... it should work ;)
[19:55] <davmor2> asac: mozplugger contains loads but no flash
[19:58] <davmor2> update-alternatives command not found.
[19:59] <davmor2> I'm off now anyway I
[19:59] <davmor2> it's getting late bye
[22:42] <dijenerate> anyone here using a Vaio UX?
[22:42] <dijenerate> I need a little help with Monday's build
[23:39] <asac> any hard freezes on ubuntu-mobile archive right now? need to update xulrunner to include the critical fix we rolled to hardy-updates
[23:40] <asac> if noone raises hands i will upload. should be low risk


[09:10] <DBO> davidbarth, what about https://code.edge.launchpad.net/~jassmith/go-home-applet/atk/+merge/10741 ?
[09:13] <davidbarth> DBO: hi; just approved it too, go ahead
[09:13] <DBO> thank you
[09:13] <DBO> merged :)
[09:14] <davidbarth> DBO: thanks to you, you're doing a great job with UNR!
[09:14] <DBO> thank you, I am just trying to stay on top of everything :)
[09:14] <DBO> do you know when a good time to catch Otto is?
[09:14] <DBO> he is working on making the active window indicator a little spiffier for WPA
[09:16] <davidbarth> DBO: he should be at the office soon now; mpt may be able to tell you more precisely when he sees him
[09:16] <mpt> No sign of him yet
[09:17] <DBO> mpt, if you see him can you gently nudge him that DBO would like just 30 seconds of his time, it it is available. Maybe in a less run-on sentence format.
[09:17] <DBO> s/it it/if it/
[09:17] <mpt> ok
[09:59] <chaotic> DBO: hey
[10:04] <DBO> chaotic, sorry about the delay!
[10:04] <chaotic> DBO: no problem
[10:04] <DBO> chaotic, I just wanted to see if you have gotten any idea for me on that indicator
[10:04] <DBO> I understand its kind of a very limited problem and all...
[10:05] <chaotic> DBO: had a crash and lost those images, can you send again?
[10:05] <DBO> ya
[10:05] <chaotic> DBO: it is limited, I guess all that can be done in such a small area is tinting the unselected items back and maybe putting a highlight colour or outline on
[10:06] <DBO> http://dl.getdropbox.com/u/269345/UNR-wpa-screen.png
[10:06] <DBO> chaotic, "tinting the unselected items back"?
[10:10] <chaotic> DBO: http://dl.getdropbox.com/u/1559554/wpa_screen.jpg
[10:11] <DBO> I love what you did with the other icons. The white background may not work since I think the UNR default theme is being changed :( I have to see whats going on there
[10:11] <DBO> but what did you do to those icons exactly???
[10:11] <DBO> just desaturated?
[10:13] <chaotic> DBO: yup - can you do that -pushes them back more
[10:13] <DBO> i sure can
[10:13] <chaotic> DBO: cool
[10:13] <DBO> making graphical effects a reality is my specialty :)
[10:16] <chaotic> DBO: I know
[10:27] <DBO> chaotic, that makes it beautiful
[10:27] <DBO> proposing the merge now :)
[10:29] <chaotic> DBO: cool man :)
[10:52] <DBO> thanks for the review MacSlow, comment taken care of.
[10:52] <MacSlow> DBO, slick
[10:53] <DBO> Im not sure the way I handle the condition is all that graceful. It paints the colored version in that case...
[10:53] <DBO> but out of memory is a bad condition for a machine to be in
[10:57] <MacSlow> but that's no excuse for not handling that case :)
[10:57] <MacSlow> DBO, you rather want someone else's code to fail in that condition and not your, right? ;)
[10:58] <DBO> im not complaining really
[10:58] <DBO> just noting that my fallback is really "hey, dont crash... do something silly, but dont crash"
[11:04] <MacSlow> DBO, well it should continue to work now and not segfault
[11:04] <DBO> indeed
[11:04] <MacSlow> DBO, although if that condition is hit, the system will be in trouble :)
[11:04] <DBO> there is a proposed merge for desktop-switcher now too
[11:04] <DBO> if you have nothing else to do...
[11:04] <DBO> :)
[11:04] <MacSlow> DBO, I assume the allocated pixbuf is something around 64x64 pixels or so, right
[11:05] <DBO> yes
[11:05] <DBO> actually no
[11:05] <DBO> 24x24
[11:06] <DBO> really tiny
[11:06] <MacSlow> but the code has to be robust
[11:06] <DBO> im not arguing that point :P
[11:06] <MacSlow> even for a 1x1 :)
[11:07] <DBO> seriously, on your side here dude :) appreciate you catching it for me :)
[11:07] <MacSlow> I sometimes scratch my head myself doing these kinds of test, when I expect in-memory buffers to be really tiny
[11:07] <DBO> though, I did miss it... and that shouldn't have happened in the first place
[11:07] <MacSlow> back in the Amiga-days such thing could happen more easily
[11:08] <DBO> Amiga days...
[11:08] <DBO> lets see
[11:08] <MacSlow> AmigaOS, Amiga 1000/2000/4000
[11:08] <DBO> I was -2 when it came out
[11:09] <DBO> so unless I was doing to pre-birth programming :P
[11:10] <DBO> anyhow, I am going to leave you to that last merge request, you have a good long time on it, I need sleep :)
[11:34] <MacSlow> DBO, see you later
[12:21] <mac_v> MacSlow: gravity... \o/ , that means they can be placed anywhere from top or bottom?
[12:22] <MacSlow> mac_v, NorthEast or East yet
[12:22] <MacSlow> yes
[12:22] <mac_v> nice :)
[12:24] <mac_v> MacSlow: and the gconf for the color and text size , have they been implemented yet , I cant seem to find it in the gconf :?
[12:24] <MacSlow> mac_v, that'll come too... but not today
[12:25] <mac_v> ok , was just wondering ;)
[12:28]  * MacSlow -> lunch
[12:32]  * ara reboots
[12:48] <mac_v> kenvandine: i'm planning on making xchat play nice with messaging menu... any suggestions? :)
[13:11] <kenvandine> mac_v, someone has started that
[13:11] <kenvandine> mac_v, one sec
[13:12] <kenvandine> mac_v, git://github.com/smerp/xchat-gnome.git
[13:12] <kenvandine> it mostly works
[13:15] <mac_v> kenvandine: oh , nice , so someone *is* fixing it ... phew , thankx
[13:15] <kenvandine> well... i wouldn't say that
[13:15] <mac_v> eh, ;) well atleast looking into it
[13:15] <kenvandine> smerp took a stab at it... got it working well enough for him and left it
[13:16] <kenvandine> :)
[13:16] <mac_v> i'll check it out
[13:42] <shakaran> some channel for launchpad ppa?
[14:59] <mac_v> DanRabbit: ping , got an idea for wired panel icon ;)
[15:24] <dashua> mac_v,  Any chance you could make a new Xchat-GNOME icon for either Breathe or Humanity?
[15:24] <dashua> Just a refresh :)
[15:25] <mac_v> dashua: hehe , i was thinking the same :) , but realized that if xchat is merged into the messaging menu , there would be no need for it :(
[15:25] <dashua> Ah yeah, good point :)
[15:26] <dashua> Damn, compiz packagers update are not repainting Xchat =/
[15:26] <dashua> Those grey scale icons are SWEET.
[15:27] <dashua> You and DanRabbit keep it up.
[15:31] <DanRabbit> mac_v: I was told by David that I had to remove non-generic application icons
[15:31] <mac_v> DanRabbit: huh? i didnt understand
[15:32] <DanRabbit> In other words, the only application icons we can have in Humanity are like web-browser, terminal, text-editor
[15:32] <DanRabbit> not pidgin, midori, xchat
[15:33] <mac_v> oh , yeah... i'm not making any of those ;)
[15:33] <mac_v> DanRabbit: rough idea for the wired > http://imagebin.ca/view/8St4jY6.html
[15:34] <DanRabbit> I was saying because dashua asked about Xchat icon
[15:34] <mac_v> hehe i'm clogging up image bin today;)
[15:34] <mac_v> oh, ok
[15:34] <DanRabbit> yea that looks good
[15:34] <DanRabbit> I like your notification icons for the battery
[15:35] <DanRabbit> it fits well with Ken's current icons
[15:35] <mac_v> thanks :)
[15:36] <mac_v> DanRabbit: i'm usually bad at coming up with new concepts , but can try to fit them ;p
[15:37] <DanRabbit> haha
[15:45] <mac_v> DanRabbit: another rough idea for the wireless connection animation > http://imagebin.ca/view/d-wIhEp.html , something like a radar
[15:56] <DanRabbit> that's an interesting concept.
[19:13] <mac_v> DanRabbit: i'v done the wired connect and disconnect, let me know when you are back :)
[19:28] <Turl> hi
[19:28] <Turl> why do the notification bubbles appear on half of my screen?
[19:28] <Turl> that's really disturbing :S
[19:28] <mac_v> Turl: just update , now
[19:30] <Turl> mac_v: I have the latest version, 0.9.19-0ubuntu1 :/
[19:30] <Turl> just checked for updates
[19:31] <mac_v> Turl: latest is > "notify-osd (0.9.20-0ubuntu1) karmic
[19:32] <Turl> mac_v: it isn't, according to my repos and http://packages.ubuntu.com/karmic/notify-osd
[19:32] <Turl> guess it's still building then
[19:33] <mac_v> Turl: nope , i have installed the update, maybe its your local server?
[19:34] <Turl> packages.ubuntu.com is international AFAIK
[19:34] <Turl> well, anyway, good to know it's fixed :D
[19:36] <SiDi> latest is 0.9.20 but its not uploaded yet
[19:37]  * mac_v must be special then ^.^
[19:37] <Turl> mac_v: maybe you have some testing repo that canonical secretly hides (?)
[19:37] <Turl> :P
[19:39] <mac_v> Turl: i think the packages page is not update , i'v had this problem of delayed updates and change the server in software sources to main , and the updates *seem* to arrive quicker
[19:39] <mac_v> not up-to-date*
[19:39] <Turl> waiting is not too bad heh :P
[19:40] <Turl> I prefer waiting for the package to get synced to the repo, than waiting for downloads at 10Kb/s in synaptic hehe
[19:41]  * mac_v hasnt had problems of slow speed with main server ^.^
[19:42] <Turl> mac_v: you don't seem to be argentine :p
[19:56] <sintack> hello.  can pynotify or notify-send make an un-critical notif. last shorter? say 1 second?
[20:00] <sintack> or anyway less than 10 seconds?
[20:02] <sintack> i've tried "set_urgency(pynotify.URGENCY_LOW)" in pynotify as well as "notify-send -u {low|normal}" but it always stays for 10 seconds.
[20:09] <sintack> oh, i'm talking about notify-osd by the way
[20:10] <sintack> version 0.9.18-1
[20:10] <sintack> libnotify-bin 0.4.5-1
[21:45] <DanRabbit> mac_v: back


[21:28] <tekisui> Hello
[21:28] <tekisui> Would ubuntu touch run on a hammer II ?
[21:29] <tekisui> The processor is a  MediaTek MT6276W
[21:30] <tekisui> Ah 2 Ghz, Quad-core MTK6761Battery5000
[21:31] <tekisui> Would be nice if its a bit more fuell efficient as an android system
[21:34] <tekisui> I been using lubuntu for ten years now and it suits me well


[09:23] <zero_coder> hello
[09:23] <zero_coder> my applications are freezing at times , totally
[09:23] <zero_coder> like a second delay before it works
[09:31] <zero_coder> Atluxity, ?
[09:31] <zero_coder> ampelbein_, ?
[22:06] <e11bits> Following https://wiki.ubuntu.com/Kernel/KernelBisection I'm trying to bisect from kernel v3.9.11-saucy to kernel v3.10-rc1-saucy. With git I can find the tag v3.10-rc1, but not the tag for v3.9.11. How do I find that?
[23:13] <maxb> e11bits: I'm not sure the bisection you propose actually makes sense
[23:13] <maxb> You need to consider the branching structure of the history you're going to bisect over
[23:14] <maxb> In this case, 3.9.11 is going to be quite some way down a 3.9.x branch which diverged from the main line of development
[23:15] <maxb> So the bisection you suggest could be likened to starting at the top two points of a V
[23:16] <maxb> It would probably be more productive to bisect between 3.9 and 3.10-rc1 which would reasonably closely approximate bisecting along a straight line of history
[23:17] <maxb> (But if you did need to find the stable release tags for some other reason, they're in the upstream linux-stable.git repository)


[00:22] <lool> Not clear to me why upstart-app-launch is listed here
[00:22] <lool> would someone be able to review?
[00:24] <lool> I mean, I'm surprized it's help up
[00:24] <lool> ah via liburl-dispatcher1
[00:24] <lool> via a Suggests?!
[00:24] <lool> gah
[00:24] <cjwatson> click is in Ubuntu desktop supported too
[00:24] <cjwatson> Suggests are ignored
[00:25] <lool> ah right click
[04:32] <pitti> ^ for the upower sync, in the queue it's quite hard to review
[04:32] <pitti> we currently have a git snapshot, and the effective delta is just two commits plus some test suite updates
[04:32] <pitti> http://cgit.freedesktop.org/upower/commit/?id=db89e5a3
[04:33] <pitti> http://cgit.freedesktop.org/upower/commit/?id=ecc4e37
[04:33] <pitti> and we really really need those two fixes, they break a lot in GNOME
[04:33] <pitti> (that is, the bug that they fix :) )
[04:33] <pitti> oh, and http://cgit.freedesktop.org/upower/commit/?id=03c4ab
[05:26] <pitti> cheers :)
[07:02] <infinity> slangasek: ^-- If you're still around, care to give a once-over to those?  New upstream version, but only a handful of bugfixes.  The git log is only a few commits.
[08:37] <dholbach> hiya, can somebody please take a look at bug 1235737? seems like another bug (already approved) in the sponsoring queue depends on it
[08:37] <ubot2`> Launchpad bug 1235737 in postbooks (Ubuntu) "FFe: Sync postbooks 4.1.0-2 (universe) from Debian sid (main)" [Undecided,New] https://launchpad.net/bugs/1235737
[08:49] <infinity> cjwatson: Since you're awake now, want to poke at those gdb/gdb-doc uploads?  bugfix-only, and rather minimal.
[08:50] <cjwatson> infinity: Was just starting on them, indeed
[08:51] <infinity> cjwatson: Sorry about the lazy copy/paste changelog from upstream, but, well.  Lazy.  I did test it, though. :P
[08:53] <cjwatson> Yeah, no problem
[08:55] <Laney> dholbach: sync away
[08:56] <Laney> I'll subscribe u-sponsors to some other ones
[08:56] <Laney> there's a little stack of postbooks things
[08:57] <dholbach> thanks Laney
[09:04] <ogra_> infinity, hmm, these touch kernels went through completely untested
[09:05] <infinity> ogra_: Who was meant to test them and how?
[09:05] <apw> ogra_, they weren't untested, all of yesterday was spent testing them
[09:05] <ogra_> (they were not supposed to be uploaded yet)
[09:05] <ogra_> apw, well, touch images have no landings without the landing team nodding it off
[09:06] <ogra_> infinity, i was supposed to test them with the autopilot tests before they get uploaded
[09:06] <apw> the rest of the bits of the landing landed already yesterday
[09:06] <ogra_> apw, which AP tests did you run ? do you have a test matrix or something, did all tests pass ?
[09:07] <apw> ogra_, not me
[09:07] <apw> ogra_, i waas more pointing out the process is opaque and confusing to those of us using it
[09:07] <ogra_> the ychanges touch click package behavior, apps might misbehave
[09:08] <apw> they are presumably stuck in -proposed anyhow by your britney block
[09:08] <ogra_> they just went into the archive
[09:08] <ogra_> there is no britney lock for universe packages
[09:08] <cjwatson> apw: It would if the touch landing team bothered to use the facilities I'd set up for them in any breadth
[09:08] <infinity> ogra_: Touch people have the power to block their packages.
[09:09] <ogra_> infinity, which doesnt help us, since android (which consumes the kernel) builds from proposed
[09:09] <infinity> ogra_: Anyhow, if you're deeply concerned, test away.   But these changes went into the master kernel yesterday, and the userspace side is all landed.
[09:10] <ogra_> infinity,  point is that per policy they would have gone through the spreadsheet stuff, which they didnt, without approval on that sheet nothing has to be uploaded
[09:10] <cjwatson> Point is that you lose.
[09:10] <cjwatson> I mean, it's inevitable with this process.
[09:10] <cjwatson> Or lack thereof.
[09:11] <ogra_> well we'll change the process to something more sane after release
[09:11] <cjwatson> Pre-upload gating while choosing not to use the technical means available is infeasible.
[09:11] <infinity> ogra_: I've uploaded a lot of stuff that's on touch images without the spreadsheet.  Why didn't you yell at me for glibc? :P
[09:12] <ogra_> cjwatson, the technical means available will be used after release, i want that as much as you ... but currently all uploads are held for the Mir switch on touch ... if we need to fix a bug on the android side for this we cant rebuild it without pulling in the kernels now
[09:13] <ogra_> infinity, i'm not yelling
[09:13] <cjwatson> Well I don't know what you propose to do about it now.
[09:13] <cjwatson> (And I will say: the arm64 porting work is not going to stop for this.)
[09:13] <ogra_> nothing just pointing it out so it doesnt happen again
[09:13] <cjwatson> (I know that's not about the kernel, but it is about other uploads.)
[09:14] <infinity> ogra_: This was a change that was wanted.  The userspace side landed.  The kernel needed to.  The idea of gating things one upload per image is insane.  Full stop.
[09:14] <infinity> ogra_: But dropping process arguments, the kernels are in.  Oh well.
[09:15] <ogra_> infinity, discuss that with asac and lool  ... i'm just pointing out something so it doesnt happen again
[09:15] <xnox> ogra_: security uploads trumps anything.
[09:15] <cjwatson> It's likely to happen again.
[09:15] <infinity> And again, and again.
[09:15] <xnox> ogra_: and it was security upload.
[09:15] <cjwatson> doko_: Curious.  No dh_autotools-dev_{update,restore}config in libsigc++-2.0?
[09:15] <ogra_> xnox, ??
[09:16] <cjwatson> doko_: And no clean handling
[09:16] <ogra_> xnox, i'm talking about the fout touch kernels that were uploaded to saucy
[09:16] <ogra_> *four
[09:16] <xnox> ogra_: so do I.
[09:16] <doko_> cjwatson, clean handling is there
[09:16] <ogra_> and they were supposed to be held back
[09:16] <doko_> using the existing one
[09:16] <ogra_> until after Mir landed
[09:17] <cjwatson> doko_: Oh, right, generic code
[09:17] <doko_> cjwatson, didn't want to interfer with the manual autoreconf in this package
[09:17] <lool> cjwatson: Problem here is that the kernels get copied into android; so we couldn't upload android anymore as soon as the kernels were uploaded to proposed (hints dont help this case)
[09:17] <xnox> ogra_: have you seen the bug they are fixing together with the matching apparmor uploads? (ps it's 6 kernels, goldfish and normal as well)  see bug #1208988
[09:17] <ubot2`> Launchpad bug 1208988 in AppArmor "AppArmor no longer mediates access to path-based AF_UNIX socket files" [High,Triaged] https://launchpad.net/bugs/1208988
[09:17] <cjwatson> Also: if these were supposed to be held back, why did nobody tell the release team?
[09:17] <lool> so completely not related to hints
[09:17] <infinity> lool: Or, you could upload android and get the new kernels.  This is bad, why?
[09:17] <ogra_> xnox, no, and thats not what this is about ...
[09:17] <cjwatson> You can't not communicate about specific things that were supposed to be held back and then expect that to happen.
[09:17] <lool> infinity: I might have to upload android and not want the new kernels
[09:17] <cjwatson> Since pre-upload gating is infeasible.
[09:17] <lool> infinity: but I can't technically stop that
[09:18] <lool> and we had agreed to coordinate the uploads later today
[09:18] <lool> but well
[09:18] <lool> I guess there was a hiccup in this part
[09:18] <ogra_> cjwatson, i just did ... for the next time :)
[09:18] <infinity> lool: I understand that you might want that, I don't understand WHY you want that.  This apparmor change is, AFAIK, necessary.
[09:18] <lool> cjwatson: I didn't expect anything to be held back
[09:18] <infinity> lool: It's bizarre to slow yourself down by only testing one tiny thing at a time.
[09:18] <xnox> ogra_: lool: apparmor changes went in (security bug) and if kernels didn't go in, your userspace and containment would be borked. Taking one without the other, means borked images.
[09:19] <lool> infinity: it is, but there are other changes (ureadahead for instance) in the kernels, the toolchain changed, we need to test the kernels and we might have to land android to fix tests before we take new kernels
[09:19] <lool> xnox: No, we actually confirmed they could go in in this order
[09:19] <lool> xnox: and separately
[09:19] <xnox> ogra_: lool: and android package makes it's own sources where it downloads the kernels from, so you can easily change it to pull kernels from -release pocket if you wish to do so. And then hints would gate keep it.
[09:19] <lool> xnox: yeah, I can workaround this specific case
[09:19] <infinity> lool: Erm, the ureadahead commit already existed in 2/4 kernels.  You intentionally want them to behave differently?
[09:20] <infinity> lool: And that's literally the only change other than the apparmor stuff.
[09:20] <lool> infinity: and being rebuilt
[09:20] <xnox> ogra_: lool: but multiple times, i've been requested to pull from -proposed to speed up image respins with updates (e.g. hybris, initramfs-tool-ubuntu-touch, etc)
[09:20] <lool> it's not like toolchains broke kernels in the past  :-)
[09:20] <lool> xnox, infinity, cjwatson: I am personally fine with what just happened
[09:20] <lool> I would like us to use hints more next cycle
[09:20] <infinity> Then why are we talking about it?
[09:20] <lool> they wouldn't help in this case
[09:20] <xnox> lool: touch kernels are build with toolchain that doesn't change any more (4.6 and 4.7)
[09:20] <lool> infinity: exactly  :-)
[09:22] <apw> right the toolchain changes do not affect these kernels at all, because the kernle doens't work if you compile it with those; which of course is an epic recommendation for the compiler you are building the rest of the stuff with
[09:23] <xnox> apw: =)))))
[09:23] <lool> also, I think we actually copied the kernel binaries
[09:23] <lool> which got tested
[09:24] <lool> apw: do you know if cking tested on Mir too?
[09:24] <infinity> I did copy with binaries, yes.
[09:24] <cking> lool, I tested with Mir enabled on maguro + manta
[09:25] <lool> cking: awesome
[09:25] <lool> infinity: great
[09:27]  * seb128 scratches head
[09:27] <seb128> why did I receive an "[ubuntu/saucy] gtk+3.0 3.8.4-0ubuntu3 (Accepted)" email this night when that version as already in saucy for a while
[09:27] <seb128> e.g https://launchpad.net/ubuntu/+source/gtk+3.0/+publishinghistory
[09:28] <cjwatson> seb128: Probably arm64 port -> new copy
[09:29] <cjwatson> Known to produce somewhat confusing mails when proposed-migration copies the new binary into the release pocket
[09:30] <xnox> cjwatson: maybe it's useful to send an email to ubuntu-devel about the emails? cause pretty much every uploader of everything that gets build on the new port will receive these confusing emails?
[09:31] <cjwatson> Actually no that's not true
[09:31] <cjwatson> The bulk of builds are happening in the release pocket (because reasons)
[09:31] <cjwatson> The only cases where you get confusing mails are uploads to -proposed after the port was initialised
[09:31]  * xnox has been getting a lot of emails already and FTBFS emails as well, wrt arm64.
[09:32] <cjwatson> Yeah, I realise that but that's tied up with details of hardware and I'm not sure what I can say publicly on that
[09:32] <lool> did you just say arm64?
[09:33] <cjwatson> I don't want to accidentally slag off a partner on a public mailing list. :-P
[09:33] <xnox> ok.
[09:33] <seb128> cjwatson, ok, thanks
[09:33] <cjwatson> (And hopefully the major cause of odd build failures will be fixed soonish ...)
[09:34] <cjwatson> lool: Yeah. :-)
[11:27] <lool> hud in unapproved has notably a workaround for when upstart mis-sets the dbus env vars in user sessions (this is apparently an upstart bug with set-env -g that we're still looking into); hud crashing is causing lots of test failure noise on touch, so greatly appreciated if we can land this  :-)
[11:27] <lool> there's a complex hud change coming up in the next hours/days to address deeper problems with it, but this one should help quite a bit already
[11:34] <Laney> Is a binary-only promotion still OK to do?
[11:34] <cjwatson> Should be
[11:34] <Laney> I want to make sessioninstaller dep on python-commandnotfound for bug #1102434
[11:34] <ubot2`> Launchpad bug 1102434 in gnome-control-center (Ubuntu) ""System settings -> Colour", fails due to missing "gnome-color-manager" package." [Low,Triaged] https://launchpad.net/bugs/1102434
[11:34] <Laney> ta
[11:34] <seb128> Laney, did you get the apturl fix tested/uploaded?
[11:34] <cjwatson> No Python 3? :-(
[11:36] <Laney> seb128: yeah
[11:36] <seb128> Laney, great ;-)
[11:36] <Laney> cjwatson: apparently not
[12:10] <apw> the linux and linux-signed uploads are to fix the arm64 linux-libc-dev (and other cross environments) builds
[12:13] <Laney> lool: where is the workaround?
[12:20] <xnox> Laney: in user-session's init hud.conf.in
[12:20] <Laney> xnox: Maybe I have the wrong diff
[12:21] <lool> Laney: the hud thing?
[12:21] <lool> Laney: in unapproved
[12:21] <Laney> I don't believe that change is in the upload
[12:22] <xnox> lool: Laney: well, we want http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.13.10/revision/326 which doesn't seem to be included in the unapproved upload.
[12:22] <xnox> (sync)
[12:22] <lool> Laney: checking
[12:22] <Laney> queue -Q unapproved -s saucy-proposed fetch hud
[12:22] <lool> Laney: you're right, it's not there
[12:22] <Laney> :-)
[12:22] <Laney> want to re-upload?
[12:23] <lool> Laney: yes
[12:23]  * Laney rejects
[12:23] <lool> need to figure out by cu2d didn't pick up though
[12:23] <lool> Laney: thanks
[12:35] <jdstrand> xnox: fyi, regarding borked images because userspace was updated but the kernels weren't-- that actually wasn't the case this time. the userspace could go in before or at the same time. it was just the kernels couldn't go in before
[12:36] <jdstrand> ah, I see someone mentioned that already
[12:37] <xnox> jdstrand: right the argument was that whilst apparmor can have block and not migrate to release pocket, android package is built with pulling kernels from -proposed (avoiding all blocks)
[12:38] <xnox> jdstrand: thus when everything is in -proposed, one had to take apparmor or otherwise be stuck with updated kernel & out of date apparmor.
[12:39] <jdstrand> sure. I am not going to participate in that conversation except to say that while I understand the desire and utility to gate the touch images, the process needs improvement and I'm glad that it is on the agenda for the next sprint
[12:39] <ogra_> xnox, that hud fix will not have your filtering i guess ... can we have that too ?
[12:39] <xnox> jdstrand: ack.
[12:39] <xnox> ogra_: upstart upload?
[12:40] <ogra_> xnox, for the dbus bridge filtering
[12:40] <ogra_> wasnt that upstart ?
[12:40] <xnox> ogra_: there was no dbus bridge filtering, i had a patch for upstart-udev-bridge to drop that one event and not generate any upstart events for it. is that what you mean?
[12:41]  * ogra_ checks the bug again
[12:42] <ogra_> xnox, oh, righ t
[12:42] <ogra_> thats what i mean
[12:44] <xnox> ogra_: ok. jodh doesn't want it upstream, but it can be uploaded into the ubuntu package.
[12:45] <ogra_> i think that would make sense
[12:45] <ogra_> (so would having the udev side fixed too i guess)
[12:46] <xnox> ogra_: it is unknown if mir needs the udev event or not.
[12:46] <xnox> ogra_: as far as I understood yesterday's discussions.
[12:46] <xnox> ogra_: but i guess that can be tested.
[12:46] <ogra_> yeah :)
[12:47] <xnox> ogra_: since kernel was changed to emit them....
[12:47] <ogra_> well, it is only emitted on maguro
[12:47] <ogra_> mako runs without it
[12:47] <ogra_> so i dont think we need it outside of the kernel
[12:47] <xnox> ogra_: yes, but propbably maguro's binary blobs want it.
[12:47] <ogra_> right
[13:04] <lool> Laney: ^
[13:05] <xnox> ogra_: if you want about upstart upload, please make it go through all the right processes.
[13:05] <xnox> ogra_: as you wish =)
[13:10] <zul> can i get a release team meber to ack https://bugs.launchpad.net/ubuntu/+source/python-cinderclient/+bug/1236901
[13:10] <ubot2`> Launchpad bug 1236901 in python-cinderclient (Ubuntu) "FFE for python-cinderclient 1.0.6" [High,New]
[13:33] <lool> Laney: Still around for the hud thing?  :-)
[13:35] <Laney> lool: back now, was lunching
[13:46] <Laney> that workaround :(
[13:49] <ogra_> Laney, well, look at the original start process of thge HUD
[13:49] <ogra_> Laney, it fits well :P
[13:49] <Laney> I like my eyes unbled :P
[13:50] <seb128> Laney, did you accept it?
[13:50] <Laney> ya
[13:50] <seb128> that seems buggy
[13:50] <seb128> http://launchpadlibrarian.net/153097115/hud_13.10.1%2B13.10.20131002.1-0ubuntu1_13.10.1%2B13.10.20131009-0ubuntu1.diff.gz
[13:50] <ogra_> (a dbus service, that calls a shellscript (with -hack- in its name actually) to trigger upstart to start an upsart job
[13:50] <ogra_> )
[13:50] <seb128> what is that apport hack
[13:50] <seb128> it's not even documented in the changelog
[13:50] <seb128> the printf line
[13:51] <seb128> (dropping the author as well seems weird)
[13:51] <Laney> I divined that they want to report when this situation happens
[13:52] <Laney> "and reporting a bug"
[13:52] <ogra_> looks like debug logging
[13:52] <seb128> that should be documented in the changelog...
[13:52] <seb128> shrug
[13:52] <ogra_> well, pete-woods is in -touch
[13:53] <seb128> it's coming from ted
[13:53] <seb128> http://launchpadlibrarian.net/153097115/hud_13.10.1%2B13.10.20131002.1-0ubuntu1_13.10.1%2B13.10.20131009-0ubuntu1.diff.gz
[13:53] <ogra_> i think they cross review their MPS
[13:53] <seb128> oh well, hacks on hacks
[13:53] <ogra_> *MPs
[13:53]  * seb128 uninstall huds
[13:53] <ogra_> yeah
[13:54] <Laney> I thought about arguing that they should be using normal dbus activation instead of this weird stuff
[13:55] <Laney> but then I decided to stay away from the battlefield
[13:56] <ogra_> http://paste.ubuntu.com/6213176/
[13:56] <ogra_> thats the current hud startup process
[13:56] <ogra_> so the patch fits in well :P
[13:57] <ogra_> its all about keeping the style right :)
[14:01] <seb128> hehe
[14:07] <xnox> ogra_: well at least i patched it to use "sh" instead of "bash" =/
[14:07] <ogra_> heh yeah
[14:07] <ogra_> that will buy us precious bootspeed
[14:07] <ogra_> every nanosecond counts
[14:08]  * ogra_ would like ot get back under 30sec
[14:22] <jodh> ogra_, jibel: could you try https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1235649/comments/44 ?
[14:22] <ubot2`> Launchpad bug 1235649 in upstart (Ubuntu Saucy) "uevent spam causes session upstart to consume massive amounts of memory on Ubuntu Touch" [Critical,Confirmed]
[14:22] <ogra_> jodh, yes (see #ubuntu-touch) will do soon
[14:22] <jodh> ogra_: thanks
[14:23] <ogra_> jodh, i fear it wont help on maguro with the uevent spam though
[14:23] <jodh> ogra_: right. There are a few problems going on here :)
[14:23] <ogra_> yeah
[14:23] <ogra_> well xnox fix works pretty well
[14:24] <ogra_> apart from the fact that udevd consumes a bit more CPU afterwards
[14:24] <jibel> jodh, what do I need to do? patch Panel.qml and Shell.qml and verify if I can reproduce?
[14:25] <ogra_> jibel, yeah, see if the session init ram consumption raises still ... on mako
[14:28] <jibel> ogra_, okay, doing that now
[14:29] <Laney> Probably → #-touch :-)
[14:30] <Laney> stgraber: queuebot went away
[14:30] <ogra_> having lunch too :)
[14:34] <doko> please could somebody review python3.3 and openjdk-7 ? just needed for the aarch64 bootstrap
[14:37] <cjwatson> python3.3 accepted, waiting for diff for openjdk-7
[14:38] <cjwatson> oh, it's there
[14:38] <cjwatson> really must apiify diffs
[14:57]  * ogra_ hugs xnox
[14:57] <ogra_> YAY !!!!
[14:59] <xnox> ogra_: can I have MIR on grouper please? =)
[14:59] <ogra_> xnox, so be it ...
[14:59] <ogra_> xnox, upgrade to 89
[14:59] <ogra_> ;)
[14:59] <xnox> ogra_: i do system image, is 89 published in devel-proposed channel? or which channel do I want?
[15:00] <ogra_> saucy-proposed, yeah
[15:00] <ogra_> (or devel-proposed)
[15:14] <rsalveti> ricmm_: ^ once it gets approved
[15:16] <ricmm_> rsalveti: great
[16:05] <lool> (would be nice to get the libhybris upload reviewed; just adds a header)
[16:11] <stgraber> queued cleaned up
[16:13] <seb128> stgraber, thanks!
[16:13] <Laney> excellent
[16:14] <Laney> I loaded the ubuntukylin-default-settings diff and had to go off to mop up my tears
[16:14] <stgraber> ;)
[16:15] <Laney> not the change itself, but the context in the diff
[16:15] <Laney> cp /some/logo /the/ubuntu/logo/in/g-c-c
[16:15]  * seb128 pokes Laney in the eyes
[16:15] <seb128> or maybe not
[16:15] <Laney> then I get to have it read to me by a screen reader
[16:16] <Laney> that seems worse :(
[16:16] <seb128> Laney, yeah, sorry about that :/
[16:16] <stgraber> right, I accepted the change because it wasn't making things any worse, actually it made things slightly better, but the context looked pretty scary indeed
[16:16] <Laney> indeed
[16:16] <seb128> but yeah, the kylin setting has quite some hacks
[16:16] <ypwong> Hi all, at what time will saucy be frozen?
[16:25] <happyaron> and this wallpaper package needs approval, for ubiquity to recognize the new wallpaper
[16:25] <happyaron> I think cjwatson did not modified the settings in ubiquity so a link must be created for it here.
[16:26] <ypwong> well, I meant about what time the final freeze will be in effect
[16:26] <happyaron> Laney: well, yes, I tried to revert as many changes as possible in previous upload, if you looked at that version, you'll be scared even more...
[16:27] <Laney> thanks for your efforts :-)
[16:27] <Laney> ypwong: usually 2100 UTC
[16:27] <ypwong> Laney, thx
[16:27] <happyaron> oh, gosh, I need to upload another version of -default-settings, it ftbfs...
[16:28] <ypwong> happyaron, the patch in the bug doesn't work?
[16:29] <happyaron> it works, but removing the unity.mo make it fail
[16:29] <happyaron> sorry everyone I'm in a big rush cuz I'll have no network in 2min...
[17:21] <dobey> is there any way to tell who accepted a particular upload to saucy?
[17:41] <slangasek> dobey: no
[17:41] <slangasek> this causes great consternation for the team
[17:42] <dobey> :(
[17:43] <dobey> slangasek: can i convince you to accept the 3 uploads of mine that you rejected last night?
[17:44] <slangasek> dobey: well, you can try, but I don't see why I would be persuaded that we should do no-change rebuilds of packages just to get 13.10 as the version number
[17:45] <dobey> slangasek: because we want to have versioning consistency across the ubuntuone projects/packages. we have been doing this for several cycles now.
[17:45] <slangasek> with freeze exceptions?
[17:46] <dobey> freeze exceptions?
[17:46] <slangasek> we're in post-beta freeze
[17:46] <slangasek> and the RC is tomorrow
[17:46] <slangasek> and package version number consistency is very low on my list of priorities
[17:48] <dobey> well, the other 6 packages i uploaded were accepted without problem, with only a version number bump.
[18:01] <stgraber> haha, looks like we've got a conflict here :)
[18:01] <stgraber> I'll reject them both and re-upload one with both changes
[18:05] <slangasek> dobey: right, I guess that's why you want to know who accepted a particular package?  But I presume those other packages were uploaded earlier
[18:05] <slangasek> I guess if you can figure out who did the other accepts and talk them into un-rejected, I won't stand in your way
[18:07] <stgraber> those were accepted by me as they weren't really causing any harm and there weren't too many of them, I then changed my mind after mentioning the problem to dobey so I'm not going to accept any more of those
[18:08] <stgraber> (I wasn't the one who rejected the rest though)
[18:08] <dobey> no slangasek rejected them
[18:09]  * slangasek nods
[18:10] <dobey> i don't see why it is a "problem"
[18:11] <stgraber> you're wasting review time, buildd resources and libraring space for nothing
[18:14] <dobey> i didn't even know they had to be reviewed until after i uploaded stuff and was getting "waiting for review" messages. final freeze isn't until tomorrow
[18:14] <stgraber> we've been freezing the archive between the final beta and release for the past 2-3 cycles now
[18:14] <dobey> and i wouldn't really call a very short build time on an emtpy build queue a "waste of resources"
[18:24] <stgraber> I uploaded that lxc so would be nice if someone else could review it in the queue
[18:41] <jdstrand> can someone look at apparmor-easyprof-ubuntu real quick? it is required for (at least) grouper with mir
[18:47] <shadeslayer> could someone also approve user-manager ( has a bug fix that allows setting the user avatar ) and soprano ( fixes a bug when the db gets corrupted and causes problems in nepomuk )
[18:48] <shadeslayer> ScottK doesn't seem to be around
[18:50] <stgraber> shadeslayer: looks like you're adding/changing strings in there...
[18:50] <shadeslayer> stgraber: which package?
[18:50] <doko> whoever did accept exempi, thanks and please accept exiv2 too
[18:51] <stgraber> shadeslayer: user-manager
[18:53] <shadeslayer> stgraber: okay
[18:56] <shadeslayer> stgraber: can we get it in either way? because apparently Riddell asked for some UI modifications which resulted in string changes
[18:56] <shadeslayer> stgraber: we just didn't upload the updated git snapshot
[18:57] <stgraber> shadeslayer: if you get a UIFe, then sure (you usually need whoever works on your documentation and translations to ack the change for that)
[18:57] <shadeslayer> okay
[19:02] <slangasek> stgraber: lxc, there are no linked bugs for either of the changes; verbose++ please?
[19:02] <slangasek> stgraber: 0011-ubuntu-cloud-prep-hook-fix-debug-helper-to-not-inapp.patch at least is self-explanatory from the shell, but the apparmor change I feel I need context for
[19:04] <stgraber> slangasek: bug 1237543 is for that cherry-picked patch (the bug was filed after hallyn fixed it upstream and in the package, that's why we don't have a LP:#xxxxx in there)
[19:04] <ubot2> Launchpad bug 1237543 in lxc (Ubuntu) "lxc-create (or clone) of cloud template with '--cloud' exits failure" [Low,In progress] https://launchpad.net/bugs/1237543
[19:04] <stgraber> slangasek: the other one was reported by vila on IRC. Basically the new apparmor blocks dbus by default.
[19:04] <stgraber> slangasek: so a standard saucy container would be unable to use dbus with our current profile.
[19:05] <zul> can someone look at python-cinderclient FFE please (#1236901)
[19:05] <stgraber> slangasek: fixing that needs adding "dbus," to our default profile, but we can't just do it unconditionaly since the same source package is backported to all releases down to precise
[19:05] <stgraber> slangasek: and any release < saucy will fail to parse an apparmor profile containing "dbus"
[19:07] <slangasek> stgraber: ok.  So I'm generally pretty opposed to applying per-version hacks in debian/rules instead of just expressing those differences in different per-release VCS branches in the natural way.  Is there a reason that couldn't be done here, even though it's a backport?
[19:09] <stgraber> slangasek: I'd rather avoid having to update 8 packaging branches and having to change all our automatic build scripts to know which branch to pick up when pushing new builds...
[19:10] <slangasek> sure; whereas I'd rather avoid having debian/rules doing magic like applying dpkg --compare-versions to lsb_release ;)
[19:10] <stgraber> (we support precise, quantal, raring, saucy in both upstream-daily and ubuntu form, so I alrady have to sync between two branches every time we change something, having to maintain per-series would be a bit of a pain)
[19:11] <slangasek> in practice this delta would only require two extra branches (saucy vs. pre-saucy) if you wanted to do it that way
[19:11] <slangasek> and effectively it would be safe to auto-merge
[19:11] <slangasek> (except when it wasn't safe, which would probably be a clue to look at it :)
[19:12] <stgraber> yeah but that'd still prevent us from using requestbackport since the automated backporting tools just take from a release and automatically spit out an updated source package ready for upload
[19:12] <slangasek> there were provisions for sourceful backports, I thought.  requestbackport doesn't handle that workflow?
[19:13] <stgraber> requestbackport takes a source series, a destination series and a source package
[19:13] <stgraber> *source package name
[19:13] <slangasek> yah
[19:14] <slangasek> so I'll allow this, because my objections don't really have anything to do with the release freeze
[19:14] <slangasek> but at minimum, I would recommend that you invert the debian/rules handling, to make the backports the special case so that 'dbus' is part of the actual source
[19:14] <slangasek> (not for saucy, but for the future)
[19:15] <stgraber> slangasek: well, my plan for the future is to move the apparmor profiles upstream and have it be a .in file
[19:16] <slangasek> ok
[19:16] <stgraber> since we already detect most distros in our configure.ac and I believe also export the distro version as a variable
[19:17] <slangasek> anyway, the point I want to express is that I don't think it's a good idea for part of the "source" of the package to be hidden in debian/rules
[19:17] <slangasek> and now I'll get off my soapbox :)
[19:19] <stgraber> slangasek: oh I agree and I was pretty annoyed by it when I got the report today as none of the apparmor abstractions would give me something that worked on all the releases I care about... so I basically ended up with 3 choices 1) hackish debian/rules 2) separate source package for backports 3) only support session+system bus and block accessibilty bus
[19:20] <stgraber> 2) meant quite a bit of time to invest in the coming years, 3) meant breaking the desktop QA test environment at least and 1) was just ugly, so ugly it ended up being :)
[19:21] <jjohansen> stgraber: you supposed to pitch a fit at us and tell us how much this sucks so we are motivated to fix it
[19:21] <jjohansen> stgraber: truth is this is bad, and something we need to fix, but I don't have a good solution atm
[19:22] <stgraber> jjohansen: oh, I certainly wanted to blame you ;) but short of having the parser accept any invalid keyword, I'm not sure what you could have done differently.
[19:24] <stgraber> block by default is always how apparmor worked, so that makes sense and the dbus keyword was only introduced this cycle, so any older parser will fail... I guess if we had a all-dbus abstraction around since precise that would have been mapped to "dbus," in saucy, then I could have used that, but you'd have had to be pretty good at predicting the future a couple years ago to do that ;)
[19:24]  * mdeslaur hands jjohansen a crystal ball
[19:25] <stgraber> well, actually there was a 4th alternative in my list above, backport apparmor to all releases where we backport lxc, but I figured this would probably cause even more problems ;)
[19:25] <jjohansen> stgraber: well 2 things
[19:25] <jjohansen> 1. the parser should be setting some conditional variables, then at the very least you could have wrapped the rule in if $COND_X in the policy  (this should have been done a long time ago)
[19:25] <jjohansen> 2. there are plans to extent the parser so you can tell it how to parse new rules as part of policy, and a little rule to ignore dbus could have been done that way.
[19:25] <jjohansen> Of course either of those mean backporting the changes
[19:25] <jjohansen> mdeslaur: well its a problem we have known about for years
[19:26] <jjohansen> stgraber: yeah, backports are a pita
[19:26] <mdeslaur> jjohansen: yeah
[19:26] <stgraber> jjohansen: ah, those two sound pretty nice, can we have that for 14.04? :)
[19:26] <jdstrand> I'll answer that with 'unlikely'
[19:26] <jjohansen> hehe
[19:26] <stgraber> ok :)
[19:27] <jdstrand> stgraber: we have a pretty big pile of stuff for 14.04 which includes lxc
[19:27] <jjohansen> stgraber: well if you can find us some resources to work on it ... :)
[19:27] <stgraber> anyway, on my personal apparmor priority list, stacking is way more important than that stuff for 14.04
[19:27] <jdstrand> stgraber: *perhaps* 14.10 would get something like that, we'll see
[19:27] <jjohansen> stgraber: you would say that :)
[19:28] <jdstrand> stgraber: yeah-- stacking is coming and planned. I know we've been saying that for a while, but a lot of work was done for that already and we hope to deliver it in 14.04
[19:28] <jdstrand> at least something quite a bit better than what we have now
[19:37] <slangasek> stgraber: done differently> they could also have backported support for the 'dbus' keyword to older releases
[19:37] <slangasek> even if it was a no-op
[19:48] <stgraber> oh, apparently I'm TIL on irssi, I didn't know that (just got a build failure for arm64)
[19:52] <infinity> Yeah, I've been discovering all sorts of things I forgot I was TIL on. :)
[19:52] <infinity> doko: Erk, why are up updating config.{sub,guess} in patches?
[19:53] <infinity> doko: That's just a recipe for failure next time.
[19:54] <infinity> doko: Something like http://launchpadlibrarian.net/152821294/bind9_1%3A9.9.3.dfsg.P2-4_1%3A9.9.3.dfsg.P2-4ubuntu1.diff.gz is much saner, and doesn't lead to a painful-to-rebase patch.
[19:54] <stgraber> I saw a few done with dh-autoreconf though I didn't check if there was a pattern there (!doko => dh-autoreconf, doko => massive ugly patch)
[19:54] <doko> infinity, well, for two or three packages, I tried to introduce autoreconf, and it did fail
[19:54] <slangasek> infinity, stgraber: you're both slackers, you should be more like me and make sure everything you touch gets in sync with Debian so that you can stop being TIL ;)
[19:54] <doko> so I assume at this stage the patch is the safest way not interfer with a build system
[19:54] <infinity> doko: Hence my pointing at the above that uses autotools-dev, not autoreconf.
[19:55] <infinity> doko: (--with autotools-dev, if it's dh(1), or as above, if it's old-style)
[19:55] <stgraber> slangasek: I'm TIL because I fixed a utf-8 related bug a while back, that got merged upstream so I've been doing standard Debian merges since as we patch irssi to suggest irc.ubuntu.com apparently...
[19:55] <slangasek> stgraber: right :)
[19:56] <doko> infinity, and this does work when files are in subdirs?
[19:56] <infinity> doko: Yup, it finds all copies.
[19:56] <doko> and figures out the right -I m4 flags?
[19:56] <doko> I give it a try for the next package
[19:56] <infinity> Err, what now?  It literally just replaces config.sub and config.guess.
[19:56] <slangasek> stgraber: also, is 91_ssl_proxy.patch still in our delta? :)
[19:57] <slangasek> ah, no apparently that's upstreamed in Debian \o/
[19:57] <roaksoax> All. So we are looking to upload a new maas release that contains various fixes and improvements to the previous FFe upload we made. We have discovered a couple of regressions that we are currently working on fixing. So we are looking into doing the upload tonight if things go as expected
[19:57] <infinity> doko: It's not a reconf (autoreconf is for that), it just updates config.{sub,guess}, but reliably, and at build-time.
[19:57] <doko> ok, then let me redo irssi
[19:57] <roaksoax> for which we might require delaying the release candidate remastering
[19:58] <stgraber> slangasek: not according to my merge changelog at least
[19:58] <slangasek> stgraber: yeah, so evidently my patch is not part of the delta, at least :-)
[20:24] <doko> infinity, irssi & jigit
[20:24] <TheDrums> tyhicks: Thanks for taking a look at the dbus bug, and for the quick fix.
[20:36] <cjwatson> stgraber: Generally I use dh_autoreconf when the existing build system looks fairly recent and I've test-built to make sure it's safe and does the job, and dh_autotools-dev_* otherwise
[20:37] <cjwatson> stgraber: And I brutalise all my own packages until dh_autoreconf is safe and does the job :-)
[20:38] <infinity> cjwatson: "... and does the job" being a key point, as autoreconf seems to miss on updating config.* in some cases.
[20:38] <cjwatson> infinity: Yes.  Fortunately I understand when and know how to deal with it.
[20:38] <cjwatson> infinity: It's not a problem for packages that use automake as well as autoconf.
[20:38] <infinity> Would be nice if it just used the same logic as dh_autotools-dev with the find-and-replace-all-copies thing.
[20:39] <cjwatson> Yeah, it wouldn't hurt; though I sort of feel autoreconf itself should do that
[20:39] <infinity> (If autogen/etc then goes and replaces again, it's not a big deal, as you just restore backups in clean, and life is good)
[20:39] <cjwatson> Feels wrong for a high-level wrapper to be doing it
[20:39] <infinity> Sure, auto* should get it right, but it doesn't always seem to.  The higher level wrapper papering over that wouldn't be bad, IMO.
[20:41] <cjwatson> The reason it currently gets it wrong is that it basically just calls a sequence of lower-level tools, and the ones that update config.{guess,sub} are automake and libtoolize.
[20:41] <slangasek> if someone would do me the honor of reviewing glm in the queue, that's a fix needed to unbreak cross-installability of unity8 build-deps
[20:41] <cjwatson> autoconf on its own doesn't.
[20:44] <infinity> cjwatson: Right.  Well, contrary to (documented) protests to the contrary, mixing dh_autoreconf and dh_autotools-dev works, if you get the sequence order right, but it's icky.  And would be nice if it was smart enough to just integrate one into the other to always get it right implicitly.
[20:45] <cjwatson> I still prefer my recipe for it, since I know exactly how it interacts :-)
[20:45] <cjwatson> (Would be nice if it worked OOTB, sure)
[20:49] <stgraber> cjwatson: any known problem with autopkgtest?
[20:49] <cjwatson> stgraber: first I've heard of it, but I've been out for a few hours
[20:49] <stgraber> cjwatson: lxc was accepted over an hour ago, britney says it's waiting on autopkgtest but I don't see any test scheduled on Jenkins
[20:50] <stgraber> http://<IP_ADDRESS>:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-lxc/ shows ubuntu9 and no ubuntu10
[20:51] <cjwatson> The running one at the top is 10, I think
[20:51] <stgraber> the one that showed up 10s ago, yep, looks like it ;)
[20:51] <stgraber> guess I wasn't patient enough
[20:51] <cjwatson> Maybe the first request got lost for some reason, not sure
[20:52] <cjwatson> I think generally the next p-m cycle will re-request if that happens
[21:14] <slangasek> cjwatson: so bug #1208800 was an MIR for click, which was accepted by jdstrand; it seems that this is the only reason click (and various dependencies that are still being iterated) are in the 'supported' seed, which has caused a couple of those to be caught in the queue that shouldn't have been.  Can we just drop this from supported and put in it the touch seed where it belongs instead (for now)?
[21:14] <ubot2> Launchpad bug 1208800 in click (Ubuntu) "[MIR] click" [Undecided,Fix released] https://launchpad.net/bugs/1208800
[21:14] <slangasek> click isn't any more or less "supported" than the rest of the phone image, AFAICS
[21:14] <cjwatson> slangasek: It's in desktop because I expect people to install it there for development
[21:15] <cjwatson> or in supported, whatever
[21:15] <slangasek> but then wouldn't we want that pulled via the sdk package?
[21:15] <slangasek> which is also not seeded
[21:15] <cjwatson> well, I expect click to be used other than via the sdk
[21:15] <cjwatson> and indeed there's the problem that that's not seeded
[21:16] <cjwatson> can we just leave it as it is for now?  it's not all that big a problem
[21:16] <slangasek> my point is that the current seeding is adding friction where I think it shouldn't
[21:16] <cjwatson> we could make an exception for it in auto-accept rather than having to move it around in the archive
[21:16] <slangasek> because the apparmor stack is (was?) still being worked on
[21:16] <cjwatson> AIUI that's quite practical
[21:16] <slangasek> for click-and-all-its-transitive-deps
[21:16] <slangasek> ?
[21:16] <cjwatson> it doesn't have *that* many
[21:17] <cjwatson> half a dozen or so I think
[21:17] <slangasek> ok
[21:17] <slangasek> if you and stgraber can sort that out, then that's the thing I really care about
[21:18] <slangasek> it just seemed inconsistent to me to have it directly seeded
[21:18] <slangasek> so I thought that might've been the easier solution :)
[21:18] <cjwatson> it just seems like a retrograde step to move it back
[21:20] <slangasek> stgraber: could you please whitelist click and its dependencies (as indicated by cjwatson) for queue auto-accept?
[21:20] <cjwatson> aha, new is now occasionally involving five binaries :)
[21:20] <slangasek> whee
[21:24] <stgraber> slangasek: I added a whitelist and whitelisted click, click-apparmor and ubuntu-system-settings
[21:25] <jdstrand> stgraber: can you also whitelist apparmor-easyprof-ubuntu?
[21:25] <jdstrand> stgraber: python3-apparmor-click (from click-apparmor) pulls it in
[21:25] <stgraber> slangasek: I didn't whitelist any of their dependencies because it's not impossible that those may get seeded or put in the packageset for other reasons (if we noticed one that gets frequent update, I'm fine with individual whitelisting)
[21:25] <stgraber> jdstrand: ok
[21:26] <stgraber> done
[21:26] <jdstrand> thanks
[21:26] <cjwatson> stgraber: upstart-app-launch was the other one in my list
[21:26] <jdstrand> stgraber: you just whitelist sources or binaries, or both?
[21:27] <stgraber> jdstrand: source
[21:27] <cjwatson> stgraber: ubuntu-system-settings was only in touch to begin with, at least according to seeded-in-ubuntu
[21:27] <jdstrand> ok
[21:27] <slangasek> cjwatson: yeah, I think ubuntu-system-settings was the one you fixed the lubuntu supported seed for earlier
[21:27] <stgraber> cjwatson: ah, good, will unwhitelist it then. It used to get stuck in the queue because of lubuntu supported
[21:27] <cjwatson> slangasek: right
[21:27] <jdstrand> url-dispatcher may be another candidate
[21:27] <cjwatson> stgraber: yeah, that was an obscure seed bug
[21:27] <slangasek> stgraber: and yeah, upstart-app-launch was the other one I knew about - thanks
[21:27] <cjwatson> jdstrand: no, that's in Ubuntu daily-live images
[21:28] <cjwatson> I haven't checked why, but it's more deeply embedded than other things listed
[21:28] <slangasek> cjwatson: it's in universe?
[21:28] <stgraber> ok, updated. Any other I'll just add as I waive them through the queue during review
[21:28] <slangasek> I mean, I see the same thing from seeded-in-ubuntu, but I'm confused by what it shows
[21:28] <cjwatson> liburl-dispatcher1 | 0.1+13.10.20131003-0ubuntu1 |         saucy | amd64, armhf, i386, powerpc
[21:28] <cjwatson> liburl-dispatcher1-dev | 0.1+13.10.20131003-0ubuntu1 |         saucy | amd64, armhf, i386, powerpc
[21:28] <stgraber> so far the click apparmor stuff has been the one I had to let through the most I think
[21:28] <cjwatson> url-dispatcher | 0.1+13.10.20131003-0ubuntu1 |         saucy | source
[21:28] <cjwatson> url-dispatcher and url-dispatcher-tools binaries are in universe
[21:28] <slangasek> oh right, source v. binary
[21:29] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/rdepends/ALL/liburl-dispatcher1
[21:29] <slangasek> so no love for url-dispatcher
[21:29] <cjwatson> reverse depends: indicator-bluetooth reverse recommends: unity
[21:29] <slangasek> interesting
[21:29] <cjwatson> and indeed several other indicators
[21:30] <cjwatson> datetime, power, sound
[21:30] <slangasek> yes, we want to make sure there's a common framework for dispatching those urls from your bluetooth headset, so that attackers don't have to search too hard ;)
[21:31] <smoser> hey. i jus tuploaded a simplestreams simplestreams_0.1.0~bzr315-0ubuntu1.dsc . that replacews the bzr314 that i did earlier.
[21:31] <smoser> if someone could nak the 314 that'd be thank ful.
[21:31] <slangasek> done


 Well for me I would like to see our goal be increase the kubuntu user base and grow the active community
[18:41] <valorie> right, but how does more money do that?
[18:42] <valorie> I will give money but I want to know what we want to spend on
 I agree Valerie and I would like the council to talk about out how we can can build upon our community and get more people involved and most importantly keep them involved
 Let's take finance and fundraising off the table and and just try to answer the question what would it take to get more people engaged and for us to grow the community
[19:00] <valorie> sounds good to me
[19:01] <valorie> then if funds are needed the publicity for that grows out of our plans


[00:11] <ScottK> Upgraded my main laptop to Quantal.  All very smooth.
[09:41] <Quintasan> \o
[09:55] <Riddelll> morning Quintasan!
[09:58] <Quintasan> Hah
[09:58] <Quintasan> Almost noon here actually
[09:58] <Quintasan> I should have been up since 10:00 but well, $STUFF
[09:58]  * Quintasan won't mention he clicked snooze 10 times
[14:18] <BluesKaj> hey all
[14:19] <smartboyhw> Hi BluesKaj
[14:19] <BluesKaj> hi smartboyhw
[17:08] <ScottK> Riddelll: What do you think about Calligra 2.5.3 for quantal?
[17:08] <ScottK> BTW, you have an extra "l".
[17:10] <Riddelll> ScottK: not a priority for me to package but if someone wants to pick it up sure
[20:55] <ScottK> Do we have a fancy l10n script for Calligra?
[21:00] <Riddelll> ScottK: no I seem to remember I did it by hand and it was excessively faffy
[21:00] <ScottK> OK.
[21:01] <ScottK> It's < 30 languages, so not horrendous.
[21:01] <ScottK> I just heaved 2.5.3 at the ninjas PPA.  We'll see if it sticks.
[21:02] <Riddelll> ScottK: actually the most faffy thing is working out how to make it build right with multi-tars and no .orig tar
[21:02] <Riddelll> it should warn you if a language has appeared or disappeared when building
[21:02] <ScottK> Oh.  It's one multi-tar package?
[21:02] <ScottK> Those are always fun.
[21:07] <Riddell> kubotu: newversion networkmanagement <IP_ADDRESS>
[21:07] <kubotu> https://bugs.launchpad.net/bugs/1063422
[21:23] <Riddell> networkmanagement uploaded to ppa:kubuntu-ppa/experimental
[21:23] <Riddell> when I run it, it displays some ad-hoc networks that have long since disappeared so I'm a bit suspicious.
[21:24] <Riddell> konversation has to be rebuilt because it hasn't been uploaded since we stopped using language packs and has no translations
[21:24] <Riddell> I wonder if we have anything else in this position
[21:45] <yofel_> ScottK: there is a script for collecting the tars in the l10n package
[21:46] <yofel_> well, not collecting them, but at least to set the multi-tar source up
[22:57] <shadeslayer> Riddell: should I go ahead and order them stickers?
[23:03] <Quintasan> oh great
[23:03] <Quintasan> Beta 2 uninstallable here
[23:03] <Quintasan> nouveau whines: Failed to idle channel 1
[23:03] <Quintasan> and then PFIFO - playlist update failed
[23:04] <Quintasan> guess I'll try upgrading the livecd
[23:06] <Quintasan> and no solution yet
[23:08] <Quintasan> hmmm
[23:08] <Quintasan> seems like 3.5 kernel broke it
[23:09] <Quintasan> That doesn't sound so good, many sad pandas if it is not fixed before final release. It was marked Critical two or three days ago
[23:14] <shadeslayer> ohai Quintasan
[23:14] <shadeslayer> ssup
[23:38] <Quintasan> shadeslayer: Tried to install quantal
[23:38] <shadeslayer> heh ok
[23:39] <Quintasan> Failed horribly
[23:39] <Quintasan> LET'S BREAK EVERYTHING FROM NV0 chip
[23:39] <Quintasan> :P
[23:43] <shadeslayer> :)
[23:44] <shadeslayer> Quintasan: I found X to be too broken in Quantal which is why I came back to Precise
[23:44] <shadeslayer> it broke for me when they introduced Xorg 1.13
[23:44] <shadeslayer> constant memory leaks and what not
[23:48] <shadeslayer> hm, spaceX launch in another 42 mins


[00:47] <mustafa> Hello
[00:47] <mustafa> What's the minimum requirement for lubuntu ?
[00:48] <holstein> mustafa: its light... id say try it
[00:49] <holstein> otherwise, you'll probably want puppy
[00:51] <Unit193> mustafa: What do you have?
[00:58] <mustafa> Unit193: it's a friend
[00:58] <mustafa> she has a intel celeron
[00:59] <mustafa> 1.07 GHZ
[00:59] <Unit193> You're installing Linux onto a friend? Might have better convos
[00:59] <mustafa> and 495 mo
[00:59] <mustafa> ram
[00:59] <wxl> NO PUPPY
[01:00] <Unit193> That's better than the one I use it on
[01:00] <mustafa> yes I will install onto my friend
[01:00] <wxl> yeah you'll do find
[01:00] <wxl> hahaha
[01:00] <mustafa> but she said that someone tried before and didn't be successfull
[01:00] <mustafa> and that someone said it's not compatible with linux
[01:01] <wxl> well yeah, usually linux is for computers, not people
[01:01] <wxl> :)
[01:01] <mustafa> but I think this person is noob
[01:01] <mustafa> and there's no reason that her computer is not compatible with linux
[01:02] <Unit193> Some crappy $randomnamebrand aren't as easy
[01:02] <wxl> mustafa: https://wiki.ubuntu.com/Lubuntu#System_requirements
[01:03] <wxl> specifically calls out a celeron with a quarter of the ram
[01:03] <wxl> you'll do fine
[01:03] <wxl> put it on her!
[01:03]  * Unit193 500MHz celeron; 512M
[01:05] <wxl> Unit193: ah so you are a bot. an embedded system, no less! ;)
[01:06] <Unit193> That's a full desktop...
[01:06] <wxl> headless server you mean?
[01:13] <mustafa> the iso of lubuntu makes live cd too ?
[01:13] <mustafa> like the iso of ubuntu ?
[01:14] <Unit193> As long as you pickup the desktop one
[01:21] <mustafa> thanks for your helps
[01:21] <mustafa> good night
[09:45] <smile> hi :D
[09:45] <pAt__> Hi (:
[09:46] <MrChrisDruif> Aloha pAt__
[09:46] <smile> MrChrisDruif: hi! :D
[09:51] <MrChrisDruif> pAt__; have got an issue or question?
[09:52] <pAt__> No thanks. I am just hanging around here, loving lubuntu ;)
[09:53] <smile4ever> pAt__: yeah! :D
[09:53] <smile4ever> #lubuntu-offtopic is also nice :)
[09:53] <pAt__> Not to help others ;)
[09:53] <pAt__> But thanks. Didnt know this channel
[09:55] <smile4ever> :)
[10:51] <MrChrisDruif> !alot
[13:23] <ubu> lukasz is here??
[15:59] <AmberJ> I remember using "Ubuntu recovery mode" from GRUB to change passwd for a user account...
[15:59] <AmberJ> I tried it on lubuntu 11.10 but it does not works
[16:06] <AmberJ> wxl, help! ;)
[16:07] <Ahmuck> i think i'm on 10.10.  how do i get to 11.10?
[16:07] <Ahmuck> er, 11.04
[16:07] <AmberJ> Ahmuck, sudo apt-get dist-upgrade
[16:08] <Ahmuck> how then do i check for dist
[16:08] <AmberJ> Or, use "Update manager"
[16:08] <AmberJ> I guess it only supports upgrading to 11.04
[16:15] <wxl> Ahmuck: you get 'er fixed?
[16:18] <wxl> Ahmuck: well, try lsb_release -rc
[16:31] <Ahmuck> 10.04
[16:31] <Ahmuck> wxl: nope :(
[16:32] <AmberJ> Ok...got my problem solved
[16:33] <AmberJ>  / was mounted as "read only"
[16:33] <AmberJ> I used "remount" (as read/write) in recovery menu...and then "password user". This did the trick.
[16:35] <wxl> AmberJ: you're doing recovery?
[16:35] <AmberJ> Done already :D
[16:35] <wxl> Ahmuck: if you look at your repos, do you have oneiric repos???
[16:36] <wxl> AmberJ: i struggled with that at first, too. it's not obvious.
[16:36] <wxl> AmberJ: networking's purdy easy tho :D
[16:36] <AmberJ> My mentor needed to change password on his ubuntu install...He forgot it ;)
[16:38] <AmberJ> heh yea...
[16:40] <Ahmuck> k, the upgrade doesn't do this automagically
[16:40] <wxl> Ahmuck: typically it's not an issue. i don't know what the deal is with what you got there.
[16:41] <wxl> Ahmuck: honestly, it usually asks you if you want the next version. that's the default behavior. unless you've changed it. you can always run a software update check, assuming you have it set up to check for new versions.
[16:41] <Ahmuck> Failed to fetch http://archive.canonical.com/ubuntu/dists/oneric/partner/source/Sources.gz  404  Not Found
[16:41] <Ahmuck> Some index files failed to download, they have been ignored, or old ones used instead.
[16:42] <wxl> try replacing canonical with ubuntu, Ahmuck, just for grins
[16:42] <Ahmuck> ah, lts only selected
[16:43] <Ahmuck> so it's not looking for upgrade if it's not a LTS release
[16:44] <wxl> THAT will be a problem
[16:45] <wxl> ok, talk amongst yourselves. i gotta get to work :D
[16:45] <Ahmuck> k, that's complete, however no upgrade
[16:45] <Ahmuck> thx wxl
[16:48] <AmberJ> Ahmuck, so, got it resolved?
[16:49] <AmberJ> did you uncheck "lts only"?
[16:49] <AmberJ> And, did you do "sudo apt-get update" after it?
[16:50] <Ahmuck> download the iso
[16:51] <Ahmuck> ing
[16:52] <AmberJ> heh
[16:53] <AmberJ> hey smile
[16:53] <smile> hi AmberJ :)
[16:53] <AmberJ> Care to tell how to record videos using download helper?
[16:54] <smile> I don't know it :( but I think video downloadhelper site has info about it :)
[16:54] <smile> AmberJ: i'm not using it daily, so (the record feature) :)
[16:54] <AmberJ> It has info for a:
[16:54] <AmberJ> 1. Paid
[16:54] <AmberJ> 2. Windows
[16:55] <AmberJ> program...how dare you recommend windows, smile? ;)
[16:56] <smile> AmberJ: i don't :o
[16:56] <smile> AmberJ: Since version 4.9, Video DownloadHelper has introduced an additional video capture method through direct grabbing on the screen. This feature relies on CamStudio when running on the Windows platform and on RecordMyDesktop when on Linux, Video DownloadHelper providing a one-click capture start capability, without the need to manually specify the region of the screen to be captured.
[16:58] <AmberJ> oopsie ;)
[16:59] <AmberJ> I thought you meant this: http://www.downloadhelper.net/applian-replay-media-catcher.php
[16:59] <smile> AmberJ: try to install recordmydesktop :) & find the button in video downloadhelper
[16:59] <AmberJ> Thanks smile :)
[16:59] <smile> AmberJ: be sure to check preferences window of video downloadhelper. There is info about it. :)
[17:05] <smile> you're welcome
[17:21] <Ahmuck> is there a way to add an ISO to the software sources?
[17:28] <Ahmuck> so, do i need to step up?  10.10 then 11.04?
[17:47] <smile> Ahmuck: yeah. But i suggest you take a clean install :)
[18:55] <wxl> back. what did i miss?
[18:55] <venik212> where do I set the preferences for my audio system in Lubuntu?  THe volume control, which in Unity allows access to them, does not do it in Lubuntu
[18:56] <wxl> venik212: alsamixer in terminal
[18:56] <wxl> (although just a volume control should exist in lxpanel)
[19:01] <venik212> it does exist in the panel, but it only controls the volume.  Under Unity, the volume control indicator also allows access to the sound card properties: which mic to use, etc.
[19:01] <wxl> venik212: no such thing in lxde (yet; want to build one?)
[19:02] <venik212> I am confused-- I thought that under Lubuntu I could use any Ubuntu application.  Alsamixer does not seem to see my rear microphone
[19:02] <venik212> and for some reason, Google Voice mail wants to use only the rear mic
[19:03] <wxl> venik212: try arecord -l
[19:03] <wxl> should list all the capture devices you have
[19:03] <venik212> in terminal?
[19:04] <wxl> venik212: you CAN use any ubuntu app. however, the panel apps require a different panel. at which point you end up steering yourself back towards ubuntu/becoming less lightweight.
[19:04] <wxl> venik212: only way to do it and get reasonable output, eys
[19:09] <venik212> wxl-- I know which devices I have (I have a front and a rear mic), but I must have a way of CHOOSING the rear mic.
[19:09] <wxl> venik212: what i'm asking you to do essentially is to see whether or not alsa (which alsamixer uses) sees the rear mic
[19:10] <venik212> Alsa listed 3 devices, did not call them mics
[19:10] <wxl> copy/paste
[19:12] <venik212> udi@udi-desktop-64:~$ arecord -l **** List of CAPTURE Hardware Devices **** card 0: Intel [HDA Intel], device 0: ALC1200 Analog [ALC1200 Analog]   Subdevices: 1/1   Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 1: ALC1200 Digital [ALC1200 Digital]   Subdevices: 1/1   Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 2: ALC1200 Analog [ALC1200 Analog]   Subdevices: 1/1   Subdevice #0: subdevice #0
[19:12] <wxl> so none of those are your rear mic?
[19:13] <venik212> I cannot really tell, but given that it says 1/1, I doubt it
[19:14] <wxl> well if none of those are your rear mic then the basic core audio system is not picking up on it which comes as no surprise why you're having problems
[19:14] <venik212> I know how to set it under Unity. so what I need is the name of the application that does it under Unity.  Synapic lists two sound indicators, one with gtk+-- maybe that is the one I need...
[19:14] <AmberJ> venik212, Does front and rear mic mean two separate tangible mics?
[19:14] <venik212> wxl-- I used this very hardware under Unity yesterday
[19:15] <venik212> I think so, since when the front mic is used no sound is recorded
[19:15] <venik212> they are the front and back of the mouthpiece
[19:16] <AmberJ> well, alsamixer should show rear mic then. I have only 1 mic, still it shows rear mic for me...
[19:16] <venik212> I may have to log in in Unity to make that phone call...
[19:16] <AmberJ> oh k
[19:16] <venik212> that is what I use it for-- long distance free calls
[19:16] <AmberJ> try: "sudo apt-get install alsamixergui"
[19:19] <AmberJ> I guess you probably have a low screen resolution and   alsamixer's ncurses-kinda interface refuses to show up rear mic settings on far right side of window...
[19:19] <AmberJ> So, alsamixergui might help
[19:19] <AmberJ> though pressing right arrow key in alsamixer should take you to far right
[19:20] <venik212> screen res is 1920X???
[19:20] <AmberJ> just try starting alsamixer once again and press right key many times....
[19:22] <smile> AmberJ: i hate alsa :|
[19:22] <smile> that's why I use pulseaudio :p
[19:23] <AmberJ> well, alsa (with default configs) has always worked well with my sound card.
[19:23] <wxl> silly smile you DO use alsa
[19:23] <AmberJ> I don't even know difference between alsa and pulseaudio :D
[19:24] <wxl> every *buntu variant passes alsa through a plugin to pulse audio
[19:24] <wxl> read and weep https://wiki.ubuntu.com/PulseAudio
[19:24] <smile> wxl: :(
[19:24] <smile> wxl: i want real PulseAudio!! :D
[19:25] <wxl> tell that to the apps you have that require alsa
[19:25] <smile> :)
[19:25] <smile> wxl: kind of compatibility mode? :p
[19:31] <venik212> I FINALLY found something called simply MIXER, which recognized all the things I needed.  ALl is well
[19:32] <venik212> too bad they hide it so well
[19:38] <smile> venik212: i hate sound ;)
[21:48] <doritoDan> Hi.
[21:48] <doritoDan> Installing Lubuntu for the first time. :-)
[21:48] <doritoDan> The installer is sort of glitched.
[21:49] <doritoDan> The cursor is mirrored and the button icons are badly positioned. :S
[21:58] <wxl> doritoDan: uh, which lubuntu you installing via with methodology on what machine?
[21:58] <doritoDan> wxl: The latest desktop one using an iso on a VMware virtual machine.
[21:58] <wxl> latest = 12.04 or 11.10?
[21:59] <doritoDan> 11.10. I did not see a 12.04 on the page.
[21:59] <wxl> well it's in the dailies. it's not official yet, but that doesn't mean you wouldn't want to go with some bleeding edge alpha stuff. not necessarily recommending it.
[21:59] <doritoDan> I never use alphas or betas. :=)
[21:59] <doritoDan> :)*
[21:59] <wxl> anywho, this is the second issue i have heard that revolved around VMware
[22:00] <wxl> i wonder if vmware itself isn't problematic
[22:00] <wxl> or.. are you doing this on windows?
[22:00] <wxl> 64 or x86?
[22:00] <doritoDan> 64.
[22:00] <wxl> vmware in windows?
[22:00] <doritoDan> OSX.
[22:00] <holstein> lol... i consider all non-lts's beta ;)
[22:00] <Unit193> I know VirtualBox works
[22:00] <doritoDan> Hehe.
[22:00] <wxl> oh hush holstein
[22:00] <wxl> yeah i know virtualbox works too
[22:01] <doritoDan> VMware could possibly cause the mirrored mouse cursor, but I have a hard time seeing how it would contribute to the image positioning inside the button elements.
[22:01] <wxl> it's fairly trivial to install on os x. i might recommend giving that a shot.
[22:01] <doritoDan> I think that has to do with me using a localized translation for the installer, and the words beeing so long that the margin between image and text disappears.
[22:01] <doritoDan> effectively making it look weird
[22:01] <wxl> i have an imac running vbox on a 64 and lubuntu has no problem.
[22:02] <wxl> that's possible.
[22:02]  * wxl looks to see who's on the translation team
[22:03] <wxl> what translation?
[22:04] <wxl> stupid subteams page i can't ever find
[22:04]  * wxl grumbles
[22:08] <wxl> yeah i'm kind of at a loss doritoDan without some help from the translation team. i would suggest giving it a shot in virtualbox
[22:08] <wxl> an alternative would be using the alternate installer
[22:09] <Unit193> Or try the LiveCD
[23:00] <doritoDan_> wxl: Swedish.
[23:00] <doritoDan_> Also, I don't have virtualbox.
[23:00] <doritoDan_> But uh
[23:00] <doritoDan_> the installer works.
[23:00] <doritoDan_> I'm just saying, it looks weird.
[23:03] <wxl> doritoDan_: virtualbox is easy to get. it's free. :D
[23:03] <wxl> doritoDan_: it would be interesting to see if the desktop is weird or just the installer
[23:03] <wxl> doritoDan_: so i'd check a livecd
[23:03] <wxl> doritoDan_: if the live cd is ok use the alternate installer and it will be no problem
[23:03] <doritoDan_> How would a livecd differ? It's the same installer. :I
[23:04] <wxl> not for the installer part
[23:04] <doritoDan_> In fact, is there even an installer at all on the livecd?
[23:04] <wxl> to check the cd out silly
[23:04] <wxl> to see if the desktop itself looks messed up
[23:04] <doritoDan_> I never complained about the desktop.
[23:04] <doritoDan_> Just the installer. :)
[23:04] <wxl> anywho either way it sounds like you have a bug of some kind so i'd probably file one
[23:04] <wxl> but first i'd probably eliminate the vmware part of it
[23:04] <wxl> so head over to #vmware and see if they know what the heck you're talking about
[23:05] <wxl> sorry i thought you needed HELP with the installer
[23:06] <wxl> complaining about things is best handled in the form of bug reports
[23:07] <doritoDan_> I'm neither complaining nor asking for help. I merely commented on it to see if it was a design error.
[23:07] <doritoDan_> :)
[23:07] <wxl> again, bug report
[23:10] <doritoDan_> Nah, I don't like bug report systems. They're too cumbersome.
[23:10] <doritoDan_> And badly designed.
[23:10] <doritoDan_> Hmm.. cool. So this is lubuntu. Is there a way to make it automatically bring up the last used user account when starting up the login screen?
[23:11] <doritoDan_> because just now it asked me to type in both my username and password
[23:12] <Unit193> it's called LXDM, that's the idea
[23:16] <doritoDan_> Unit193: What is the idea?
[23:16] <Unit193> LXDM does that, it's normal, nothing different there. You can set autologin if you wanted
[23:18] <doritoDan_> I don't want autologin - i just want it to automatically pick my username
[23:18] <Unit193> Fine, either try LightDM, GDM, KDM, or some other DM that does that :P
[23:25] <doritoDan_> Unit193: Aren't those more resource intensive?
[23:26] <Unit193> Yes, maybe less so for Lightdm
[23:27] <doritoDan_> Isn't there a way to achieve what I want on LXDM?
[23:29] <Unit193> It does with 0.3.0, but you'd have to find a greeter that has it
[23:29] <pingcasts> doritoDan_: you can try slim but the project is dead as far as I know
[23:30] <Unit193> AFAIK, slim needs you to type username
[23:31] <pingcasts> you can configure it to auto login but I think if you leave out the password it'll just do the username
[23:31] <doritoDan_> I got an error when I tried to update my files using the update manager
[23:31] <doritoDan_> "The daemon died."
[23:32] <pingcasts> you could also try lxdm
[23:33] <pingcasts> https://wiki.archlinux.org/index.php/LXDM
[23:33] <Unit193> Lubuntu currently uses that by default....
[23:43] <doritoDan_> So does lubuntu run ubuntu apps?
[23:44] <]spectre[> sure doritoDan_
[23:45] <doritoDan_> Cool.


[11:55] <rvchila> morning!
[14:32] <paradoxuncreated> Heya, routing alsa to jack, hopefully to expose an interface, I can route in jack, anyone know? I already tried this: http://alsa.opensrc.org/index.php/Jack_%28plugin%29 that doesn't seem to do anything.
[16:04] <holstein> hey paradoxuncreated
[16:04] <holstein> i seem to be able to get everything i need routed to jack using the GUI
[16:04] <paradoxuncreated> ullo
[16:04] <holstein> qjackclt
[16:04] <paradoxuncreated> ok
[16:04] <holstein> or whatever
[16:05] <holstein> i did use netjack for a bit
[16:05] <paradoxuncreated> how did you get the alsa sound, into jack?
[16:05] <paradoxuncreated> I want to do system wide EQ through jack.
[16:05] <holstein> but i was still able to use the connection bay from qjackctl
[16:05] <holstein> hmm
[16:06] <holstein> i dont remember that being an issue
[16:06] <holstein> i was mostly using jack aware synths, or line in/out from my firepod
[16:06] <paradoxuncreated> I need for instance, "alsa" ports.
[16:06] <paradoxuncreated> oh yeah, I am using a firewire device too.
[16:06] <holstein> what are you trying to route?
[16:07] <paradoxuncreated> regular alsa audio.
[16:07] <holstein> with alsa?
[16:07] <holstein> a media player?
[16:07] <paradoxuncreated> So that non-jack applications are routed into jack.
[16:07] <paradoxuncreated> (alsa)
[16:07] <holstein> well, that would be handy
[16:07] <paradoxuncreated> hehe
[16:07] <holstein> ive never needed to work that out though
[16:08] <holstein> maybe somebody will know here in a bit :)
[16:12] <paradoxuncreated> I hope it will be me.
[18:26] <Draggin> Good evening... I'm wondering if someone can point me in the right direction... I wish to know which files to edit, where to start looking, etc. if you want a basic Linux system to automatically start up X and GDM upon boot.  Mine does this, of course, being US 9.10, but I have uninstalled GDM to replace with GDM 2.2 (legacy) in order to have the old-look login screens
[18:26] <Draggin> Now, when I boot up, I get a message saying that X is already running - do I want to start it on another screen...
[18:26] <Draggin> How can I fix this?