[00:12] <amurray> mbuhl: hey, thanks for the feedback on the podcast - fwiw I was also thinking it might be better to go back to the previous format anyway


[00:00] <asac> i would rank nsCSSFrameConstructor at least at #2
[00:15] <Ubulette> did you follow the memory fragmentation threads in ff3 ?
[00:17] <Ubulette> the last one is http://blog.pavlov.net/2007/12/04/vlad-and-analysis-of-dtrace-was-used/
[00:18] <Ubulette> 1st was http://blog.pavlov.net/2007/11/10/memory-fragmentation/
[06:35] <[reed]> asac / Ubulette: ping
[07:39] <asac> [reed]: ?
[07:39] <[reed]> asac: so, looks like we're going to have (for now) a build dependency on libgnomeui-dev but not a runtime dependency
[07:39] <[reed]> for Fx3
[07:40] <asac> cool
[07:40] <asac> (or not so cool, depending on what is done now :))
[07:40] <[reed]> so, I guess some rules file on your side will need to be updated with that
[07:40] <[reed]> well, until a patch landed today, it was both a build+runtime dependency ;p
[07:41] <[reed]> now just a build
[07:44] <asac> ok i see
[07:48] <asac> [reed]: do you have any screenshot how ffox 3 beta looks like on win?
[07:48] <asac> or is it still the same theme as before on windows?
[07:49] <[reed]> asac: same as before
[07:49] <[reed]> for now
[07:49] <[reed]> the new theme hasn't landed
[07:49] <[reed]> it's still in-progress
[07:49] <[reed]> win is way behind Linux and Mac this time
[07:50] <asac> but its the same direction? e.g. use stock icons?
[07:50] <[reed]> no
[07:50] <[reed]> only Linux is using stock icons
[07:50] <[reed]> both mac and win aren't
[07:50] <asac> ok, so the windows theme can probably used under linux as well?
[07:51] <[reed]> yes
[07:51] <asac> ok thats important
[07:51] <[reed]> why? :)
[07:51] <[reed]> who wants to use winstripe?
[07:51] <asac> one main argument to use firefox in distros is to provide a bridge for window users
[07:51] <[reed]> when you could use gnomestripe!
[07:51] <asac> so they feel like "home" when browsing
[07:51] <[reed]> ew
[07:52] <[reed]> but the new winstripe is going to be radically different, as far as using icons that will look completely out of place on Linux
[07:52] <[reed]> they will be very much XP/Vista based
[07:52] <asac> hmm
[07:52] <[reed]> and icons will be different between XP and Vista
[07:52] <asac> and new mac theme will be completely different as well?
[07:53] <[reed]> yes, it will look like a normal OS X app
[07:53] <asac> ok, lets hope that users that switch from win to linux to mac can still recognize each app as firefox
[07:53] <asac> (which is the main point of having the same theme everywhere i guess)
[07:54] <[reed]> yeah, did you read faaborg's blog post on that?
[07:54] <asac> nope :) ... its just my concern about all this :)
[07:54] <[reed]> let me get the link
[07:54] <asac> you have an url?
[07:54] <[reed]> yeah
[07:54] <[reed]> that's what I meant by "the link"
[07:54] <[reed]> :)
[07:55] <[reed]> one sec
[07:55] <[reed]> http://blog.mozilla.com/faaborg/2007/11/15/the-shape-of-things-to-come/
[07:56] <[reed]> read the "Platform Integration vs. Cross Platform Identity" part
[07:56] <asac> thanks
[07:57] <[reed]> and have a laugh at faaborg's expense on the phallic symbol he attempts to use as a demonstration
[07:57] <[reed]> s/on the/at the/
[08:08] <asac> lets see how this "shape for X-platform identity" will work out.
[08:28] <Ubulette> hey guys
[08:28] <Ubulette> doesn't xulrunner 1.8.1.* deserve a security update like ff2 ?
[08:31] <asac> it does ... but its in universe :)
[08:31] <Ubulette> !info xulrunner debian
[08:31] <ubotu> xulrunner: XUL + XPCOM application runner. In component universe, is optional. Version <IP_ADDRESS>-2ubuntu5 (gutsy), package size 273 kB, installed size 980 kB
[08:31] <asac> didn't we update xulrunner for <IP_ADDRESS>
[08:31] <asac> ?
[08:32] <Ubulette> I did <IP_ADDRESS> 2 or 3 weeks ago
[08:32] <Ubulette> a merge from debian
[08:32] <Ubulette> !info xulrunner unstable
[08:32] <ubotu> xulrunner: XUL + XPCOM application runner. In component main, is optional. Version <IP_ADDRESS>-1 (unstable), package size 270 kB, installed size 964 kB
[08:33] <asac> right ... there is a new merge waiting :)
[08:33] <asac> http://merges.ubuntu.com/universe.html
[08:33] <Ubulette> !info xulrunner experimental
[08:33] <ubotu> xulrunner: XUL + XPCOM application runner. In component universe, is optional. Version <IP_ADDRESS>-2ubuntu5 (gutsy), package size 273 kB, installed size 980 kB
[08:33] <asac> <IP_ADDRESS>-1
[08:33] <Ubulette> I think i'll do it then
[08:33] <Ubulette> unless someone beat me to it
[08:33] <asac> but still thats not a security update for gutsy
[08:34] <Ubulette> !info xulrunner gutsy
[08:34] <ubotu> xulrunner: XUL + XPCOM application runner. In component universe, is optional. Version <IP_ADDRESS>-2ubuntu5 (gutsy), package size 273 kB, installed size 980 kB
[08:34] <Ubulette> why ?
[08:34] <asac> yeah ... upgrading from <IP_ADDRESS> to <IP_ADDRESS> is a huge bump
[08:35] <asac> well ... xulrunner isn't used as gecko provider in gutsy
[08:35] <asac> so i apparently just merged it once during gutsy cycle
[08:38] <Ubulette> ftp://ftp.mozilla.org/pub/xulrunner/releases/  lol
[08:39] <asac> yeah ... they don't provide updates ;)
[08:45] <Ubulette> ok, i'm leaving for work
[08:45] <Ubulette> asac, if you have the chance, could you please see with persia for prism ? he'll be gone when I'll return
[09:01] <asac> Ubulette: will do
[10:25] <asac> Ubulette: ok i advocated prism
[10:25] <asac> maybe ask for upload in -motu if nothing happens
[10:40] <armin76> bumb
[10:42] <asac> ?
[10:51] <asac> [reed]: any idea what is planned for self-signed certs?
[10:51] <asac> will it stay the way its currently handled?
[10:51] <[reed]> I don't see why not. It seems fine to me
[10:51] <[reed]> you can easily accept them
[10:51] <asac> (e.g. just get an error page that tells you to add the domain to exceptions)
[10:51] <asac> how?
[10:52] <asac> there is no user-guidance to do that (last time i looked)
[10:52] <[reed]> look again
[10:52] <[reed]> :)
[10:52] <asac> in b2?
[10:52] <[reed]> in a current nightly, yes
[10:52] <[reed]> but most of this was in b1
[10:52] <[reed]> some new stuff has been added
[10:53] <[reed]> we haven't really had complaints about it at all since the exception stuff was added
[11:00] <asac> oh ... latest-nightly doesn't have any icons at all for me here :)
[11:00] <asac> (any of those that are stock ones now)
[11:01] <asac> [reed]: ok the exception thing is now fine
[11:01] <asac> thanks
[11:01] <[reed]> hmm
[11:01] <[reed]> oh, latest-nightly
[11:01] <[reed]> check back tomorrow :)
[11:02] <[reed]> you must not have libgnomeui installed
[11:02] <[reed]> by tomorrow, I mean in two hours or so
[11:02] <[reed]> when nightlies run ;)
[11:03] <asac> i am running gnome
[11:03] <asac> so i have libgnomeui
[11:03] <[reed]> are you sure?
[11:03] <[reed]> are you 64-bit?
[11:03] <asac> yes
[11:03] <asac> right :)
[11:03] <asac> i remember now
[11:04] <[reed]> ubotu: 162993
[11:04] <ubotu> Sorry, I don't know anything about 162993 - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[11:04] <[reed]> lp ubotu: 162993
[11:04] <[reed]> er
[11:04] <asac> [reed]: btw, the exception dialog rocks imo ... but i am not a usability expert
[11:04] <[reed]> lp 162993
[11:04] <ubotu> Launchpad bug 162993 in firefox "ia32-libs missing 32-bit gnome libraries needed for gtk stock icons" [Unknown,Fix released] https://launchpad.net/bugs/162993
[11:04] <[reed]> but the fix made today should help you, too
[11:04] <asac> [reed]: so which icons should be used if there is no libgnomeui?
[11:05] <[reed]> check out an hourly
[11:05] <[reed]> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/fx-linux-tbox-trunk/firefox-3.0b2pre.en-US.linux-i686.tar.bz2
[11:05] <[reed]> check that out
[11:05] <[reed]> see if you have icons
[11:06] <asac> [reed]: ok one more thing ... will the great new addons manager happen for firefox 3.0?
[11:06] <[reed]> define "great new addons manager"
[11:06] <asac> do you know what i refer to?
[11:06] <[reed]> not really
[11:06] <asac> let me see if i can find it
[11:06] <[reed]> there's work to be done on it, such as integration with AMO
[11:06] <[reed]> but most stuff has already been done besides that
[11:08] <asac> [reed]: "great new..." == http://wiki.mozilla.org/Firefox:Add-ons_Manager_UI
[11:09] <[reed]> yeah, that's the AMO integration
[11:09] <[reed]> that's coming
[11:09] <[reed]> it's blocked on AMO actually getting a working API
[11:09] <[reed]> which is about 99% done
[11:09] <asac> [reed]: ok, point is i talked with mconnor about getting an apt backend into source base
[11:09] <[reed]> like what ubufox has?
[11:09] <asac> problem was that nothing had happened at that time so we agreed to revisit when things are there
[11:10]  * [reed] actually has never used ubufox
[11:10] <asac> yes, but for real ... like a multi-backend so you can add other search databases
[11:10] <asac> and install methods
[11:10] <asac> so the backend is already there?
[11:10] <[reed]> I've never used any distro-made Mozilla product
[11:10] <[reed]> hehe
[11:10] <[reed]> either Mozilla official or build my own :)
[11:10] <[reed]> anyway
[11:10] <[reed]> what backend?
[11:10] <[reed]> apt?
[11:10] <asac> you should ... ubuntu rocks for mozillas :)
[11:10] <[reed]> nah, you are too far behind :)
[11:10] <asac> no ... the backend for AMO
[11:11] <[reed]> ah
[11:11] <[reed]> not in the browser, no
[11:11] <[reed]> I don't think so, at least
[11:11]  * [reed] looks
[11:11] <asac> well, we provide 3.0 builds for you ... but I guess you want nightlies :)
[11:12] <[reed]> considering I commit fixes myself, I want to be able to use those fixes asap
[11:12] <[reed]> :p
[11:12] <[reed]> are there any changes that you've made for ubuntu that are general enough to go upstream?
[11:12] <[reed]> for Firefox
[11:12] <[reed]> I really want to make sure you are upstreaming stuff
[11:14] <[reed]> mozilla bug 404024
[11:14] <ubotu> Mozilla bug 404024 in Extension/Theme Manager "Add AMO integration pane" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=404024
[11:14] <[reed]> so, doesn't look like work has started
[11:14] <asac> [reed]: thats the idea ... i want to do it general enough, but for that I wanted code that is at least close to final
[11:16]  * asac looking at bugs
[11:16] <[reed]> anyway
[11:16] <[reed]> I have an exam in less than 4 hours
[11:16] <[reed]> and I haven't studied
[11:16] <[reed]> so
[11:16] <[reed]> later :)
[11:16] <asac> [reed]: ok thanks for the info so far ... cu later :)
[11:16] <asac> good luck
[11:16] <asac> better start to switch context now I guess
[12:22] <[reed]> bad armin76 for making me look at Firefox stuff
[12:22] <[reed]> armin76: bsmedberg already gave you sr+
[12:22] <[reed]> so, you can just set sr+ yourself as a carryover
[12:23] <[reed]> I'm gone again
[12:23] <armin76> err
[12:23] <armin76> he said i should sr him with that change?
[12:26] <[reed]> no, he said you can have sr=bsmedberg if you make that change
[12:26] <[reed]> you made it, he already granted it with the understanding that you would make it
[12:26] <[reed]> so, you can carry it over
[12:26] <[reed]> so, you just need review from timeless
[12:26] <[reed]> as you already have superreview from bsmedberg
[12:29] <armin76> ah
[12:29] <armin76> sorry, i'm not used to this stuff
[18:28] <BUGabund1> hya
[18:28] <BUGabund1> any FF devs here?
[18:28] <BUGabund1> just got a strange error on an hardy test machine
[18:42] <Ubulette> back
[18:43] <Ubulette> BUGabund1, just ask your question, instead of waiting for an ack ;)
[20:12] <Ubulette> asac, http://archive.ubuntu.com/ubuntu/pool/universe/s/seamonkey/  ?? i don't get it. where are the debs ?
[20:24] <asac> no idea :)
[20:24] <asac> in queue nEW ?
[20:25] <asac> maybe there is an archive issue?
[20:31] <Ubulette> no, they are DONE
[20:43] <Ubulette> asac, i've merged xul. building.. if it's ok, i'll post a debdiff or an interdiff
[21:10] <asac> good
[21:48] <Ubulette> done
[21:50] <Ubulette> asac, bug 174219
[21:50] <ubotu> Launchpad bug 174219 in xulrunner "Please merge xulrunner <IP_ADDRESS>-1 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/174219
[22:08] <Ubulette> i wanted to merge ruby-gnome2 (so it unlocks kaze on some arches) but it's a sync, not a merge
[22:31] <asac> Ubulette: he?
[22:31] <Ubulette> ?
[22:31] <asac> Ubulette: you have to request a sync then
[22:31] <Ubulette> bug 174243
[22:31] <ubotu> Launchpad bug 174243 in ruby-gnome2 "Please sync ruby-gnome2 0.16.0-10 (universe) from Debian Sid (main)" [Undecided,New] https://launchpad.net/bugs/174243
[22:32] <asac> ok
[22:32] <asac> have you followed procedures in wiki?
[22:32] <Ubulette> i think so
[22:32] <asac> ok
[22:32] <Ubulette> but that's not fun
[22:33] <asac> hmm .. shouldn't you subscribe some other role as well?
[22:33] <asac> ah you need someone to confirm first, right?
[22:33] <asac> then subscribe ubuntu-archive ?
[22:34] <Ubulette> no, for the sync, i'm done. motu will subscribe ubuntu-archive
[22:34] <asac> k
[22:35] <asac> does the previous merger know about that?
[22:35] <Ubulette> that's bluekuja, he told me a while ago "fell free to do it"
[22:37] <asac> hell ... when did i get the merge for igerman98
[22:37] <Ubulette> ?
[22:39] <asac> i am listed as last merger of that package on main.html


