[02:16] <lotuspsychje> good morning
[05:16] <lotuspsychje> vion: please divide discussions with actual ubuntu support, into the right channels
[05:16] <lotuspsychje> here you can discuss about ubuntu
[05:18] <lotuspsychje> vion: stop using #ubuntu as general chat please
[05:18] <vion> I joined ubuntu-offtopic how did I get here?
[05:19] <lotuspsychje> maybe you pushed a magic button?
[05:19] <vion> non-support discussions about Ubuntu like what slander?
[05:20] <lotuspsychje> the users choice
[05:23] <vion> This channel is not official and in violation
[05:23] <vion> I will be reporting this exchange
[05:24] <lotuspsychje> vion: in violation with what?
[05:24] <vion> of the irc guidelines
[05:25] <lotuspsychje> vion: elaborate
[05:25] <vion> Not going to happen I don't want it official
[05:26] <vion> its a middle man limbo if I ever saw one
[05:27] <lotuspsychje> limbo all you need, im gonna grab a coffee
[05:44] <ducasse> good morning
[14:11] <daftykins> lol that user was nuts
[14:11] <lotuspsychje> yeah, added to the troll list
[14:15] <leftyfb> which one?
[14:15] <lotuspsychje> vion


[02:08] <jrib> ola
[02:08] <jrib> !info sun-java6-jre
[02:08] <ubotu> sun-java6-jre: Sun Java(TM) Runtime Environment (JRE) 6. In component multiverse, is optional. Version 6-00-0ubuntu1~edgy1 (edgy-backports), package size 6174 kB, installed size 14144 kB
[02:08] <jrib> any reason #ubuntu does not search edgy-backports?
[02:09] <lkoos> Hi there.
[02:09] <tonyyarusso> hi
[02:09] <nalioth> jrib: huh?
[02:09] <lkoos> I appear to be unable to join #ubuntu
[02:09] <tonyyarusso> Ah, that's why.
[02:09] <tonyyarusso> !tor | lkoos
[02:09] <ubotu> lkoos: The #ubuntu channel and related channels ban users joining from anonymous gateways like tor/silenceisdefeat/cgi:irc because the abuse:useful ratio is close to infinity:nothing -- project cloaks will let you join, otherwise you should simply not use an anonymizer.
[02:09] <ubotu> Attention tor users.  You may think you are anonymous, but you are not.  Please visit http://tor.unixgu.ru/ and see for yourself.   Please evaluate your need to use tor here on irc.  If you wish anonymity, Freenode offers cloaks of many different types. http://freenode.net/faq.shtml#cloaks
[02:10] <jrib> ubotu only searches edgy and edgy-seveas repositories using !info in #ubuntu, however, elsewhere, he seems to include edgy-backports
[02:10] <lkoos> That's an interesting statement regarding my ability to be anonymous with tor.
[02:12] <jrib> nalioth: ^
[02:13] <lkoos> Whoever told ubotu to direct people to tor.unixgu.ru is misinformed.
[02:13] <lkoos> Yes, someone can sniff an exit node.
[02:13] <lkoos> However, without regard for the content I produce, I am effectively as anonymous as one can be online.
[02:14] <lkoos> Using a cloaking service is not anonymous and it disregards the actual need to use tor for many use cases.
[02:14] <tonyyarusso> I don't know anything about how tor actually works, all I can tell you is you can't join #ubuntu with it.
[02:15] <lkoos> I propose that someone changes that bot output as it's misleading.  It has been extensively tested but is still BETA software, so use it with caution. Installation instructions at http://lunapark6.com/?p=1710 (Dapper) and http://ubuntuforums.org/showthread.php?t=217009/ (Edgy)
[04:51] <tonyyarusso> Jordan_U: Do we have a non-beta version in Ubuntu, or is only upstream non-beta?
[04:52] <Jordan_U> tonyyarusso: Only upstream
[04:52] <Jordan_U> tonyyarusso: Let me see if the linked instructions install the latest version...
[05:10] <ubotu> In ubotu, cables said: no, hi is <reply> Hi! Welcome to #ubuntu! This is a channel where you can ask questions and get help with Ubuntu. Feel free to ask a question, and if someone knows how to help you, they'll try their best.
[05:11] <Jordan_U> Ok, I'll update the Ubuntu Wiki first with instructions on installing the 1.0 then change the ubotu message
[05:11] <tonyyarusso> sounds like a plan :)
[05:12] <cables> Hey, just a question, Ubotu seems to respond to !hi differently depending on where you say it. Is that a special script?
[05:13] <tonyyarusso> cables: It's built into the plugin handling factoids.
[05:13] <tonyyarusso> !-hi-#ubuntu
[05:13] <ubotu> Sorry, I don't know anything about hi-#ubuntu - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[05:13] <tonyyarusso> bleh
[05:13] <tonyyarusso> !-hi
[05:13] <ubotu> hi aliases: howdy - added by Seveas on 2006-07-11 17:20:25
[05:13] <tonyyarusso> !-hi-#ubuntu-offtopic
[05:14] <tonyyarusso> where is it different?
[05:14] <cables> tonyyarusso, I said it in pm and it said welcome to ubotu
[05:14] <cables> in #ubuntu it says welcome to #ubuntu
[05:14] <cables> in offtopic it says welcome to #ubuntu-offtopic
[05:14] <tonyyarusso> ah, yeah.  It's welcome to (some variable wherever you are)
[05:15] <cables> ok
[05:16] <cables> Do you like my new !hi ?
[05:29] <tonyyarusso> what is the sysrq key anyway?
[07:55] <ttmrichter> How, precisely, is the supposed weakness in my router being tested?
[07:59] <Madpilot> ttmrichter, you got redirected to -read-topic?
[07:59] <ttmrichter> Yes.
[07:59] <ttmrichter> And found a distinct paucity of actual information.
[08:00] <Madpilot> ttmrichter, if you fixed the issue -read-topic points out, join me in #madpilot for a test attack
[08:00] <ttmrichter> Look at it from my (paranoid) perspective: I suddenly get told by an irc bot that I'm "vulnerable", get pointed to a freely-editable wiki page with no real information.
[08:01] <ttmrichter> I won't be adjusting anything until I know what is being tested and get something sensible out of it.
[08:01] <ttmrichter> Looking at my router, there's nothing on any port open that's vulnerable.
[08:01] <ttmrichter> So what's the story?
[08:01] <Madpilot> your router is freaking out when people send D C C instructions thru it.   I assume I have to log out and back in?
[08:12] <ttmrichter> OK.  Fire away.
[08:13] <ttmrichter> On port 8001 as instructed.
[08:13] <Madpilot> ttmrichter, join #madpilot, please - I won't launch a test attack here
[08:17] <Madpilot> ttmrichter, you're clear, you should be able to get into #ubuntu now
[10:19] <Jordan_U> !seen Jordan_U
[10:19] <ubotu> Sorry, I don't know anything about seen jordan_u - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[10:19] <Jordan_U> Is that feature broken or removed?
[10:21] <Madpilot> removed, I think
[10:21] <Madpilot> use seenserv instead
[11:14] <elkbuntu> @schedule
[11:14] <Ubugtu> Schedule for Etc/UTC: Current meeting: MOTU Council | 24 Feb 21:00: Ubuntu US LoCo Team Mentor | 25 Feb 17:00: LoCo Team | 26 Feb 23:00: Community Council | 27 Feb 20:00: Technical Board | 28 Feb 18:00: Accessibility Team
[11:15] <elkbuntu> @schedule sydney
[11:15] <Ubugtu> Schedule for Australia/Sydney: Current meeting: MOTU Council | 25 Feb 08:00: Ubuntu US LoCo Team Mentor | 26 Feb 04:00: LoCo Team | 27 Feb 10:00: Community Council | 28 Feb 07:00: Technical Board | 01 Mar 05:00: Accessibility Team
[11:17] <morrolan> Hello - can anyone tell me why the version of libglu-mesa and libglu-dev are cvs versions, and not full releases?  It causes the install of UFO:Alien Invasion to die miserably.
[11:18] <elkbuntu> maybe if you stay longer than 30 seconds?
[11:18] <morrolan> !opengl
[11:18] <ubotu> Sorry, I don't know anything about opengl - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[11:19] <elkbuntu> morrolan, not a clue about the libglu bits. have you submitted bug reports?
[11:20] <elkbuntu> meanwhile, this is a discussion channel for the irc ops, not a support channel
[11:27] <Seveas> elkbuntu, look at his host :)
[11:27] <elkbuntu> Seveas, meh
[11:28] <Seveas> elkbuntu, shoarma
[11:29] <elkbuntu> Seveas, eh?
[11:29] <Seveas> meh -> sheep -> dead sheep -> shoarma
[11:31] <elkbuntu> you really are weird
[11:31] <elkbuntu> :
[11:31] <Seveas> I am
[11:32] <elkbuntu> wow... someone cut loose at joel bryan juliano on -sounder
[11:32] <Seveas> yeah
[11:33] <Seveas> michael richter should behave
[11:33] <elkbuntu> im pretty sure i've seen similar from him before somewhere
[12:14] <cntb> \o
[12:14] <cntb> I saw a new bot ubot3
[12:14] <elkbuntu> cntb, yes, it is a redundancy for ubotu
[12:14] <cntb> ty elkbuntu
[12:15] <cntb> same daatbase in real time ?
[12:15] <elkbuntu> should be
[12:15] <cntb> ok
[12:15] <elkbuntu> ubotu is used so much he cant keep up, so ubo3 is a helper for channels such as loco channels
[12:15] <ubotu> I'll remember that, elkbuntu
[12:15] <elkbuntu> oh f...
[12:16] <elkbuntu> Seveas!!!
[12:16] <Amaranth> !ubotu
[12:16] <ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://bots.ubuntulinux.nl - Usage info: http://wiki.ubuntu.com/UbuntuBots
[12:16] <elkbuntu> phew
[12:16] <Amaranth> !
[12:16] <Amaranth> it seems to have set "nothing"
[12:16] <cntb> ha ha you made a new factoid>?
[12:16] <Amaranth> so, uh, i smell DB corruption :)
[12:17] <Amaranth> oh
[12:17] <cntb> at least it is backed up
[12:17] <cntb> bye
[12:17] <elkbuntu> cya cntb
[12:17] <Amaranth> !ubotu is used so much he cant keep up, so ubo3
[12:17] <ubotu> is used so much he cant keep up, so ubo3 is a helper for channels such as loco channels
[12:17] <Amaranth> buggy
[12:17] <elkbuntu> wot the heck
[12:17] <Amaranth> !forget ubotu is used so much he cant keep up, so ubo3
[12:17] <ubotu> In #ubuntu-ops, Amaranth said: !forget ubotu is used so much he cant keep up, so ubo3
[12:17] <Amaranth> meh
[12:17] <elkbuntu> !forget ubotu is used so much he cant keep up, so ubo3
[12:17] <ubotu> I know nothing about ubotu is used so much he cant keep up, so ubo3 yet, elkbuntu
[12:18] <elkbuntu> hahah
[12:18] <Amaranth> o_O
[12:18] <elkbuntu> this is now dennis' problem
[12:18] <Amaranth> indeed
[01:20] <Seveas> elkbuntu, why do you always have to find obscure bugs?
[01:20] <elkbuntu> Seveas, it's a gift.
[01:21] <elkbuntu> you realise i need extra huggles now that you went and slapped me?
[01:21] <elkbuntu> pray tell. what did it name the factoid?
[01:21] <Seveas> maybe nalioth has some hugglecake left
[01:27] <highvoltage> what is hugglecake?
[01:27] <elkbuntu> highvoltage, nalioth's cooking. should speak for itself
[01:27] <highvoltage> :)
[01:38] <Myrtti> I want white chocolate with blueberries
[01:45] <Seveas> I do
[01:45] <Seveas> I don't like green chocolate
[01:45] <highvoltage> no peppermint crisps for you then
[01:46] <elkbuntu> i only like white chocolate that is supposed to be white chocolate
[01:46] <highvoltage> elkbuntu: good answer!
[01:46] <elkbuntu> bloomed stuff sucks
[01:48] <Seveas> lol
[01:48] <Seveas> or white chocolate with whole hazelnuts
[01:48] <Seveas> or butterscotch
[01:49] <Seveas> or cappucino flavor
[01:49] <elkbuntu> mmmm butterscotch
[01:49] <elkbuntu> mmmm caffeine
[01:51] <Seveas> @now melbourne
[01:51] <Ubugtu> Current time in Australia/Melbourne: February 23 2007, 23:51:48 - Next meeting: Ubuntu US LoCo Team Mentor in 1 day
[01:51] <Seveas> mmmmm sleep!
[01:51] <Seveas> go to bed
[01:52] <elkbuntu> but there's still another cup worth of coffee in the pot~
[01:52] <elkbuntu> s/~/!/
[01:52] <Hobbsee> elkbuntu's not in melbourne, anyway...
[01:53] <Seveas> Hobbsee, timezone is the same :)
[01:53] <Hobbsee> true that :P
[01:53] <Seveas> elkbuntu lives in the middle of nowhere
[01:53] <elkbuntu> almost
[01:53] <Hobbsee> but you're insulting her, trying to tell her she's in melbourne
[01:54] <Seveas> border?
[01:54] <PriceChild> lol
[01:54] <elkbuntu> Seveas, between nsw and vic
[01:54] <Seveas> ah
[01:55] <elkbuntu> there was no obstetrics within decent distance on the nsw side, so i was born in the city just across the state border
[01:55] <Hobbsee> elkbuntu: ahhh....fair enough
[01:55] <Hobbsee> which starts with a t, i believe
[01:55] <Hobbsee> near the town called "goodnight"
[01:55] <elkbuntu> ...
[01:55] <elkbuntu> neither albury nor wodonga start with t
[01:56] <Seveas> wodonga...
[01:56] <Hobbsee> i realise that.  somewhere near there though, there's one that does
[01:57] <elkbuntu> Seveas, hmm?
[02:01] <PriceChild> !tor | user1562
[02:01] <ubotu> user1562: The #ubuntu channel and related channels ban users joining from anonymous gateways like tor/silenceisdefeat/cgi:irc because the abuse:useful ratio is close to infinity:nothing -- project cloaks will let you join, otherwise you should simply not use an anonymizer.
[02:01] <ubotu> Attention tor users.  You may think you are anonymous, but you are not.  Please visit http://tor.unixgu.ru/ and see for yourself.   Please evaluate your need to use tor here on irc.  If you wish anonymity, Freenode offers cloaks of many different types. http://freenode.net/faq.shtml#cloaks
[04:03] <ubotu> In ubotu, jrib said: alternative is <alias> alternate
[04:05] <tonyyarusso> !alternative
[04:05] <ubotu> Sorry, I don't know anything about alternative - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[04:05] <tonyyarusso> !alternative is <alias> alternate
[04:05] <ubotu> In #ubuntu-ops, tonyyarusso said: !alternative is <alias> alternate
[04:06] <Tm_T> really?
[04:07] <tonyyarusso> lol
[04:07] <tonyyarusso> %login
[04:23] <tonyyarusso> !tor | oneyozfest182
[04:23] <ubotu> oneyozfest182: The #ubuntu channel and related channels ban users joining from anonymous gateways like tor/silenceisdefeat/cgi:irc because the abuse:useful ratio is close to infinity:nothing -- project cloaks will let you join, otherwise you should simply not use an anonymizer.
[04:23] <ubotu> Attention tor users.  You may think you are anonymous, but you are not.  Please visit http://tor.unixgu.ru/ and see for yourself.   Please evaluate your need to use tor here on irc.  If you wish anonymity, Freenode offers cloaks of many different types. http://freenode.net/faq.shtml#cloaks
[05:08] <lucascle> Hi
[05:08] <tonyyarusso> !burners =~ /graveman/graveman,/
[05:08] <PriceChild> hey lucascle
[05:08] <ubotu> I'll remember that tonyyarusso
[05:08] <PriceChild> !proxy | lucascle
[05:08] <ubotu> lucascle: The #ubuntu channel and related channels ban users joining from anonymous gateways like tor/silenceisdefeat/cgi:irc because the abuse:useful ratio is close to infinity:nothing -- project cloaks will let you join, otherwise you should simply not use an anonymizer.
[05:08] <ubotu> Attention tor users.  You may think you are anonymous, but you are not.  Please visit http://tor.unixgu.ru/ and see for yourself.   Please evaluate your need to use tor here on irc.  If you wish anonymity, Freenode offers cloaks of many different types. http://freenode.net/faq.shtml#cloaks
[05:08] <tonyyarusso> !tor | lucascle
[05:09] <PriceChild> PriceChild, 1 : 0 tonyyarusso
[05:09] <lucascle> I have a proposal for the universe: Why don't you add the code:blocks ide?
[05:10] <lucascle> the website is http://www.codeblocks.org/ and there is an ubuntu version
[05:11] <tonyyarusso> PriceChild: Just because my lag ranges from 5s to 1 min....
[05:11] <PriceChild> tonyyarusso, Still stands :)
[05:11] <PriceChild> lucascle, this is not #ubuntu
[05:11] <PriceChild> lucascle, #ubuntu probably isn't the best place for this either, #ubuntu-motu manage the universe
[05:11] <lucascle> ok, thx
[05:12] <PriceChild> lucascle, Please read the message above from ubotu about why you got re-directed here from #ubuntu :)
[05:12] <tonyyarusso> Let me tell you how much fun IRC is with lag measured in minutes...  I've made a fool of myself in #ubuntu a few times today.
[05:54] <pochu> Hello ops! I have a question: is it possible to have an #ubuntu- channel as private? Look at this: #ubuntu-es+1 (protected with passwd)
[05:54] <pochu> -ChanServ- Channel [#ubuntu-es+1]  is private
[05:56] <tonyyarusso> pochu: possible, clearly.  Wise/necessary/allowed/etc., I have no idea.
[05:57] <pochu> tonyyarusso: ok, Seveas will know it right?
[05:58] <tonyyarusso> pochu: Should, yes.
[05:58] <pochu> tonyyarusso: ok, ty :)
[06:13] <gnomefreak> pochu: nalioth or seveas would knwo for sure
[06:13] <pochu> nalioth: ping?
[06:14] <pochu> gnomefreak: thanks :) I'm asking that channel's users at #ubuntu-locoteams
[06:14] <gnomefreak> i beleive all #ubuntu- official channels cant be private but im not totally sure
[06:15] <gnomefreak> ok back to work
[07:52] <gnomefreak> @btlongin
[07:52] <gnomefreak> @btlogin
[07:53] <arrenlex> !repeat | There is a comma splice in the first sentence: two independent clauses should be joined by ";" or ":"
[07:53] <ubotu> There is a comma splice in the first sentence: two independent clauses should be joined by ";" or ":": Don't feel ignored and repeat your question quickly, if nobody knows your answer, nobody will answer you. You can search https://help.ubuntu.com or http://wiki.ubuntu.com while you wait. Also see !patience
[07:54] <mc44> ah grammar pedantry ftw :p
[07:54] <arrenlex> Indeed!
[07:59] <tonyyarusso>  He's right.  :)
[08:00] <tonyyarusso> !repeat =~ /quickly,/quickly;/
[08:00] <ubotu> I'll remember that tonyyarusso
[08:01] <arrenlex> Hurrah! :D My lust for grammar is satisfied. Thank you very much.
[08:01] <mc44> quick change it back now :)
[08:02] <tonyyarusso> lol
[08:14] <ubotu> In #kubuntu, _eMaX_ said: ubotu what is the purpose of your existence?
[10:06] <elkbuntu> @schedule sydney
[10:06] <Ubugtu> Schedule for Australia/Sydney: 25 Feb 08:00: Ubuntu US LoCo Team Mentor | 26 Feb 04:00: LoCo Team | 27 Feb 10:00: Community Council | 28 Feb 07:00: Technical Board | 01 Mar 05:00: Accessibility Team | 01 Mar 07:00: Edubuntu
[10:21] <gnomefreak> tonyyarusso: he was using that as excuse to continue in #ubuntu (im willing to bet he goes offtopic very shortly. i remember him for some reason
[10:22] <tonyyarusso> gnomefreak: yeah - soundray says he's been a low-level but persistent offtopicer all day.  I have him on hilight, so it's just a matter of what buttons he finds now, or if the !ops was enough to _maybe_ scare him.
[10:23] <tonyyarusso> gnomefreak: (know anything about building Mozilla apps?)
[10:24] <gnomefreak> yeah a bit :) brb though
[10:24] <tonyyarusso> 'k
[10:29] <gnomefreak> tonyyarusso: whats the question?
[10:31] <tonyyarusso> gnomefreak: So I'm trying to build an app (named either Nvu 1.1 or KompoZer, depending on a decision which is imminent), for Ubuntu.  Currently, my Ubuntu .deb results in this upon running the command: "Cannot find mozilla runtime directory. Exiting."  However, building in non-debianized form from the source was successful.  What should I look for to fix?
[10:31] <tonyyarusso> (we can take it to #ubuntu-motu if you care, btw)
[10:32] <gnomefreak> not sure i havent try that one yet. does it build using .mozconfig
[10:33] <tonyyarusso> Yes.  In the packaged version, debian/mozconfig.debian, otherwise, .mozconfig.
[10:35] <tonyyarusso> There is very little difference between the .mozconfig and the mozconfig.debian as I used them, and the difference is that my failed build I uncommented the section labelled "uncomment for debian", and my successful build I did not.
[10:35] <gnomefreak> tonyyarusso: best bet would be to join #ubuntu-mozillateam on monday and ask asac he would know what runtime dir. its talking aobut. maybe if i get time ill play with it and if i get it to build ill add it to http://gnomefreak.youmortals.com/ and let you know what was worng
[10:35] <nalioth> tonyyarusso: look at your debian/* dir
[10:35] <tonyyarusso> nalioth: There.  What am I looking for?
[10:35] <nalioth> tonyyarusso: if it builds w/o error using configure/make/make install it should build just fine into a deb
[10:36] <tonyyarusso> gnomefreak: Okay, thanks.
[10:36] <tonyyarusso> This is the commented/uncommented section if it means anything to you nalioth :
[10:36] <tonyyarusso> > export OS_LIBS="-lc -lpthread"
[10:36] <tonyyarusso> > export CFLAGS="-DDEBIAN"
[10:36] <tonyyarusso> > export CXXFLAGS="-DDEBIAN"
[10:37] <tonyyarusso> Any other files besides the mozconfig that could be responsible?
[10:37] <gnomefreak> rules file maybe?
[10:38] <nalioth> tonyyarusso: i suggest you join irc.mozilla.org and /list
[10:38] <tonyyarusso> nalioth: 'k :)
[10:38] <tonyyarusso> gnomefreak: Maybe.  rules is a bit of a mystery to me still, unfortunately.
[10:38] <gnomefreak> control shouldnt and changelog shouldnt so all i can think of is you typoed in rules or you just diudnt add a file to debian dir/.
[10:38] <nalioth> see if you can find a dev channel over there, tonyyarusso
[10:39] <gnomefreak> we have one here but asac is off until later this weekend
[10:40] <tonyyarusso> scanning the /list
[10:43] <nalioth> if you don't find a dev channel, just ask in #nvu or #$PROJECT_NAME
[10:47] <tonyyarusso> nalioth: There's a #development, #mozbuild, #composer, #dev, and #MozillaDev.
[10:47] <gnomefreak> #mozilladev :)
[10:47] <tonyyarusso> One nick besides me.... :(
[10:48] <gnomefreak> nvu is no longer maintained :( konpozer sucks too :(
[10:48] <gnomefreak> kompozer even
[10:48] <tonyyarusso> gnomefreak: If you can list things it needs fixed we might be able to get them done.  btw, he plans a 0.8 release next week.
[10:48] <gnomefreak> i still have upstream tar ball so i will play with it this weekend and see if i can get to figure it out before i leave nextweek
[10:49] <gnomefreak> tonyyarusso: well if it wasnt you building it it would be me :(
[10:49] <gnomefreak> so ty
[10:49] <tonyyarusso> yw then :)
[10:50] <tonyyarusso> (what happened to giskard doing it?)
[10:50] <gnomefreak> didnt know he planed to
[10:50] <tonyyarusso> he did nvu in edgy is all
[10:50] <tonyyarusso> or helped, not sure
[10:50] <gnomefreak> as a team we know nothing about kompzer being added to feisty
[10:51] <gnomefreak> we have new mozilla maintainer
[10:51] <gnomefreak> i havent seen giskard in a while
[10:52] <tonyyarusso> I just thought of it last week - I knew about nvu not being in, and just stumbled across the kompozer site.  And since I and both of my parents have used Nvu from time to time, I jumped on it and started frantically reading packaging documentation, and so here I am, with a "so close to working it hurts to watch" package.
[10:52] <tonyyarusso> giskard was in -motu two days ago - we talked briefly.
[10:52] <gnomefreak> is it being accepted in feisty?
[10:52] <PriceChild> giskard is always in beryl-dev
[10:52] <gnomefreak> has it been*
[10:53] <tonyyarusso> gnomefreak: No, as I did not have a package ready in time for UVF.  If I get something done very shortly I will be asking for exemption consideration.  I spoke to the developer about the deadline for that possibility (~Mar 15th), and asked to get a reply about whether it will be nvu 1.1 or kompozer something by then if at all possible.
[10:54] <tonyyarusso> (UVF being yesterday, of course)
[10:54] <gnomefreak> name it kompozer IMHO
[10:54] <tonyyarusso> Quite likely, yes, but if it turns out that it can be called nvu, that will be useful for people upgrading, who wouldn't otherwise hear of it.
[10:54] <gnomefreak> as everyone knows NVU is no longer maintained and would be scared to use/have it
[10:55] <tonyyarusso> He was going to talk to Linspire (trademark holder?) about the name.
[10:55] <gnomefreak> not them again :(
[10:56] <tonyyarusso> Ah, yep - "Nvu is a trademark of Linspire, Inc"
[10:56] <tonyyarusso> gnomefreak: we only need trademark permission though this time, the actual developer seems receptive to patches (I just e-mailed him the ones I'm using)
[10:56] <gnomefreak> well that may answer the question i asked earlier :(
[10:57] <tonyyarusso> If UbuntuStats were here you would be the sad person of the day.
[10:57] <gnomefreak> tonyyarusso: david is working with them to get patches for mozilla products so we can check with mozilla than we can add them :(
[10:57] <gnomefreak> good its been like that all week
[10:57] <gnomefreak> i working hard this week so i can go away and not worry about this stuff
[10:58] <tonyyarusso> Good for you - enjoy a vacation.
[10:58] <PriceChild> Yeah where did UbuntuStats disappear to...
[10:58] <gnomefreak> ty but its not so much as vacation but emergency trip
[10:59] <tonyyarusso> Oh, that's less nice.
[10:59] <tonyyarusso> Medical?
[10:59] <gnomefreak> much
[10:59] <gnomefreak> yeah a family member is extreamly sick the past week or so so we planned the trip
[11:00] <tonyyarusso> ah
[11:00] <tonyyarusso> best wishes then
[11:05] <gnomefreak> tonyyarusso: the kompozer site should have a page for building it. maybe it will list runtime libs needed?
[11:06] <tonyyarusso> gnomefreak: Well, I was able to successfully build it, just not as a debian package.  I need to find out what's being done differently between the two processes.
[11:08] <gnomefreak> tonyyarusso: normally the rules file (since that controls dpkg-buildpackage with ./configure and make
[11:08] <nalioth> gnomefreak: he can't package it, he is having some trouble with the debian/*
[11:08] <tonyyarusso> Probably debian/rules, yes.  I jsut have to figure out what about it.
[11:09] <gnomefreak> nalioth: without looking at it all i can give him is the debian dir i have for totem ff and thunderbird but may not help since they rely on different things. but maybe hes missing a build-dep of runtime libs :)
[11:10] <tonyyarusso> gnomefreak: There's a not-most-recent, but for our purposes, good enough version on REVU.  http://revu.tauware.de/details.py?upid=4453 should be it.
[11:10] <gnomefreak> but if i get time ill look at it this weekend
[11:10] <nalioth> gnomefreak: no, it's that [many expletives deleted]  build system mozilla uses
[11:11] <tonyyarusso> (things changed after that version are things like adding the icon)
[11:16] <gnomefreak> ok i pinged asac if he gets back in next couple hours hell ping me
[11:17] <gnomefreak> as long as im not completely froze up :(
[11:20] <gnomefreak> anyone feel like wartning sender again? im getting tired of warning him
[11:20] <gnomefreak> warning*
[11:24] <tonyyarusso> I'm off to meet my parents for dinner, but I'll stay connected.
[11:25] <nalioth> gnomefreak: like that?
[11:26] <gnomefreak> i was getting htere
[11:26] <gnomefreak> there
[11:26] <gnomefreak> ty
[11:26] <gnomefreak> hes been offtopic for like an hour or 2
[11:54] <FIRESIDE91> Hey, Tony, why'd you ban me from #ubuntu?
[11:56] <FIRESIDE91> Can anyone tell me?  I've been banned from #ubuntu and can't get back in....the kick message gave told me to read IrcGuidlines on the Wiki, but I wasn't doing anything wrong.
[11:56] <mc44> tonyyarusso ^
[11:57] <nalioth> FIRESIDE91: join me in #moderation please
[11:57] <FIRESIDE91> K
[11:57] <nalioth>  /j ##moderation
[11:57] <nalioth> or that
[11:58] <nalioth> FIRESIDE91: please rejoin #moderation
[12:05] <FIRESIDE91> Back
[12:10] <nalioth> hi Hobbsee
[12:11] <nalioth> FIRESIDE91: you're good to go.  thanks for your patience
[12:15] <Hobbsee> nalioth!
[12:15] <nalioth> i didn't do it, Hobbsee
[12:16] <Hobbsee> nalioth: i blame you anyway
[12:16] <nalioth> :D
[12:16] <nalioth> is the bot doing ok, Hobbsee ?
[12:16] <nalioth> nobody seems to want to use it
[12:16] <Hobbsee> nalioth: dunno.  it's working in #kubuntu-devel
[12:16] <nalioth> not my bot
[12:17] <nalioth>  i put ubot3 in some #ubuntu channels
[12:17] <nalioth> ljl is on vacation
[12:18] <Hobbsee> ah right
[12:24] <elkbuntu> yay
[12:24] <Hobbsee> yep :)


[00:26] <mbiebl_> jdstrand: there is a AppArmorProfile= stanza
[00:26] <mbiebl_> http://www.freedesktop.org/software/systemd/man/systemd.exec.html
[00:26] <mbiebl_> is that what you are looking for?
[00:26] <mbiebl> (v204 doesn't have that yet, though)
[00:27] <mbiebl> needs at least v211 iirc
[00:27] <mbiebl> actually, it's v210
[04:55] <pitti> stgraber: util-linux> ah, I'll add a pointer to the patch; I asked the reporter before whether he'll test it on stable
[04:55] <pitti> ogasawara: phonesim-autostart> sorry, no, it does need dbus-launch; but that fixed Xsession.d/ script has been in utopic since yesterday, so it should be harmless now?
[04:56] <pitti> Good morning
[05:00] <RAOF> pitti: Good morning!
[05:01] <ScottK> pitti: Do all programs that we switched to use an upstart job need their sysvinit script restored?
[05:01] <RAOF> pitti: Would you be able to run a colord build on a mips porter box? I'd like to know whether some changes fix the build.
[05:03] <pitti> ScottK: at least all which are dependencies of other init.d scripts
[05:04] <ScottK> OK, but not leaf packages then.
[05:04] <pitti> ScottK: right; it often lowers the delta to Debian to put it back anyway, but it's not required
[05:04] <pitti> and of course it'll make things work under systemd
[05:05] <pitti> RAOF: yes, can do
[05:05] <ScottK> The package I'm worried about is already forked, so no rush.
[05:15] <RAOF> pitti: If you'd kindly run a arch-dependent only build of the tip of colord.git that'd be aces.
[05:17] <RAOF> pitti: Oh, also, does autopkgtest set an environment variable containing the build path anywhere? ADTTMP is not what I'm after; I want to be able to cat the test logs so that the automake test runner can output marginally useful messages.
[05:18] <pitti> RAOF: that should just be pwd; if you change directory in your test you could just save the original dir?
[05:19]  * RAOF goes to check the location of the logs.
[05:22] <RAOF> Hm, no.
[05:23] <RAOF> pitti: Running “make -C lib/colord check; cat lib/colord/test-suite.log” in a normal build tree works fine, but in the adt test can't find test-suite.log?
[05:25] <pitti> hmm, no immediate idea; this should certainly work
[05:25] <pitti> RAOF: btw, why is this 'build needed' *and* you call make check again?
[05:25] <pitti> oh, the build-needed would also run ./configure
[05:26] <RAOF> pitti: Because make check isn't run during the build?
[05:26] <pitti> *nod*
[05:27] <pitti> RAOF: so you get failures, but no test log written? I have no idea whre they'd go, given that you call "make check" in the cwd where the package is
[05:27] <RAOF> Oh.
[05:28] <RAOF> You know what? I should try --shell-fail and see where they are!
[05:28] <pitti> but the ones in jenkins succeed
[05:28] <RAOF> The ci.debian.org ones don't.
[05:28] <pitti> (I'm not sure whether automake's test runner also writes the logs on success)
[05:29] <pitti> See lib/colord/test-suite.log
[05:29] <pitti> yeah, it should indeed be just there
[05:29] <pitti> RAOF: build deps installing on the mips porter box, btw; this just takes rather long
[05:30] <RAOF> pitti: Well, the 1.2.0-3 *build* seems to time out after 300 minutes, so I'm perfectly prepared to believe that installing the dependencies is also slow :)
[05:31] <pitti> urgh
[05:31] <pitti> I should have started that in screen
[05:31] <RAOF> As long as you don't build the arch:all packages it should no longer take that long.
[05:31]  * pitti restarts the whole thing, better now than wasting half a day :)
[05:32] <RAOF> :)
[05:42]  * pitti NEWs ubuntu-app-launch to untangle the autopilot uninstallability
[05:54] <pitti> RAOF: debuild started now
[05:55] <RAOF> With just binary-arch, right?
[05:59] <pitti> RAOF: dpkg-buildpackage -us -uc -B -j8
[05:59] <RAOF> Sweet.
[06:00] <RAOF> Just making sure. Otherwise you get wait for the process that consumes gigabytes of memory and takes ages :)
[06:00] <pitti> ah, this box only has 2 GB
[06:00] <pitti> but 16 cores :)
[06:01] <richardus> so i want to make an upload to debian of a package that fixes an ubuntu bug.  do i make a changelog entry to close it or will the ubuntu people/ubuntu changelog do that? and what is the format for the entry?
[06:02] <richardus> i should add that debian also exhibits the ubuntu bug, i'm not completely crazy
[06:02] <RAOF> richardus: If you add (LP: #bugnumber) to the changelog it'll get automatically closed when the package is imported.
[06:03] <RAOF> Or when it's merged manually, if we've got Ubuntu-local changes to it.
[06:04] <Unit193> xnox: The systemd beep seems to be related to brltty, when I purged that the beep sounded.
[06:05] <pitti> indeed, I don't have brltty installed
[06:05] <pitti> Unit193: where "sounded" means "stopped", or "it sounded differently"?
[06:06] <Unit193> pitti: Sounded = the system made the beep.
[06:06] <pitti> Unit193: interesting; so I don't have brltty installed and don't hear a beep; but that might also be because my notebook might not have a PC speaker (or whatever beeps there)
[06:06] <pitti> Unit193: so you get this as well?
[06:07] <Unit193> pitti: Yes I do, but I can't technically comment as I'm using trusty and a slightly custom setup.  Might get it on the netbook, I don't remember.
[06:08] <pitti> Unit193: so if you install brltty the beep goes away? that'd be a very interesting data point indeed
[06:08] <pitti> would be interesting to compare boot/syslogs with and without brltty, etc.
[06:10] <RAOF> Bah!  You don't need root?
[06:14] <pitti> I'm aware of --output-dir messing things up (need a better way to find the real stdout/err with output redirection)
[06:14] <pitti> RAOF: lxc's -s switch calls lxc through sudo
[06:14] <RAOF> Ah.
[06:15] <pitti> $ sudo ./run-from-checkout --shell -B ~/ubuntu/tmp/testpkg// --- lxc -e adt-utopic
[06:15] <pitti> works as well, though
[06:15] <pitti> RAOF: does it have any error message, about /dev/stdout blabla not found, or similar?
[06:15] <pitti> you should at least get the "- - running shell" bit
[06:15] <RAOF> pitti: I'll try that command again and get some clean logs.
[06:21] <Unit193> pitti: Nono, if I *purge* brltty, the system will beep because it's stopping the service before removal.
[06:22] <pitti> Unit193: do you also get it beeping when rebooting if you have brltty installed?
[06:22] <Unit193> Yep.
[06:24] <pitti> Unit193: nice, that sounds exactly like bug 1316804 then
[06:25] <Unit193> My point exactly.
[06:25] <pitti> brltty has a systemd unit, I wonder if this behaves any different than the init.d one; it does not have an upstart job
[06:26] <pitti> brendand: could you try rebooting or purging with removing /lib/systemd/system/brltty.service ?
[06:26] <pitti> sorry, Unit193 ^
[06:26] <pitti> Unit193: this might even be something semi-deliberate, like indicating to the blind user that brltty  is starting/stopping/etc.
[06:26] <pitti> but certainly not supposed to happen on reboot
[06:27] <TheMuso> pitti: In the init.d script for brltty, we set thigns up via /etc/default to disable brltty by default way back, as it leaked memory. Not sure if it does any more, but most people do not need it running by default, and it runs sytem wide so is a security issue, which really needs fixing anyway.,
[06:27] <pitti> aah!
[06:27] <pitti> RUN_BRLTTY=no
[06:27] <pitti> we don't start it by default
[06:27] <TheMuso> No.
[06:27] <TheMuso> Scripts were written for the installer to enable it explicitly if a user requests it.
[06:27] <pitti> TheMuso: right, that'd explain it then -- brltty is causing the beep as a kind of notification, and as we never started it in the past few people noticed
[06:28] <TheMuso> Longer term, brltty needs to become a user session service.
[06:28] <TheMuso> But thats a whole ball of wax.
[06:29] <Unit193> pitti: Added brltty back, and service brltty stop does make the beep.
[06:29] <pitti> TheMuso: so in the short term, the systemd unit should probably read the /etc/default file?
[06:30] <pitti> Unit193: thanks for confirming
[06:30] <TheMuso> pitti: Or however is best to implement stuff. I am happy to change things elsewhere to tweak things however they need to be for systemd units...
[06:30] <Unit193> pitti: No problem!
[06:30] <TheMuso> pitti: i.e if we want to move away from /etc/default, now is as good a time to do so.
[06:30] <pitti> TheMuso: I mean, it is intended to not run brltty by default?
[06:30] <TheMuso> pitti: Correct, we do want to keep that behavior.
[06:31] <pitti> TheMuso: yeah, enabling/disabling services with default files works really badly with the unit model, so we need some hacks if we want to continue using default files that way
[06:31] <TheMuso> Debian runs it if brltty is installed, so this is an Ubuntu change which I am happy to keep.
[06:31] <TheMuso> pitti: I am happy to adopt whatever better method for systemd units there is.
[06:32] <pitti> TheMuso: the usual way is to enable/disable services using "systemctl enable" (or disable)
[06:32] <TheMuso> pitti: Ok, sounds clean enough.
[06:32] <pitti> TheMuso: I'm interested in why we install brltty by default but not enable it; most packages are enabled on installation
[06:33] <pitti> TheMuso: do we have that so that you can enable/disable brltty in the live environment, i. e. the package shoudl be installed always?
[06:33] <pitti> TheMuso: anyway, I'll adjust the unit file; we do the same in whoopsie
[06:34] <TheMuso> pitti: If the user has a USB display, brltty is also activated via udev.
[06:34] <TheMuso> The only time the user needs to explicitly enable brltty is if they use a serial or bluetooth display. Mind you the bluetooth setup is not done through the GUI...
[06:34] <pitti> it looks odd in systemctl status as brltty will appear as "failed" when disabled, but can't help that for now
[06:34] <pitti> TheMuso: ah, thanks for the heads-up
[06:35] <pitti> xnox: so, mystery solved for bug 1316804 :)
[06:35] <TheMuso> pitti: Thanks. Long term brltty needs to be beaten into submission as a user session service.
[06:35] <TheMuso> Too much stuff still runs as root for blind/vision impared users.
[06:35] <TheMuso> And that needs to change.
[06:35] <pitti> TheMuso: *nod* until then we'll just need to live with the unit appearing as "failed" when it's disabled; mostly cosmetical
[06:41] <TheMuso> If it weren't for users demanding braille, I'd chcuck brltty out of main... I dare say an audit would find many a security hole...
[06:41] <TheMuso> Its one of those packages thats been in main from the beginning, and probably really hasnt' had a proper going over, and has changed internally a fair bit over the years.
[07:00] <pitti> TheMuso, xnox, Unit193: I uploaded https://launchpad.net/ubuntu/+source/brltty/5.0-2ubuntu3 which ought to fix the beep (more precisely, respect the /etc/default/brltty file)
[07:05] <dholbach> good morning
[07:06] <TheMuso> pitti: Ok thanks.
[07:07] <mardy> cjwatson: hi! Do you know if the user click hook "Exec"'d processes have access to the D-Bus session? Looks like that when I run them with "sudo click install..." they don't, but I wonder if they do when an app is installed via the UI
[07:08] <pitti> RAOF: so each ../../client/cd-create-profile takes some 20 minutes or so; I wish they'd parallelize :)
[07:10] <RAOF> They're trivially parallelisable, but if you --enable-print-profiles each one takes over a GiB of memory, so upstream disabled parallel building there :)
[07:10] <pitti> ah, makes sense
[07:11] <RAOF> On the basis that eating ~20GiB of RAM isn't going to be particularly conducive to exploiting your cores :)
[07:13] <brendand_> pitti, i myself have the problem with bltty
[07:13] <brendand_> pitti, i was ignoring it so far
[07:13] <pitti> brendand_: oh, are you also already running with systemd?
[07:14] <brendand_> pitti, at least the symptoms match xnox's
[07:14] <brendand_> pitti, i am
[07:14] <pitti> brendand_: wow
[07:14] <pitti> brendand_: I mean, I sometimes get the wrong addressee in IRC pings, but I never actually happened to pick someone who was affected by the very same topic :)
[07:15] <pitti> brendand_: you are running it because you are interested, or still a leftover from last week's sysvinit debacle?
[07:15] <Unit193> pitti: Netbook thinks it's a good idea to make a loud beep when you unplug it or plug it in. >_<
[07:16] <brendand_> pitti, leftover - i guess i can remove it now?
[07:16] <pitti> brendand_: well, not remove in the package sense, but disable again if you want
[07:16] <brendand_> pitti, yeah - i mean remove the init= from grub
[07:16] <pitti> yes
[07:17] <pitti> brendand_: make sure you are fully updated, though :)
[07:17] <brendand_> pitti, yeah i thought of that :)
[07:23] <pitti> RAOF: OOI, are the color profiles arch dependent?
[07:24] <RAOF> pitti: No, they're not. I've picked the low-hanging fruit there (--enable-print-profiles is only passed when building arch-indep), but with a little extra work I could not build the rest when building arch-indep.
[07:27] <pitti> RAOF: they are so small, it almost seems like an upstream  release ought to ship them pre-generated, similarly to HTML documentation :)
[07:27] <RAOF> pitti: They get translations merged in at build time. Otherwise, yeah.
[07:27] <pitti> with appropriate .icc : .xml rules so that they are rebuilt on modifications
[07:27] <pitti> RAOF: ah, ok
[07:28] <pitti> they are just 4 KB, didn't look like they'd have much stuff in them
[07:29] <RAOF> I mean, they still could be generated at release time, but then we'd need to do some magic if we wanted to do translation bugfixes...
[07:38] <pitti> RAOF: ideally they should depend on the .po files too, so if you patch those the profiles should just get rebuilt; but yes, theory :)
[07:39] <LocutusOfBorg1> xnox, you there?
[07:39] <LocutusOfBorg1> may I know if this package is suitable for debian? https://launchpad.net/ubuntu/+source/mediascanner
[07:40] <LocutusOfBorg1> also this one https://launchpad.net/ubuntu/+source/lucene++
[07:40] <LocutusOfBorg1> is needed in the new poedit upstream release
[07:40] <LocutusOfBorg1> we might benefit from uploading directly in debian and then autosync, right?
[07:44] <ekarlso> apw: u around boss ? :)
[07:55] <dholbach> salut didrocks - ça va?
[07:55] <didrocks> dholbach: ça va bien, et toi ?
[07:55] <dholbach> didrocks, très bien, merci! :-)
[07:56] <dholbach> didrocks, t'as un petit peu de temps la prochaine semaine de parler un peu de "how contributions make it into Ubuntu"? :-)
[07:57] <lool> stgraber: Added SRU information to LP #1310715, thanks
[07:57] <dholbach> didrocks, I was thinking we could do a session together at Ubuntu Online Summit - I could talk a bit about "getting a fix for a package in" and you could talk a bit about how a fix for some touch project makes it onto an image?
[07:59] <didrocks> dholbach: I'm not in charge of the touch project CI process anymore. I can still talk about it, but I would prefer just to "participate" to the session to not bringing confusions on who is now in charge :)
[07:59] <didrocks> dholbach: sil2100, robru are the ones leading this now
[07:59] <dholbach> ok cool - thanks didrocks :)
[08:00] <didrocks> yw ;)
[08:00] <dholbach> didrocks, any other session you'd like to give? either demo or discussion sessions are fine (http://fridge.ubuntu.com/2014/05/28/calling-for-ubuntu-online-summit-sessions/) :-)
[08:02] <didrocks> dholbach: I need to think about it, having filed and abused the schedule a lot in the past, not sure I have anything valuable to discuss (yet). I'll follow and participate mostly to the cloud devops sessions at least
[08:03] <ricotz> hello :), is there a reason why there are no trusty daily iso-builds? (like it is done for precise)
[08:06] <dholbach> didrocks, ok cool
[08:17] <mlankhorst> chrisccoulson: that would be me, but that bug seems hard :P
[08:19] <chrisccoulson> mlankhorst, yeah. I have absolute faith in you though :)
[08:24] <pete-woods> mardy: hi, was wondering if you'd heard anything regarding the Vimeo API bug?
[08:24] <mardy> pete-woods: yes, they acknowledge the bug, and said they'll fix it soon
[08:24] <pete-woods> mardy: cool, thanks :)
[08:25] <mardy> pete-woods: I'll forward you their email
[08:25] <pete-woods> cheers
[08:25] <mardy> pete-woods: done
[08:26] <xnox> LocutusOfBorg1: lucene++ probably yes, but it FTBFS in ubuntu at the moment. I don't think mediascanner would be useful in Debian, as development has moved on to mediascanner2 and it is at the moment Ubuntu specific package (needs unity scopes/gallery to consume scanned media)
[08:30] <dholbach> sil2100, how are you doing? do you think you'd have some time during UOS next week to give a demo session together with me? (I talked about it with Didier above already) :)
[08:32] <sil2100> dholbach: hey! Let's have a chat in some moments :)
[08:33] <dholbach> sil2100, rock and roll :)
[08:36] <pete-woods> mardy: as a further question, now I've upgraded to utopic, I just get a black pane instead of the embedded browser in the online accounts settings, is this something you're aware of?
[08:36] <mardy> pete-woods: on the desktop?
[08:37] <pete-woods> mardy: yes
[08:37] <pete-woods> hmm, I don't seem to have signon-ui installed
[08:37] <mardy> pete-woods: yes, that's certainly the issue
[08:38] <pete-woods> mardy: bit strange that it's not installed by default
[08:39] <pete-woods> installing it makes all happy again, though :)
[08:39] <seb128> pete-woods, what is not installed by default and where?
[08:40] <pete-woods> seb128: I just had to manually install signon-ui to get online accounts to work
[08:40] <mardy> pete-woods: the last ubuntu-system-settings-online-accounts version can't be installed at the same time as signon-ui
[08:40] <seb128> pete-woods, desktop or touch?
[08:40] <pete-woods> this is on a pretty recent utopic desktop (last week)
[08:41] <seb128> mardy, why not?
[08:41] <seb128> pete-woods, http://cdimage.ubuntu.com/daily-live/current/utopic-desktop-i386.manifest
[08:41] <seb128> signon-ui	0.16+14.04.20140304.is.0.15+14.04.20140313-0ubuntu2
[08:41] <mardy> seb128: because on touch we merged the functionality of signon-ui into online-accounts-ui,
[08:41] <seb128> pete-woods, it's installed by default ... maybe you got it uninstalled when you tried to install some touch component?
[08:41] <mardy> seb128: and we would have a conflict when installing the d-bus service file
[08:42] <seb128> mardy, how is that going to work for people who install unity8 on their desktop next to unity7?
[08:42] <mardy> seb128: I'm afraid it will break online accounts on unity7 :-(
[08:42] <pete-woods> seb128: could well be possible, I do have unity8 installed
[08:42] <seb128> mardy, we need to fix that
[08:42] <rbasak> stgraber: ah, it should be bug 1300991, sorry. I just copied the changelog straight from Debian. I should have checked it.
[08:43] <rbasak> stgraber: do you want to reject and I'll re-upload with a fixed changelog?
[08:43] <seb128> mardy, otherwise pete-woods is going to be the first of a long serie of unhappy users
[08:43] <mardy> seb128: I don't see an easy way to fix it... both packages want to install /usr/share/dbus-1/services/com.nokia.singlesignonui.service
[08:44] <rbasak> @pilot out
[08:44] <rbasak> oops
[08:44] <seb128> mardy, you could split that .service in its own binary and have both ui depending on it
[08:44] <mardy> seb128: maybe we could make the service file launch a shell script, that decides which binary to launch based on environment variables
[08:44] <Laney> is the service somehow linked to the frontend?
[08:45] <seb128> mardy, right, or you can do that check in the .service itself, we used to do that for notify-osd
[08:45] <mardy> Laney: yes, the service implementation is a UI component
[08:46]  * mardy goes and has a look at notify-osd
[08:46] <mardy> seb128: "used to do that", means you don't do that anymore?
[08:47] <mardy> seb128: found it in version 0.33, thanks
[08:47] <seb128> mardy, yw!
[08:48] <seb128> mardy, yeah, I think we dropped that logic, we just use notify-osd when installed now
[08:48] <mardy> seb128: OK, that sounds like a viable solution; I'll work on that
[08:48] <seb128> mardy, thanks
[08:53] <apw> ekarlso, hi ?
[08:55] <pitti> @pilot in
[08:58] <mardy> seb128: how would you detect that we are running on unity8? I see "QT_QPA_PLATFORM=ubuntumirclient" in the env variables, would it be OK to use that?
[08:59] <seb128> Saviq, ^ do you know?
[09:00] <seb128> mardy, I guess that works, or you could just check for XDG_CURRENT_DESKTOP=Unity and assumes that's unity7
[09:01] <mlankhorst> why do you want to detect it?
[09:02] <mardy> mlankhorst: to know whether the D-Bus service should popup the desktop UI or the touch one
[09:02] <Laney> it's =Unity on touch too
[09:03] <mardy> Laney, seb128: I'll use the QT_QPA_PLATFORM then
[09:05] <Laney> mardy: You could check DESKTOP_SESSION is ubuntu-touch or unity8*
[09:05] <mlankhorst> mardy: but can't you try to pop up the touch one, if that fails fall back to desktop one?
[09:06] <infinity> mardy: If you're using unity8 == touch, that's going to end in tears when unity8 is the default on the desktop too...
[09:07] <seb128> infinity, depends what you call "touch"
[09:07] <seb128> we want the new UI in unity8-desktop as well
[09:07] <mardy> mlankhorst: the problem is that the touch one will run on the desktop, but it can't be embedded in the unity-control-center (using XEMBED)
[09:07] <ogra_> we'll just ship touchscreens with the images
[09:07]  * infinity mumbles something about convergence.
[09:07] <seb128> infinity, well, "touch" is going to be used on desktop as well
[09:08] <infinity> seb128: But not the same UI, obviously.  Is it all screen-size/form-factor autodetecty yet?
[09:10] <mardy> infinity: the point is not about convergence; it's that we have two different implementations, for unity7 and unity8, and from the D-Bus .service file we need to decide which one to pop up
[09:10] <ogra_> infinity, far from that ...
[09:10] <Fudge> running Mangler in gdb, if it dies like it has been do I just run bt to give to you guys?
[09:10] <mardy> infinity: eventually, we'll use the unity8 one on all form factors
[09:10] <Fudge> oops sorry wrong channel
[09:10] <ogra_> infinity, but as i understood the lightning talk about it it should anyway be use-case driven ... based on available input/output devices
[09:11] <Laney> the QPA_PLATFORM thing seems like it might be an implementation detail which might not be reliable
[09:11] <ogra_> that will only tell you you are running Mir
[09:11] <ogra_> (or X11 or surfaceflinger)
[09:12] <ogra_> wont tell you anything about what device you are on
[09:12] <seb128> infinity, well, we have a "new UI" and "legacy UI", ideally the legacy UI is going away, but we still need it for Unity7 because that doesn't have Mir, etc
[09:12] <pete-woods> tvoss: as my go-to C++ guy, do you have a recommendation for doing base64 encoding in C++? doing it with boost seems really unweildy
[09:12] <seb128> infinity, so that's not a case of detecting form factor, just a case of keeping something working for unity7 until our desktop has the techs needed to run the new UI
[09:14] <infinity> pete-woods: http://stackoverflow.com/questions/342409/how-do-i-base64-encode-decode-in-c
[09:14] <infinity> pete-woods: Might have a few decent pointers.
[09:15] <infinity> pete-woods: If you happen to already have openssl or glib in your dependency tree, both have base64 functions.
[09:17] <pete-woods> I was hoping to avoid implementing my own encoder, glib is sounding like the best option so far, as the C++ ones aren't in main
[09:18] <cjwatson> mardy: No, I wouldn't expect them to have access to it, and design-wise I think I'd prefer that they didn't assume that
[09:19] <mardy> cjwatson: OK, that's fine
[09:19] <infinity> pete-woods: Or just snag a copy of the coreutils one from the source or something.  It's not lkike base64 is complicated, any mature codebase will have had a bug free implementation for ages that you can steal and run with if you want to avoid pulling in a whole library just for it.
[09:20] <cjwatson> ricotz: I've been holding off on switching on trusty builds because there's only a single builder per architecture at the moment and so it's easy for contention to get pretty bad; I'm hoping that I'll be able to land the livefs-in-LP work before we desperately need trusty image builds in preparation for 14.04.1
[09:21] <pete-woods> infinity: part of the purpose of what I'm writing is to provide an example scope, I really don't want to say, hey you're going to have to implement your own base64 encoder just to do OAuth in your scope
[09:22] <infinity> pete-woods: Oh.  Perhaps an oauth library that does all the heavy lifting is what's wanted here, if it's something more than one scope is likely to want.
[09:23] <pete-woods> infinity: I already have an OAuth lib doing the basic case, but this API also needs a header encoding in a specific way
[09:23] <infinity> Ahh, indeed, liboauth is in main.  I guess it doesn't do the base64 stuff you need, though.
[09:23] <infinity> Oh, but it depends on libnss, which is also likely to have a base64 implementation hiding in it.
[09:24] <infinity> Cause pretty much every crypto library has to.
[09:25] <infinity> pete-woods: /usr/include/nss/base64.h from libnss3-dev looks promising.
[09:26] <infinity> pete-woods: (Assuming you're using liboauth anyway, you already have libnss3... But maybe you're using a different oauth lib)
[09:26] <shadeslayer> mhall119: btw you're working with the SDK team right?
[09:26] <infinity> pete-woods: Oh, nssb64.h is more complete (same source)
[09:27] <pete-woods> infinity: cool, thanks, right now I'm happy to take just about any library in main that doesn't involve introducing a big lump of boilerplate code
[09:28] <infinity> pete-woods: Well, my usual M.O. there is to check your current dep tree and see if something in it can solve the problem.
[09:28] <infinity> pete-woods: So, if you're using liboauth, libnss is a slam dunk.  If you have glib for some other reason, same argument.  Etc.
[09:29] <infinity> pete-woods: But it's pretty hard to write something meant to talk to the intertubes that doesn't use NSS, OpenSSL, or GnuTLS, and all three should have base64 goop to abuse.
[09:29] <pete-woods> yep
[09:34] <LocutusOfBorg1> thanks xnox
[09:34] <LocutusOfBorg1> are you working on fixing the FTBFS?
[09:34] <LocutusOfBorg1> I would like to upload in debian, just to pass the new queue
[09:34] <LocutusOfBorg1> otherwise poedit won't be uploaded
[09:35] <xnox> LocutusOfBorg1: go ahead with uploading to Debian, but check if it builds there.
[09:35] <ricotz> cjwatson, hi, thanks for the clarification, looking forward to them to be available
[09:35] <xnox> LocutusOfBorg1: i'm not working on resolving bugs in lucene++ at the moment, as the plan was to remove it from the archive, once mediascanner is dropped.
[09:36] <LocutusOfBorg1> xnox, mmm and for poedit?
[09:36] <LocutusOfBorg1> it needs lucene++
[09:36] <xnox> LocutusOfBorg1: if it's reintroduced, that's fine.
[09:37] <LocutusOfBorg1> sil2100, you there?
[09:37] <LocutusOfBorg1> agreed xnox I understand
[09:37] <LocutusOfBorg1> so I would like to know if sil2100 would like to maintain in debian too
[09:37] <sil2100> Hi!
[09:37] <LocutusOfBorg1> Hi sil!
[09:38] <LocutusOfBorg1> I think you already got some mails to the poedit adopter
[09:38] <LocutusOfBorg1> :)
[09:38] <LocutusOfBorg1> do you mind uploading in debian?
[09:40] <sil2100> LocutusOfBorg1: so, hm, I need to browse through my mailbox since I can't remember this well enough, but I could pick up maitaining the packaging for lucene++ in Debian if anything
[09:40] <sil2100> If that's needed
[09:43] <LocutusOfBorg1> yes, would be nice
[09:43] <LocutusOfBorg1> just put the version on mentors and sync on ubuntu
[09:43] <LocutusOfBorg1> you will simplify a LOT the packaging of the new poedit
[09:43] <LocutusOfBorg1> sil2100, Timur is the person who wants to adopt poedit
[09:44] <sil2100> LocutusOfBorg1: ok, will try doing that this week :)
[09:46] <LocutusOfBorg1> wonderful :)
[09:46] <LocutusOfBorg1> great thanks!
[09:49] <Timur> yes, thanks a lot
[09:50] <GunnarHj> rbasak: Did you see the dpkg-divert idea for skype-translation that infinity mentioned yesterday?
[09:59] <rbasak> GunnarHj: I saw it but haven't had a chance to read it yet. If infinity says it's reasonable though, that's good enough for me.
[09:59] <rbasak> GunnarHj: if you do exactly what infinity wants and he says it's good then I'm happy to upload it :)
[10:07] <seb128> hum
[10:07] <seb128> does anyone see an issue with that mountall translation?
[10:07] <seb128> msgid "Checking disk %1$d of %2$d (%3$d%% complete)"
[10:07] <seb128> msgstr "Vérification du disque %1$d sur %2$d (avancement : %3$d%%)"
[10:07] <seb128>
[10:07] <seb128> I wonder why the % doesn't display in french on the plymouth screen
[10:09] <GunnarHj> rbasak: Ok. I checked it out last night, and it seems to do the trick. Then I'll go on and make a new version and also addressing your questions on the bug report. Will ping you when done. :)
[10:11] <rbasak> GunnarHj: great. Thanks!
[10:12] <GunnarHj> rbasak: Thank _you_ for great sponsoring work!
[10:12] <tseliot> seb128: hey, I've just made a merge request for the touchscreen issue, which I assigned to you (feel free to reassign). This is for 14.10. When we're done, I'll do the same for the SRU in 14.04: https://code.launchpad.net/~albertomilone/unity-settings-daemon/lp1287341-14.10/+merge/222011
[10:18] <seb128> tseliot, thanks
[10:19] <tseliot> yw
[10:27] <Mirv> mitya57: qtwebkit finally building at https://launchpad.net/~ci-train-ppa-service/+archive/landing-004/+packages - I just needed to update ppc64el and arm64 symbols. dbarth has still some apparmor change brewing that will get to the same silo in addition to the already approved webbrowser-app branch, hopefully it'll be ready soon.
[10:29] <dbarth> Mirv: well,apparently i can't change apparmor :/
[10:30] <dbarth> Mirv: so it means i could switch to qtwebkit 5.2 for old webapps
[10:30] <jjohansen> dbarth: what needs changed?
[10:30] <dbarth> Mirv: but i can't transparently migrate them to oxide
[10:30] <dbarth> the 1.0 webapp policy group
[10:31] <dbarth> this one prevents oxide from being used, to ensure only qtwebkit is
[10:31] <jjohansen> ah
[10:31] <dbarth> so apparently no choice but to force (or wait for) eveyone to switch to 14.04 before i can turned down qtwebkit support
[10:32] <Mirv> dbarth: can't as in won't be done? so then the only result is that we need slightly more testing and maybe some help to parse a list of apps not switched to 14.04 framework but using webkit
[10:32] <dbarth> Mirv: so we can only get 1 of the 2 goals here: ie unblock qtwebkit 5.2, but i can't remove the dependency just yet (to help with the image size)
[10:33] <jjohansen> dbarth: are we not phasing out the 1.0 webapp policy group?
[10:33] <cjwatson> well, we probably needed a reason for somebody to work on deprecating the 13.10 framework anyway
[10:33] <Mirv> qtwebkit 5.2 was tested to be quite good when Qt 5.2 landing was being made, so I don't expect huge problems unless some old webapp is using WebGL site
[10:33] <dbarth> Mirv: jamie seemed to think that it was an interface change, so not acceptable for a framework meant to be all sealed by now
[10:33] <Mirv> dbarth: ok
[10:34] <BluesKaj> Hiyas all
[10:35] <jjohansen> dbarth: hrmmm, I was actually thinking more along the lines of, if its deprecated how bad would it be to add oxide permission to it. But I will defer to jdstrand
[10:36] <dbarth> jjohansen: and jdstrand was not so keen on doing that
[10:37] <jjohansen> dbarth: right, I'll poke him in the morning so I can better understand his reasoning, thanks
[10:38] <dbarth> jjohansen: i guess it's because it's not just changing one line in the webapp policy group (the one that says deny)
[10:38] <dbarth> it's probably adding a whole lot in templates, to let the whole oxide process family be authorized
[10:38] <jjohansen> right, I expected it would be more than that
[10:38] <dbarth> something that only happened when 1.1 was designed
[10:38] <jjohansen> ah
[10:38] <dbarth> and the new webview policy group
[10:40] <dbarth> cjwatson: yes, i'm happy to be that extra reason really
[10:52] <mardy> seb128: I want to rename signon-ui to signon-ui-x11, and make both signon-ui-x11 and u-s-s-o-a "Provides: signon-ui"
[10:52] <mardy> seb128: and both of them will depend on a new signon-ui-service package which installs the D-Bus service file
[10:53] <mardy> seb128: does this sound reasonable? (I have another question after this :-) )
[11:04] <seb128> mardy, yes, sounds reasonable
[11:05] <seb128> mardy, be careful though, provides are not versioned, so if you have things depending on signon-ui (=> version) that's not going to work (you need an empty/dummy binary in that case)
[11:07] <mardy> seb128: actually, this is my next question: signon-ui-service replaces a file from signon-ui (<< 0.17) and u-s-s-o-a (<< something), but I'm not sure how to encode this information
[11:07] <mardy> seb128: for u-s-s-o-a I could add a Conflicts, I guess
[11:08] <rbasak> mardy: https://wiki.debian.org/PackageTransition is a helpful reference for this sort of stuff, if that helps.
[11:08] <mardy> seb128: but for signon-ui, will dpkg be able to handle it correctly, since the newest version will be a virtual package (unversioned)?
[11:09] <rbasak> AIUI, Breaks+Replaces is preferred over Conflicts where possible, as it's less constraining on upgrade ordering.
[11:09] <mardy> rbasak: that's useful, I'm reading it now
[11:09] <seb128> mardy, I was going to point the url rbasak just shared
[11:09] <mardy> rbasak: cool, I think that mine is case #5
[11:31] <mardy> seb128: can I add you as a reviewer for the changes I'm about to propose about signon-ui and u-s-s-o-a?
[11:32] <evfool> hey all, do we know about Gnome apps in utopic? I know apps using headerbars have been rejected for trusty LTS, will this change for utopic?
[11:32] <seb128> mardy, sure
[11:32] <seb128> evfool, we don't know yet, larsu and Trevinho are working on making those work under Unity
[11:32] <mardy> seb128: done: https://code.launchpad.net/~mardy/signon-ui/signon-ui-service/+merge/222017 and https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/signon-ui-service/+merge/222016
[11:33] <seb128> once GTK and Unity are improved, we need to revisit the impact on the usability
[11:33] <evfool> seb128: ok, thanks
[11:33] <seb128> evfool, it's fine to update things that are not the ubuntu-desktop, knowing that you are making some user experience miserable on the way
[11:33] <seb128> but that's an upstream issue, not a lot we can do for those who care only about gnome-shell users
[11:40] <seb128> mardy, the changes look fine technically but there is an issue that u-s-s-o-a is in universe so you can't make signon-ui-x11 depends on a binary built from it, you are going to need to do it the other way around and build the service from signon-ui
[11:41] <mardy> seb128: uh, OK
[11:47] <seb128> evfool, it would be nice, if as an upstream, you would support non gnome-shell environments for your software ;-)
[11:48] <seb128> (just saw your comment on the bug)
[11:49] <evfool> seb128: I don't want to start philosophical discussions here, I run system monitor 3.13.1 on Unity, and I'm satisfied, so System Monitor supports non-gnome-shell environments
[11:49] <seb128> evfool, it's using GtkHeaderBar? Can you move/resize the window?
[11:49] <seb128> I can't here
[11:49] <seb128> not sure what is different in your session though
[11:50] <evfool> seb128: I'll have to check when I get home though, but I'm almost sure I would've noticed if I couldn't
[11:50] <seb128> because not having decoration/borders, not being able to resize or move the dialogs is the known state under several non shell environments, including Unity (which we are working on fixing)
[11:51] <evfool> seb128: I was only aware of some XFCE issues, which I don't understand, as I am also able to run System Monitor with headerbar under XFCE
[11:51] <seb128> evfool, the xfce issue is the inverse, you would likely get double decorations
[11:51] <seb128> the headerbar and a wm bar
[11:52] <mardy> seb128: about your remark on Conflicts/Replaces/Provides: I think that my case is very close to #5 here: https://wiki.debian.org/PackageTransition
[11:52] <seb128> evfool, like https://lh4.googleusercontent.com/-YlXpA1jR3O0/UpMsjN5c_OI/AAAAAAAAAXo/ZKPUsRLr-5s/w480-h500-k/xfcecalc.png
[11:53] <evfool> seb128: btw, I have spent quite a few hours trying to figure out a solution for a UI working both with and without a headerbar, but it turned out that I would have to duplicate lots of code
[11:54] <seb128> evfool, yeah, GNOME put developers in a tricky situation, basically you have different platforms there so you can't do well with one simple codebase
[11:55] <seb128> mardy, oh, so you keep an empty "signon-ui" binary as transitional?
[11:56] <mardy> seb128: yes, because we have some packages depending on it, and I'll make both signon-ui-x11 and u-s-s-o-a provide "signon-ui"
[11:57] <seb128> mardy, provides != transitional package
[11:57] <seb128> transitional would be a binary listed in debian/control with no content but a Depends: new-binary
[11:58] <mardy> seb128: ah, no, then it's not a transitional package
[11:58] <mardy> seb128: I guess I confused transitional with virtual
[11:58] <seb128> mardy, so you are not in case 5, use C,R,P then
[11:58] <mardy> seb128: OK, thanks
[11:58] <seb128> yw
[12:02] <evfool> seb128: yup, everyone has their ideas, GNOME had an idea, and the first implementation had some rough edges, but we've all been through this, I hope eventually GNOME and Ubuntu will be able to go down the road hand in hand, even with this convergence madness involved
[12:03] <seb128> evfool, I doubt the GNOME solution is ever going to work great for other desktops, they are making design choices that are meant to integrate with their "OS"
[12:04] <xnox> evfool: cinnamon, mate, lxqt started in part due to GNOME coding against gnome-shell only. How to achieve working hand in hand?
[12:04] <seb128> evfool, you can't really assume that GNOME UI = Ubuntu UI and that you can do well on both environment without at least runtime checks and tweaks
[12:06] <evfool> seb128: yes, that's true, runtime checks and tweaks would be fine for me, but last time I checked, it involved serious code duplication
[12:07] <evfool> and I wanted to avoid that
[12:07] <seb128> well, you can't get your cake and eat too there...
[12:07] <seb128> you have 3 choices
[12:07] <seb128> 1- don't use GtkHeaderbar, and work everywhere (though being less integrated in the GNOME look)
[12:08] <seb128> 2- use GtkHeaderBar and care only about gnome-shell users
[12:08] <seb128> 3- duplicate code to support the different environments
[12:09] <mardy> seb128: I updated those two MPs
[12:09] <seb128> mardy, looking
[12:09] <evfool> ok, if these are the only choices i choose 3, I don't like the first two, 1. because for me the headerbar is not only about the gnome look 2. because I'm also using ubuntu on several computers
[12:11] <evfool> seb128: thanks for the discussion, I'll take another look at supporting non-shell environments, and hopefully will manage to improve the situation (resulting in system monitor 3.xx.xx upload in the utopic archives)
[12:11] <seb128> evfool, 3 is a good option, I think that's mostly where we are heading anyway
[12:11] <seb128> evfool, thanks for looking at the issue, sorry that those design decisions from GNOME/us is making things more difficult for you as an app writer
[12:12] <seb128> we are looking at making header bars working better under Unity
[12:12] <seb128> but they are still going to feel inconsistant and different from others using the wm decorations
[12:16] <evfool> seb128: I saw the progress from the initial implementation (from only close button to supporting the buttons set in gsettings), so I feel like the situation is improving, and yes, the headerbar apps will look different compared to other apps, just like skype does, or acrobat, or eclipse, or firefox
[12:16] <seb128> none of those look different from the menubar perspective atm
[12:17] <seb128> but yeah, which is why I said earlier that it's up to the app writer to have their app looking different or not
[12:17] <seb128> we are just blocking the ones in the default unity set atm
[12:17] <evfool> seb128: yes, the menubar is the same, but look at theming widget looks, etc.
[12:17] <seb128> because we don't want inconsistency in our default installation
[12:17] <evfool> seb128: ok, I understand that
[12:17] <seb128> where we can avoid it
[12:17] <seb128> (like we need it for e.g firefox or libreoffice)
[12:21] <jdstrand> dbarth, jjohansen: the one line change isn't the issue per se. it is the 'webview' policy group that no 13.10 webapp currently has because it didn't exist at the time which all 14.04 and higher webapps have
[12:22] <jdstrand> dbarth, jjohansen: the webview policy group is actually fairly extensive. just adding the policy group to the policy isn't enough, because the 13.10 framework webapps won't already have it so would have to be adjusted anyway
[12:23] <jjohansen> okay
[12:24] <jdstrand> dbarth, jjohansen: I could technically add it to the ubuntu-webapp template, but then it is likely that an app running on an actual 13.10 device won't work. plus, I would need to update the ubuntu-sdk template for apps that use ubuntu webviews)
[12:25] <jdstrand> dbarth, jjohansen: this is extremely disruptive from a policy point of view, and one of the reasons why we have frameworks in the first place. if we are just going to retroactively fix everything going forward, there is little point in having a framework
[12:27] <jdstrand> dbarth, jjohansen: finally, apparmor-easyprof-ubuntu is currently backported into at least one (if not more ppas) for the sdk and these changes could be problematic there if people are using the ppa on a 13.10 system and testing the 13.10 framework
[12:28] <jdstrand> could this be done? yes, but it would be a distraction and throwaway work
[12:28] <jdstrand> (imo)
[12:31] <jdstrand> if we really want to continue supporting the 13.10 framework, then let's actually do it-- ship the qtwebkit 5.1 somewhere where the webapp container can find it. if not, obsolete the framework and get the framework definition off the device. the webapp authors will update their webapps so the webapps show up ion the store and on the device again
[12:32] <jdstrand> and as Colin pointed out, that is work that we need to figure out how to do anyway. IMHO it is wise to do it now when we can afford to make mistakes/learn things when there are no shipping phones
[12:33] <mardy> seb128: thanks a lot for the reviews!
[12:35] <seb128> mardy, yw, thanks for the fixes!
[12:36] <shadeslayer> pitti: https://jenkins.qa.ubuntu.com/job/utopic-adt-kapptemplate/1/ARCH=amd64,label=adt/console fails just because no tests were found?
[12:36] <pitti> shadeslayer: right
[12:37] <shadeslayer> huh
[12:37] <pitti> shadeslayer: this usually indicates some packaging error (wrongly copy&paste'd XS-Testsuite, or typo in debian/tests/control, etc.)
[12:37] <pitti> we treat this as error to detect these
[12:37] <dbarth> jdstrand: ok, nw; i'll keep qtwebkit support for now
[12:37] <mlankhorst> chrisccoulson: good news, I know what's wrong with webapps, bad news, it's hard to fix
[12:37] <dbarth> jdstrand: the problem will solve itself since we don't accept 13.10 apps anymore
[12:38] <shadeslayer> pitti: ok
[12:39] <dbarth> mlankhorst: what's up with webapps?
[12:40] <mlankhorst> I'm guessing the different places that use opengl
[12:40] <mlankhorst> simultaneously
[12:44] <mlankhorst> I'll try something dumb first, maybe I'll get lucky
[12:53] <cjwatson> Noskcaj: expat sync: best to actually check the diff, as in this case the Debian maintainer said they'd applied the dh-autoreconf patch in the changelog but did not in fact do so.  I'm fixing it up for you
[12:53] <cjwatson> dholbach: ^- cc as the sponsor
[12:53] <dholbach> cjwatson, urgh... sorry about that
[12:53] <cjwatson> have also reopened the Debian bug
[12:54] <dholbach> thanks a lot for taking care of all of this
[12:54] <cjwatson> np
[12:59] <mlankhorst> hm hack works
[12:59] <mlankhorst> by not calling flush in swapbuffers
[13:10] <mlankhorst> and doing something even more evil
[13:11] <nectarys_> I'm trying to abitye myself with the linux environment (am a developper). what kind of distribution do you advice me to abitye myself with, please?
[13:13] <cjwatson> (abitye isn't a standard English word.  Google suggests Haitian for "cope", which wouldn't quite fit but I think I know what you mean ...)
[13:13] <cjwatson> If you ask in an Ubuntu development channel then I think you can expect people to suggest that you use Ubuntu :-)
[13:16] <pitti> "appetite"? :)
[13:16] <brendand> Arch, arch, arch!
[13:17] <ogra_> lol
[13:17] <brendand> cjwatson, 'familiar' is also suggested
[13:17] <brendand> cjwatson, which makes sense
[13:18] <brendand> almost
[13:18] <ogra_> familiar was a nice distro :)
[13:19] <brendand> ogra_, not what i meant
[13:19] <ogra_> might have become hard to find the matching hardware for it nowadays though :P
[13:19] <ogra_> brendand, i know ;)
[13:19] <brendand> just googled it
[13:19] <brendand> interesting
[13:19] <brendand> ubuntu touch for 20 years ago :)
[13:20] <ogra_> yeah :D
[13:20] <cjwatson> ah yes, familiarise would fit
[13:23] <nectarys_> brendand, why Arch :p ?
[13:23] <brendand> nectarys_, because i'm being facetious
[13:23] <brendand> which is mostly why anyone suggests arch
[13:24] <nectarys_> brendand, doesn't it take too long to configure ?
[13:26] <brendand> nectarys_, yes!
[13:27] <brendand> nectarys_, ignore us all and just use ubuntu
[13:29] <chrisccoulson> mlankhorst, yay \o/ ;)
[13:31] <mlankhorst> it has the nasty side effect of breaking other things that worked before, though..
[13:36] <mlankhorst> hm i might be able to make things work, but it would require updating libdrm :/
[13:41] <Laney> @pilot in
[13:43] <seb128> woot, between dholbach pitti and Laney the sponsoring queue is going to be empty tonight ;-)
[13:43]  * pitti ^5s dholbach
[13:43] <pitti> but will have to stop soon :/
[13:43]  * dholbach hugs Laney, rbasak, seb128 and pitti
[13:43] <Laney> ha
[13:43] <dholbach> I just did a very few entries today :)
[13:43] <Laney> I'm not the fastest sponsor ever
[13:44] <pitti> but it just lost some 20 entries, I think that's a glitch
[13:44] <pitti> I've seen the sponsoring queue missing two dozen entries at times, and some minutes later they came back
[13:44] <pitti> last time I reloaded we had 65
[13:44] <pitti> oh, and now it's indeed back to 63, nevermind
[13:45] <Laney> I'm looking at the grilo branches
[13:46]  * Laney nods Mirv
[13:47]  * pitti fixes the duplicate patch pilot topic entry, seems I didn't get it quite right this morning (it got truncated)
[13:48] <seb128> xnox, hey, could you push https://code.launchpad.net/~xnox/unity-control-center/utopic/+merge/216962 manually to trunk?
[13:48] <mlankhorst> Laney: hm didn't you file a bug about webapps too?
[13:49] <Laney> umm did I file it?
[13:50] <seb128> what about those?
[13:50] <seb128> oh, nouveau issue
[13:51] <Laney> yeah
[13:51] <Laney> mlankhorst: I think you told me it was https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1300411
[13:54] <pitti> @pilot out
[13:55] <mlankhorst> Laney: ah right, there seems to be a webapps bug now, but the fix is not going to be fun :p
[14:07] <xnox> seb128: in-progress
[14:11] <xnox> seb128: done.
[14:12] <seb128> xnox, thanks
[14:33] <mhall119> shadeslayer: yes I work with the SDK guys, why?
[14:34] <shadeslayer> mhall119: I wanted to get an update on the Qt 5.3 status, but it was posted on the ML a few minutes ago, so it's all good :)
[14:34] <mhall119> shadeslayer: great
[14:35] <rbasak> Do I need to run update-maintainer on an SRU with no Ubuntu changes (but with an ubuntu version number since it's an SRU)?
[14:35] <rbasak> It's a straight rebuild of a more recent version from Debian, since the only thing changed in sid is a fix for the bugs being SRUd
[14:37] <shadeslayer> rbasak: why not a sync then?
[14:37] <shadeslayer> unless that's not possible
[14:38] <rbasak> shadeslayer: I didn't think that's possible because the version is already published in Utopic, and we presumably want a rebuild for Trusty.
[14:39] <rbasak> Since publishing binaries in Trusty built on Utopic would probably not be a good idea (I'm guessing)
[14:39] <rbasak> So I've modified the changelog (and only the changelog).
[14:55] <mdeslaur> cjwatson: I'm stealing the chkrootkit merge from you
[15:02] <shadeslayer> rbasak: hm, I am unsure how that could be handled, best to ask someone in -release I guess
[15:03] <cjwatson> mdeslaur: ah, yeah, be my guest
[15:04] <cjwatson> rbasak: I don't personally think it's necessary to run update-maintainer, but wouldn't reject it if you did
[15:04] <cjwatson> And yeah, we generally wouldn't copy backwards like that
[15:05] <cjwatson> The only exceptions are when rebuilding is hard for some reason and we can be sure that the result doesn't depend on anything interesting from the host system - so the only case I'm aware of is shim/shim-signed
[15:05] <cjwatson> In that case not so much that rebuilding is hard but that it's expensive when the checksum changes
[15:12] <rbasak> cjwatson: OK, thanks!
[15:15] <rbasak> stgraber: auto-apt re-uploaded to trusty-proposed with the LP bug reference fixed. Sorry about that.
[15:16] <stgraber> rbasak: np
[15:36] <cjwatson> doko: hm, is it a bug for the compiler to pollute the built-in namespace with "#define bool bool"?
[15:37] <niemikorpi> what do you think about an idea of creating an own, chromium-based browser with npapi-support?
[15:37] <cjwatson> doko: that is, "gcc -xc -E -dD /dev/null | grep -w bool" returns non-empty on powerpc but empty on amd64
[15:38] <cjwatson> doko: this is the root cause of the haskell-gio build failure on powerpc/ppc64el; I can work around it but am interested in whether it's a compiler bug
[15:44] <doko> cjwatson, from altivec.h:
[15:44] <doko>    'pixel' and 'bool' as context-sensitive AltiVec keywords (in
[15:44] <doko>    non-AltiVec contexts, they revert to their original meanings,
[15:44] <doko>    if any), so we do not need to define them as macros.  */
[15:44] <doko> #if !defined(__APPLE_ALTIVEC__)
[15:44] <doko> #define vector __vector
[15:44] <doko> #define pixel __pixel
[15:44] <doko> #define bool __bool
[15:44] <doko> #endif
[15:44] <doko> so looks like intent =) however that wouldn't explain why you see it on powerpc
[15:45] <seb128> xnox, do you see anything wrong in ""Vérification du disque %1$d sur %2$d (avancement : %3$d%%)"" (that's a mountall translations for "Checking disk %1$d of %2$d (%3$d%% complete)")
[15:45] <cjwatson> doko: I'm seeing it defined to bool rather than __bool
[15:46] <cjwatson> doko: It looks like the effect of /usr/lib/gcc/powerpc64le-linux-gnu/4.8/include/stdbool.h, but I wouldn't expect that to be included without asking for it?
[15:46] <doko>   if (TARGET_EXTRA_BUILTINS)
[15:46] <doko>     {
[15:46] <doko>       /* Define the AltiVec syntactic elements.  */
[15:46] <doko>       builtin_define ("__vector=__attribute__((altivec(vector__)))");
[15:46] <doko>       builtin_define ("__pixel=__attribute__((altivec(pixel__))) unsigned short");
[15:46] <doko>       builtin_define ("__bool=__attribute__((altivec(bool__))) unsigned");
[15:46] <doko>       if (!flag_iso)
[15:46] <doko>         {
[15:46] <doko>           builtin_define ("vector=vector");
[15:46] <doko>           builtin_define ("pixel=pixel");
[15:46] <doko>           builtin_define ("bool=bool");
[15:46] <doko>           builtin_define ("_Bool=_Bool");
[15:46] <doko>           init_vector_keywords ();
[15:46] <doko>           /* Enable context-sensitive macros.  */
[15:46] <cjwatson> Hmm, maybe not, __bool_true_false_are_defined isn't there
[15:46] <doko>           cpp_get_callbacks (pfile)->macro_to_expand = rs6000_macro_to_expand;
[15:46] <doko>         }
[15:46] <doko>     }
[15:46] <xnox> !pastebin
[15:48] <xnox> seb128: seems resonable. Unless %%) is somehow parsed incorrectly whilst "%% " does the right thing
[15:49] <seb128> xnox, let me try that, because the % part is missing in plymouth for some reason
[15:50] <doko> cjwatson, $ gcc -E -dM - </dev/null | grep bool doesn't show anything on powerpc
[15:52] <cjwatson> doko: oh, sorry, I'm testing on ppc64el after all
[15:52] <cjwatson> identical haskell-gio failure on powerpc though ...
[15:52] <doko> cjwatson, so yes, then I think this is expected. otoh, maybe we can raise it ...
[15:53] <cjwatson> doko: I could probably just use --std=c89 then
[15:53] <doko> yes
[15:54] <Laney> stgraber: https://code.launchpad.net/~rcj/ubuntu/precise/libdumbnet/sru/+merge/221919 could you confirm/deny that you asked for this?
[15:54] <stgraber> Laney: I can confirm but it's already been uploaded and is currently in precise-proposed
[15:55] <Laney> oh okay
[15:55] <Laney> let me get that merge proposal off the queue then ;)
[15:55] <cjwatson> or maybe there's some way I can glue in cpphs
[15:57] <doko>  * Adjust watch file to new hackage layout
[15:57] <doko> ^^^ do you trust such packaging? ;-P
[15:57] <seb128> xnox, no, adding a space doesn't fix it
[15:57] <cjwatson> what's wrong with that?
[15:59] <doko> "hackage" layout
[15:59] <cjwatson> doko: http://hackage.haskell.org/
[15:59] <cjwatson> not a typo
[15:59] <doko> ahh
[16:00] <doko> cjwatson, on powerpc I get the define only, if I explicitly add -maltivec
[16:04] <cjwatson> doko: I think I'll just whack in --std=c89 for now and see if that fixes things across the board
[16:05] <doko> cjwatson, or does ghc turn on altivec by default?
[16:05] <cjwatson> er with one -
[16:05] <cjwatson> doko: checked, doesn't seem to
[16:06] <cjwatson> though who knows what lurks in the depths of that build system
[16:06] <doko> yes, like all -f and -m options
[16:08] <seb128> xnox, so, it doesn't like the ":" in the string
[16:11] <cjwatson> oh for goodness' sake I can't pass in -std=c89 through the .cabal file.  Will have to hold nose and use -Ubool I think
[16:14] <tseliot> seb128: shall I merge and upload the code myself now that you have approved it?
[16:15] <seb128> tseliot, no, that's going through CI train, it's in https://launchpad.net/~ci-train-ppa-service/+archive/landing-014/
[16:16] <tseliot> seb128: oh, nice, I had no idea that's how it works. Thanks
[16:16] <seb128> tseliot, yw, thanks again for working on that!
[16:17] <tseliot> seb128: yw. BTW shall I do the same for the SRU for 14.04?
[16:18] <seb128> tseliot, did you want some feedback from utopic first?
[16:19] <xnox> seb128: there is non-breaking space before ":" in your paste above (at least that's how it came through to me)
[16:19] <seb128> xnox, of course, that's french :p
[16:19] <xnox> seb128: sounds very weird though, as ":" isn't a special character in gettext.
[16:19] <tseliot> seb128: not really, we have already done the testing on the limited use cases that we support. It was more of a matter of landing things in 14.10 first
[16:20] <seb128> tseliot, ok, I can do the SRU upload as well
[16:20] <xnox> seb128: is the trailing ) always printed? e.g. to eliminate the case where the translated string is simply much longer than "C" translation.
[16:20] <tseliot> seb128: ok, I'll prepare the SRU then, thanks
[16:21] <seb128> xnox, I did tweaks to the translations, like I changed it for "done %3$d%%" and it works "done : %3$d%%" and it stops working
[16:21] <xnox> *sigh*
[16:21] <seb128> tseliot, don't bother, I'm going to go through the CI landing as well
[16:22] <seb128> tseliot, but if you could make the bug SRU compliant that would be nice (impact, test case, regression potentiel)
[16:22] <tseliot> seb128: sure
[16:22] <seb128> tseliot, thanks
[16:22] <tseliot> :)
[16:31] <dpm> pitti, could you enable the utopic langpack cron job? The export schedule in LP has now been updated
[16:40] <tseliot> seb128: ok, the description should be fine now. Thanks again
[16:40] <seb128> tseliot, yw!
[17:02] <infinity> doko: Your binutils upload dropped my multiarch fix.
[17:05] <nectarys_> i'm trying to connect a open my usb via virtualbox where i've launched Windows 7, but I wasn't able to find how. Does anyone know how to deal with, please ?
[17:26] <Laney> @pilot out
[18:30] <rbasak> schroot can't remove /var/lib/schroot/mount/<session>. Any ideas?
[18:31] <rbasak> Doing it by hand gives me "Device or resource busy", but I don't see it mounted, and lsof doesn't see anything inside it.
[18:31] <rbasak> This might have happened because I forgot about the session and updated the chroot underneath it
[18:32] <rbasak> Nothing in /proc/mounts that I can see.
[19:09] <CodePulsar> Can I have two versions of Boost Libraries installed on the system?
[19:09] <CodePulsar> i.e.  Boost 1.54 and 1.55 ?
[19:09] <CodePulsar> I see if I try to install 1.55 it tries to uninstall 1.54 and all the application that depend on it including Ubuntu SDK
[21:02] <brendand> anyone hitting a similar problem to this? http://paste.ubuntu.com/7590314/
[21:03] <brendand> luatex : Depends: texlive-binaries (>= 2014) but 2013.20130729.30972-2build4 is to be installed
[21:03] <brendand> is the gist of it
[21:09] <ScottK> brendand: Probably a stale mirror.
[21:12] <brendand> ScottK, i just have archive.ubuntu.com and gb.archive.ubuntu.com in my sources.list
[21:13] <ScottK> Dunno.  The newer texlive-binaries is in uptopic.
[21:13] <ScottK> utopic even
[21:14] <ajmitch> at a glance, luatex was removed from utopic a couple of days ago
[21:19] <nottheoilrig> i just launched an ubuntu ec2 image and ran aptitude install git
[21:19] <nottheoilrig> Err http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ utopic/main git amd64 1:2.0.0-1
[21:19] <nottheoilrig>   403  Forbidden
[21:20] <nottheoilrig> what am i doing wrong?
[21:20] <nottheoilrig> please let me know if theres a more appropriate irc channel for this
[21:23] <sladen> nottheoilrig: you're not doing anything wrong; that archive mirror appears to be currently down
[21:24] <sladen> nottheoilrig: you can edit /etc/apt/sources.list  to select another mirror
[21:24] <nottheoilrig> okay thanks is there a web page with the status of the various ubuntu infrastructure?
[21:25] <nottheoilrig> like https://status.github.com/
[21:25]  * sladen traies to find it in https://launchpad.net/ubuntu/+archivemirrors
[21:26] <nottheoilrig> status.ubuntu.com is a thing...
[21:27] <mterry> Laney, you set bug 1325505 to won't fix?
[21:37] <sladen> nottheoilrig: I've reported that one machine being 403 to the sysadmin's tracking system;  There are several hundred more available though!
[21:37] <sladen> nottheoilrig: see  https://launchpad.net/ubuntu/+archivemirrors
[21:37] <sladen> nottheoilrig: or just change to to plain 'archive.ubuntu.com' for the moment
[21:38] <sladen> nottheoilrig: status.ubuntu.com is actually for tracking bug process across the whole OS and application stack
[21:38] <nottheoilrig> sladen: awesome thanks did you find a webpage with the status of eg http://us-east-1.ec2.archive.ubuntu.com
[21:39] <sladen> nottheoilrig: https://launchpad.net/ubuntu/+archivemirrors
[21:39] <sladen> nottheoilrig: probably https://launchpad.net/ubuntu/+mirror/us.archive.ubuntu.com-archive
[21:39] <sladen> nottheoilrig: but I suspect that is served by several machines; one of which happens to be this one
[21:40] <sladen> nottheoilrig: it says (in general) "last checked 15 hours ago"
[21:40] <rbasak> sladen: #ubuntu-mirrors is the right place to ask this I think
[21:40] <rbasak> I don't see anything in that channel topic though
[21:42] <brendand> anyone running utopic can tell me what ' systemctl status cgmanager.service' returns for them?
[21:43] <stgraber> root@lantea:~# systemctl status cgmanager.service
[21:43] <stgraber> Failed to get D-Bus connection: No connection to service manager.
[21:43] <stgraber> brendand: which is the expected result since we haven't switched to systemd yet and systemd obviously isn't running on that system
[21:44] <brendand> stgraber, oh - but i am running systemd
[21:44] <brendand> stgraber, i tried switching back earlier today and it messed everything up
[21:45] <brendand> stgraber, like network-manager didn't start and lot's of other weirdness
[21:45] <stgraber> brendand: then you're pretty much on your own then, we don't support doing that yet (pitti is working on it but it's very much work in progress)
[21:48] <brendand> mterry, set it back to in progress. people should comment on status changes
[21:49] <mterry> brendand, yeah...  I'll ask in bug for clarification too
[22:07] <Laney> I blame the gremlins
[22:23] <smoser> anyone know how
[22:24] <smoser>  http://archive.ubuntu.com/ubuntu/pool/main/m/maas/maas_1.5.2+bzr2282.orig.tar.gz
[22:24] <smoser> differs from
[22:24] <smoser>  https://launchpad.net/ubuntu/+archive/primary/+files/maas_1.5.2%2Bbzr2282.orig.tar.gz
[22:24] <smoser> (second is seen at https://launchpad.net/ubuntu/+source/maas)
[22:25] <smoser> ugh.
[22:27] <smoser> ugh. no it doesnt. ignore that
[22:33] <lifeless> smoser: full marks :)
[22:46] <sarnold> xnox,pitti, this seems like one for you guys, even though it says 14.04: 1326412
[22:48] <RAOF> pitti: Huh, I seem to have lost backscroll. How did mips go?
[22:51] <xnox> sarnold: hey, what's up?
[22:53] <sarnold> xnox: bug 1326412 looks like it might be related to something you guys were working on in malta; I wanted to aim it your way in case you were working on a pile of these sorts of issues all at once :)
[22:54] <acrilex> hello, I just created my PPA on launchpad, and the package fail to compile with deps errors. can someone help me plz?
[22:55] <acrilex> Here is the build log, it is long, but the most important should be at the end: https://launchpadlibrarian.net/176941630/buildlog.txt.gz
[22:56] <sarnold> acrilex: this line looks most important: dpkg-source: info: fuzz is not allowed when applying patches  dpkg-source: info: if patch 'opengles' is correctly applied by quilt, use 'quilt refresh' to update it
[22:56] <xnox> sarnold: looking at the package i'd think it's mvo or bmurray. Oh, wait. nah you can't do that yet.
[22:57] <xnox> sarnold: we don't support a whole bunch of stuff when booted with systemd at the moment. One can't dist-upgrade, or even just install/upgrade a bunch of packages yet.
[22:57] <sarnold> xnox: ah :)
[22:57] <xnox> sarnold: hence all of us working on bringing systemd support flip between booting upstart & systemd at the moment (by tweaking init=/lib/systemd/systemd vs init=/sbin/init)
[22:58] <acrilex> do you think there is a fix I can apply to fix compile issue (this is launchpad buildbot, can't send him command)
[22:58] <xnox> sarnold: i've added a tag "systemd-boot" which is what we use to track everything. and will comment in a second.
[22:58] <sarnold> xnox: thanks!
[22:58] <acrilex> do you think there is a fix I can apply to fix compile issue (this is launchpad buildbot, can't send him command)
[22:58] <sarnold> acrilex: what does 'quilt pop -a ; quilt push -a' report in your local tree?
[22:59] <acrilex> wait 1 sec, doing it
[23:00] <acrilex> oh no! need to pull back project, it will take 1 minute
[23:04] <acrilex> Patch opengles does not exist
[23:05] <acrilex> who can I clean the patch from project and recreate it?
[23:05] <acrilex> how*
[23:07] <sarnold> acrilex: I don't know much about this end of things.. does 'bzr status' show anything unexpected?
[23:08] <acrilex> I will repull the original one and redo my job! will be easier
[23:28] <xnox> wgrant: barry: in lazr.restfulclient's test-suite, i think it should be possible to still use wsgi_intercept, but instead of serving lazr.restful test-app, serve a WSCGIProxy.spawning app (aka shim). That shim would fork python2 interpreter, and server lazr.restful using python2. But it should allow running a full python3 test-suite in the lazr.restfulclient.
[23:28] <xnox> there are a few python3 compat things left unported in lazr.restulclient, so i'll tackle those first.
[23:29] <barry> xnox: what are still left unported?
[23:29] <xnox> and then work on the frankenstein (six) runner.
[23:29] <xnox> barry: in your branch: still a few "except Exception, e" & it uses oauth, instead of oauthlib.
[23:30] <xnox> barry: one can run a partial (non-lazr.restful dependant) test-suite under python3 and those things show up.
[23:30] <xnox> (oh and a few import statements compats)
[23:30] <xnox> I'll propose my work in progress branch to clean up those.
[23:30] <barry> xnox: sounds great!
[23:30] <xnox> Haven't done authlib port yet though. Should be easy (following your notes)
[23:31] <barry> yep
[23:31]  * barry -> dinner
[23:31] <xnox> barry: the documentation on WSCGIProxy.spawn is sparse though. I hope it will work.
[23:32] <xnox> (should be more straightforward than cjwatson's mock C functions in python via reverse python-gi)