[00:07] <duanedesign> nhandler: now i am going to try fnotify.pl
[02:56] <greg-g> duanedesign: yeah, it comes in handy when you want to marry your friends :)
[05:01] <paultag> doctormo: well done. All home and happy
[05:01] <paultag> huzzah
[05:01] <doctormo> huzzah au
[05:01] <doctormo> paultag:
[05:01] <paultag> :)
[05:03] <paultag> doctormo: P.S. Miguel de Icaza started GNOME too
[05:03] <doctormo> paultag: sortof
[05:03] <paultag> I thought so
[05:04] <paultag> doctormo: I leave for a few hours to get drunk with a friend and I get back to a full inbox
[05:04] <paultag> my jebus
[05:04] <doctormo> paultag: Anything interesting?
[05:05] <paultag> doctormo: no, normal biz
[05:06] <paultag> doctormo: and apparently, according to this email, I am "a qualify winner of 1,350,000,00 Pounds in the Irish Online Promotion". All I need to do is "Send your Full Names: ,Country: ,Sex: ,Tel:".
[14:48] <paultag> doctormo: not sure if you'll get this, but I do't think I can make it downtown today :(
[15:17] <nigelb> I may have interesting data for dholbach tomorow.
[15:17] <nigelb> I looked through mozilla's instructions for new contributions and I'm trying to checkout how easy it is.
[15:17] <nigelb> Compared to our packaging resources
[16:31] <greg-g> nigelb: they have nice looking resources, at least (benefit of being a company full of web devs :) )
[16:33] <nigelb> greg-g: Indeed. I've been working along with their webdevs for a while now.
[16:34] <nigelb> They're a good fun lot :)
[16:38] <greg-g> nigelb: I bet :)