[00:01] <Daekdroom> !daily
[10:58] <BluesKaj> 'Morning all
[13:59] <BluesKaj> BBL
[17:48] <shay_shay_> http://hastebin.com/upudopobik.vhdl
[17:49] <shay_shay_> is this just a case of this package hasnt been packaged for utopic yet?
[17:49] <shay_shay_> if so, i'm okay with waiting this pc is right next to the router :P
[17:50] <penguin42> shay_shay_: Try doing an apt-get update and trying again
[17:50] <penguin42> shay_shay_: That normally happens where your index says to get version x.y but there's now a newer version on the mirrors
[17:50] <shay_shay_> ah
[17:50] <shay_shay_> that must be the case. i was just installing things from a livecd
[17:51] <shay_shay_> working
[17:51] <shay_shay_> hah i am dumb
[17:51] <penguin42> no problem
[17:51] <shay_shay_> i'm surprised the gui driver selector doesnt apt-get update
[17:52] <shay_shay_> it was erroring out (silently) because of that
[17:53] <penguin42> yes, it seems silly not to
[17:53] <shay_shay_> utopic uses systemd correct?
[17:54] <shay_shay_> trying to restart my networkmanager with systemctl but its giving me "Failed to get D-Bus connection: No connection to service manager."
[17:59] <shay_shay_> oh i need systemd-sysv?
[18:02] <shay_shay_> odd
[18:02] <shay_shay_> root@ubuntu:~# ps -p 1 -o comm=
[18:02] <shay_shay_> init
[18:11] <shay_shay_> ubuntu@ubuntu:~$ sudo modprobe -r b43 ssb wl
[18:11] <shay_shay_> modprobe: FATAL: Module ssb is in use.
[18:11] <shay_shay_> any idea ... i need to unload those modules and then reload wl
[18:15] <shay_shay_> :/
[18:16] <shay_shay_> ahah!
[18:17] <shay_shay__> i figured it out
[18:18] <shay_shay__> ssb_hcd was depending on ssb module
[18:18] <shay_shay__> couldnt remove ssb without removing ssb_hcd first
[18:19] <shay_shay__> then wl loaded and i restarted networkmanager and BAM i could see all wifi ssids
[23:37] <shay_shay> hello
[23:40] <shay_shay> http://hastebin.com/pucovakipi.pas can i get some help with this please
[23:45] <mikeit> http://sourceforge.net/projects/corefonts/files/corefonts/1.3/
[23:49] <mikeit> this is an rpm repo
[23:49] <mikeit> shay_shay,
[23:49] <shay_shay> yes i am listening
[23:49] <shay_shay> and i'm reading the .spec
[23:50] <mikeit> you are what distro
[23:50] <shay_shay> ubuntu mate
[23:50] <mikeit> sorry for my english i'm italian
[23:50] <mikeit> ok
[23:50] <shay_shay> i'm on 14.10
[23:51] <mikeit> and for this ttf-mscorefonts-installer you are add an other repo?
[23:55] <shay_shay> http://packages.ubuntu.com/utopic/ttf-mscorefonts-installer
[23:58] <mikeit> gedit /etc/apt/sources.list and hastebin it


[07:10] <elfy> brainwash: 2 or 3 reboots/cold starts since yesterday - nothing with the unity-greeter
[08:41] <elfy> ali1234: I've forgotten what you said a while back - what is that's stopping indicator-applications from working in gtk3 ind panel?
[09:41] <brainwash> elfy: so you should add lightdm-gtk-greeter to the list of affected packages
[09:43] <brainwash> + a comment containing the package version
[10:32] <bluesabre> hey elfy, brainwash
[10:33] <bluesabre> go ahead and ping ochosi too
[10:33] <bluesabre> :)
[10:35] <bluesabre> I can start work on my fix for the graphical corruptions today
[11:03] <elfy> brainwash: funny that - did it this morning :p
[11:03] <elfy> hi bluesabre
[11:03] <bluesabre> hey elfy
[11:04] <bluesabre> how are things?
[11:04] <elfy> pretty good thanks - you?
[11:04] <bluesabre> same
[11:05] <bluesabre> setting up my new ubuntu vps
[11:05] <elfy> your graphical corruptions comment - is that this stuff = bug 1267742
[11:05] <bluesabre> yeah, that should be it
[11:05] <bluesabre> we had hoped that by properly setting the image with x, the problem would be resolved
[11:05] <elfy> okey doke - just checking - I know we spoke about it pre-xmas, but then I've not seen you much since
[11:06] <bluesabre> since it doesn't, I'm going back to using GtkImage assuming everything with that works correctly
[11:07] <elfy> I trust you to know that isn't gobbledygook :p
[11:07] <bluesabre> :D
[11:08] <elfy> bbs
[12:06] <ochosi> bluesabre: hm, what exactly is up? i feel like i've been missing something here..
[12:07] <bluesabre> ochosi: the graphical corruption in the login screen with nouveau and other drivers
[12:07] <ochosi> "with nouveau and other.."? :)
[12:07] <ochosi> = all drives?
[12:07] <ochosi> +r
[12:07] <bluesabre> and *potentially* other drivers
[12:07] <bluesabre> better? :)
[12:08] <ochosi> ah the garbled background
[12:08] <bluesabre> thats the one!
[12:08] <ochosi> well at least that doesn't make things unusable
[12:08] <ochosi> but it's a long-standing one
[12:08] <ochosi> and iirc there wasn't much we could do about it
[12:08] <ochosi> you added some workarounds but not sure they worked
[12:08] <bluesabre> the gtkimage branch I was using fixed it with gtk
[12:09] <ochosi> you used a gtkimage for the bg?
[12:09] <bluesabre> 1 gtkimage per display
[12:09] <ochosi> i see
[12:09] <ochosi> why not a window?
[12:10] <ochosi> or a gtkdrawing-area that we could draw into with cairo?
[12:10] <bluesabre> yeah, we could probably do that
[12:10] <bluesabre> I figured gtkimage was the simplest though
[12:10] <bluesabre> since we are already making a pixbuf, we set the image to that
[12:10] <ochosi> yeah, if we wanna forget about the cross-fading fast :>
[12:10] <bluesabre> true
[12:10] <ochosi> yeah, but from a pixbuf, drawing with cairo is just as easy
[12:11] <bluesabre> k, so that sounds reasonable then
[12:11] <ochosi> gdk_cairo_set_source_pixbuf(..); cairo_paint(cr);
[12:11]  * ochosi has done lotsa cairo stuff this week
[12:11] <ochosi> not sure you read it, but i implemented a proof-of-concept for making avatars circular
[12:12] <ochosi> we could also check how unity-greeter sets the background
[12:12] <bluesabre> yup
[12:13] <bluesabre> we could hack on that today
[12:13] <bluesabre> if you're around
[12:17] <elfy> hi ochosi
[12:22] <ochosi> bluesabre: yeah, i mam
[12:22] <ochosi> am
[12:22] <ochosi> :)
[12:22] <ochosi> brb, lunchtime
[12:22] <ochosi> hey elfy
[12:42] <ochosi> ok, i'm back
[12:42] <ochosi> elfy: whazzup?
[12:43] <ochosi> bluesabre: when is a good time for you? now?
[12:43] <bluesabre> ochosi: soon, migrating my server atm
[12:44] <ochosi> okeydokey, just ping me
[12:44] <ochosi> we should also look at what exactly we wanna fix in the greeter
[12:44] <ochosi> background drawing is one thing
[12:44] <ochosi> related is cross-fading, which i looked into last night
[12:44] <ochosi> and custom avatar-drawing, which is highly optional
[12:55] <elfy> ochosi: did you know I reported this bug yesterday and marked it as a security issue
[12:55] <ochosi> nope
[12:56] <elfy> I'd not ever thought of it like that till I restarted and came back to someone's forum login details/infractions/e-mail on the login screen
[12:56] <ochosi> but it's a kinda long-standing issue
[12:56] <elfy> yea - I remembered evntually last night seeing it with xmir
[12:57] <ochosi> we'll try to fix it for real this time
[12:58] <ochosi> i guess it'll take some refactoring of the code
[12:58] <elfy> :)
[13:01] <ochosi> maybe you can test something tomorrow or on monday
[13:02] <elfy> yep - not working here till Thursday (hopefully) so just shout out :)
[13:18] <ochosi> bluesabre: i just checked out unity greeter and it seems that everything is within one main window
[13:18] <bluesabre> makes sense
[13:19] <ochosi> we should probably refactor our code to do that as well...
[13:19] <bluesabre> since we're using cairo, we could do the same with GtkOverlay (but only once we kill gtk2)
[13:19] <ochosi> but it's a lot of refactoring to be frank
[13:20] <bluesabre> yup
[13:20] <ochosi> at least if we wanna put everything in one window
[13:20] <elfy> bluesabre: quick question re mugshot - I'm just checking the testcases, it assumes that it's installed - of course it's not there yet - is the PPA ok for people to use?
[13:21] <ochosi> alternatively we could probably also just create a background_window that we paint separately. that should work i think...
[13:21] <bluesabre> elfy, yes, the ppa should be fine. mugshot won't change much at all
[13:21] <elfy> ok - thanks
[13:21] <bluesabre> ochosi: yup, thats an option (and my gtkimage code should be a good basis for that)
[13:22] <ochosi> yeah, it's basically the same, just with a different widget
[13:22] <bluesabre> since its a GtkImage on a background_window
[13:22] <ochosi> the drawing routine is pretty much the same as what i added in the transparency branch#
[13:24] <elfy> bluesabre: except there's no trusty in there yet - can you do that before I do the call later in week?
[13:24] <ochosi> since we already have a global background pixbuf there, we can simply reuse it
[13:24] <bluesabre> elfy: oh! I'll do taht today
[13:24] <bluesabre> *that
[13:24] <bluesabre> ochosi: check if you can login: http://<IP_ADDRESS>/doku/doku.php
[13:25] <elfy> thanks
[13:29] <ochosi> phu, what was my pwd again :)
[13:29] <bluesabre> lol
[13:29] <bluesabre> my problem too :P
[13:30] <ochosi> ok, successfully logged in
[13:31] <bluesabre> cool
[13:31] <bluesabre> my site is almost transferred now :)
[13:32] <elfy> bluesabre: when you've got a mo - need to talk about mugshot bug
[13:32] <bluesabre> elfy: whats the bug?
[13:33] <elfy> no camera option
[13:33] <elfy> that's with the mugshot-dev-daily-trusty.list
[13:34] <ochosi> bluesabre: good, so we can start with the greeter soon :)
[13:34] <ochosi> bluesabre: imo, we should first finalize/merge the transparency branch, cause it'll help with the background stuff
[13:35] <bluesabre> ochosi: already merged
[13:35] <ochosi> oh :)
[13:36] <bluesabre> elfy, do you have gstreamer1.0-plugins-good installed?
[13:36] <elfy> yep
[13:37] <bluesabre> ok... :\
[13:37] <bluesabre> I'll get back to you on that
[13:38] <elfy> ok - no rush, if I have to I'll make a note in the testing call not to worry about the camera for the moment
[13:39] <elfy> bluesabre: also there is the help bug for it too - jjfrv8 reported that one recently
[13:40] <bluesabre> elfy: yeah, probably going to get rid of the help button altogether
[13:42] <elfy> :)
[13:42] <elfy> that works too :p
[13:43] <ochosi> bluesabre: personally, i would leave the whole background drawing routine there (for the cairo root bg) and just add the window on top of it
[13:43] <ochosi> as opposed to what you did in the image-branch (replacing the rootbg with the window)
[13:43] <bluesabre> yeah, that was before the fixed rootbg
[13:44] <ochosi> mmh
[13:58] <ochosi> bluesabre: i've started to manually merge in the image branch
[14:02] <bluesabre> ochosi: good luck :)
[14:02] <ochosi> yeah, might need it :)
[14:03] <ochosi> it builds, but i haven't touched your glist stuff yet
[14:10] <ochosi> bluesabre: hm, it still builds and works...
[14:10] <ochosi> can you use/test nouveau?
[14:11] <ochosi> if so, i can push it to a new branch
[14:11] <ochosi> and if it works like this, i'll do away with the gtkimage and draw in the window directly with cairo
[14:17] <ochosi> (and after that we could look into the fading)
[14:22] <ochosi> bluesabre: please test and let me know: https://code.launchpad.net/~lightdm-gtk-greeter-team/lightdm-gtk-greeter/background_window
[14:28] <elfy> well - all I can say is - checking testcases is a whole lot more boring than writing them - and that was boring enough
[14:29] <ochosi> hehe
[14:29] <ochosi> bluesabre: ok, i managed to run a quick test
[14:29] <ochosi> sooo
[14:29] <ochosi> the background is fine now
[14:29] <ochosi> but but but
[14:29] <ochosi> when you log in, because of the retain-permanent stuff, the garbled stuff comes up for a split-second
[14:30] <ochosi> because it's in the rootpixmap
[14:30] <ochosi> no idea why that one is so garbled
[14:30] <ochosi> silly nouveau
[14:31] <elfy> indeed :p
[14:31] <ochosi> it really seems to be a nouveau-only problem
[14:31] <ochosi> have never seen that with any other driver
[14:32] <elfy> yep - I can install nvidia and it's fine
[14:32] <ochosi> hm, so with a bg-image everything is fine in the login-transition
[14:33] <ochosi> the corruption now seems to only happen with setting a bg-color in the greeter.conf
[14:33] <ochosi> also, fake transparency breaks with that
[14:33] <ochosi> bluesabre: ^
[14:35] <ochosi> i think the security issue is still less grave when the garbled stuff only comes up for a very short period in the login
[14:36] <ochosi> (in comparison to having it there on the login screen where you have time to take notes)
[14:41] <bluesabre> ochosi: could we draw the root pixbuf after the window is visible?
[14:43] <ochosi> bluesabre: sure, but what diff would that make?
[14:44] <bluesabre> dunno, but worth a short
[14:44] <bluesabre> *shot
[14:45] <ochosi> personally i don't think we can do much about the login-transition with nouveau
[14:45] <ochosi> (apart from filing a bugreport against nouveau wrt root-pixmap)
[14:45] <elfy> ochosi> i think the security issue is still less grave when the garbled stuff only comes up for a very short period in the login
[14:46] <elfy> that's fine as long as someone doesn't get called away
[14:46] <ochosi> called away?
[14:46] <ochosi> not  sure i get what you mean
[14:46] <elfy> could be at work or something - just saying - then it's sitting there till you come back
[14:46] <ochosi> no
[14:47] <elfy> what do you mean no?
[14:47] <ochosi> with the current patch, it's only visible for a split-second *after* you've entered your password
[14:47] <ochosi> so that's exactly my point, it can't sit there anymore
[14:47] <elfy> sorry then - not read the whole scrollback :)
[14:47] <ochosi> no worries ;)
[14:48] <elfy> just make it part of the 45 second grey bit lol
[14:48] <ochosi> yeah, more or less
[14:48] <ochosi> nothing much we can do about that it seems
[14:48] <elfy> with the current patch, it's only visible for a split-second *after* you've entered your password
[14:48] <elfy> that would certainly allay my worries
[14:48] <ochosi> err, why are you parroting me? :pü
[14:48] <brainwash> for any user?
[14:49] <elfy> ochosi: just so you know what I'm saying is fine :p
[14:49] <ochosi> elfy: hehe, ok
[14:49] <brainwash> so copying the strategy of unity-greeter is not possible?
[14:50] <ochosi> brainwash: what is the strategy of unity-greeter?
[14:50] <brainwash> don't know, but it works without any corruption
[14:51] <ochosi> well now the bug happens *after* the greeter, so it
[14:51] <ochosi> 's a bit out of our hand
[14:51] <ochosi> s
[14:51] <ochosi> now it's a question of how the session/xfwm starts up i'd say
[14:52] <ochosi> copying the root-pixmap in xfwm4 is actually what should now produce the corruption, ironically
[14:52] <brainwash> ok, so it breaks the seamless transition :(
[14:52] <ochosi> from how i understand things, nouveau breaks the seemless transition, yes
[14:52] <brainwash> do you use the patched xfwm4?
[14:53] <brainwash> or properly built I mean
[14:53] <brainwash> monitor root pixmap
[14:53] <ochosi> i use Unit193's PPA
[14:53] <brainwash> ok
[14:53] <ochosi> anyway, you test it, you're the login-transition expert ;)
[14:53] <brainwash> I can only test with intel/AMD
[14:54] <ochosi> knowing whether it works with that is also helpful
[14:54] <elfy> given instructions I don't need to think about I can test with nouveau and nvidia
[14:55] <brainwash> right, but it would help even more, if this stuff would be available for everyone to test (daily image)
[14:55] <elfy> of course
[14:55]  * elfy has been banging that particular drum since October :p
[14:56] <elfy> I'd apologise - but I'll be doing the same thing in May - so it hardly seems appropriate :D
[14:58] <brainwash> we still don't know when new fixes/features will land in the official repo?
[15:03] <elfy> no idea
[15:41] <ochosi> bluesabre: actually i think the branch fixes it for me more or less
[15:41] <ochosi> since there is no more visible corruption in the greeter anymore, it's also not retained anymore
[15:42] <ochosi> so after one more reboot i don't see those crazy artifacts anymore
[15:42] <ochosi> was only retained the first time when i hadn't used the fix
[15:42] <ochosi> so if you can confirm that, i'll work on drawing the bg with cairo instead of loading it into the gtkimage
[15:45] <knome> jjfrv8, i need to catch you some day so we can sit down and go through the documentation blueprint to check the actual status and reassess what's realistic to achieve this cycle, and further see how we're laying that out
[15:46] <elfy> hi knome
[15:47] <knome> hey elfy
[15:50] <elfy> knome: need 10 minutes at some point soonish, just not now - early next week maybe?
[15:50] <knome> works for me
[15:50] <elfy> ok :)
[16:58] <eric_the_idiot> brainwash, I found a way to cause the xfdesktop theme issue, just need time to write and test a fix. Hopefully tomorrow.
[19:12] <bluesabre> ochosi: awesome
[19:12] <bluesabre> I'll check that out shortly
[19:12] <ochosi> bluesabre: oh, nice, you're back :)
[19:12] <bluesabre> we had stepped out for a few minutes, but our car died, so a few minutes became a few hours
[19:12] <bluesabre> but now all is well
[19:12] <ochosi> oh, sorry to hear :/
[19:13] <ochosi> might not be around for much longer this evening (well, it's 8pm here)
[19:14] <bluesabre> thats cool
[19:14] <ochosi> but if you give me some test-results, i'll take care of the cairo-drawing to the latest on monday (might go for a trip tomorrow)
[19:14] <bluesabre> I'll let you know if everything works
[19:15] <ochosi> ok thanks
[19:15] <ochosi> also, the transparency with bg-color-only needs another check
[19:16] <bluesabre> k, I'll have a look
[19:20] <bluesabre> ok, looks like my site is usable again
[19:21] <ochosi> i have a local version here with cairo drawing already btw
[19:21] <bluesabre> smdavis.us/doku or wiki.smdavis.us
[19:21] <ochosi> so as soon as you greenlight me, i'll push
[19:21] <bluesabre> k, one sec
[19:23] <bluesabre> hm,background_window crashes in my test-mode
[19:24] <bluesabre> there we go
[19:24] <bluesabre> crashes with no wallpaper
[19:32] <ochosi> bluesabre: what happens with wallpaper?
[19:33] <bluesabre> works
[19:33] <ochosi> ok
[19:33] <ochosi> then we have to set a big TODO for background colors :)
[19:33] <ochosi> and i can push my current code
[19:33] <ochosi> cause it also works with wallpapers
[19:34] <ochosi> well in fact i might have to account for multi-monitor situations...
[19:37] <ochosi> bluesabre: ok, try what i just pushed
[19:37] <ochosi> bbl
[19:37] <ochosi> or tomorrow
[19:37] <bluesabre> crash
[19:37] <bluesabre> I'll look into it
[20:13] <Noskcaj> terminal 0.6.3 is now in trusty-proposed
[20:16] <bluesabre> yay!
[20:16] <bluesabre> Noskcaj, is that your doing? :)
[20:17] <Noskcaj> bluesabre, Yeah, bur finding a sponsor is difficult as always
[20:18] <brainwash> no auto sync :(
[20:20] <Noskcaj> one tiny patch
[20:20] <brainwash> Noskcaj: any news regarding power-manager? it's kinda important, because saucy is affected too
[20:20] <brainwash> and people continue to complain about this
[20:20] <Noskcaj> brainwash, no, sorry. I suggest you go and ping corsac a lot
[20:21] <brainwash> what about your PPA then?
[20:21] <brainwash> it could be used instead (meantime)
[20:22] <brainwash> via SRU
[20:22] <brainwash> or is that a bad idea? like it creates too much overhead
[20:22] <Noskcaj> brainwash, If someone else could do the SRU, that should be fine.
[20:37] <ochosi> bluesabre: crash? details?
[20:37] <bluesabre> ochosi: lightdm --test-mode, window pops up, I see the shape of the login window, lightdm dies
[21:23] <jarnos> brainwash,  I have made some reports: https://bugs.launchpad.net/lightdm-gtk-greeter/+bug/1268099 https://bugs.launchpad.net/ubuntu/+source/x11-xserver-utils/+bug/1268080
[21:27] <brainwash> jarnos: I suggest reporting the xrandr issue upstream
[21:28] <brainwash> it might get lost on launchpad
[21:28] <brainwash> without anyone caring about it
[21:29] <brainwash> ochosi is running a multi monitor setup, so he can take a look at issue #1
[21:47] <ochosi> bluesabre: weird, gotta check it out
[22:11] <brainwash> ochosi: what do you think about this.. an extra menu entry, panel item and/or key binding in gtk greeter to blank the screen on demand
[22:11] <brainwash> in case the user does not want to wait 10min until the next screen blank
[22:14] <brainwash> or is it planned to reduce the timeout to like 1min or less (similar to xscreensaver)?
[22:25] <brainwash> so check for lock_hint while initializing the greeter and if it's set call the set_saver() function
[22:28] <jarnos> I think esc key could be one way to enable screen saver, "i3lock --dpms" uses that.
[22:30] <brainwash> reducing the timeout to 1min or so seems to be the way to go
[22:31] <brainwash> xscreensaver even has this visual indicator to show the amount of time until the screen blanks again
[22:32] <brainwash> while the session is locked and the user is required to type the password to unlock it
[22:39] <jarnos> brainwash, i wonder, if I should have reported the xrandr bug against xorg, instead of x11-xserver-utils. Now the bug report does not contain any information about graphics driver and hardware.
[22:39] <brainwash> jarnos: true, but x11-xserver-utils is the correct package
[22:40] <brainwash> well, it might not be xrandr's fault after all
[22:41] <brainwash> it's just a tool to manipulate the settings
[22:41] <brainwash> the X server implements the randr extension
[22:42] <brainwash> jarnos: an upstream report would inform the code maintainer(s)
[22:46] <brainwash> oh, new upstream version of xfce4-terminal available in trusty :)
[22:47] <brainwash> now with solarized theme
[22:47] <brainwash> colortheme I mean
[23:01] <jarnos> brainwash, xfce4-terminal has nice set of command line options :)
[23:15] <brainwash> jarnos: new ones?
[23:15] <jarnos> brainwash, I don't know.
[23:16] <brainwash> I actually never use xfce4-terminal
[23:16] <jarnos> brainwash,  --hold is handy, -x may be to
[23:16] <brainwash> I only open it to confirm bugs
[23:16] <jarnos> oh
[23:17] <brainwash> but a new release it still awesome
[23:18] <jarnos> brainwash, how?
[23:18] <ali1234> i've started using terminator
[23:21] <brainwash> jarnos: I mean that a new version of a core application is something great
[23:23] <brainwash> and if we adopt them early, then we got more time to test until the final release
[23:48] <jarnos> brainwash, do you mean I should report the xrandr issue upstream against xorg?