[00:00] <zumper> i cant see wireless and stuff now
[00:00] <zumper> i did install it again doing apt-get install xfce4-indicator-plugin
[00:00] <zumper> but i cant see wireless..
[00:00] <zumper> only bluetooth now
[00:00] <zumper> how do i get it back?
[00:03] <zumper> ...
[00:04] <zumper> I also removed , by accident , my icon for wireless network connection.  When I put in the terminal : sudo nm-applet  I have my icon back for the wireless connections.
[06:28] <cb_> Hi, I want to configure desktop notifications for my wifi hotspot connection.. so that when a new device gets added it would also show its name in notification popup.. any ideas how do i do that?
[11:06] <gdi2k> how can I adjust the sensitivity of the volume control keys? mine drive the volume from off to ear piercing in about 3 steps...
[11:20] <gdi2k> to answer my own question: xfconf-query -c xfce4-mixer -n -p /volume-step-size -s 1 -t uint
[15:34] <asantos3> uhm, hi
[15:34] <asantos3> does someone remember me from yesterday?
[15:35] <drc> no...best to restate your problem, what you did to correct it and what is still wrong.
[15:35] <asantos3> ok, I write the problem and how I got where I'm now
[15:37] <asantos3> I'm on Xubuntu 15.04 with an Radeon HD 7670M and I'm having fps drops in 3D fullscreen OpenGl games following an update
[15:37] <holstein> asantos3: whatever its an update to, you can try simply reverting the update
[15:38] <asantos3> well, the problem I don't know what was it
[15:38] <holstein> that can at least confirm that, for you. then, you can file a bug, but, i suggest going upstream as far as you can
[15:39] <holstein> asantos3: id day, thats an assumption then. you can try reverting the kernel, then, the driver.. or, just look for, and start your own bug report.. you can try #ubuntu as well, and see if you can find someone with the exact same hardware. that would be helpful
[15:40] <drc> I've never had occasion to use it or even look, but I'd assume that there's an update log <somewhere> ?
[15:40] <asantos3> I tested this a  bunch of times
[15:40] <drc> This should tell you what was updated.
[15:41] <asantos3> I know what I update because I took an screenshot of it
[15:41] <drc> "<asantos3> well, the problem I don't know what was it"  Then what was this?
[15:41] <holstein> asantos3: ah, so, as i suggested, you can try steppting back the versions of what you think is the cause.. its likely you can have a regression bug
[15:41] <holstein> it happens, for sure
[15:43] <asantos3> Here's the screenshot http://i.imgur.com/WQxKg9i.png I took one because monday or so I had fps drops so I tested and bunch of stuff, even switched to ubuntu mate and reinstalled xubuntu 15.04
[15:44] <asantos3> I don't know what could have affected it from that list :/
[15:44] <holstein> asantos3: the drivers, and core kernels, and other parts, are the same.. so, switching DE's wont address driver support, like that
[15:45] <asantos3> But it did ran finned, with everything updated on lubuntu 15.04 and ubuntu 15.04
[15:46] <holstein> asantos3: sure.. both, lubuntu and ubuntu 15.04 are ubuntu as well.. same kernel, and GPU drivers.. *if* you have the same GPU drivers installed
[15:46] <asantos3> I did
[15:46] <asantos3> my gpu doesn't like the proprietary drivers
[15:47] <asantos3> so I always run the Radeon driver
[16:17] <thatdudeguyyoukn> Hi
[16:18] <thatdudeguyyoukn> I installed xubuntu 15.05 and Firefox from the link in the menu doesnt run
[16:18] <thatdudeguyyoukn> I get failed to execute default browser - IO error
[16:18] <thatdudeguyyoukn> Anyone seen this?
[16:19] <asantos3> what do you mean by "from the link in the menu"?
[16:19] <thatdudeguyyoukn> shortcut in the main pulldown
[16:20] <asantos3> runs just fine in a fresh install here
[16:20] <holstein> so, a fresh install of 15.04? and you click on firefox and it doesnt run? what happens, thatdudeguyyoukn ?
[16:20] <thatdudeguyyoukn> yes, that is what I am describing
[16:21] <thatdudeguyyoukn> I get failed to execute default browser - IO error
[16:21] <drc> 1) Works here, 2) what happens if you uninstall then reinstall FF?
[16:21] <thatdudeguyyoukn> Did I break the Internet?
[16:21] <thatdudeguyyoukn> lol
[16:21] <drc> No, you're not that good.
[16:22] <holstein> thatdudeguyyoukn: please open a terminal, and type "firefox" and hit return, and see if it runs..
[16:22] <thatdudeguyyoukn> drc, I'm sure you aren't either
[16:22] <thatdudeguyyoukn> process:4380): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
[16:22] <thatdudeguyyoukn> Could not create gnome accelerators directory `/home/joe/.gnome2/accels': Permission denied
[16:23] <holstein> thatdudeguyyoukn: did it start?
[16:23] <thatdudeguyyoukn> nope
[16:23] <thatdudeguyyoukn> got that error
[16:23] <holstein> thatdudeguyyoukn: how did you install? from what iso?
[16:24] <thatdudeguyyoukn> usb from fresh download
[16:24] <holstein> thatdudeguyyoukn: sure.. from fresh download of what?
[16:24] <thatdudeguyyoukn> I'm gonna reinstall and see if the issue persists
[16:24] <holstein> thatdudeguyyoukn: reinstall what? xubuntu 15.04? 64bit?
[16:24] <thatdudeguyyoukn> holstein, from the ISO download.
[16:24] <thatdudeguyyoukn> 64bit yes
[16:25] <holstein> thatdudeguyyoukn: i would simply update, first. though, it looks like you may just have a simple permissions issue.. did you create a user post install?
[16:25] <holstein> thatdudeguyyoukn: would you try starting firefox as the guest user?
[16:25] <thatdudeguyyoukn> holstein, I did patch it and restart
[16:25] <holstein> thatdudeguyyoukn: you patched what? how?
[16:26] <thatdudeguyyoukn> apt-get
[16:27] <thatdudeguyyoukn> apt-get update; apt-get dist-upgrade
[16:27] <holstein> well, im updated here, and firefox runs.. so, i dont think that is the issue.. did you add any ppa's?
[16:27] <thatdudeguyyoukn> nope
[16:27] <thatdudeguyyoukn> nada
[16:27] <holstein> does it run as the guest?
[16:27] <thatdudeguyyoukn> fresh install.  I'm gonna try as guest
[16:28] <thatdudeguyyoukn> Matter of fact, gonna redownload.  Copy ISO to known good USB and reinstall
[16:28] <thatdudeguyyoukn> oh and also checksum after download
[16:28] <drc> and check the media from the menu affter booting the USB, before installing
[16:29] <thatdudeguyyoukn> yes, I will do that as well.
[16:29] <thatdudeguyyoukn> Thanks yall
[16:50] <asantos3> I tried rolling back some updates but didn't figured it out
[16:50] <asantos3> can anyone more knowledge than me see what package could be causing an fps drop? http://i.imgur.com/We4llgE.png This is the update history, the stuff at 04:17 caused it, dunno what.
[20:54] <parzon> hey, can someone tell me how can i hide docky icon?
[20:54] <knome> maybe ask a docky channel?
[22:28] <Mahe> would installing vm+
[22:28] <Mahe> sry accidently hit enter
[22:29] <Mahe> would installing vivid's intel driver deb package (xserver-xorg-video-intel) on trusty break the system (e.g. is it kernel dependent)?
[22:30] <knome> i wouldn't suggest doing that
[22:31] <mrkramps_> Mahe, you could install the HWE
[22:31] <mrkramps_> if not already done
[22:32] <xangua> Mahe: why would you need that? What is your Real issue?
[22:32] <Mahe> I've got a graphical problem with xfdesktop (both with Xfce 4.10 and 4.12) on trusty that isn't present on vivid.
[22:33] <Mahe> If I set the icon size on xfdesktop higher (e.g. 64) and start dragging an element on the desktop my mouse cursor turns in to a garbled mess of the cursor and icon texture mixed together.
[22:33] <Mahe> it's not visible on screenshots but stays for a few minutes
[22:34] <mrkramps_> Mahe, graphics card?
[22:34] <Mahe> It's happening on an Intel HD 4000 integrated graphics
[22:35] <Mahe> it happens when using the SNA accel method (default)
[22:35] <mrkramps_> Mahe, already tried UXA?
[22:35] <Mahe> yes, then the issue disappears
[22:35] <Mahe> but I can't get VSync via compton to work correctly on UXA
[22:36] <Mahe> so it's not a solution for me either
[22:36] <mrkramps_> Mahe, would you mind posting the result of the following command:$ apt-cache policy xserver-xorg-video-intel* | fgrep '***'
[22:36] <Mahe>  *** 2:2.99.914-1~exp1ubuntu4.5~trusty1 0
[22:37] <mrkramps_> ok, that's the lts-utopic driver
[22:38] <Mahe> I used the point release #2 install medium (14.04.2)
[22:38] <Mahe> so I'm already on HWE?
[22:38] <mrkramps_> Mahe, yes
[22:39] <Mahe> that means the life cycle of this install won't even reach 2019?
[22:39] <mrkramps_> nope
[22:40] <mrkramps_> there should be support for this stack until july 2016
[22:40] <Mahe> D:
[22:40] <Mahe> can I downgrade to 'true' LTS?
[22:41] <mrkramps_> ah, sry!!! _not_ 2016
[22:41] <mrkramps_> argh, i never get this right
[22:43] <mrkramps_> Mahe, original trusty until 2019, lts-utopic and -vivid until july 2016 and lts-(16.04) until 2019 as well
[22:44] <Mahe> I'm new to this HWE stuff
[22:44] <Mahe> so that means the xorg and kernel stuff gets regularily backported to the LTS?
[22:45] <mrkramps_> introduced with 12.04.2 for all following LTS releases, yes
[22:45] <Mahe> okay, so next I'd get vivid's backported xorg and kernel stack?
[22:45] <mrkramps_> exactly
[22:46] <mrkramps_> then willy and then 16.04 (no name by now)
[22:46] <mrkramps_> and 16.04 can be used until EOL 14.04 in 2019
[22:47] <Mahe> okay
[22:47] <knome> for what it's worth, xubuntu LTS releases are supported for 3 years
[22:48] <mrkramps_> knome, thanks. that's something i should have mentioned before :S
[22:48] <knome> what this basically means is that all of the xubuntu-specific stuff has 3 years of support; all core/shared components get the support level ubuntu provides
[22:48] <Mahe> idc, I already use the 4.12 ppa for the xfce stuff
[22:48] <knome> but even then, the xubuntu team suggests upgrading after 3 years on an LTS, since the team does not support the aforementioned components any longer
[22:49] <knome> "xubuntu-specific stuff" isn't just xfce, but sure, it's your choice
[22:50] <Mahe> The important things of an LTS for me are core component security updates and the stable kernel
[22:51] <knome> i'm just pointing this out
[22:51] <Mahe> yea no problem, thanks for the heads up
[22:51] <Unit193> And, the PPA doesn't get new stuff, and usually drops old releases no longer supported.
[22:52] <Mahe> Xfce's development is not as fast-paced and the current version is quite mature so I think I can live with this release a while
[22:52] <mrkramps_> Mahe, most likely you cannot stop yourself from upgrading to next LTS with point release 16.04.1 anyways
[22:53] <knome> of course you can
[22:53] <Mahe> That's fine if it's running as well as the current LTS
[22:53] <Mahe> but for instance xubuntu 15.04 breaks my hibernate, even with the 4.0 kernel
[22:54] <mrkramps_> it's not LTS
[22:54] <Mahe> yea I know
[22:54] <mrkramps_> and yes, you have to test carefully before upgrading
[22:55] <Mahe> Just noticed that the vivid HWE packages are already in the repos
[22:56] <mrkramps_> Mahe if 15.04 breaks your hibernate you should expect this to happen with lts-vivid as well
[22:57] <Mahe> yea I thought about that as well just now :D
[22:57] <Mahe> so it might fix the graphics but break my hibernate :P
[22:58] <Mahe> I'll just do a dd backup image tomorrow and try it
[23:05] <Mahe> how can I restart xfdesktop from the command line?
[23:06] <mrkramps_> -R
[23:06] <Mahe> thx
[23:06] <mrkramps> or --reload
[23:08] <Mahe> okay seems like I successfully patched xfdesktop to use a fixed 48px drag texture size which avoids the graphic issue as well
[23:15] <Mahe> one last question about the HWE stuff: did I get that correctly that if I keep updating my point release it will eventually install the vivid backported stuff?
[23:15] <mrkramps> Mahe, no
[23:16] <mrkramps> you have to install a new stack manually
[23:16] <mrkramps> Mahe, see https://wiki.ubuntu.com/Kernel/LTSEnablementStack
[23:17] <Mahe> k thanks
[23:22] <Mahe> then I'll just try out the vivid stack and if it doesn't work I'll downgrade to the trusty LTS stack
[23:23] <Mahe> thanks for all your explanations and guidance! :)


[14:21] <Speck> eutsch?
[14:21] <Speck> Ekuse möi
[14:21] <Speck> Deutsch?
[19:49] <janolap1> Hi there, I'm trying to use Processing to create some visual effects. But I have this message : libEGL warning: failed to create a pipe screen for i915  Smooth is not supported by this hardware (or driver)
[19:49] <janolap1> Does it mean that I have to install a driver, for example using : http://www.omgubuntu.co.uk/2014/05/intel-linux-graphics-driver-installer-1-0-5
[19:51] <janolap1> or is there any workaround ?
[19:52] <janolap1> I'm using Processing 2.2.1 for 32bits on Lubuntu, of course !
[19:53] <wxl> janolap1: sounds like the i915 driver (or the hardware itself) doesn't support that GL that it's trying to use
[19:53] <phillw> janolap1: have a read of http://forum.processing.org/one/topic/p3d-issues-with-ubuntu-13-04-and-processing-2-0-2.html
[19:53] <wxl> janolap1: if `lspci -vvnn | grep i915` pops up something, you have the driver already installed. you can see if there's a different driver available, but i doubt it. i would hit up the processing folks.
[19:54] <janolap1> Result : Kernel driver in use: i915
[19:54] <wxl> yeah so you have the driver.
[19:55] <wxl> janolap1: you can use `lspci | grep -i VGA` to get the device ID and google it for other drivers, but it's doubtful they're out there.
[19:55] <wxl> janolap1: if they are, they're likely proprietary and will be problematic in terms of support, maintainence, etc.
[19:55] <janolap1> 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
[19:56] <wxl> oh maybe you need to add -vn
[19:56] <wxl> there should be something like [xxxx:yyyy] where x and y are alphanumeric values
[19:56] <janolap1> 00:02.0 0300: 8086:2772 (rev 02) (prog-if 00 [VGA controller])
[19:56] <wxl> 8086:2772
[19:59] <janolap1> Ok, I have the solution using an old Processing version... which seems to use old OpenGL... http://forum.processing.org/two/discussion/7134/failing-to-draw-with-opengl-lighting-under-ubuntu-14-hp-compaq/p1
[20:00] <janolap1> I'm trying this first...
[22:15] <MnstH> hey there
[22:15] <MnstH> I'm having issues with my Lubuntu installation, can anyone help me?
[22:16] <MnstH>  I installed a few updates earlier (like most days), and now, whenever I want to log into my account, I get a blank wallpaper and a mouse icon, the desktop won't load... when I log in as guest, it works normally
[22:22] <explodingmango> Hey MnstH, still there? Guess it's up to me to try...
[22:22] <MnstH> sure, query?
[22:22] <explodingmango> Okay, something you can try is to hit Ctrl-alt-T to open a terminal, then type in lxpanel
[22:23] <explodingmango> (I'm looking at a web page reporting a similar problem, if that step works then we've gotten somewhere at least)
[22:23] <ianorlin> MnstH: did you log into openbox
[22:23] <MnstH> I guess I logged into LXDE (?)
[22:23] <ianorlin> does right clicking on the desktop do anything
[22:24] <MnstH> ianorlin: no
[22:24] <MnstH> it's just the wallpaper with a mouse cursor
[22:24] <MnstH> right clicks etc. do nothing
[22:24] <MnstH> I have read at least 30 threads now but some have really funky suggestions so I guess I want to start small
[22:25] <explodingmango> And Ctrl+Alt+T doesn't bring up terminal?
[22:25] <ianorlin> MnstH: try hitting control alt f1
[22:26] <MnstH> I have yet to try... I wanted to gather a few suggestions before I try them all out... I'm on the same machine currently, as a guest
[22:26] <MnstH> so far I have: try to open console with either Ctrl + Alt + T or + F1 (whichever works), then try "startx" or "lxpanel"
[22:26] <ianorlin> can you log out and make sure you are logged into the lubuntu session?
[22:26] <MnstH> and then some sites suggested to revert the lxsession settings to default
[22:26] <explodingmango> MnstH: It's fine, just hitting Ctrl-alt-T or Ctrl-Alt-F1 won't do anything permanent, nor will running lxpanel
[22:27] <explodingmango> MnstH: (whoops sorry I didn't read your message right, ignore me)
[22:27] <MnstH> well, I can't be trying it out and chat with you guys, hence why I said I wanted to gather a few ideas first
[22:27] <MnstH> :)
[22:28] <MnstH> so, anything else I should try in case none of the above works?
[22:29] <MnstH> then I'll try and come back
[22:29] <explodingmango> MnstH: Well if reverting your settings requires deleting folders or files, make sure you back em up and know where to put them back if you need to undo your changes, I guess. Sorry if this is old news
[22:30] <MnstH> the thread suggested deleting ".configs/lxsession/Lubuntu" for my profile (if I manage to access it)
[22:30] <MnstH> .config
[22:31] <MnstH> I wonder what caused this anyway... since this guest account will load everything just fine
[22:31] <MnstH> :(
[22:32] <testdr> MnstH: you should not delete (rm) it - you should rename it - you can even rename the whole   ".config" directory to for example:   mv    .config   .config_old     then you still have it to recover things from it.
[22:32] <explodingmango> MnstH: Wait, so does starting lxpanel or startx from terminal work? i.e. bring back the desktop temporarily
[22:32] <explodingmango> MnstH: Because if it does you'll have no problem accessing those locations
[22:32] <MnstH> testdr: thanks, that sounds reasonable
[22:33] <MnstH> explodingmango: I will try those out now
[22:33] <MnstH> ok, see you in a bit
[22:34] <explodingmango> MnstH: good luck!
[22:48] <MnstH> well... that didn't work...
[22:49] <MnstH> I can only open the console with the "+ F1" combination... if I try "startx", my screen just goes black... if I try "lxpanel", I get the error "(lxpanel:1744): Gtk-WARNING**: cannot open display:"
[22:49] <MnstH> and now, whenever I want to login into my regular account, it "loads something" and then bounces back to the login screen
[22:50] <MnstH> explodingmango ianorlin testdr
[22:50] <testdr> MnstH: in the login-screen ->  press   strg+alt+F1 -> in the text-console login  with your account and     mv   the   .config    to   .config_old
[22:51] <MnstH> also, when I login to the guest account, it comes up with an error box that reads "No session for pid 1671"
[22:51] <MnstH> but everything else works
[22:52] <testdr> MnstH:  did you do what i said?  Go to text-console with   strg+alt+F1    or     strg+alt+F2        there login  and rename the directory   .config
[22:53] <MnstH> from the guest account/now?
[22:53] <testdr> no - go to the kitchen and try it from there ... -- are we not speaking about your computer?
[22:54] <MnstH> ...
[22:54] <explodingmango> hey hey. When you hit Ctrl+Alt+F1 it'll ask you to login via text, even if you're already logged in as guest
[22:54] <testdr> MnstH: Do you not know what pressing    strg+alt+F1   is?
[22:54] <MnstH> I do, I used it earlier
[22:55] <MnstH> I was just wondering if I needed to do anything afterwards that would require me to login (attempt) to the other account
[22:55] <explodingmango> I guess after all's said and done you can go back and login from GUI, but right now I think everything's gonna happen in the Ctrl-Alt-F1 terminal so it won't matter yet
[22:56] <MnstH> yeah
[22:56] <MnstH> sec
[22:56] <explodingmango> By the way, to go back to GUI is Ctrl-Alt-F7, at least on my computer.  I'm having a problem with xfce4-power-manager. If I start it with --no-daemon all works, the battery icon shows up and everything. However, if I start it with no parameters nothing happens. The daemon runs, but no icon shows up on my tray
[23:05] <aflag> does xfce4-power-manager daemon logs things somewhere
[23:05] <aflag> ?
[23:08] <explodingmango> Sorry, I'm not ignoring you, I just don't know.
[23:08] <explodingmango> However, does this mean anything to you?
[23:08] <explodingmango> [2014-10-29 17:40] [ALPM-SCRIPTLET] :: Xfce Power Manager no longer provides a tray icon. [2014-10-29 17:40] [ALPM-SCRIPTLET]    Please add the new Power Manager Plugin to your panel. [2014-10-29 17:40] [PACMAN] upgraded xfce4-power-manager (<IP_ADDRESS>.g75107db-1 -> 1.4.1-2)
[23:09] <aflag> Hm, not sure. It does show the icon when I start it with --no-daemon
[23:10] <aflag> also, when I start it as a daemon xfce4-power-manager-settings doesn't work -- while it does work with --no-daemon
[23:14] <explodingmango> Uh, this is a really dumb shot in the dark for me: does anything show up in dmesg regarding it?
[23:16] <aflag> hm, it doesn't look like it, unfortunately :(
[23:17] <explodingmango> Ah, quote "There also might be some useful information in the ~/.xsession-errors log file."
[23:18] <aflag> hm, nothing :( I wonder why something like that could happen. I will try to execute --no-daemon in background :P
[23:19] <explodingmango> Yea :/ This might be the same bug here but they never found a resolution: https://bugs.archlinux.org/task/40180
[23:22] <explodingmango> Another quote from another web page: Trying sudo xfce4-power-manager --dump does nothing for a minute or so, then gives me the following message: ...
[23:23] <explodingmango> Same pages suggests what I think you said you'd try, to disable the power manager on startup and add your own startup entry for power manager --no-daemon or whatever
[23:25] <aflag> yes, that's what I am thinking on doing as well :P
[23:25] <aflag> let's not fight the current :)
[23:25] <explodingmango> Yea, diminishing returns
[23:27] <explodingmango> or whatever. Long as it works, seems to have worked for the answerer to http://askubuntu.com/questions/129671/how-can-i-workaround-the-xfce4-power-manager-being-broken
[23:27] <krytarik> aflag: Fwiw, LP bug 1347272, too.
[23:30] <aflag> well, maybe some day someone will get it fixed :) Thanks for all the attention, you guys. I will try to login again and see if my hack worked :)
[23:32] <aflag> fyi, it worked :)
[23:32] <explodingmango> Sweet


[01:54] <arges> yes?
[02:26] <psusi> just saw a question on askubuntu about installing the gdb64 package on amd64 and it wants ot remove a bunch of important packages.  It looks like this is an i386 only binary with no multi-arch header, so why is it even coming up as installable from amd64?
[04:12] <ari-tczew> infinity: hey, are you gonna to get debootstrap updated in trusty (incl. utopic's script), as well?
[04:12] <Logan_> [13:55:46]  <barry> infinity: are you SRU'ing a backport of debootstrap into trusty (for the utopic symlink)?
[04:12] <Logan_> [14:00:56]  <infinity> barry: I hadn't prepped one but, yes, I should do so for all supported releases.
[04:15] <pitti> infinity: yes, we found out why, missing .result files; we have them now, but they are broken
[04:27] <ScottK> ari-tczew: It's in the queue for ubuntu-sru review.
[04:47] <pitti> infinity: so what needs to happen now is to roll out current lp:auto-package-testing to tachash and poke all the jenkins jobs to update themselves; I can't do that unfortunately, needs jibel
[05:41] <jayaura> I believe this is a proper channel to ask. How do I get information on a kworker thread? I hdd is continuously being written by a kworker every second. I disabled journalling.
[05:42] <jayaura> How can i get more info on this kworker? On who's behalf is it working ?
[05:42] <jayaura> And, oh yes I'm on trusty
[05:45] <jayaura> its /proc/<TID>/stack doesnt give any useful information.
[05:45] <jayaura> [<ffffffff810846f1>] worker_thread+0x1d1/0x410
[05:45] <jayaura> [<ffffffff8108b312>] kthread+0xd2/0xf0
[05:45] <jayaura> [<ffffffff8172637c>] ret_from_fork+0x7c/0xb0
[05:45] <jayaura> [<ffffffffffffffff>] 0xffffffffffffffff
[06:35] <alkisg> Hi, in 12.04+ the keyboard layout switching is managed by unity-settings-daemon instead of XKB. Due to Xorg limitations, unity-settings-daemon doesn't get notified when the layout switching shortcut is pressed inside full-screen applications that grab the keyboard (e.g. LP bug #388547).
[06:35] <alkisg> The result is that now that apps like `tuxpaint --fullscreen` etc are completely unusable for non-latin environments.
[06:35] <alkisg> In 12.04 we did manage to work around that issue by telling gnome not do manage the keyboard layout, but allow XKB to do it. In 14.04 that's not doable anymore because of unity-settings-daemon regressions.
[06:35] <alkisg> My question is, if I spend a fair bit of time trying to file bugs and send patches in that direction (let XKB manage the keyboard), is Ubuntu willing to accept them even if Gnome does not? Or should I try to solve that upstream with Gnome first?
[06:55] <dholbach> good morning
[07:56] <GunnarHj> dholbach: Hi Daniel!
[07:58] <dholbach> hi GunnarHj
[07:58] <GunnarHj> dholbach: Thanks for your help yesterday with bug 1310738.
[07:58] <GunnarHj> dholbach: Is there any chance that it can be queued to trusty as well, or would that need to be some kind of SRU?
[07:59] <dholbach> GunnarHj, hum - not sure how we go about adding new packages to stable releases
[07:59] <dholbach> ^ does anyone know? pitti maybe?
[08:01] <pitti> dholbach: it either needs to be synced to trusty-proposed *only* and then binary-copied to unicorn (not the usual approach though), or synced to utopic and uploaded as ~trusty to trusty-proposed (the usual approach)
[08:01] <pitti> GunnarHj: ^
[08:02] <GunnarHj> dholbach, pitti: Thanks pitti. Sounds like it would be easiest then to remove it from the utopic queue and queue it to trusty instead.
[08:05] <pitti> the SRU team might still insist on building the utopic sync with the utopic tool chain
[08:06] <GunnarHj> pitti: Is "and uploaded as ~trusty to trusty-proposed" something else (aka easier) than the SRU process?
[08:08] <pitti> GunnarHj: no, that is the SRU process (and it's an SRU either way)
[08:08] <GunnarHj> pitti: Ok, I see. So then I suppose I'd better wait until it gets approved to utopic, and then SRU it.
[08:10] <GunnarHj> dholbach: ^ So I just wait and apply for an SRU later on.
[08:11] <dholbach> ok cool
[08:11] <dholbach> brb
[08:26] <dholbach> @pilot on
[08:26] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[08:26] <dholbach> @pilot in
[09:05] <pitti> cjwatson, infinity: is http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html stuck or just busy?
[09:22] <cjwatson> pitti: It only cycles when the archive changes, normally
[09:23] <cjwatson> (Which is a slight problem for autopkgtests, but usually the archive is busy enough that it doesn't matter ...)
[09:23] <cjwatson> pitti: Do you need a manual run?
[09:23] <pitti> cjwatson: ah, ok
[09:23] <pitti> cjwatson: we just fixed a couple of autopkgtest bugs and the results files (which were making everything appear as RUNNING)
[09:23] <cjwatson> pitti: OK, let me run it manually
[09:23] <pitti> cjwatson: we just retriggered the worls, so maybe in an hour or so, when we have a bunch of results?
[09:23] <pitti> world, too
[09:24] <cjwatson> Oh, well, I already started it
[09:24] <cjwatson> But sure
[09:46] <dholbach> seb128, do you know if there is a reason we never updated gnome-bluetooth?
[09:46] <seb128> dholbach, "never"?
[09:46] <dholbach> sorry, I meant "since 3.8.something"
[09:46] <seb128> dholbach, the newer versions require bluez5
[09:46] <dholbach> ahhh ok
[09:46] <seb128> which is a big transition
[09:46] <seb128> why?
[09:47] <seb128> do you need something from 3.10?
[09:47] <dholbach> I was just looking at a SRU bug regarding a microsoft mouse or keyboard
[09:47] <seb128> k
[09:47] <dholbach> 3.12
[09:47] <seb128> we can probably backport selected changes
[09:47] <seb128> but updating is blocked on bluez
[09:47] <dholbach> and I helped fix a bug like that some time ago already
[09:47] <dholbach> ok, I see
[09:47] <dholbach> makes sense
[09:48] <seb128> if that's a list of devices in some xml/test list, we should backport the update
[09:48] <seb128> though I think I remember they slightly changed the format, so we might need to tweak or backport code changes as well
[09:48] <dholbach> no worries - I'll just take care of the single fix right now
[09:49] <seb128> thanks
[09:50] <dholbach> seb128, do you know if anyone had a look at bluez5 already?
[09:50] <seb128> dholbach, https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1162781
[09:50] <dholbach> aha!
[09:50] <dholbach> thanks
[09:50] <seb128> yw
[09:50] <dholbach> seb128, you still know bug numbers by heart! :)
[09:50] <seb128> that's likely going to happen this cycle
[09:51] <seb128> dholbach, lol, I still use the awesome bar in an efficient way rather ;-)
[10:00] <doko> pitti, jibel: are gcc-4.9 autopkg tests really running=
[10:00] <doko> ?
[10:05] <cjwatson> pitti: Oh, proposed-migration crashed
[10:05] <cjwatson> In adt-britney
[10:05] <cjwatson> pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/log/2014-04-25/09:23:43.log
[10:06] <cjwatson> doko: ^- hence out of date
[10:19] <jibel> cjwatson, fixed in r341
[10:20] <cjwatson> pulled, thanks
[10:21] <cjwatson> rerunning
[10:31] <jibel> doko, test crashed, re-running
[10:33] <cjwatson> pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html - happier?
[10:40] <doko> jibel, the subversion fail looks like an infrastructure problem
[10:45] <pitti> cjwatson: thanks; we might need a re-run in a bit
[10:46] <pitti> doko: you mean the libapache2-mod-svn install failure?
[10:46] <pitti> doko: that looks like the kind of transient failures with arches being out of sync, I'll retry it
[10:49] <doko> what should be out-of-sync at this time?
[10:50] <doko> cjwatson, infinity: any reason to keep the general freeze block?
[10:52] <doko> ahh, ruby-defaults is in place
[10:54] <pitti> doko: sorry, not out of sync; the postinst failed, not depends:
[10:57] <cjwatson> doko: I'm waiting for us to be sure of the autopkgtest stuff before dropping it
[10:58] <doko> cjwatson, sure, but libreoffice seems to be bit oversized for a test of libgcc1 ...
[10:58] <cjwatson> I mean in general
[10:59] <cjwatson> Like, making sure that we're actually picking up failures, which we weren't earlier
[10:59] <pitti> cjwatson: I think now-ish would be a good time for re-running britney; the queue is empty now, just testing a few stragglers
[10:59] <doko> cjwatson, sure, but how can you see this while the general block request i still in place?
[10:59] <pitti> to see the pass/fail/running for gcc
[11:00] <pitti> oh, no cdbs merge to do this cycle -- a first!
[11:00] <pitti> tribute to dh 9, I guess :)
[11:00] <cjwatson> doko: autopkgtest output is visible even with a block
[11:00] <cjwatson> pitti: running
[11:21] <pitti> doko: hmm, so both https://jenkins.qa.ubuntu.com/job/utopic-adt-subversion/3/ARCH=amd64,label=adt/console and https://jenkins.qa.ubuntu.com/job/utopic-adt-subversion/3/ARCH=i386,label=adt/console still fail in libapache2-mod-svn's postinst
[11:22]  * pitti sees if he's got enough bandwidth in the train to try and reproduce in a schroot
[11:26] <pitti> ... meh, slow
[11:57] <pitti> cjwatson: mind running britney again? everything except apport and eglibc has finished
[11:57] <pitti> there's still an awful lot of RUNNING on current excuses; I wonder if it's just out of date, or our .result files are still buggy
[11:58] <jibel> pitti, I think that the first run from this morning with the buggy output
[11:59] <jibel> pitti, I'll retry unar to verify
[11:59] <pitti> e. g. ceph is PASS, unar's test never succeeded (also in trusty), it's broken
[11:59] <pitti> jibel: no, cjwatson restarted it an hour ago
[12:00] <pitti> jibel: thanks (can't look at logs, keeps hanging)
[12:00] <jibel> pitti, but unar for example didn't run since 0701UTC
[12:00] <jibel> which before the fix
[12:00] <jibel> +is
[12:01] <pitti> ah right, I misremembered; https://jenkins.qa.ubuntu.com/job/trusty-adt-unar/? is all green
[12:02] <jibel> pitti, it's all red but marked running
[12:02] <pitti> jibel: http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-unar/5/ARCH=i386,label=adt/console doesn't look like an infrastructure problem, though
[12:02] <pitti> jibel: perhaps missing dependency?
[12:03] <pitti> (which was installed in the bigger trusty VMs)
[12:04] <jibel> pitti, it fails because there is an error on stderr "Unable to create time zone ..."
[12:05] <pitti> yes, that's the error
[12:05] <pitti> or rather, failure
[12:06] <jibel> pitti, isn't it because the base VM is provisioned differently than in trusty?
[12:06] <cjwatson> pitti: It ran by itself 12 minutes ago - is that enough?
[12:06] <pitti> jibel: yes, surely; it's certainly not something liek a missing allow-stderr, as otherwise it would have failed ealier, too
[12:07] <pitti> cjwatson: yes, I think so
[12:07] <pitti> jibel: so http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html still has a lot of RUNNING for stuff which finished; still something wrong with *.results?
[12:09] <jibel> pitti, that's all the tests that have been triggered before 0700
[12:10] <jibel> pitti, I re-ran unar to check if reconciliation is correct now and will do the other if it's fine
[12:10] <pitti> jibel: oh, ok; so we'll need to re-run ceph & friends?
[12:18] <jibel> pitti, in utopic VM /etc/timezone starts with a comment, is it valid?
[12:19] <jibel> pitti, if it is then it is a bug in unar testsuite
[12:19] <pitti> jibel: ah, systemd's timedatectl also fails, I'm currently looking at that
[12:20] <jibel> pitti, http://paste.ubuntu.com/7329429/
[12:20] <pitti> jibel: hm, given we ship that kind of file in cloud images, I guess/hope it is..
[12:21] <pitti> jibel: ah, in run-adt-test we copy the host's timezone into the VM, so we didn't notice
[12:23] <pitti> or rather, we set "timezone: $TZ" there, while adt-buildvm-ubuntu-cloud just hardcodes "timezone: Etc/UTC"
[12:24] <jibel> pitti, unar thinks otherwise. I added a comment in /etc/timezone and it returns a warning
[12:24] <jibel> ⟫ unar foo.zip
[12:24] <jibel> foo.zip:
[12:24] <jibel> Unable to create time zone for name: '# Created by cloud-init v. 0.7.5 on Thu, 24 Apr 2014 14:03:29 +0000
[12:25] <pitti> yes, timedatectl also fails on that
[12:26] <pitti> actually no, it doesn't stumble over the comment, timedatectl is something else
[12:27] <pitti> right, I need to filter out comments in that test
[12:29] <pitti> ok, fixed in systemd
[12:30] <pitti> jibel: I'm still not sure whether comments are legit there (and frankly it seems like unnecessarily making things hard for programs)
[12:30] <pitti> jibel: but I think it's a good idea to copy the host's timezone like in run-adt-test, I'll do that
[12:32] <kirkland> infinity: doh, thanks
[12:34] <pitti> jibel: filed bug 1312701, will do that when I have bandwidth again (need cloud image for testing)
[12:37] <jibel> pitti, so for unar the problem is in NSTimeZone.m in gnustep-base which loads /etc/timezone in a string and assumes it is the timezone.
[12:39]  * zyga sees objc and wonders what happens in #ubuntu-devel
[12:40] <kirkland> infinity: thanks a lot for that;  fix released
[12:40] <cjwatson> pitti,jibel: So is this just test setup / individual test suite problems, and we're confident that the p-m integration is working now?
[12:45] <jibel> cjwatson, I'm checking that tests marked RUNNING are leftover from this morning and going through the list of failures to confirm if they are problems in the testsuite or not
[12:49] <rbasak> Where can I get old Debian binaries - that were in sid but now superceded and never released? I'd like to reproduce an upgrade bug.
[12:49] <rbasak> Or do I need to rebuild them?
[12:50] <cjwatson> snapshot.debian.org is your best bet
[12:50] <rbasak> Ah - thanks.
[12:59] <xnox> cjwatson: jibel: so comparing http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/ and http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/ there are "Red" tests in Trusty that are not at all present in "Utopic" view. Don't we want to trigger all tests against utopic, to have a baseline?
[12:59] <xnox> eg cherrypy3, bzrtools missing, unless i'm failing at jenkins navigation.
[13:00] <dholbach> @pilot out
[13:36] <zyga> hey, I just got http://paste.ubuntu.com/7329886/ (aptsources.distro.NoDistroTemplateException)
[13:37] <zyga> I assume that's just missing integration, is that something I can easily patch locally?
[13:38] <zyga> pitti: ^^ maybe you would know
[13:38]  * zyga looks at apt sources
[13:38] <xnox> zyga: /usr/share/python-apt/templates/Ubuntu.info is not updated yet.
[13:38] <zyga> ah, thanks
[13:39] <xnox> zyga: you can just use "devel" instead on utopic, until fixed.
[13:39] <zyga> xnox: thanks
[13:39] <xnox> although that also has other caveats.
[13:39] <zyga> xnox: I noticed you uploaded a few packages to utopic yesterday
[13:40] <zyga> xnox: can I just patch that file inline quickly?
[13:40] <xnox> zyga: so <IP_ADDRESS> from unstable already has utopic.
[13:40]  * zyga looks
[13:40] <xnox> zyga: so we just need that.
[13:41] <zyga> xnox: is that in proposed yet by any chance?
[13:41] <xnox> zyga: no it's nowhere at the moment.
[13:41]  * zyga gets the package from sid then
[13:42] <zyga> xnox: I don't see <IP_ADDRESS> anywhere in sid, am I missing something?
[13:44] <xnox> zyga: hence "nowhere at the moment" =) http://packages.qa.debian.org/p/python-apt.html it got uploaded < 6h ago
[13:44] <xnox> zyga: and you know debian doesn't do dinstall every 5 minutes.
[13:44] <zyga> yeah
[13:44] <zyga> ok
[14:02] <roadmr> cgregan: want to join? if you'd rather not on account of feeling not too well, it's ok: https://plus.google.com/hangouts/_/calendar/YXJhLnB1bGlkb0BjYW5vbmljYWwuY29t.qdr2voggco0i1nc07alp84mokk
[14:18] <tkamppeter> mdeslaur, jdstrand, I have released cups-filters 1.0.53 with some security fixes, see https://bugs.linuxfoundation.org/show_bug.cgi?id=1204, https://bugzilla.novell.com/show_bug.cgi?id=871327.
[14:21] <rsalveti> xnox: I updated bug 1305315 and the issue is that the linker binary, created with our own toolchain, contains a procedure linkage table, when it shouldn't
[14:21] <rsalveti> xnox: the linker itself can't have any plt
[14:22] <rsalveti> now I need to find out how to debug this issue specifically, and understand why our toolchain is generating the plt for the linker binary
[14:22] <xnox> rsalveti: yeah i saw the email updates, thanks a lot for debugging this. i have been dissecting aosp toolchain builds and there are a few patches and build-options that may be related to this.
[14:23] <rsalveti> xnox: any patch or option you think we should try?
[14:23] <rsalveti> if you have the links as well, that might be useful
[14:23] <xnox> rsalveti: they don't however do a bootstrap, so it's a bit different (they use prebuild bionic.so =/)
[14:23] <rsalveti> xnox: right, saw that as well
[14:33] <pitti> jibel: in the train I updated adt-virt-qemu to copy the host's timezone; I roll that out now so that unar and friends will work
[14:36] <cjwatson> pitti: Is that the last bit (ish)?  It'd be nice to be able to open
[14:36] <jdstrand> tkamppeter: thanks
[14:36] <cjwatson> jibel: How goes the audit?
[14:42] <jibel> cjwatson, http://paste.ubuntu.com/7330086/ is the list of tests potentially failed because of the new testing env. I'm fixing the 2 first points. I am not sure about u-drivers-common and need a review from pitti if he hasn't already done so
[14:43] <caribou> infinity: is it normal that lintian on  Debian build (makedumpfile) complains that ppc64el is an unknown architecture ?
[14:43] <caribou> infinity: this is to remove the remaining delta b/w ubuntu & debian for makedumpfile
[14:44] <ScottK> doko: FYI, the ruby2.1 maintainer accepted the changes I needed to make to get it to build in Ubuntu for Debian and the resulting sync is waiting in the queue.
[14:46] <cjwatson> caribou: Yes, we haven't got round to teaching lintian about ppc64el yet; you can safely ignore that
[14:46] <caribou> cjwatson: ok, thought so but just wanted to be sure; thanks
[14:48] <cjwatson> jibel: OK, none of those feel like opening blockers to me - would you agree?
[14:49] <pitti> jibel: rolled out, restarting systemd and unar
[14:50] <infinity> caribou: Err, which version of lintian?
[14:50] <infinity> caribou: That should be fixed in both sid and trusty.
[14:50] <caribou> infinity: lemme check
[14:51] <caribou> infinity: <IP_ADDRESS>
[14:51] <infinity> caribou: A version not shipped in any Ubuntu or Debian release.  Well done.
[14:52] <infinity> caribou: Anyhow, 2.5.22 understands what ppc64el is, from trusty, sid, jessie, and wheezy-backports.
[14:53] <caribou> infinity: paste.ubuntu.com/7330345/
[14:53] <caribou> infinity: don't ask me where it comes from then
[14:54] <infinity> caribou: That chroot needs an upgrade? :P
[14:54] <infinity>  lintian | <IP_ADDRESS>         | jessie            | source, all
[14:54] <infinity>  lintian | <IP_ADDRESS>         | sid               | source, all
[14:54] <infinity> caribou: Alternately, ftp.fr could be months out of date, but that seems unlikely.
[14:54] <caribou> infinity: most probably yes, I'm not up to date on my Debian VMs as I am with Ubuntu
[14:54] <xnox> caribou: from France?
[14:55] <caribou> xnox: yeah, that's where I live
[14:55] <jibel> cjwatson, I agree
[14:55] <xnox> caribou: =)))) bad joke for "where it comes from"
[14:55] <caribou> xnox: :)
[14:56] <pitti> jibel: ah, how did you whitelist linux? use a different -o option? (instead of /run/shm/)
[14:56] <cjwatson> infinity: Anything else you know of before we open, given that autopkgtest should be OK now?
[14:56] <pitti> jibel: I'll look into the $HOME thing
[14:56] <xnox> caribou: in my ~/.sbuildrc i have "$run_lintian = 1;" that way lintian is run at the end of build with the right and up-to-date lintain, e.g. sid's at the end of sid build, precise at the end of precise build etc.
[14:56] <cjwatson> Oh, I guess we should wait for the latest binutils to finish
[14:57] <caribou> xnox: thanks; I'll take note of that
[14:58] <infinity> cjwatson: If autopkgtest is okay, and doko signed off on his gcc-4.9 test results, I think we're good to open 'er up.
[14:58] <cjwatson> infinity: ppc64el/lintian> ah, I was assuming that because the table of file(1) output wasn't up to date that the rest wasn't either; OK
[14:58] <infinity> doko: Were you happy with your gcc-4.9 tests?
[14:58] <doko> I always am
[14:59] <infinity> cjwatson: lintian was just ages behind on a dpkg data import, we got that fixed in .22
[14:59] <jibel> pitti, you built the base VMs with the default disk size?
[14:59] <cjwatson> infinity: I definitely want to get binutils consistent first, but that shouldn't take long
[14:59] <pitti> jibel: 4 GB, yes; can rebuild with a bigger one, but I thought that's what we used in the previous system too?
[15:00] <cjwatson> infinity: But I guess we can drop the block-all source, leave things frozen until binutils is done, and then open
[15:00] <infinity> doko: I didn't mean "are you generally content", I meant "did you look at and sign off on the testsuite output you were going to look at earlier" :P
[15:01] <doko> yes, they are ok, besides the usual fall-out for the hardening default flags
[15:01] <infinity> doko: Kay, cool.  Thanks.
[15:02]  * cjwatson removes the freeze block
[15:02] <k1l> hi there. i see some confusing information about the EOL of 12.10. was it the 18th april or is it some other date?
[15:03]  * infinity wonders what's up with that subversion adt failure...
[15:03] <infinity> rbasak: Can you look at that?
[15:04] <infinity> k1l: I'll send out an email today.  It is extended by a tiny bit to give some overlap and unwind confusion between the 18mo->9mo support cycle change.
[15:05] <infinity> k1l: But I don't mind people pretending it's already EOL and upgrading today. :P
[15:06] <k1l> infinity: ok. there was some info ( idont get the source anymore) that it was the 18th april. i am fine with it already beeing EOL :)
[15:19] <infinity> doko: Your gnat is unbuildable in the archive (build-deps on a version that doesn't exist).
[15:20] <infinity> doko: 4.6, that is.
[15:21] <doko> infinity, yeah, won't fix anymore
[15:21] <doko> 4.9 looks fine
[15:25] <kees> we need to turn on -fstack-protector-strong by default in gcc-4.9 :)
[15:30] <seb128> slangasek, hey
[15:31] <seb128> slangasek, you know freetype best around, do you think you could have a look to https://bugs.launchpad.net/ubuntu/+source/freetype/+bug/1310728 and https://bugs.launchpad.net/ubuntu/+source/freetype/+bug/1310017
[15:31] <seb128> slangasek, they both point to an upstream commit each (the second needs small changes to apply correctly)
[15:32] <seb128> slangasek, they seem issues worth trying to fix in the LTS, but I don't know enough about freetype to be confident uploading those (though I guess I could do basic testing and throwing it to proposed and see how it goes)
[15:58] <infinity> kees: Is anyone else planning on using -strong by default, so we don't bear the sole burden of upstreaming fixes?
[15:58] <infinity> kees: (Sounds like the sort of thing SUSE might do, for instance...)
[16:01] <rbasak> infinity: looking
[16:02] <infinity> rbasak: The failure isn't in the tests, but actually in libapache2-mod-svn being installed.  Which could be a testbed issue, or could be a dire critical bug in subversion or apache2. :P
[16:03] <infinity> rbasak: Given the latter, definitely worth looking into.
[16:03] <rbasak> ack
[16:04] <kees> infinity: no one has 4.9 yet
[16:05] <kees> infinity: but, fwiw, on a tiny subset of packages, chromeos has seen no problems.
[16:05] <rbasak> Hmm. This dep8 test looks familiar :)
[16:06] <rbasak> infinity: AFAICT, there's no problem in the archive itself. I can't make it break.
[16:07] <infinity> rbasak: And, yet... https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-subversion/3/ARCH=amd64,label=adt/artifact/results/log
[16:07] <rbasak> Yeah
[16:07] <rbasak> Any idea why the log appears a bit corrupt?
[16:07] <infinity> Does it?
[16:07] <rbasak> Line 31
[16:07] <rbasak> Uh
[16:08] <rbasak> Line 287
[16:08] <rbasak> Relatively numbering won't help :)
[16:08] <infinity> rbasak: Well, that's the failure I'm talking about. :P
[16:08] <rbasak> Or perhaps that's just stdout/stderr recombining wrong
[16:09] <infinity> Yeah.
[16:09] <infinity> i386 seems to fail similarly, though the log breaks differently.
[16:09] <rbasak> http://paste.ubuntu.com/7330782/ is what I just tried (amd64 in lxc)
[16:09] <rbasak> I did a dist-upgrade to utopic first
[16:10] <rbasak> Not precisely the same as the test environment, but I can't see why it would be any different if there's a bug in the archive.
[16:10] <infinity> Weirdly, I get a much larger set to install when I do it locally.
[16:11] <infinity> I guess the adt chroots aren't as clean as mine.
[16:11] <infinity> And yeah, doesn't break here.  Bother.
[16:11] <infinity> pitti: HALP.
[16:12]  * ogra_ sees bug 997737 and senses the next referendum dawning
[16:12] <rbasak> Unless it's an ordering thing.
[16:15] <infinity> ogra_: Bah, close enough.
[16:16] <ogra_> :)
[16:17] <infinity> pitti: I can't reproduce https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-subversion/3/ARCH=i386,label=adt/artifact/results/log
[16:18] <infinity> pitti: Is there any way of reproducing the exact state (a package list of installed packages in that environment might help, as well as the apt cmdline that I wish was echoed to the logs but isn't)
[16:18] <infinity> jibel: ^
[16:24] <jibel> infinity, I'm on it, I can reproduce it in the lab with autopkgtest/run-from-checkout subversion --- qemu cache/disks/adt-utopic-amd64-cloud.img
[16:25] <infinity> jibel: Also, how do I go about getting the right creds/access to retry jobs, so I don't keep bugging other people?
[16:26] <infinity> (Looks like a bunch failed due to a network blip or something causing DNS resolution failures)
[16:28] <jibel> infinity, someone playing with interfaces on one of the machine. I brought it offline
[16:30] <rbasak> infinity, jibel: I can't see why libapache2-mod-svn.postinst might fail, but if it does fail, it looks like it'll fail silently.
[16:31] <rbasak> Doesn't look like it could be anything but apache2 packaging (dh_apache2 etc) if it is a bug there. I can't see one.
[16:31] <infinity> rbasak: From the mangled output, it looked more likely that apache2 (or apache2-data) is failing...
[16:31] <rbasak> infinity: right, but see the last few lines.
[16:31] <infinity> But it's hard to tell, and without a reproducer I can play with locally, a bit of a mystery.
[16:32] <rbasak> That makes me pretty sure it's libapache2-mod-svn.postinst. And that fits the (broken) line 287.
[16:32] <infinity> Yeah, perhaps.
[16:37] <rbasak> infinity, jibel: reproduced. I duplicated the unpack and configure ordering. I'll dig further.
[16:38] <slangasek> seb128: I know enough about freetype to not be confident in any updates; please just do what you think is best :)
[16:38] <seb128> slangasek, ok
[16:54] <infinity> mvo: Does that double-seek bug in apt need to be backported to trusty?
[16:55] <infinity> mvo: (Is that what was responsible for my sid chroots constantly failing to download Packages.xz sanely?)
[16:55] <mvo> infinity: that would be possible, I have prepared a backport to trusty with it
[16:55] <mvo> infinity: was collecting some more
[16:55] <mvo> fixes
[16:56] <infinity> mvo: Sure, it's probably not critical, but since the changelog claims it affects bzip as well (which is our default), I assume it's only a matter of time before I see it on trusty like I was seeing in sid... If that was the bug causing my issue. :P
[16:59] <mvo> infinity: not sure if thats the case, but I will upload a fix nevertheless probably later tonight
[16:59] <mvo> together with a fix for the apt tab completion
[16:59] <mvo> but gtg for dinner first :)
[16:59]  * mvo waves
[16:59] <infinity> mvo: Happy eating.  I need breakfast, thanks for the reminder. :)
[16:59] <mvo> haha
[17:00] <mvo> happy eating to you as well then
[17:09] <rbasak> infinity: it's a bug in apache2 packaging. Reproduced on sid, too. I'll file bugs.
[17:09] <rbasak> In the meantime, I don't see an easy workaround (or a trivial solution to the bug).
[17:10] <infinity> rbasak: Huh.  Weird that it never tripped until now. :/
[17:10] <infinity> rbasak: I guess I'll just ignore the failure for now, since it seems touchy to reproduce.
[17:10] <rbasak> It happens only if apache2 is unpacked and not configured when libapache2-mod-svn is configured.
[17:10] <infinity> rbasak: That's a prefectly reasonable state to expect your deps to be in.
[17:10] <rbasak> libapache2-mod-svn wants to enable dav_svn, which depends on dav, which is supplied by apache2 but not enabled.
[17:11] <infinity> rbasak: The obvious solution to that would be to make a2invoke or whatever it's called be a trigger.
[17:11] <infinity> rbasak: So all the calls run at the end of the dpkg run, instead of in postinst.
[17:12] <rbasak> infinity: that would make any real problems fail in trigger though. Also, aren't triggers sort of optional, in that if dpkg decided to run triggers at different times, the bug would still occur?
[17:12] <infinity> rbasak: The broken (and easy) solution would be to change all the deps to pre-deps.  Please warn them against that, as it makes apt's life WAY harder.
[17:12] <rbasak> Well, libapache2-mod-svn doesn't even depend on apache2.
[17:12] <infinity> Oh!
[17:12] <rbasak> It only tries to enable the module if it thinks that it should (because apache2 is "installed")
[17:12] <infinity> That's the bug, then.
[17:13] <rbasak> Except it just checks for the presence of /usr/sbin/apache2-mainscript-helper, which is unpacked but apache2 is not configured in this case.
[17:13] <infinity> If it depends on a module from apache2, it needs a packaging level dep as well, obviously.
[17:13] <infinity> Sorry, I misread your ordering issue, I think.
[17:13] <rbasak> It doesn't really need apache2, since they allow for /etc/apache2/ to be managed by you entirely.
[17:13] <rbasak> (and for you to only use apache2-bin)
[17:13] <rbasak> But if you *do* have apache2 installed, then installing a module will automatically enable it.
[17:13] <infinity> Well, they allow, except for the postinst failing if not.
[17:14] <infinity> Unless that's all well-guarded.
[17:14] <rbasak> It is, mostly. Except for this.
[17:14] <infinity> Curious problem, I guess.
[17:14] <rbasak> If you don't have apache2 installed, then it's supposed to just not try to do anything in /etc/apache2/
[17:16] <Logan_> when will the UDD branches start appearing for utopia?
[17:17] <Logan_> *utopic
[17:39] <rbasak> infinity, jibel: filed https://bugs.launchpad.net/debian/+source/apache2/+bug/1312854 (and Debian bug). Not sure how to fix - I'll see what Debian say.
[17:40] <pitti> infinity: there should be artifacts testbed-packages and <testname>-packages with the exact versions from that testrun
[17:54] <pitti> jibel: so want me to re-do the VMs?
[17:55] <pitti> for 50 GB, I mean?
[18:09] <pitti> jibel: doing now
[18:12] <doko> pitti, jibel: according to jenkins the binutils autopkg-test did succeed, however update_excuses isn't yet updated
[18:43] <infinity> doko: Did you drop a multiarch patch or something from binutils?
[18:43] <infinity> doko: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-lintian/8/ARCH=amd64,label=adt/artifact/results/log
[18:43] <infinity> doko: binaries-libc-link: ld: cannot find -lm
[18:44] <infinity> doko: http://paste.ubuntu.com/7331812/
[18:44] <infinity> doko: Looks everywhere except /usr/lib/x86_64-linux-gnu/libm.so
[18:47] <infinity> doko: We can't open with that, who knows what fun things it might break. :/
[18:47] <infinity> doko: Want to fix, or just remove that version from proposed?
[18:48] <infinity> Oh, bah.  If we remove it, all the compiler deps break too.
[18:51] <infinity> pitti, jibel: There's another case of tests myteriously falling off the list...
[18:51] <infinity> pitti, jibel: binutils should have triggered lintian (and it did), but eventually, the lintian failure just stopped showing up there.
[18:52] <infinity> pitti, jibel: If I hadn't caught it manually just now, that would have migrated.
[18:52] <infinity> pitti, jibel: I don't know what's causing this, but it *needs* to be fixed, or adt-britney is pretty much useless. :/
[19:18] <infinity> doko: In fact, it skips looking in /usr/lib/$triplet and /lib/$triplet
[19:21] <infinity> doko: And ditto for local...
[19:21] <infinity> doko: So, old output: http://paste.ubuntu.com/7332024/
[19:21] <infinity> doko: And new output: http://paste.ubuntu.com/7331812/
[19:50] <jobin_> Hey, all! I am trying to check the status of cron service using sudo service cron status as a non-privileged user on ubuntu 14.04 desktop 64-bit but get a status: Unknown job: cron error in return. However, if I do the same thing on ubuntu 12.04 64-bit desktop I get the appropriate result. I notice that I can check the status if I am root on 14.04. Why is this happening and how can I solve this?
[19:52] <infinity> (base)adconrad@cthulhu:~$ sudo service cron status
[19:52] <infinity> [sudo] password for adconrad:
[19:52] <infinity> cron start/running, process 1106
[19:52] <infinity> jobin_: Works for me?
[19:53] <Laney> Is it using the user session? (Can't test that here)
[19:54] <Laney> (i.e. does `status --system cron' work?)
[19:55] <jobin_> infinity: Do you mean to say you can check the status without being root on 14.04?
[19:55] <infinity> jobin_: You said you were using "sudo service cron status" which *is* root.
[19:55] <infinity> jobin_: But if you're just using "status cron", then as Laney says, you need --system
[19:55] <infinity> (base)adconrad@cthulhu:~$ status cron
[19:55] <infinity> status: Unknown job: cron
[19:55] <infinity> (base)adconrad@cthulhu:~$ status --system cron
[19:55] <infinity> cron start/running, process 1106
[19:56] <jobin_> infinity: This is what i get: sudo service cron status status: Unknown job: cron
[19:56] <infinity> (base)adconrad@cthulhu:~$ service cron status
[19:56] <infinity> status: Unknown job: cron
[19:56] <infinity> (base)adconrad@cthulhu:~$ service cron status --system
[19:56] <infinity> cron start/running, process 1106
[19:56] <infinity> If you prefer that syntax.
[19:56] <infinity> jobin_: You shouldn't need sudo/root at all, just --system
[19:57] <jobin_> Laney: Yes, if I use --system as sudo service cron status --system then i get cron start/running, process 1152
[19:57] <Laney> Job done
[19:57] <jobin_> infinity: This is what I get for service cron status:   status: Unknown job: cron
[19:57] <infinity> Why your sudo is behaving differently from mine in that regard is likely a local configuation thing.
[19:57] <Laney> It's probably passing through UPSTART_SESSION
[19:57] <infinity> Maybe you're intentionally preserving your environment, while mine scrubs it.
[19:58] <infinity> Preserving environment in sudo generally considered harmful, part III.
[20:01] <jobin_> infinity: Oh yes, I see that i had aliases sudo as sudo -E for using my proxy variables, however, I get status: Unknown job: cron for service cron status but cron start/running, process 1152 for sudo service cron status
[20:01] <jobin_> Laney: I don't need to use --system for service cron status on 12.04, but have to on 14.04, why is that?
[20:02] <Laney> You have an upstart instance running in your session in 14.04, which service is looking at in preference
[20:02] <jobin_> Laney: I see that cron in /etc/init.d/cron is a soft link to upstart-jobs
[20:03] <jobin_> Laney: No, I didn't get you there
[20:03] <infinity> jobin_: You might want to add http_proxy to env_keep in /etc/sudoers instead of preserving your ENTIRE user environment with "sudo -E".
[20:03] <infinity> jobin_: You're asking for trouble doing the latter.
[20:04] <jobin_> infinity: yes, i would avoid that now on, but then how do you explain service cron status returning unknown job on 14.04 but not on 12.04?
[20:04] <Laney> jobin_: http://ifdeflinux.blogspot.co.uk/2013/04/upstart-user-sessions-in-ubuntu-raring.html is the feature
[20:04] <Laney> If that's available, which it is by default in 14.04, then service will behave differently (try to use the 'user' upstart) by default
[20:04] <infinity> jobin_: Because 14.04 uses user sessions, so "service" is looking at your user session, not the system session, and your user isn't running cron.
[20:05] <infinity> jobin_: So, "sudo service" will default to the system session (if you don't leak your user env), and "service blah blah --system" will poke at the system session bypassing your user session.
[20:06] <jobin_> infinity: And what did
[20:06] <jobin_> the version before 14.04 use?
[20:07] <infinity> jobin_: User sessions didn't exist in 12.04.  I think Laney's explained this more than well enough, given this isn't a support channel.
[20:08] <jobin_> infinity & Laney: I had to explain this on askubuntu.com. Do you mind if I share this transcript publicly?
[20:08] <ScottK> jobin_: It's already public and logged.
[20:08] <infinity> It's already public.
[20:09] <jobin_> infinity: great! Thanks!
[20:35] <xnox> infinity: jobin_: initctl --system status cron
[20:36] <xnox> infinity: ah, sorted.
[20:36] <xnox> infinity: i however have a fix for "service" command to always look at system init, and not session.
[21:39] <ScottK> Can autocrats required
[21:40] <ScottK> Urgh.
[21:40] <ScottK> Can autopkgtests require network access?
[21:41] <xnox> ScottK: there is no such stanza in the spec - http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests;hb=HEAD
[21:42] <xnox> ScottK: i believe at the moment on ubuntu dep-8 runner there is network access to e.g. ubuntu mirror and a few similar resources, but not "general web"
[21:42] <xnox> ScottK: and i think on debian dep-8 runner (ci.debian.net) there is network access.
[21:56] <infinity> ScottK: autocrats can totally required.
[21:58] <infinity> ScottK: I think you'll find (as xnox says) that it's implementation specific right now, but a needs-intarwebs thing might not be a bad control variable to add.
[21:58] <infinity> ScottK: Then paranoid people can just skip those tests, while others can sort out a sane NAT or whatever strategy for their VMs.
[21:58] <infinity> ScottK: (Feel free to proposed and/or provide patches)
[21:59] <infinity> doko: I think I have your binutils thing fixed, will upload to Ubuntu and NMU to Debian as well, given the ickiness of the bug.
[21:59] <xnox> infinity: but about autocrats.... i'm not sure "a 1940s British single-engined three-seat high-wing touring monoplane" scale well enough - do you think would just lego models do?
[22:00] <infinity> xnox: That sounds more like a decepticrat.  Autocrats can't fly.
[22:01] <xnox> infinity: \o/ re:binutils.
[22:01] <xnox> "My Dad asked me last night why I carry my 1911 in the house, what am I afraid of? I looked him straight in the eye and said, “The Goddamn Decepticons.” He laughed, I laughed, the toaster laughed, I shot the toaster. It was a good time."
[22:02] <xnox> infinity: but when binutils would finish building & autopackage-tests finish -> you wouldn't still be around to open the archive, would you?
[22:03] <infinity> xnox: I will be.
[22:03] <infinity> xnox: When I'm satisfied with this binutils, I'll open the floodgates.
[22:03] <ScottK> infinity: Alternately I just go "Oh, that package can't do autopkgtests" and move on to other things.
[22:04] <infinity> ScottK: Yeah, or that.
[22:04] <infinity> ScottK: Though, if this is a package with build-time tests disabled for the same reason, that's a bit of a fail on our part. :/
[22:05] <ScottK> It's a DNS module, so it's kind of hard to test without having a network to do DNS'y things.
[22:05] <infinity> (Unless literally off it its tests need interwebs, then maybe the tests need rewriting, or we indeed need a testbed with unfettered internet)
[22:05] <infinity> s/off/all/
[22:05] <infinity> ScottK: Well, depends on the DNSy things, I suppose.
[22:05] <infinity> ScottK: But yeah, hard to know what you can and can't look up in a restricted network.
[22:06] <ScottK> Since it's python-dns, it's whole job it to ask questions of the DNS and get answers.
[22:06] <infinity> ScottK: FWIW, unlike our buildd network which can't even RESOLVE the outside world, I suspect the autopkgtest machines can resolve, just not connect.
[22:06] <xnox> ScottK: you could try doing a quick sample and throw it to the archive and see if it sticks.
[22:06] <infinity> ScottK: (But I dunno)
[22:07] <ScottK> I'd have to override some pretty low lever pieced of the python networking stack to mock up the right responses.
[22:08] <infinity> JABBERWOCKY: SEARCH_DIR("=/usr/x86_64-pep/lib"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
[22:08] <infinity> JABBERWOCKY2: SEARCH_DIR("=/usr/x86_64-pep/lib"); SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib/x86_64-linux-gnu"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib/x86_64-linux-gnu"); SEARCH_DIR("=/usr/lib");
[22:08] <Unit193> (Copied over from -motu, because I noticed the package is in main) So I finally decided to look at the problem rather than hold on to the saucy package.  python-parsedatetime in trusty is a bit broken (gives traceback when you use gcalcli), and the way to fix it is either to update to a new version, or apply https://github.com/bear/parsedatetime/commit/51d47dd57a8ac78208aa69015d7e13bdf1bd3574 (and optionally: ...
[22:08] <infinity> That looks like a correct mangling, right?
[22:08] <Unit193> ... https://github.com/bear/parsedatetime/commit/692168f4bd336efc07e7575dcde7012eaa1e2075 There were a fair amount of other bug fixes, I believe, so not sure which route you'd prefer.  I'd prefer not to do the SRU paperwork myself, so I don't break something.)
[22:09] <infinity> Unit193: Do you have a bug filed with the above info?  It'll probably get lost in IRC backscroll unless someone feels the urge to jump on it Right Now (which I don't).
[22:09] <Unit193> infinity: I haven't, at least not yet, no.
[22:15] <ScottK> zul: I fixed kazoo for you in trusty, but it needs a merge now.  Would you please take care of it.
[22:19] <infinity> Alright, one last test build without debugging statements, and then I'll throw lintian's failure against it and upload if all good.
[22:20]  * infinity crosses his fingers.
[23:09] <infinity> doko: In case I have the wrong number and I'm SMSing into a void, I NMUd binutils to Debian for you, as well as the Ubuntu upload.  Enjoy.