[15:40] <drmacro> fresh install 16.04, studio icon in upper left corner (sorry, don't know what it's called so can't google it...) shows normal menus/apps (i.e. Audio production > Ardour, etc.), use menu editor to add a program I installed, now menus missing (Audio production, Video production and in All things like Ardour, Audacity, Brasero, Blender not found (all work from terminal) not sure how to begin trouble shoot... :P
[15:51] <dr_cianuro> Hi folks
[15:52] <dr_cianuro> im having some trouble with guitarix...
[15:52] <dr_cianuro> somebody may help me ?


 The wiki is fairly safe, don't worry
[09:58] <Kamping_Kaiser> lol. which reminds me, i was going to go and set myself up to do some work once breezy goes stable
[09:59] <MadpilotPPC> work in the Ubuntu wiki?
[09:59] <Kamping_Kaiser> wiki and -doc project.
[09:59] <MadpilotPPC> Are you running Breezy right now?
[10:00] <Kamping_Kaiser> yeh, since hoary went stable
[10:00] <Kamping_Kaiser> and then ill go and track dapper
[10:00] <MadpilotPPC> https://wiki.ubuntu.com/Archive  <-- this needs updating by someone savvier than I am, who can make the intro blurb make sense to someone running Breezy
[10:01] <MadpilotPPC> it's still talking about Warty and the plans for Hoary... :(
[10:01] <Kamping_Kaiser> :S
[10:10] <Kamping_Kaiser> sorry, called away :\ back now
[10:29] <MadpilotPPC> ya
[10:29] <MadpilotPPC> Ubuntu needs to do some pretty serious streamlining of accounts... I've got a Launchpad/wiki one, a Ubuntu Bugzilla one, a Ubuntu forums one... gah...
[10:30] <MadpilotPPC> Kamping_Kaiser, you going to have a go at that Archives page?
[10:31] <Kamping_Kaiser> um. spose i could. :/
[10:31] <Kamping_Kaiser> i should, but i might do it later.
[10:32] <mdke> hi all
[10:32] <Kamping_Kaiser> hi mdke :)
[10:32] <MadpilotPPC> hi mdke
[01:47] <spayne> yo all
[09:15] <kbrooks> Hey all.
[09:38] <mdke> hi
[09:51] <Burglaptop> salut
[09:55] <kbrooks> Long time no see :P