[02:58] <mhall119> popey: belkinsa made them, I suspect by some amount of copy/paste, I can edit them manually in the admin
[03:01] <mhall119> popey: fixed


[00:49] <_marx_> 22 killed in nc
[00:50] <_marx_> 62 tornadoes
[00:50] <_marx_> wow
[03:54] <jack_^> akgraner, do you know if there is a release party scheduled in raleigh yet? a buddy at mine at work was talking about making the trip out to chapel hill but i told im we may have one here
[04:50] <axisofentropy> hey when's dat party?
[11:46] <akgraner> jack_, the one in Chapel Hill is the only one being planned in the triangle area (unless you or someone else would like to plan one) :-)
[11:47] <akgraner> axisofentropy_, Thursday 28, 7-10 crunkleton in Chapel Hill - a more formal invite will hit the internets today :-)
[21:17] <bac> jack_ : the details for the CH release party are now up at http://loco.ubuntu.com/events/team/906/detail/
[21:18] <jack_> i'd rather go to a raleigh party to be honest :X
[21:18] <jack_> when is the release date?
[21:18] <bac> 28th
[21:18] <jack_> damn. in like 9 days? i dont think thats enough notice. last time we had 3 people show up. the me, sascha, and my buddy i brought along
[21:18] <bac> jack_, i hear you.  otoh it would be kind of nice to have more people and let it rotate around the triangle
[21:31] <billfarrow> I posted the CH party details to the TriLUG mailing list a couple of days ago.
[21:38] <billfarrow> why does the natty release party registration not use the Name field from my profile and only the username
[21:54] <bac> thanks billfarrow
[21:55] <bac> billfarrow: don't know why the difference between you and jon's display and mine
[21:59] <billfarrow> bac: weird huh. something is broken, oh well.
[22:35] <bac> billfarrow: do you still have your launchpad account?
[22:36] <billfarrow> bac: yeah, but when the events page showed my username I went and changed it to something more recognisable, and the link is now broken
[22:37] <bac> billfarrow: doh
[22:39] <billfarrow> kinda strange that launchpad allows you to change the unique key that other sites link to :-)
[22:39] <akgraner> billfarrow, thank you - I got a couple of emails from people on the list...yay!
[22:39] <bac> billfarrow: you may want to try to change your registration status
[22:39] <bac> toggle it off then on again and see if the link is recreated
[22:39] <billfarrow> tried that, didn't help
[22:39] <bac> darn
[22:40] <billfarrow> I guess I could change my username back and try again
[22:42] <billfarrow> Arrg, I'll leave it as my old username and retain the links
[22:46]  * marco_polo just went natty on an lubuntu install
[22:46] <bac> billfarrow: i found this in the loco-directory code:
[22:46] <bac> # set real name as username for now,
[22:46] <bac>         # we get the name later on via cronjob
[22:46] <bac> so, maybe check back tomorrow?
[22:47] <mhall119> billfarrow: you changed your LP username?
[22:48] <bac> billfarrow: btw, LP heavily discourages users from changing their LP id if they have internal resources addressed by it, such as a PPA
[22:49] <mhall119> billfarrow: there's a fix working it's way through the process that will allow loco-directory to follow LP username changes
[22:49] <mhall119> it'll probably take a few weeks before it's live though
[22:50] <billfarrow> I'm not in a hurry, I was just suprised that it broke
[22:50] <mhall119> billfarrow: it's a bug we've been dealing with for a while, but it's in the django-openid-auth project code, which links launchpad (SSO to be more specific) to loco-directory, so we've had to submit patches to them


[06:54] <makara> exit
[12:43] <coreycb> cpaelzer: fyi kashyap in #openstack-nova opened this for the firmware descriptor files issue we discussed - https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1836859
[12:46] <cpaelzer> thanks coreycb I'll ping dannf who usually takes care of edk2
[12:46] <coreycb> cpaelzer: ok thank you
[15:24] <teward> for 18.04 servers, is it possible to roll custom nameservers with DHCP and ignore the DHCP assigned nameservers?
[15:24] <teward> i forget :P
[15:25] <teward> (this is for LXD containers which get DHCP'd network data)
[15:43] <lordcirth> teward, yes
[15:44] <lordcirth> teward, using netplan, you need dhcp4: true but dhcp4-overrides: use-dns: false
[15:45] <lordcirth> Assuming the docs are correct, haven't tried it
[17:00] <seveneleven> how can i configure a NIC to use vlan id 2 using ubuntu preseed?
[17:01] <lordcirth> seveneleven, the NIC is on a tagged port, and you need it to create a vlan2 interface and configure networking on that?
[17:01] <seveneleven> lordcirth, it's on an untagged vlan 2 port
[17:01] <seveneleven> lordcirth, so i should just configure pvid 2 on that port instead?
[17:02] <lordcirth> seveneleven, if it's untagged, why would you need to do anything different?
[17:02] <seveneleven> wait, let me rethink why it didn't work last time
[17:02] <seveneleven> ok i described it wrongly
[17:03] <seveneleven> it's a vm on a hypervisor, now the hypervisor is connected to a tagged vlan 2+3 port, last time i created a br.2 bond and got the vm working with an internet connection
[17:04] <lordcirth> seveneleven, so the hypervisor should expose an untagged port to the VM, and put it on vlan 2.
[17:04] <seveneleven> yeah
[17:05] <lordcirth> We do that with LXC containers at $WORK
[17:05] <seveneleven> i use libvirt kvm qemu
[17:06] <lordcirth> seveneleven, ok, so what problem are you having?
[17:06] <seveneleven> i wonder how I can configure br.2 in ubuntu's preseed
[17:07] <lordcirth> seveneleven, if the hypervisor is providing an untagged eth0, why would you need to?
[17:08] <seveneleven> hmm, not sure
[17:08] <seveneleven> last time I simply created a br0 bond, and got no route to WAN, once I created the br.2 explicitely it worked
[17:08] <seveneleven> thats why i thought i need it
[17:09] <lordcirth> seveneleven, then your hypervisor was passing in a tagged port.
[17:09] <seveneleven> hmm
[17:13] <seveneleven> lordcirth, i just checked and my hypervisor uses a bridge between the vm http://dpaste.com/0NB8V3S
[17:13] <lordcirth> seveneleven, ok, so what is br0 tied to? 'brctl show br0'
[17:14] <seveneleven> enp0s31f6, vnet1 and vnet2
[17:15] <lordcirth> seveneleven, and enp0s31f6 is the tagged one with vlans 2+3, right?
[17:16] <seveneleven> yeah
[17:16] <lordcirth> seveneleven, so, br0 is tagged, and your VM's interface is therefore tagged.
[17:16] <seveneleven> enp0s31f6 is like eth0
[17:16] <seveneleven> ohh gotcha
[17:16] <lordcirth> What you want is to create a enp0s31f6.2 interface on the host, which is untagged vlan2
[17:17] <lordcirth> Then make a br2 that is tied to that, and put your VM on that.
[17:17] <seveneleven> oh that's clever
[17:18] <lordcirth> Our LXC servers essentially do this - I use Salt to generate the netplan configs for a list of vlan IDs, and we get a iface.422 tied to a br422, and make containers on br422, etc.
[17:18] <seveneleven> wow then you end up with many many interfaces
[17:19] <lordcirth> yeah, but, automation :P
[17:19] <seveneleven> im going to try that, but just out of curiousity, would it have been possible to configure ubuntu to br.2 via the preseed? i assume yes, but it's probably more complicated
[17:20] <lordcirth> It is probably possible, but I don't know how.
[17:20] <lordcirth> Well, you could drop a netplan file in, but that wouldn't get you networking in the installer.
[17:25] <seveneleven> mhmm
[17:26] <seveneleven> i keep it simple and stupid and try your solution :-)
[17:36] <seveneleven> yeah seems custom bonds are not really supported for ubuntu installer https://askubuntu.com/questions/528211/can-d-i-ubuntu-installer-configure-bond-vlan-and-second-network-interface-dur
[17:53] <seveneleven> lordcirth, should i configure an ip on the iface.422?
[17:53] <seveneleven> or just "create" it and configure the IP on the br422?
[17:53] <seveneleven> im using /etc/network/interfaces for configuration
[17:54] <lordcirth> seveneleven, you don't need an IP on the host side to have the VM work
[17:54] <seveneleven> mmhm
[17:55] <seveneleven> so I just add `auto enp0s31f6.2` and `auto br2` inside /etc/network/interfaces?
[17:56] <seveneleven> (and use brctl to add enp0s31f6.2 to br2)
[18:00] <lordcirth> seveneleven, this is what I have: https://gist.github.com/lordcirth/a4c3b71a0f6ec29be704a440ceb5961e
[18:01] <lordcirth> brctl is transient, you want it all in files.
[18:01] <seveneleven> aaah right, brctl forgets it after reboot
[18:01] <lordcirth> the vlan device needs to be explicitly tied to the interface, and the bridge to the vlan
[18:04] <anton4i3ke> Im seveneleven, seems like my network died after restarting its service hehe 😊
[18:05] <lordcirth> anton4i3ke, it is easy to make a mistake when doing this
[18:06] <sarnold> anton4i3ke: you might have missed < lordcirth> the vlan device needs to be explicitly tied to the interface, and the bridge to the vla
[18:09] <anton4i3ke> Yeah
[18:09] <anton4i3ke> Going to troubleshoot now
[18:12] <sarnold> anton4i3ke: due note that it's entirely normal for all existing connections to an IP address to drop when you add a bridge to a NIC (or add a NIC to a bridge?) -- on linux the IP is associated with the *bridge*, not the nic..
[18:13] <coreycb> jamespage: sahid: i think i have the remaining py2 drops done. once we get the RM bugs handled we should know for sure.
[19:27] <seven-eleven> lordcirth, hmm i dont get a route between the vm and the hypervisor
[19:28] <seven-eleven> how does your interfaces config look like on the vm?
[19:28] <lordcirth> seven-eleven, just eth0 as a static IP
[19:28] <seven-eleven> hmm i tried that
[19:28] <seven-eleven> i worry this is a libvirt issue
[19:28] <lordcirth> seven-eleven, can you pastebin your /etc/network/interfaces on the host?
[19:28] <seven-eleven> ok
[19:31] <seven-eleven> lordcirth, sorry i need a while, i have X running in the basement now, so i cant connect to the X remotely anymore, and i dont know what display manager i used so i cant stop it :D
[19:31] <lordcirth> seven-eleven, lol. you can kill X?
[19:31] <seven-eleven> i tried killall X
[19:31] <seven-eleven> i run `startx` in the basement
[19:32] <lordcirth> seven-eleven, killall Xorg
[19:32] <seven-eleven> let me try
[19:32] <seven-eleven> not found hmm
[19:32] <seven-eleven> i can just reboot, but im curious
[19:33] <seven-eleven> i reboot
[19:38] <seven-eleven> i cant pastebin because i dont have a connection, so I write it 1:1 http://dpaste.com/0R0RKCT
[19:40] <lordcirth> seven-eleven, is that the host or the guest?
[19:40] <seven-eleven> ah thats the guest
[19:40] <seven-eleven> a moment
[19:41] <seven-eleven> https://termbin.com/1ixi
[19:41] <seven-eleven> ohhh
[19:41] <seven-eleven> found the mistake!
[19:42] <seven-eleven> it's actually libvirt issue
[19:42] <seven-eleven> libvirt automatically adds vnet1 to br5, so now we have enp0s316.5 and vnet1 inside br5
[19:43] <lordcirth> And you wanted 2?
[19:43] <seven-eleven> nope
[19:44] <lordcirth> I thought you wanted vlan 2, but there's no enp0s31f6.2. Was it 5 you wanted?
[19:44] <seven-eleven> ah, two interfaces dont matter regarding tagged vlan, would have to be two vlans inside br5 to be considered tagged?
[19:44] <seven-eleven> i wanted vlan 2
[19:44] <seven-eleven> but the problem is if I set it to vlan 2 then br0.2 stops working
[19:45] <lordcirth> seven-eleven, if the switch port is tagged, it's tagged, even if there's only 1 vlan
[19:45] <seven-eleven> i had to delete enp0s31f6.2 to get my LAN back working
[19:45] <seven-eleven> gotcha
[19:45] <seven-eleven> so I need to get the vm to use vlan 2
[19:46] <lordcirth> But the host also needs an IP on vlan 2?
[19:46] <seven-eleven> that means I have to remove br0.2, rewrite my iptables to source through br2
[19:46] <seven-eleven> yes
[19:46] <seven-eleven> the host itself needs an ip
[19:46] <seven-eleven> i would add it to br2 right?
[19:47] <lordcirth> I would create a enp0s31f6.2, which is an untagged interface. Then tie it to 'br2'. Then set an IP for the host on br2, and attach the VM's eno3 to br2 as well
[19:47] <seven-eleven> so i would do something like http://dpaste.com/00YW181 ?
[19:48] <seven-eleven> ok i retry this :-)
[19:50] <seven-eleven> lordcirth, should I move br0.3 to enp0s31f6.3 respectively or leave it as br0.3?
[19:50] <seven-eleven> br0.3 is not used for guests, br0.3 goes directly to the WAN router
[19:50] <seven-eleven> br0.3 is tight via br0 to enp0s31f6
[19:51] <seven-eleven> not sure if br0.3 can coexist with using enp0s31f6.2
[19:51] <seven-eleven> i will just try
[19:53] <lordcirth> seven-eleven, the paste looks correct, assuming you use '2' instead of '5' and that the enp0s31f6.2 interface is also correct
[19:53] <seven-eleven> lordcirth, ok
[19:54] <seven-eleven> lordcirth, so i leave br0.3 tied to br0
[19:54] <seven-eleven> and use now br2
[19:54] <lordcirth> I am not sure how your network is set up for br0.3
[19:54] <seven-eleven> br0.3 is in the subnet of my WAN router
[19:55] <seven-eleven> br0 is tied to eth0
[19:55] <seven-eleven> br2 is now tied to eth0.2
[20:49] <seven-eleven> lordcirth, works fine. now it's properly configured, so much easier to just configure eth0 on the guests, and makes auto installing easier
[20:49] <seven-eleven> thx! :-)
[20:49] <lordcirth> seven-eleven, great, you're welcome