[04:58] <skellat> .nws 44004
[04:58] <jenni> Winter Weather Advisory issued December 05 at 9:28PM EST until December 06 at 10:00PM EST by NWS
[04:58] <jenni> Complete weather watches, warnings, and advisories for Ashtabula, OH, available here: http://alerts.weather.gov/cap/wwaatmget.php?x=OHC007 -- You may also PM the bot to get the full list.
[04:59] <skellat> .nws 44135
[04:59] <jenni> Winter Weather Advisory issued December 05 at 9:28PM EST until December 06 at 10:00PM EST by NWS
[04:59] <jenni> Complete weather watches, warnings, and advisories for Cleveland, OH, available here: http://alerts.weather.gov/cap/wwaatmget.php?x=OHC035 -- You may also PM the bot to get the full list.
[05:03] <Unit193> /mode -c ;D
[05:03] <Unit193> Temp: 30 F (-1 C) ~ snow ice pellets mist ~ Windchill: 23 F (-5 C) ~ Humidity: 93% ~ Alert: Winter Weather Advisory ~ Observed: Fri 06, 00:00
[13:56] <belkinsa> Well that's nice, I don't need to go class today because of the weather.
[14:14] <jrgifford> nice!
[14:14] <jrgifford> no such luck here
[14:15] <belkinsa> Yeah, but in my class that I was canceled, I'm three points away from a "A".
[14:16] <belkinsa> Correction A+
[14:20] <jrgifford> hah
[14:37] <andygraybeal>  is it really that bad up north?
[14:37] <andygraybeal> i'm down here past athens, near parkersburg and everythign still looks okay
[14:38] <jrgifford> here in cleveland it's fine
[14:38] <jrgifford> some snow on the ground, roads are clear, nothing terrible.
[14:38] <belkinsa> We just have ice on the roads and snow is coming around 1 PM here in South-west.
[14:40] <andygraybeal> my post got lost in #ubuntu maybe you guys could hold my hand.. here is the posting:
[14:40] <andygraybeal> if i connect a usb drive to my computer, and it doesn't automatically pop up, what steps should i take ot troubleshoot?   i do an "sudo lsusb" and it shows up in my usb device list.  i do an "sudo fdisk -l" but nothing pops up.  any help is appreciated.
[14:59] <jrgifford> andygraybeal: interesting
[14:59] <andygraybeal> :)
[14:59] <jrgifford> so do you have the gnome disk tool installed?
[15:00] <jrgifford> or gparted?
[15:00] <andygraybeal> hmmm i dunno.. gparted yes.
[15:00] <jrgifford> does it work?
[15:00] <andygraybeal> i can fire it up two secs
[15:00] <jrgifford> s/work/show up there
[15:00] <jenni> jrgifford meant to say: does it show up there?
[15:00] <andygraybeal> nope, doesn't register
[15:00] <andygraybeal> fdisk -l, or gparted doesn't show  a thing
[15:00] <jrgifford> is it just that drive?
[15:00] <andygraybeal> just my normal stuff.. you know, not the drive i'm after
[15:00] <jrgifford> and just that port?
[15:01] <jrgifford> s/and/or
[15:01] <jenni> jrgifford meant to say: or just that port?
[15:01] <jrgifford> jenni: well thats going to get annoying quickly
[15:01] <andygraybeal> hmm oh.. the usb port, i i can try another port, but this is the third machine i've tried to get this drive to work on.
[15:01] <jrgifford> the drive might be dead-dead.
[15:01] <andygraybeal> yano, control your jenni :)
[15:01] <jenni> jrgifford: *aims lazer poiner and fires*.
[15:01] <jrgifford> the onboard chip might have fried itself.
[15:02] <jrgifford> jenni: yolo!
[15:02] <jrgifford> i think yano is hiding behind his bot now... ;)
[15:02] <jenni> jrgifford, You Only Live Once.
[15:02] <andygraybeal> hahahahaha
[15:02] <belkinsa> Bot is alive?
[15:02] <andygraybeal> jenni, i'm so lonely.
[15:02] <jrgifford> or at least pretending to be.
[15:02]  * belkinsa stares at jenni
[15:02] <jenni> andygraybeal, Why are you lonely?
[15:03] <andygraybeal> jrgifford, rad thank you for your helps.
[15:03] <jrgifford> andygraybeal: sadly, that sounds like a dead drive to me.
[15:03] <jrgifford> not a linux problem. :(
[15:03] <andygraybeal> oh shitza bros!  i had a kid.. he's up in dublin methodist hospital at the NICU
[15:03] <andygraybeal> he's been there for a week, but it looks like he's gonna pull through
[15:04] <andygraybeal> i get him back on monday!!!!  if everything goes well.
[15:04] <jrgifford> congrats!
[15:04] <jrgifford> i hope everything goes well, i remember when my sister was in the NICU at that age.
[15:04] <andygraybeal> jrgifford, i wasn't blaming linux for sure!
[15:04] <andygraybeal> jrgifford, yea, i've never had any one i know in  a NICU
[15:04] <jrgifford> andygraybeal: wasn't saying you were, was just stating the facts.
[15:05] <andygraybeal> jrgifford,  :)
[15:05] <andygraybeal> they did all kinds crap to the poor guy... but at least he is alive.
[15:05] <andygraybeal> that is all that matters
[16:39] <cid420> hi all
[16:40] <Unit193> Howdy.
[16:42] <cid420> what you upto Unit
[17:39] <cid420> hey guys, i have an offer if interested head over to my website, if you are looking for cheap VPS http://power-factor.org
[19:56] <belkinsa> Hey
[19:58] <cid420_> anybody know a good HTML Editor for xubuntu?
[19:59] <belkinsa> Would Bluefish work?
[19:59] <cid420_> never tried it.. let me look in the software center
[20:00] <cid420_> I will give that a shot thanks Bel
[20:00] <belkinsa> Not a problem, and you can call me Svetlana, if you want.
[20:00] <belkinsa> Belkin is my last name
[20:01] <cid420_> oh ok i will try to remember :)
[20:01] <belkinsa> It's cool, I think we most just type in the full nick
[20:02] <jrgifford> cid420_: i like sublime text 2/3
[20:02] <cid420_> oh yea, there is one for xubuntu too?
[20:03] <cid420_> they have the libraries
[20:03] <cid420_> no ide in the software center
[20:03] <belkinsa> It's for all Linux dirstos, I believe
[20:04] <cid420_> ok
[20:04] <cid420_> going to try out the bluefish right now
[20:19] <cid420> oh Hey Svet my real name is William
[20:19] <cid420> simple name to remember
[20:19] <belkinsa> Yeah, but you should really use Sveta or Lana.
[20:19] <belkinsa> Sveta is my Russian nick and Lana is the English one
[20:20] <jrgifford> i just use irc handles.
[20:20] <jrgifford> easier to remember people. ;p
[20:21] <belkinsa> I do too.
[20:40] <cid420_> guys i use handles.. .i was being polite and offer my real name
[20:40] <cid420_> was being informal
[20:40] <belkinsa> I think it's just different in this community.
[20:41] <belkinsa> this = Ubuntu as a whole
[20:43] <Unit193> jrgifford: Heh, yeah.  Yours is easier as it is in your nick. :D
[20:44] <jrgifford> Unit193: OK nameless one ;)
[20:44] <paultag> crash_override
[20:44] <Unit193> Hey!  I've said mine, Unit 193!  :D
[20:53] <jrgifford> rofl
[20:53] <paultag> wat is ubuutu wehere did windows go, this game sucks
[21:05] <dzho> such funny
[21:05] <paultag> i've got http://www.youtube.com/watch?v=0TAXt5a0v9U on loop right now
[21:05] <paultag> which is
[21:05] <jenni> [ Rhabarber - Barbara - YouTube ] - https://j.mp/1bm2Lxs
[21:05] <belkinsa> Nice timing
[21:05] <belkinsa> ;)


[10:43] <BrunoADuarte> Hello
[10:44] <BrunoADuarte> [   13.512947] cloud-init[477]: Cloud-init v. 23.2.1-0ubuntu0~20.04.2 running 'init-local' at Fri, 04 Aug 2023 09:56:19 +0000. Up 13.23 seconds.
[10:44] <BrunoADuarte> [   13.515664] cloud-init[477]: 2023-08-04 09:56:20,232 - url_helper.py[WARNING]: Exception(s) [UrlError('Failed to parse: http://<IP_ADDRESS>/latest/api/token'), UrlError('Failed to parse: http://[fd00:ec2::254]/latest/api/token')] during request to http://[fd00:ec2::254]/latest/api/token, raising last exception
[10:44] <BrunoADuarte> How can I fix this error?
[10:44] <BrunoADuarte> It happens everytime I restart my Ubuntu AWS virtual machine.
[10:45] <meena> that looks like a perfectly good URL to me
[11:00] <BrunoADuarte> Yes, but it seems my vm has problems connecting to it at startup
[11:00] <BrunoADuarte> datasource:
[11:00] <BrunoADuarte>     Ec2:
[11:00] <BrunoADuarte>       metadata_urls: [ 'http://<IP_ADDRESS>:80', 'http://instance-data:8773' ]
[11:00] <BrunoADuarte>       timeout: 5 # (defaults to 50 seconds)
[11:00] <BrunoADuarte>       max_wait: 10 # (defaults to 120 seconds)
[11:01] <BrunoADuarte> Can I add this to the /etc/cloud/cloud.cfg file to skip this huge default timeout of 120s ?
[11:03] <BrunoADuarte> [    5.461936] cloud-init[869]: 2022-04-09 03:53:54,863 - url_helper.py[WARNING]: Calling 'http://<IP_ADDRESS>/latest/api/token' failed [0/120s]: request error [Failed to parse: http://<IP_ADDRESS>/latest/api/token]
[11:03] <BrunoADuarte> meena
[11:07] <meena> why is it failing to parse these? that doesn't make sense
[11:15] <BrunoADuarte> [  OK  ] Reached target System Time Synchronized.
[11:15] <BrunoADuarte> [  OK  ] Finished Load AppArmor proâ¦s managed internally by snapd.
[11:15] <BrunoADuarte> [    6.557320] cloud-init[479]: Cloud-init v. 23.1.2-0ubuntu0~20.04.2 running 'init-local' at Fri, 04 Aug 2023 09:46:41 +0000. Up 6.27 seconds.
[11:15] <BrunoADuarte> [    6.560078] cloud-init[479]: 2023-08-04 09:46:42,205 - url_helper.py[WARNING]: Exception(s) [UrlError('Failed to parse: http://<IP_ADDRESS>/latest/api/token'), UrlError('Failed to parse: http://[fd00:ec2::254]/latest/api/token')] during request to http://[fd00:ec2::254]/latest/api/token, raising last exception
[11:15] <BrunoADuarte> [    6.565378] cloud-init[479]: 2023-08-04 09:46:42,205 - url_helper.py[WARNING]: Calling 'None' failed [0/120s]: request error [Failed to parse: http://[fd00:ec2::254]/latest/api/token]
[11:15] <BrunoADuarte> [    7.709959] cloud-init[479]: 2023-08-04 09:46:43,358 - url_helper.py[WARNING]: Exception(s) [UrlError('Failed to parse: http://<IP_ADDRESS>/latest/api/token'), UrlError('Failed to parse: http://[fd00:ec2::254]/latest/api/token')] during request to http://[fd00:ec2::254]/latest/api/token, raising last exception
[11:16] <BrunoADuarte> The URL is ok, there's a parsing error, but there are not much details about it
[11:16] <BrunoADuarte> Maybe something related to IPv6 ?
[11:17] <BrunoADuarte> And it keeps retrying for 2 x 120 seconds
[11:17] <minimal> BrunoADuarte: please do not paste logs in the channel, use something like pastebin
[11:17] <minimal> BrunoDuarte: is this running on AWS?
[11:17] <BrunoADuarte> ok, sorry
[11:18] <BrunoADuarte> yes
[11:19] <minimal> why are you specifying the urls in the cloud-init config? the EC2 datasource should have the metadata urls builtin
[11:26] <minimal> do you have disable_ec2_metadata set in your user-data?
[13:03] <BrunoADuarte> minimal so ealier you asked if my VM was on AWS. Yes it is... here's the last cloud-init startup log I got from it, the error ocurred several times
[13:03] <BrunoADuarte> https://pastebin.com/UyN27ytg
[13:04] <BrunoADuarte> The first error appears on line #65
[13:09] <minimal> the fetches for [fd00:ec2::254] will fail as no IPv6 is setup
[13:09] <minimal> I assume these logs/errors are NOT from the 1st boot after this VM has been created. Is this correct?
[13:11] <BrunoADuarte> correct.
[13:11] <BrunoADuarte> This is 3 year old AWS Ubuntu instance that I always upgrade when there are new updates to it.
[13:11] <minimal> did you notice this in the logs: 2023-08-04 09:48:46,043 - DataSourceEc2.py[WARNING]: IMDS's HTTP endpoint is probably disabled
[13:15] <BrunoADuarte> no... I never messed with the IMDS
[13:16] <minimal> have you tried wget/curl to it from the CLI?
[13:16] <BrunoADuarte> no...
[13:17] <minimal> then try that to see what happens?
[13:22] <BrunoADuarte> wget http://<IP_ADDRESS>/latest/meta-data/
[13:22] <BrunoADuarte> --2023-08-04 13:19:24--  http://<IP_ADDRESS>/latest/meta-data/
[13:22] <BrunoADuarte> Connecting to <IP_ADDRESS>:80... connected.
[13:22] <BrunoADuarte> ....
[13:22] <BrunoADuarte> Saving to: ‘index.html’
[13:22] <BrunoADuarte> ....
[13:22] <BrunoADuarte> 2023-08-04 13:19:24 (45.3 MB/s) - ‘index.html’ saved [320/320]
[13:22] <minimal> ok, and what's the current IP address of the VM?
[13:23] <BrunoADuarte> but if fails for IPv6
[13:23] <BrunoADuarte> Connecting to [fd00:ec2::254]:80... failed: Network is unreachable.
[13:24] <BrunoADuarte> inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
[13:24] <BrunoADuarte>         inet6 fe80::1486:10ff:fe06:d17b  prefixlen 64  scopeid 0x20<link>
[13:24] <minimal> if IPv6 actually configured for the VM? I believe not
[13:24] <BrunoADuarte> inet6 fe80::1486:10ff:fe06:d17b  prefixlen 64  scopeid 0x20<link>
[13:24] <minimal> ok, that's a link-local IPv6 address, not sure if metadata server is reacable via that
[13:26] <BrunoADuarte> on the AWS page there's no IPv6 assigned
[13:26] <BrunoADuarte> *aws console page
[13:28] <minimal> not relevant, cloud-init only uses temp IPv4 (no IPv6) config to contact metadata server, and as cloud-init was unable to contact metadata server (for network config) it therefore only setup the IPv4 fallback config - IPv4 via DHCP, no IPv6 config
[13:28] <minimal> s/uses/used/
[13:28] <minimal> line 40
[13:29] <minimal> the version of cloud-init you're using only uses dhclient/IPv4 (newer releases use dhcpc for both IPv4 & IPv6)
[13:32] <minimal> can you run an "ip r" to show the routing table
[13:34] <BrunoADuarte> default via <IP_ADDRESS> dev ens5 proto dhcp src <IP_ADDRESS> metric 100
[13:34] <BrunoADuarte> <IP_ADDRESS>/20 dev ens5 proto kernel scope link src <IP_ADDRESS>
[13:34] <BrunoADuarte> <IP_ADDRESS> dev ens5 proto dhcp scope link src <IP_ADDRESS> metric 100
[13:40] <minimal> ok, that basically matches the routes cloud-init "manually" added before trying to contact metadata server, lines 54 & 55
[13:41] <BrunoADuarte> correct
[13:41] <minimal> you have the datasource urls defined in /etc/cloud.cfg or a file in /etc/cloud.cfg.d/ ?
[13:41] <BrunoADuarte> no... the lines are commented
[13:42] <BrunoADuarte> datasource:
[13:42] <BrunoADuarte>     Ec2:
[13:42] <BrunoADuarte>       metadata_urls: [ 'http://<IP_ADDRESS>:80', 'http://instance-data:8773' ]
[13:42] <BrunoADuarte>       timeout: 5
[13:42] <BrunoADuarte>       max_wait: 10
[13:42] <BrunoADuarte> i though of adding like this, to it gives up after 10s
[13:43] <BrunoADuarte> *so
[13:43] <minimal> they don't appear commented out there
[13:44] <BrunoADuarte> this is what I want to add...
[13:44] <BrunoADuarte> the actual lines are
[13:44] <BrunoADuarte> #    Ec2:
[13:44] <BrunoADuarte> #      metadata_urls: [ 'blah.com' ]
[13:44] <BrunoADuarte> #      timeout: 5 # (defaults to 50 seconds)
[13:45] <BrunoADuarte> #      max_wait: 10 # (defaults to 120 seconds)
[13:45] <BrunoADuarte> *the default lines
[13:47] <minimal> this is a VPC instance rather than a "Classic" (non-VPC) instance, right?
[13:49] <BrunoADuarte> correct
[14:00] <minimal> the "Failed to parse" error is coming from the urllib python library I think
[14:00] <minimal> which cloud-init uses
[14:06] <BrunoADuarte> yes, from "url_helper.py"  it seems
[14:06] <minimal> I mean it almost seems like urllib is where the issue is. The urls look ok to me from the logs
[14:07] <minimal> you said you upgraded, could something have gone wrong with that?
[14:12] <BrunoADuarte> I'm not sure, the machine works fine I don't remember of any broken updates... maybe I can force the update of this library?
[14:12] <BrunoADuarte> TOKEN=`curl -X PUT "http://<IP_ADDRESS>/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 'REDACTED'"` && curl -H "
[14:12] <BrunoADuarte> X-aws-ec2-metadata-token: $TOKEN" -v http://<IP_ADDRESS>/latest/meta-data/
[14:12] <BrunoADuarte> this command works perfectly from the cli
[14:13] <BrunoADuarte> is the same request that fails with the url_helper lib
[14:13] <minimal> yeah, it looks to me like cloud-init never actually requests the url, the "parse" error happens just before then
[14:13] <minimal> I'm out of ideas, perhaps someone else in channel has some?
[14:23] <meena> I ran out of ideas hours ago
[14:23] <meena> I would start an iphython shell and look what the url_helper does step by step
[14:24] <meena> only do this if you're desperate
[14:38] <BrunoADuarte> meena , can I just run "sudo dpkg-reconfigure cloud-init" and leave only "NoCloud" enabled ?
[15:06] <meena> BrunoADuarte: if you're in AWS, why would you have anything other than AWS enabled as source?
[16:21] <minimal> looking at the config schema I see various entries marked as "required: [ "abc" ]" but there is nothing on the docs website to highlight those things that are required
[17:47] <BrunoADuarte> meena because the AWS EC2 source isn't working.
[17:51] <minimal> BrunoADuarte: have you tried deploying a new VM instance to see if that works?
[17:58] <BrunoADuarte> It will probably work, otherwise I believe there would be a lot of issues reported, and I could not find anything related. It's a specific problem with my machine. It makes the boot take up to 5 minutes.
[17:59] <minimal> yeah that was what I was thinking to narrow down, that in general it works and that is is something specific to that VM instance
[18:00] <minimal> it would also givew you something to compare with, i.e. the contents of /etc/cloud/ with a working machine on the same OS version, same user-data etc
[20:04] <blackboxsw> trying to catch up on BrunoADuarte's conversation here. the first strange thing with the logs is that line 11 telling us that the DataSourceNone was detected on this machine prior to the most recent boot logs from 23.1.2. I'd be curious what was failing before this boot of 23.1.2 as it may shed light on the problem.
[20:07] <blackboxsw> The 2nd thing strange is  the log "Calling None failed..." which tell us that at the point of failure implying that the url_reader_cb never successfully returned a valid url (due to the urlparse error).. yet urllib.urlparse is happy  with that url as is.
[20:07] <blackboxsw> python3 -c 'from urllib.parse import quote, urlparse, urlunparse; print(urlparse("http://[fd00:ec2::254]/latest/api/token"))'
[20:07] <blackboxsw> ParseResult(scheme='http', netloc='[fd00:ec2::254]', path='/latest/api/token', params='', query='', fragment='')
[20:25] <minimal> blackboxsw: yeah it's all very strange
[20:26] <blackboxsw> BrunoADuarte: if you get a chance to file an issue with cloud-init and attach your full cloud-init logs (obtained via cloud-init collect-logs) plus your the output of your configured network (ip r; ip -6 r; ip addr) that'd help debug a bit async on this, and with a bit more data. I'm wondering how the upgrade path could hit this flavor issue.
[20:28] <minimal> blackboxsw: he filed #4316 but didn't attach logs to it
[20:28] <blackboxsw> But, there is obviously something else going on here as the DataSourceEc2 was not previously detected.   And, it does look like the `url_helper.dual_stack` implementation may need to better handle exceptions in ipv4 vs ipv6 stacks when errors occur as it looks like it loops indefinitely.
[20:28] <blackboxsw> ahh thx.
[20:28] <minimal> IPv6 uses link-local address to reach metadata server?
[20:30] <blackboxsw> yep it does https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-ipv6-only-subnets-and-ec2-instances/
[20:30] <blackboxsw> and same with the typical openstack/ec2 ivp4 too . <IP_ADDRESS>
[20:31] <blackboxsw> theory being that the IMDS is on the private subnet locally accessible to the vm/instance being launched and won't need external routing to get to that addr
[20:32] <minimal> yupe. Of course some other providers in future could implement IPv6 access in a completely different way :-(
[20:33] <blackboxsw> LL should allow cloud-init to avoid costly ephemeral dhcp client setup in init-local boot stage if we have enough data to understand a unique link local address we can assign pre-network setup.
[20:33] <BrunoADuarte> Sure, I'll export the cloud-init logs and attach there.
[20:33] <blackboxsw> BrunoADuarte: many thanks I was commenting on that issue with that request now.
[20:40] <minimal> blackboxsw: hmm, the IPv6 metadata server address is a ULA address, so wondering if AWS's RA announces a default route to that via the link-local gateway fe80:ec2::1, otherwise how would VM get to it
[20:57] <blackboxsw> yeah, not certain offhand how that's sorted.
[21:07] <minimal> blackboxsw: actually I'm wrong, that AWS article doesn't make sense as fe80:ec2::1 is *not* a link-local address (as LL are fe80 followed by 56 "0" bits) and LL addresses are /64 so I'm confused how with LL only a machine can get to outside the LL /64
[21:27] <blackboxsw> Sorry, I think I got my wires are crossed here but EC2 ipv6 IMDS looks like it is  **not** a link local address yet the default ipv6 config on aws instances is that systemd.networkd is configured LinkLocalAddressing=ipv6... Which gives typical instances LL ipv6 addresses `$ python3 -c 'from ipaddress import IPv6Address; print(IPv6Address("fe80::14:2aff:fe09:57b9").is_link_local); print(IPv6Address("fd00:ec2::254").is_link_local)'
[21:27] <blackboxsw> True
[21:27] <blackboxsw> False
[21:27] <blackboxsw> `
[21:37] <minimal> blackboxsw: that was my point, how to get to a ULA metadata server from a LL address without a route? (which would require an RA to announcing such a route and the distro to be configured to see RA announcements)


[00:12] <racarr_> Buffer stream is supposedly done gonna let it sit for a day then do some self review/iteration though
[00:12] <racarr_> don't want it to turn in to the 4500 line MR where everyone comes to hate me
[00:12] <racarr_> :p
[00:12] <racarr_> or rather It hink that may be what it is now
[00:12] <racarr_> and want to turn it in to something else
[00:13] <RAOF> Pfft!
[00:13] <RAOF> :)-
[00:52] <racarr_> deleting code is definitely the best way to spend last hour or so of work day
[03:01] <duflu_> OK, now bzr diff is lying to me
[03:03] <duflu> What the?! My whole fix got merged over without conflicts?
[03:04] <duflu> That's a new and scary bzr bug
[03:12]  * duflu longs for git
[03:33] <mikodo> duflu, Thank you!  https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400580
[03:34] <duflu> mikodo: No problem
[06:43] <duflu> alf__: Could you have another look at nice-log?
[09:34] <alf__> duflu: FYI, client-api-platform-operation-* branches updated
[09:36] <alan_g> alf__: got a moment to review this? https://code.launchpad.net/~alan-griffiths/mir/publish-server-examples-and-docs/+merge/244026
[09:37] <alf__> alan_g: sure
[09:37] <alf__> duflu: oops, just a moment
[09:40] <duflu> alf__: Thanks. Not sure if I'll have time to try and land them again today
[09:40] <duflu> But anyone can do it
[09:41] <alf__> duflu: np, thanks
[09:42]  * alan_g looks to see who has... interesting: http://paste.ubuntu.com/9454116/
[09:44] <alf__> aargh, merging back the trunk which contains the revert of the client-platform-* removes files from my branch!
[09:45] <alf__> why bzr, why?
[09:46] <duflu> alf__: Yeah I meant to warn you of that. Need to resubmit under a different name
[09:46] <duflu> Because bzr is awesome
[09:46] <duflu> But it was my mistake not testing x-compile
[09:47] <duflu> alf__: I had the same thing happen (with less explanation) this morning. I had to download the diff from LP and patch it back in :S
[09:49] <alf__> duflu: no worries, I should have checked x-compile to, but I forgot (I am used to CI checking it)
[09:49] <alf__> s/to/too
[09:49] <duflu> alf__: I *thought* building all platforms covered the Android code on desktop
[09:50] <duflu> Must have been in #ifdef ANDROID
[09:51] <alan_g> duflu: it builds the all production code, but the tests only for the first platform
[09:51] <duflu> alan_g: Ah
[09:51] <duflu> alan_g: We *could* build tests for both
[09:52] <alan_g> duflu: there's stuff with different implementations that we'd need to split out
[09:52] <alan_g> But we *should*
[09:52]  * alan_g can't be motivated to log a bug
[10:17] <alan_g> alf__: any opinion on mir_demo_server[_basic|_example|]?
[10:20] <alf__> alan_g: +1 for "mir_demo_server"
[10:21] <alan_g> I'll roll that into the update then. :)
[10:35] <alan_g> alf__: pushed
[10:50] <greyback> alf__: hey, on a displayconfiguration change, is there any chance existing DisplayBuffers are all destroyed and re-created?
[10:53] <alf__> greyback: they are
[10:54] <greyback> alf__: ok, explains things on my end
[10:54] <greyback> thanks
[10:55] <alf__> greyback: Do you know which channel I should use to get the latest phone image? vivid-proposed?
[10:55] <greyback> alf__: yes, that's it
[10:55] <alf__> greyback: ta
[10:55] <greyback> np
[15:37] <mlankhorst> racarr_: how's mirevent 2.0 coming along?
[17:15] <kgunn> seb128: did you file a bug the other day on relative screen position ?
[17:15] <kgunn> i was just chatting with alf__ and it seems we already have this :)
[17:16]  * kgunn is also curious about racarr_'s answer re mirevent2.0....as is anpok
[17:43] <alan_g> Have we defined any version macros that users can use to conditionally compile server code?
[17:49] <racarr_> mlankhorst: The new accessors landed but we hav to port everything and make a release before we can rip out hte old event and start making more detailed changes
[17:49] <racarr_> e.g. mir event-2.0 is there now but
[17:49] <racarr_> equivalent to mir event 1.0 still basically
[17:50] <seb128> kgunn, not yet
[17:50] <seb128> kgunn, I had to call it a day yesterday and was not working today, going to do that tomorrow
[17:58] <kgunn> racarr_: so anpok should start to conform to the new mirevents structures for the libinput work ?....i mean since they're in there
[17:59] <kgunn> seb128: ack...so i think tomorrow your morning, just chat with alf__
[17:59] <kgunn> before bugging
[18:00] <racarr_> kgunn: Not yet, he still outputs the old mir event structures and clients see the new one (or the old one)
[18:00] <racarr_> I think we talked about it yesterday and are on the same page
[18:00] <racarr_> unless this is something else...
[18:00] <racarr_> :)
[18:01] <kgunn> could be, just trying to help things along
[18:01] <racarr_> no worries. I am wondering if I should speed up any bits to help
[18:01] <racarr_> libinput
[18:20] <seb128> kgunn__, k, thank you
[18:28] <anpok> re
[18:28] <anpok> racarr_: ah ok, wasnt sure about outputting the old one..
[18:28] <anpok> thought the new ones were just around the corner
[18:30] <mlankhorst> racarr_: ok
[18:31] <racarr_> anpok: Well...I dunno...like I said the new ones are there for clients
[18:31] <racarr_> but even if something was mped to port every client now
[18:31] <racarr_> it would be what, 2 weeks at least before we could drop the old code
[18:31] <racarr_> and right now the old event is used over the wire
[18:31] <racarr_> :/
[18:31] <racarr_> for accessing MirEvent though you should
[18:32] <anpok> hm for input .. we still have the mapping ..
[18:32] <racarr_> use the new mir_input_event*
[18:32] <racarr_> stuff
[18:32] <anpok> yeah
[18:32] <anpok> mapping to droidinput structures..
[18:32] <racarr_> mm
[19:17] <kdub> anpok, racarr_ any more thoughts on the namespace stuff from yesterday?
[19:18] <kdub> iirc, we were thinking about changing mir::input to mir::event because "input" is somewhat vague
[19:22] <racarr_> aha thats not what I was thinking ;)
[19:22] <racarr_> I was thinking that mir::input is fine as it is because its understood to mean input devices
[19:22] <racarr_> and that if we put everything related to events
[19:22] <racarr_> in the same namespace
[19:22] <racarr_> we lose that meaning
[19:22] <racarr_> so if you wantt o have stuff related to MirEvent, but don't want it in the mir:: namespace
[19:22] <racarr_> maybe it belongs in a mir::events:: namespace
[19:22] <racarr_> or something
[19:23] <racarr_> but certainly for example, an input device prober, or the input dispatcher, etc
[19:23] <racarr_> I think those make more sense in mir::input::
[19:26] <kdub> okay, I see the distinction, although from the graphics side of the fence... all looks like input to me :)
[19:27] <racarr_> kdub: You are right a generalization could be made I just think its more confusing than helpful
[19:27] <racarr_> e.g. mir::output::logging, mir::output::graphics
[19:27] <racarr_> wouldn't be helpful ;)
[19:27] <racarr_> lol
[19:28] <kdub> right, but mir::hid or mir::events might be
[19:29] <kdub> anyways, so dropping the namespace stuff... I guess we're still looking for what to do with the 3 EventSink interfaces
[19:37] <racarr_> kdub: I dunno...sorry ill think about it in a  sec...furiously debugging
[19:39] <AlbertA> does anyone know why we don't have a mir_surface_spec_set_output_id? we have a set_fullscreen_on_output....
[19:40] <kdub> AlbertA, just a fuzzy memory, but iirc, something having to do with helping more mesa bypass happen
[19:41] <AlbertA> ok...I'm just wondering so I can migrate the examples....
[19:41] <AlbertA> to the new spec api
[19:41] <AlbertA> since eglapp uses the output id parameter to place a non-fullscreen surface
[19:42] <AlbertA> in a specific output id
[19:42] <AlbertA> if the user sets up that option
[19:42] <racarr_> Interesting
[19:42] <racarr_> I thought output_id was equivalent
[19:42] <racarr_> to fullscreen on output
[19:42] <racarr_> and didnt know the other behavior was allowed
[19:43] <AlbertA> so perhaps we just want to deprecate that behavior?
[19:43] <AlbertA> although reading the windowing spec
[19:44] <AlbertA> the system needs to support restoring the previous client context....
[19:44] <AlbertA> which may include being in a certain monitor and non-fullscreen
[19:44] <AlbertA> but I guess that can just be done in the server side
[19:44] <racarr_> I think thats opaque
[19:44] <racarr_> to the client
[19:44] <racarr_> yeah
[19:44] <racarr_> ikf there is any client involvement
[19:45] <racarr_> its through an opaque
[19:45] <racarr_> cookie
[19:45] <racarr_> im not sure apps are even allowed to use fullscreen_on_output
[19:45] <racarr_> afaik the approved use case is: xmir
[19:45] <racarr_> and nested
[19:46] <kdub> and eglspinner?
[19:48] <kdub> maybe what that means is that USC allows clients to do that (returns true), but U8 does not (returns false)
[19:48] <racarr_> ah probably
[19:49] <AlbertA> ok, I think I have my answer :) change eglapp....:)
[20:13] <anpok> kdub: no further thoughts so far
[20:40] <mibofra> kdub, nothing I've checked and I've the same problems/errors of the last time. But I think, also wayland on the framebuffer library works well xD . Is there an option to force mir to use only the framebuffer (as /dev/graphics/fb0)?
[20:40] <mibofra> *or the rendering method of the render_to_fb demo
[20:42] <kdub> "--disable-overlays true" (argv) or "MIR_SERVER_DISABLE_OVERLAYS=true" (env) forces the render_to_fb demo rendering method
[20:42] <mibofra> let's try (again
[20:42] <mibofra> )
[20:43] <mibofra> MIR_SERVER_DISABLE_OVERLAYS=true , well, It's visible that it's an env specification xD
[20:49] <mibofra> kdub as usually segfault on egl demo, and nothing displayed on the screen for others
[20:49] <mibofra> just a thing, I launch the compositor in this way:
[20:49] <mibofra> unity-system-compositor --file '/run/mir_socket' --from-dm-fd 0 --to-dm-fd 1 --disable-overlays true
[20:50] <kdub> try mir_demo_server_shell
[20:52] <mibofra> the same result
[20:54] <kdub> any kernel or logcat error msgs?
[20:57] <mibofra> kdub, http://paste.ubuntu.com/9467210/ from dmesg, but I think is not really useful
[20:57] <kdub> nah, so thats okay
[20:59] <kdub> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/android_new_device_bringup.md
[20:59] <kdub> has some more suggestions... one day it'll make it to unity.ubuntu.com/mir
[21:01] <mibofra> kdub, from logcat: http://paste.ubuntu.com/9467244/
[21:01] <kdub> and try the mir_integration_tests
[21:02] <mibofra> ok
[21:07] <mibofra> well, kdub it doesn't accept the filters, anyway the integration test segfault after [ RUN      ] StaleFrames.are_dropped_when_restarting_compositor and fail at http://paste.ubuntu.com/9467332/
[21:09] <kdub> how does this one do?: mir_integration_tests --gtest-filter="TestClientIPCRender.test_accelerated_render_double"
[21:10] <mibofra> kdub, it returns the help of mir_integration_tests
[21:11] <kdub> oh, sorry, --gtest_filter
[21:12] <mibofra> kdub, http://paste.ubuntu.com/9467365/
[21:13] <kdub> mibofra, so, the render_overlays one won't output anything for hwc 1.0, but the server should still work (and the render_to_fb works, so thats good)
[21:14] <mibofra> kdub, anyway on the android_new_device_bringup.md there is also --gtest-filter instead of --gtest_filter
[21:14] <kdub> right, should be updated
[21:53] <mibofra> kdub, http://paste.ubuntu.com/9467658/ , line 55
[21:53] <mibofra> is normal that the compositor stops before the drawing?
[21:56] <kdub> mibofra, no, its strange
[21:56] <kdub> I guess if that integration test is working, and the render_to_fb works, the driver components are working... something else is going on
[21:58] <mibofra> kdub, does the compositor need some tty?
[21:58] <mibofra> like the tty1?
[21:58] <kdub> no, it doesnt
[21:58] <mibofra> ok
[21:59]  * kdub hasnt seen StaleFrames be the failing test for a new device before
[22:00] <mibofra> kdub, I had an idea
[22:01] <mibofra> kdub, it uses /dev/ump as part of the driver (egl) no?
[22:02] <kdub> perhaps, that's abstracted to mir and different on each chipset
[22:02] <mibofra> I've fusered /dev/ump to see if there was something using it, and I've found something with lsof
[22:02] <mibofra> I've found Binder_1 , kdub
[22:02] <mibofra> maybe it interferences in a way?
[22:03] <kdub> not sure
[22:05] <mibofra> kdub, other process too are using ump
[22:10] <RAOF> AlbertA: Requests for output_id that _weren't_ fullscreen were denied.
[22:11] <mibofra> kdub, _render_to_fb access in another way, I think is not only problem of setting --disable-overlays true, because it doesn't solve the problem on the other mir servers (demo or not)
[22:11] <RAOF> AlbertA: mir_surface_spec didn't change that, it just meant that you couldn't make a request that we'd automatically deny :)
[22:15] <AlbertA> RAOF: ack
[22:16] <mibofra> hi AlbertA, hi RAOF
[22:17] <AlbertA> hi there
[22:23] <racarr_> RAOF: Linux is about choice and MirSurfaceSpec is ruining it.
[22:23] <racarr_> :p
[22:23] <racarr_> Good morning
[23:31] <RAOF> Ok. Naming problem.
[23:32] <RAOF> I've got an interface, currently called Dispatchable, which has “get pollable fd” and dispatch() operations.
[23:33] <RAOF> I need to name an interface for something that has a create_dispatchable_for_me() operation.
[23:41] <AlbertA> RAOF: DispatchableFactory? :)
[23:41] <RAOF> Yeah, possible, but you only ever want to produce one Dispatchable from it.
[23:41] <RAOF> The interface is more create_a_dispatchable_that_will_dispatch_me()
[23:42] <RAOF> And it very rarely makes sense to have more than one of those.
[23:52] <racarr_> DispatchableProgenitor
[23:52] <racarr_> hmm
[23:52] <racarr_> Sorry what is a dispatachable?
[23:52] <racarr_> or rather what does dispatch() do
[23:53] <racarr_> for whom
[23:57] <RAOF> dispatch() does whatever should be done when there's something ready.