[00:08] <racarr> annnnd race resolved
[03:21] <thomi> anyone awake in here? RAOF perhaps?
[03:23] <thomi> I'm pretty sure I've found another race condition in mir - this time in the client library. :-/
[08:19] <alan_g> alf__: re Thomi's email "Mir client library thread safety" - shall I deal with this one?
[08:20] <alf__> alan_g: I haven't started looking into it yet, so feel free to take it
[10:38] <hikiko> wow what sort of magic does boost and when you assign a foo shared ptr to a bar shared ptr the ptr has knowledge of the correct type?
[10:38] <hikiko> it's not based at the template parameter at all
[10:39] <hikiko> :s/boost/std now :)
[10:48] <alan_g> hikiko: the first "magic" pointer was this one http://www.octopull.co.uk/arglib/TheGrin.html - shared_ptr is clever - it also allows a user defined deleter
[10:50] <hikiko> yes yes!! i just saw the boost documentation hehe :) but i can't imagine how the hell they implemented it!!!
[10:51] <hikiko> i tried without the make shared to see where's the magic and it was in the assignment, then I found the doc but still!! i don't understand it!
[10:51] <hikiko> I got how it works though :) cool!!!
[10:52] <alan_g> :)
[10:58] <alan_g> hikiko: have you seen https://code.launchpad.net/~alan-griffiths/mir/Wno-non-virtual-dtor/+merge/165551 ?
[11:01] <hikiko> oh no I didn't :) I started geting mir notifications today, that's cool :D
[11:01] <hikiko> so, you get a warning
[11:01] <hikiko> immediately
[11:01] <hikiko> btw alan_g does it happen to you to trigger internal compiler errors with gcc 4.7?
[11:02] <alan_g> It happens to everyone
[11:02] <hikiko> cool :) i am not the only one :)
[11:02] <alan_g> Is a bug in 4.7.2
[11:03] <hikiko> i switch to clang from time to time, when I have no info about the error at all
[11:04] <hikiko> but i hope they fix it soon!
[11:04] <alan_g> hikiko: it is fixed upstream
[11:05] <hikiko> oh cool then I can just compile the new version
[11:07] <alf__> alan_g: hikiko: I have 4.7.3 (from raring archives) and I haven't seen compiler errors for a while. I am not sure if 4.7.3 contains the fix, or I have been lucky enough not to trigger them...
[11:11] <alan_g> alf__: it is fixed in 4.7.4 (and 4.8_
[11:13] <alf__> alan_g: perhaps the fix has been backported to the ubuntu 4.7.3 packages?
[11:15] <alan_g> alf__: no, you've just not compiled bad code
[11:15] <alf__> alan_g: ok
[11:16] <hikiko> hmm i have 4.7.3
[11:17] <hikiko> maybe i have to compile the 4.7.4 :)
[15:00] <kdub> good morning, status, working on swapinterval 0 for clients
[15:01] <alan_g> Good afternoon. status tweaking code to get the customisation points I want
[15:05] <alf__> kdub: does that involve BufferSwapperMultiSpin?
[15:05] <kdub> alan_g, alf__ with adding a swapping algorithm for swapinterval0, i'm weighing 1) just making BufferSwapperMulti more capable or 2) making BufferBundleSurfaces able to change between different algorithms
[15:05] <kdub> thoughts?
[15:06] <kdub> i'm sort of leaning towards 2), just because we'll have resizing, composition bypass, synchronous and asynchronous modes
[15:07] <alan_g> kdub: changing algorithms is something that might help switching to/from composition bypass
[15:07] <alf__> status: investigating performance issues in Mesa (for some reason we wait for a GPU fence for ~5ms every frame, which doesn't happen for X11)
[15:08] <alf__> kdub: I vote for (2), too. Btw, in order to get some performance numbers for the Mesa investigation I hacked together a spin version of BufferSwapper (not properly validated or tested though)
[15:08] <alf__> kdub: I can push it somewhere if you are interested
[15:09] <alan_g> kdub: for the avoidance of doubt: +1 for 2
[15:10] <kdub> alf__, yeah, that sounds useful for looking at android performance in the meantime
[15:11] <alf__> kdub: ... or if your plate is full, I can take on the spin bufferswapper work
[15:13] <kdub> alf__, i think today i'll focus on making the mc::BufferBundleSurfaces switch between mc::BufferSwapper algorithms
[15:13] <kdub> so if on monday you want to write a mc::BufferSwapperSpin : public mc::BufferSwapper, that sounds like a good parallelization of work :)
[15:14] <alf__> kdub: sounds good to me, too :)
[15:15] <alan_g> sounds excellent to me too. ;)
[15:17] <alan_g> kdub: what's the motivation for mga::GraphicBufferAllocator (AFAICS it adds alloc_buffer_platform(), which doesn't really do anything other than expose a different interface to what alloc_buffer() already does).
[15:18] <kdub> alan_g, admittedly its a bit weird... but there's a mc::BufferUsage and an mga::BufferUsage, with the only difference being that mga::BufferUsage has a framebuffer type
[15:19] <kdub> that android needs to allocate in the android platform, and in the review of the branch, we decided not to put the use_framebuffer type in mc::BufferUsage, because its not relevant to gbm
[15:23] <alf__> kdub: alan_g: IIRC, the reason was because BufferUsage::framebuffer was not relevant to/needed by the compositor interface, it is an internal Android flag.
[15:23] <alan_g> kdub: OK, that fine point was eluding me. So the real question then is should we really be extending the mc::GraphicBufferAllocator interface to give us an interface for allocate frame buffers. (Or should that be a different interface.) *Thinks..."
[15:29] <kdub> oh, also, us bank holiday on monday
[15:31] <alan_g> kdub: uk too
[15:31] <alan_g> And the sun has just come out here...
[15:32] <alf__> hikiko: Hi! Any news about the VT runtime issue we were discussing yesterday? I am curious about what could be going on there.
[15:33] <alf__> alan_g: The cosmos is telling you to end your week/day ;)
[15:33] <alan_g> alf__: the cosmos has to wait - I want to get something finished first. ;)
[15:35] <alf__> alan_g: :)
[15:39] <hikiko> lol @alan, alf__ sorry i am busy with something this very moment I'll ping you later
[15:52] <alf__> hikiko: np
[15:56] <kgunn> kdub: alf ....read the scroll back, just wondering....the reason to create a mga::BufferUsage was to avoid having an android flag in the compositor ?
[15:56] <kgunn> but conceptually...it just means "this is a frame buffer"
[15:56] <kgunn> right?
[15:57] <kdub> right, but gbm doesn't need to make a distinction
[15:57] <kgunn> kdub: sure....but it doesn't hurt to have that info along for the ride either does it ?
[15:57] <kgunn> note...you can tell me, too late...don't unearth this :)
[15:58] <kgunn> just thinking that offscreen & fb's have so much in common...
[16:00] <kgunn> kdub: back to alan_g 's question about should it have a seperate interface for fb alloc
[16:00] <kgunn> i suppose to match it should
[16:00] <alan_g> kgunn: I've already split the interfaces on my WIP - don't think too hard about it.
[16:02] <kgunn> :)
[16:02] <kgunn> alan_g: i might hurt myself
[16:03] <alan_g> kgunn: I hope that's not a threat. ;^)
[16:03] <alf__> kgunn: the reason for mga::BufferUsage, isn't so much that gbm doesn't need the flag. It's that the compositor interface (which mc::BufferUsage is part of) doesn't need the flag. We would be adding a flag to the external interface just to service an internal need of an unrelated component. Of course, this may change if we want to allow external (to the compositor) entities to ask for framebuffer surfaces.
[16:04] <alf__> kgunn: (to ask the compositor components for fb surfaces)
[16:05] <kgunn> alf__: thanks, makes sense.... (you guys prob consider sloppy, but i don't mind having things for "other clients" in api's)
[16:07] <alan_g> kgunn: it depends on the type of API - here we're defining the *minimum* needs of compositor to minimise coupling.
[16:07] <kgunn> actually making me think...so would control for going in/out of bypass lie in the unity-mir layer ?
[16:08] <kgunn> e.g. is the compositor going to be smart (oh you're opaque & full screen)...or dumb (special wm client, you tell me when you want to go straght to fb)
[16:11] <kdub> off the top of my head, i'd say it wouldn't bypass the unity-mir layer, (be dumb)
[16:11] <alan_g> kgunn: I don't need to decide that (yet). ;)
[16:11] <kdub> yeah, we haven't grappled with the question fully
[16:11] <kdub> yet!
[16:13] <alan_g> 1. Get a CB mode working  2. Get CB mode switchable 3. Decide how to chose CB mode.
[16:14] <kgunn> alan_g: ;) sure...i just enjoy topics like this
[16:15] <alan_g> kgunn: np this is how I get informed before the decision needs to be made
[16:15] <kgunn> :)
[17:03] <alan_g> And the sun has just come out here...(again - following dark clouds and heavy rain). Must be time to go.
[17:06] <alan_g> kdub: kgunn - have a good holiday weekend!
[17:06] <kdub> you too alan_g|EOW
[17:19] <kgunn> alan_g|EOW: you too
[17:24] <kdub> i'm tempted to name this class mir::compositor::SwapperSwapper
[17:48] <racarr> kdub: For resizing?
[17:49] <racarr> I thought about a swapperswapper once XD
[17:49] <kdub> i think SwapperSwitcher is a better name
[17:50] <racarr> yes probably
[18:32] <racarr> just drudging through some clean up, resolving little todos I left around on this input branch
[18:33] <racarr> fixed the race in the acceptance test though, and touch input picking with multiple clients is working well :)
[19:01] <racarr> :D
[19:02] <racarr> completely removed the mir::input::android namespace
[19:02] <racarr> from default server configuration
[20:12] <racarr> Lunch/laundromat time!
[22:48] <racarr> My present for all of you to joyfully review come monday: https://code.launchpad.net/~robertcarr/mir/rebuild-input-targeting/+merge/165712 ;)
[23:04] <kdub> only the runner up to the biggest diff this month :)
[23:04] <kdub> after glm removal
[23:06] <racarr> kdub: XD. Besides the acceptance test it's actually
[23:06] <racarr> pretty balanced in +/-
[23:06] <racarr> it's just different
[23:06] <racarr> it just made me giggle when I checked at the end...


[15:13] <PC> Hi evertyone
[15:13] <PC> i newbie on his room
[15:13] <PC> anyway Hi everybody
[15:18] <nordo> i want to create my own installer based on ubiquity
[15:18] <nordo> or contribute on ubiquity
[15:19] <nordo> the important for me is to be good on on programming an installer
[15:25] <cyphermox> nordo: installers are hard. if you want to start contributing, pick some bug you find while testing and try to fix it
[15:44] <nordo> the idea behind this choose is i've created my own distro LFS
[15:44] <nordo> and im very family with ubuntu and debian
[15:45] <nordo> and currently i would to do a good thing in linux by understand the installer
[15:45] <nordo> really i love the design of ubiquity
[15:46] <nordo> it's very easy and i know that he hide difficult thing behind this design
[15:46] <nordo> i want some advise
[15:46] <nordo> or help to continue my way

[16:02] <nordo> are you still here
[16:02] <cyphermox> yes
[16:02] <cyphermox> there isn't much to say there, just pick something you're interested in and ask specific questions
 okay
[16:39] <nordo> now when i can start
[16:39] <nordo> to personalize ubiquity
[16:40] <nordo> where i can start
[16:40] <nordo> to personalize ubiquity
[16:40] <nordo> and sorry for this question


[15:26] <tseliot> tjaalton: can you have a look at the nvidia-glx-dev.postrm.in of the lrm, please?
[15:26] <tseliot> maybe it's just my impression but I think there's something wrong with them
[15:28] <tseliot> for example shouldn't be looking for /usr/lib/libGL.so in the 1st diversion instead of /usr/lib/nvidia/libGL.so.xlibmesa ?
[19:04] <tjaalton> tseliot: no it's correct
[19:05] <tjaalton> hmm
[19:07] <tjaalton> it doesn't seem to remove the diversion of /usr/lib/libGL.so
[19:14] <tjaalton> ah
[19:15] <tjaalton> wrong package
[19:24] <tjaalton> tseliot: it's irrelevant which one dpkg-divert lists, they both give the same result
[20:18] <tseliot> yes, I tried to say 2 things at the same time. I wanted to say that it should remove the diversion made by the -dev package
[20:23] <tseliot> tjaalton: the other problem which I wanted to report might be specific to my own packages (nvidia-glx.postrm.in) . I have yet to see if the same problem affects the default lrm. I'll let you know if it does.
[21:39] <tjaalton> tseliot: it does remove them all
[21:44] <tseliot> tjaalton: in my packages (for some reason) /usr/lib32 is removed before the diversions are removed. It might depend on my rules though. The .postrm itself is ok.
[21:48] <tjaalton> ok
[23:56] <pwnguin> are the openGL manpages under an evil license?
[23:59] <jcristau> if by evil you mean not free, then yes, iirc


[05:07] <JamesGeek1> Hello World!
[05:18] <malv> https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1008682 < Bug is hurting the Xubuntu experience
[06:18] <knome> mr_pouit, micahg: can you look at bug #1008682? i can confirm it, and it *is* annoying, and should be fixed asap
[06:19] <knome> (i know i linked a duplicate, but the desription is better than in the original)
[06:20] <micahg> knome: ask the desktop team about it
[06:21] <micahg> hrm, doesn't do it in unity
[06:55] <ochosi> i'm wondering whether people can confirm it with ambiance
[06:56] <ochosi> it's not impossible that there is a setting in the gtk3-file
[06:56] <ochosi> (i already noticed this bug/behavior pre-precise, so i switched of "move window by dragging toolbar", obviously that wasn't the issue)
[06:57]  * micahg can't debug more ATM
[07:00] <ochosi> ambiance has set "-GtkWidget-window-dragging: true;" for both .menubar and .primary-toolbar
[07:01] <ochosi> since i thought the problem would be the toolbar, i switched that off
[07:01] <ochosi> i can also switch off the menubar-dragging, maybe it's somehow misbehaving with xfwm4 and is therefore not reproducible with unity
[07:05] <ochosi> ok, maybe we have to switch off the resize-grip (ambiance doesn't show one, so another reason why it wouldn't happen on unity)
[07:07] <ochosi> meh
[07:14] <ochosi> knome: please try to disable the resize-grip in greybird (gtk-widgets.css, search for "-GtkWindow-resize-grip-default" and set to false)
[07:14] <ochosi> bbl
[07:18] <knome> ochosi, we're leaving soon, i'll do that on Fri
[07:21] <astraljava> Ahh... so that's why you're up this "early".
[07:30] <knome> astraljava, yes.
[07:30] <knome> :)
[07:41] <knome> ok, off until Fri. see you!
[07:47] <ochosi> hehe
[07:47] <ochosi> knome: hf!
[18:30] <cc_INC> There is a meeting on Wednsday, June 13th but on the wiki it says Wednesday, June 16th
[18:30] <cc_INC> Is this a mistake?!
[18:30] <pleia2> what calendar are you looking at?
[18:31] <cc_INC> I would love to join the community meeting but I can't make it :(
[18:31] <cc_INC> https://wiki.ubuntu.com/Xubuntu/Meetings
[18:31] <pleia2> I see, there is some confusion here
[18:32] <pleia2> the email to the list said the 13th
[18:32] <pleia2> the 16th isn't a Wednesday, the 13th is
[18:32] <pleia2> so it looks like the wiki is confused
[18:32] <cc_INC> It states, I quote: The next meeting is on Wednesday, June 16th at 15:00 UTC on #xubuntu-devel in the Freenode IRC network (chat.freenode.net). But my birthday is on Thursday the 14th :) 16th of June is on Saturay
[18:32] <pleia2> yeah, evne the link says the 13th
[18:32] <pleia2> fixing the wiki
[18:33] <cc_INC> Haha, don't want to be a pain in the behind or anything :)
[18:33] <pleia2> thanks, it's the 13th :)
[18:33] <cc_INC> I was hoping it was on Saturday, so I can attend the meeting until I checked the link to see my time zone
[18:34] <cc_INC> I guess I'll just read the meeting minutes and keep spreading the gospel of Xubuntu.
[18:34] <pleia2> we're having a QA meeting on Sunday if you're interested in that
[18:34] <pleia2> the 17th
[18:35] <cc_INC> What time is that scheduled?
[18:35] <Unit193> Can we embed the calendar in the website, or would that not be as helpful as I'm lead to think?
[18:37] <pleia2> cc_INC: 16:00 UTC
[18:37] <cc_INC> I think a link is sufficient....the website looks so sleek and clean....
[18:37] <pleia2> Unit193: website is mostly for customer-facing
[18:38] <Unit193> Figured. :/
[18:38] <cc_INC> Would be shame to crowd it :)
[18:38] <pleia2> if we actually manage to maintain this calendar, we should link it to the wiki somewhere
[18:39] <Unit193> So I can just nag you and knome if you forget, right? :D
[18:43] <cc_INC> Anyone here going to Linuxcon Europe?!?
[18:44] <Unit193> I hope to make OLF this year though.
[18:45] <pleia2> Unit193: yeah, and if we aren't good at it we'll add you as an editor ;)
[18:46] <cc_INC> Looking for Xubuntu-addicts who are also gonna head to Linuxcon for a little meet n' greet
[18:47] <cc_INC> Oh before I forget I'm in the process of writing down directions to getting Xubuntu on a Power Mac G5. a) is it usefull and b) if so, who do I submit it to?!
[18:48] <pleia2> probably something like https://help.ubuntu.com/community/Installation/PowerPC/Xubuntu
[18:48] <pleia2> and then link it to https://help.ubuntu.com/community/Installation/PowerPC
[18:51] <cc_INC> Okay. I need to login @ Launchpad to be able to create a page?!?! Sorry for being such a N00b, but besides a few bugs I have not done anything at all with Launchpad :(
[18:52] <pleia2> no need to use so many ?!s :) and it uses Ubuntu Single Signon
[18:53] <pleia2> clicking "Login to edit" should redirect you to a page with instructions if you don't have an account
[18:54] <cc_INC> GREAT!!! Thanks pleia2 very much appreciated.
[18:54] <pleia2> sure
[18:56] <cc_INC> You guys rock! Keep the vibe alive! I'm off to get some stuff done. Talk to you soon.