[00:05] -queuebot:#ubuntu-quality- Builds: Lubuntu Alternate i386 [Artful Dot One] has been marked as ready
[00:05] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop i386 [Artful Dot One] has been marked as ready
[00:05] -queuebot:#ubuntu-quality- Builds: Lubuntu Alternate amd64 [Artful Dot One] has been marked as ready
[00:05] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop amd64 [Artful Dot One] has been marked as ready
[06:50] -queuebot:#ubuntu-quality- Builds: Ubuntu Desktop amd64 [Artful Dot One] has been marked as ready
[11:43] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop amd64 [Artful Dot One] has been marked as ready
[11:43] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop i386 [Artful Dot One] has been marked as ready
[17:57] <flocculant> tsimonq2: I think the testcase shown against alternate no network on your tracker  needs changing  bug 1742665
[17:57] <flocculant> just fyi :)
[17:59] <tsimonq2> flocculant: ack, although I'm going to bounce this to wxl because he's Lubuntu's QA head :)
[17:59] <wxl> siiiiiiiiiigh
[18:00] <wxl> tsimonq2: go make a GCI task for him to fix it :)
[18:00] <flocculant> they can't
[18:01] <flocculant> if they can - then I will jump up and down so much - that you'll be getting a tsunami over your side of the pond :D
[18:02] <flocculant> tsimonq2 wxl - anyway - I did my bit, made the bug invalid :D
[18:03] <wxl> OH
[18:03] <wxl> ok i see the problem
[18:03] <wxl> it's not a testcase issue
[18:03] <wxl> it's something the release manager can fix
[18:03] <wxl> so off to you tsimonq2 XD
[18:04] <flocculant> ha ha ha
[18:04] <flocculant> you 2 crack me up :)
[18:05] <wxl> yeah it's a constant game of Not My Job™ XD
[18:05] <flocculant> I could of course fix it as well - but I've been out of the house for 12 hours, had no tea, could eat a scabby dog, and am still sat in the motorbike waterproofs :P
[18:05] <wxl> or at least: It's Your Job™
[18:05] <wxl> we don't typically do this to other contributors :)
[18:05] <flocculant> biab - when I dealt with various things ...
[18:05] <wxl> o/
[18:06] <tsimonq2> /
[18:06] <wxl> oops he lost his head
[18:06] <flocculant> oh noes
[18:06] <tsimonq2> hahaha
[18:07] <tsimonq2> wxl: Yeah well TECHICALLY you're ALSO an RM but I guess this one time I'll JFDI ;)
[18:07] <tsimonq2> *TECHNICALLY
[18:07] <wxl> *TECHNICALLY*
[18:08] <wxl> but *ACTUALLY*
[18:08] <wxl> you are it :)
[18:08] <tsimonq2> hahahahaha
[18:09] <flocculant> it's like the Statler and Waldorf show in here :p
[18:13] <tsimonq2> wxl: ugh give me the right testcase number
[18:13] <flocculant> tsimonq2: it's in the bug report :p
[18:13] <flocculant> 1700 if I'm right :)
[18:14] <wxl> and flocculant is never wrong
[18:14] <flocculant> ha ha ha
[18:14] <flocculant> if only that were so - I could make millions :p
[18:14] <wxl> yeah i mean jeez look at trump
[18:14] <wxl> he's a genius
[18:15] <flocculant> ha ha ha
[18:15] <flocculant> stablye jeenius he is for sure :p
[18:15] <wxl> a stable one at that, i hear
[18:15] <flocculant> kerching
[18:16] <wxl> i'm just going to go ahead and quietly drop this here. just pretend you didn't see anything. https://www.youtube.com/watch?v=1WxNRtu8jh4
[18:16] <flocculant> This video is not available
[18:17] <wxl> aww fooey
[18:17] <wxl> trump probably took it down
[18:17] <wxl> it's "Mein Trumpf" by MDC
[18:17] <flocculant> :)
[22:12] <tsimonq2> wxl: Soo... I have no idea what I'm doing :)
[22:12] <tsimonq2> wxl: How do I edit this from my end?
[22:12] <wxl> well
[22:12] <wxl> you know what i've always done?
[22:13] <tsimonq2> No clue :)
[22:14] <wxl> keep clicking at it until it works XD
[22:14] <wxl> if you figured out how to fix the links for dot one i'm sure you can handle it
[22:15] <wxl> tl;dr i don't know for sure
[22:15] <wxl> not joking.
[22:15] <tsimonq2> wxl: Here's the thing, I need to edit the test*suite*
[22:16] <tsimonq2> wxl: I'll poke around in the website source but I have a feeling I can't do that as a non-admin :/
[22:16] <wxl> i KNOW there's a way to do it somehow
[22:16] <wxl> i guess i'll log in and see if i can figure it out
[22:16] <wxl> 1700 right?
[22:16]  * tsimonq2 greps the source
[22:16] <tsimonq2> wxl: yeah
[22:19] <wxl> http://iso.qa.ubuntu.com/admin/config/services/qatracker/testsuites/299/edit
[22:19] <wxl> which one is the WRONG one?
[22:19] <tsimonq2> wxl: I can't access that page.
[22:19] <tsimonq2> hmm
[22:19] <tsimonq2> uhm
[22:19] <wxl> oh really?
[22:19] <wxl> are you logged in?
[22:19] <tsimonq2> wxl: 1689 in Alternate is the wrong one
[22:19] <tsimonq2> Yeah I'm logged in
[22:20] <wxl> weird
[22:20] <wxl> oh
[22:20] <wxl> you know i do have perms others don't
[22:20] <wxl> i'm not just release manager, i have testcase/qa-site status
[22:20] <tsimonq2> How would I go about getting those if that's a thing people are willing to give me? :)
[22:21] <wxl> well you might want to check with flocculant
[22:21] <tsimonq2> flocculant: hi :)
[22:31] <wxl> fixed it
[22:32] <tsimonq2> k cool
[22:39] <wxl> https://launchpad.net/~ubuntu-qa-website-devel
[22:39] <wxl> i think that's what you want
[22:39] <wxl> i'm also in https://launchpad.net/~ubuntu-testcase but i doubt that gives top level admin access
[22:40] <wxl> it's also possible it's hardcoded, as i believe general release manager access is
[22:40] <wxl> like there's not *A* team one can get added to to mark things as ready/not
[22:41] <wxl> there's a bunch of hardcoded teams


[07:45] <mpt> https://launchpad.net/~78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgszpjpwcmvkb-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o65qze67n1wneepm is a pretty impressive Launchpad ID
[07:56] <StevenK> I fixed the bug that was causing that around that time, I think
[13:18] <dobey> mpt: lol, nice ssh key :)
[13:19] <mpt> I like how it has “-launchpad-” skulking in the middle there
[13:27] <Peng> their user ID is *that*, and their display name is "Aubs"!?
[14:23] <Saviq> another spammer: https://bugs.launchpad.net/mir/+bug/1317897
[14:25] <cjwatson> Saviq: they're gone
[14:26] <Saviq> cjwatson, thanks, do you think those are people spammers or we have some issue with automated registration?
[14:26] <cjwatson> I don't have a way to tell
[14:26] <cjwatson> They only seem to report very small numbers of spam each
[14:26] <cjwatson> But that could be deliberate
[14:27] <Saviq> cjwatson, yeah it does sound like a manual spammer then
[14:28] <cjwatson> Or it could be to try to evade attention and maximise the chance of gaining pagerank from LP - not sure how we'd tell, maybe grovel through appserver logs to see how fast the registration happened?
[14:34] <sithlord48> i having a problem importing a branch from git hub . i keep getting the branch not found error in my log for import. if i click the link launchpad shows for my import code it goes to the correct location anyone have some pointers?
[15:24] <sithlord48> got started of an import now have different errors. http://launchpadlibrarian.net/175030143/sithlord48-q-gears-trunk.log  how do i check out just a branch of my github code?
[15:26] <dobey> append ",branch=$branchname" to the end of the url
[15:27] <sithlord48> dobey:  use the address for the main branch?
[15:28] <dobey> the https url yes
[15:28] <sithlord48> dobey i used git://github.com/sithlord48/q-gears/tree/trunk.git before should i use git://github.com/sithlord48/q-gears.git,branch=trunk?
[15:28] <dobey> yes
[15:29] <dobey> having /tree/ there is wrong
[15:29] <sithlord48> ok
[15:29] <sithlord48> i have never imported from git or github before only svn and sourceforge so its a tad different
[15:50] <sithlord48> awesome after waiting for it to start it seams to be importing correctly now ! Thanks dobey!!\
[15:55] <sithlord48> dobey : got mostly done then died any idea? http://launchpadlibrarian.net/175031961/sithlord48-q-gears-trunk.log
[16:01] <sithlord48> Is that an error in my stuff to be imported or the importer?
[16:46] <dobey> sithlord48: looks like something possibly has a name that is not valid utf-8
[16:46] <sithlord48> ok ill see what i can find
[19:12] <lazyPower> allo, any idea why a juju charm branch references vim-rails as it's upstream location? https://code.launchpad.net/charms/+source/rails
[19:18] <dobey> lazyPower: you should probably ask the juju charms people
[19:18] <lazyPower> dobey: i am a juju charms people
[19:19] <lazyPower> i however don't have access to edit this.
[19:21] <dobey> no
[19:21] <dobey> err
[19:21] <dobey> nor i
[19:21] <dobey> you need to ping someone in https://launchpad.net/~charmers
[19:21] <dobey> that is the team that maintains the distribution
[19:22] <lazyPower> dobey: http://launchpad.net/~lazypower
[19:22] <lazyPower> i'm a member of the group - this is an alias however - oh wait.. it hink i just answered my problem. I need to look at the ~charmers branch
[19:22]  * lazyPower looks
[19:23] <dobey> huh, well you should have whatever perms are needed for that i think, being a member of the maintenance team
[19:24] <dobey> on the other hand, it's been 15 minutes and my meager branch still hasn't been scanned :(
[19:31] <lazyPower> dobey: for the charm queue?
[19:31] <lazyPower> or to show up in the store?
[19:32] <dobey> my branch? neither
[19:32] <dobey> just a branch on launchpad
[19:32] <lazyPower> ah
[19:32] <dobey> i ended up deleting it and re-pushing
[19:32] <dobey> but now launchpad isn't linking it ot the bug as it's supposed to do :(
[19:35] <lazyPower> oi


[07:31] <pepshan> hi
[07:31] <pepshan> i have this problem: E:Encountered a section with no Package: header, E:Problem with MergeList /var/lib/apt/lists/bg.archive.ubuntu.com_ubuntu_dists_trusty_restricted_i18n_Translation-en, E:The package lists or status file could not be parsed or opened.
[11:01] <silver_m> #powerpoint
[12:13] <Novice01y> Hello. I don't have sound on Lubuntu from installation. Is there other way to solve this than installing pulseaudio>
[21:10] <Novice201y> Hello. How to send file from Lubuntu to phone by bluetooth?
[21:11] <ianorlyn> Novice201y, I don't use bluetooth myself but the application in lubuntu is called blueman
[21:12] <Novice201y> ianorlyn: Thank You.
[22:28] <l1n3x> hey guys
[22:28] <ianorlyn> hi anyway I can help?
[22:29] <l1n3x> do you need help?
[22:29] <ianorlyn> no I don'
[22:29] <ianorlyn> no I don't
[22:30] <l1n3x> well i am experiencing a issue, whenever i attempt to open the shutdown menu nothing happens, even in lxpanel the only way to properly shutdown for me atm is via sudo poweroff
[22:32] <l1n3x> i can get to the login screen via sudo service lightdm restart


[21:39] <tumbleweed> jamespage: python-testtools is getting a good few packages caught up in -proposed, thanks to ADT failures


[00:50] <thiagoandrade> I can see the work items on launchpad, but how should I proceed in case I want to help some specific work item? Should I talk to the responsible for it or what?
[00:51] <bryce> thiagoandrade, yes.  Or if you're not sure who to talk to, ask robert or thomas for guidance.
[06:11] <llstarks> why mir? why not smithers?
[06:20] <RAOF> Why not Zoidberg?
[06:44] <duflu> "Zoidberg ate my windows" sounds plausible
[06:53] <tvoss> good morning :)
[07:14] <llstarks> RAOF, don't let #wayland get under your skin. mir actually works. i've never seen a working wayland environment outside of rebecca black
[07:14] <llstarks> or weston
[07:20] <RAOF> Well, I got to roughly the point that we're currently at with respect to a system compositor some 6 months or so ago with weston :)
[08:23] <llstarks> RAOF, can you rephrase that? i interpreted that as "mir is where weston was 6 months ago"
[08:24] <llstarks> i'm probably just too tired to think straight
[08:34] <RAOF> llstarks: Well, it's not so much "mir is where weston was 6 months ago" as "weston could do this thing, 6 months ago, that mir does now".
[08:36] <tvoss> RAOF, admittedly focusing on the desktop form-factor, right?
[08:36] <RAOF> tvoss: Indeed.
[08:36] <RAOF> And it's not much help *weston* being able to do something, because weston isn't actually intended to be used.
[08:37] <RAOF> It's more a testbed.
[08:37] <tvoss> RAOF, yup
[10:00] <testi> Will Applications compiled for Mir run natively without compatibility layer (protocol translation, additional context switches) on Wayland Compositors? Does that apply for the other direction too? By application I mean anything not deeply integrated with the system, especially games, because under no circumstances I want Mir to introduce any delay (context switch, protocol translation) only because some game developer has chosen Mir as targ
[10:00] <testi> Is Mir capable of reliable bypass offscreen on fullscreen? (also in order to reduce delays)?
[10:01] <testi> in my last tests compiz is not reliable in that, while kwin does a good job
[10:05] <tvoss> testi, for your app related question: It's a question of the toolkit integration. So the integration work with the compositor normally happens on the toolkit layer (Qt/GTK/XUL...), so apps talk the native language of the compositor
[10:06] <tvoss> testi, for non-composited fullscreen: yes, we are working on that. Any specific use-case apart from fullscreen games/apps you have in mind?
[10:07] <testi> tvoss: and by a strongly-propaged default any toolkit will be compiled with both mir and wayland support?
[10:08] <tvoss> testi, toolkits normally have a platform abstraction layer that is pluggable at runtime. Qt for example allows you to switch the actual backend implementation by setting an environment variable
[10:08] <tvoss> testi, I'm not sure about the exact mechanism for GTK3, but I think it should support that
[10:08] <testi> I actually just have games in mind. That's all I care and I just want them to make the shortest path from input to screen, no matter what compositor I use.
[10:09] <testi> except for X11 I'd accept an external wrapper-server and protocol translation
[10:10] <tvoss> testi, @games: sure, we will optimize unredirected fullscreen and optimize for cases where pixel-type of a surface is xrgb and a surface is fullscreen
[10:11] <tvoss> testi, any specific game-engine you have in mind?
[10:12] <testi> tvoss: Unigine, ioquake3, warsow, xonotic, any wined3d game, any wine opengl game, Source Engine, Doom3
[10:13] <tvoss> testi, that's a comprehensive list :) I hope I could answer your question?
[10:15] <testi> tvoss: I just wonder what happens when a game supports wayland only - will there be a wrapper-server, or will it be an in-process module of the Display-Server without any wrapping, in other words equally short paths, no additional context switch
[10:17] <tvoss> testi, right now, if a game only supports wayland, it will not run against mir. However, a wrapping approach would be one way to solve it, essentially allowing the game to talk wayland to Mir, and then switching to unredirected fullscreen.
[10:18] <llstarks> tvoss, what will wayland/mir-enabled video players be like on ubuntu touch? for example, mplayer2 and mpv support wayland. if they support mir in the future, would i be able to compile or use an armhf binary and run it on the phone?
[10:18] <testi> but then wayland is not translated to Mir? it directly reports to the inner agnostic core? And there is no delay because of that? And mir is basically a Display Server which speaks 2 languages and Mir is only offically but not physically the main protocol?
[10:19] <tvoss> llstarks, sure. Again, most of the applications will rely on a toolkit and we will work towards enabling them for Mir
[10:20] <tvoss> testi, right, think about the protocol as a bridge to a certain degree. Almost all of the rendering is anyway done via the (e)gl(es) drivers, i.e., the actual buffer content is not transmitted via any protocol
[10:21] <testi> tvoss: I know, but input events are
[10:22] <tvoss> testi, sure, those would need to be translated
[10:22] <testi> tvoss: translated into Mir?
[10:23] <tvoss> testi, from Mir into Wayland, to be picky here, but yes
[10:23] <testi> tvoss: of course
[10:25] <testi> tvoss: but why? It doesn't need to talk "Mir" if it ends up in a wayland client.
[10:26] <tvoss> testi, at some point, things from the core need to be mapped to a protocol/communication layer, that's where the translation happens. That's server-side though, not client side
[10:27] <testi> tvoss: but then it's not mapped from protocol to protocol, but from the core directly to wayland?
[10:27] <tvoss> testi, yup
[10:28] <testi> tvoss: Well okay - if these are the goals, I'm fine - I'm a bit a latency/performance fanatic
[10:29] <tvoss> testi, fair enough, we all are :) we are working to put quite extensive benchmarking in place, too
[10:29] <tvoss> testi, for the ubuntu touch demos, we used highspeed cameras twice to check on our actual frame rate and responsiveness to input
[10:33] <testi> :-)
[11:35] <xnox> Can I run raring unity on mir on amd64?
[11:35] <xnox> If so, where and how? =)
[11:40] <alan_g> xnox: soon (I'm not sure of exact status - some packages were missing)
[11:40] <alf_> xnox: You can run unity3d (i.e. the current unity) on X11 on xmir. We are in the process of setting up detailed instructions for that (and other things).
[11:40] <alan_g> xnox: And instructions
[11:40] <alan_g> alf_: snap
[11:41] <xnox> ok. I'm fine with early breakge and stuff. Cause i work on upstart usersessions, so I'd like to see if I can be monitoring / respawning mir with upstart user session support.
[11:41]  * xnox is running current ubuntu session like that, we are planning on merging and landing upstart1.7 soon.
[11:42] <tvoss|food> xnox, you might want to talk to robert_ancell, too
[11:42] <tvoss|food> xnox, he is offline, currently
[11:42] <xnox> tvoss|food: is he usually in this channel?
[11:43]  * xnox ponders about pointing to "juju deploy znc" ;-)
[11:50] <tvoss|food> xnox, yup
[13:47] <pete-woods1> irc://irc.canonical.com:6697/#ubuntu-uds-client-2
[13:47] <pete-woods1> d'oh
[13:47] <pete-woods1> :-$
[13:56] <tvoss> pete-woods, :)
[15:25] <thiagoandrade> Following the instructions in HACKING.md I get errors in the command mk-build-deps and it simply states 'dpkg call error'
[15:26] <thiagoandrade> How should I proceed to build?
[15:28] <thiagoandrade> Ok, managed it. There was an error in the command.
[15:29] <alan_g> thiagoandrade: what was the error?
[15:32] <thiagoandrade> alan_g, I forgot a dash in the tool option
[15:32] <thiagoandrade> Just realized after.
[15:32] <alan_g> thiagoandrade: ok. Thanks
[16:12] <kdub> bumping to g++4.7!
[16:24] <kdub> alan_g, do you think i should doc the android stuff in HACKING.md or on the wiki?
[16:24] <kdub> i'm leaning towards HACKING.md
[16:25] <alan_g> kdub: Is there enough to be  HACKING-android.md?
[16:26] <kdub> yeah, there is... i'll do that
[16:26] <alan_g> kdub: but I favour the source tree. (We should be getting the make doc output up on a webserver.)
[16:26] <bryce> kdub, principle documentation should ship with the code
[16:27] <kdub> yeah, i was just about to say... would be nice if the HACKING.md files ended up on a webpage
[16:46] <AlanBell> what kind of configurations will mir support? dual screen? multiple screens? orientation changes? different colour depth screens like an e-ink screen on the back of a regular screen etc?
[16:50] <bryce> AlanBell, long term, yes to all
[16:51] <bryce> last I checked a couple weeks ago, it does clone mode on dual-head ok (as set up by drm), but not hotplugging or anything fancy
[16:52] <bryce> the configuration dialog will probably be more minimal than the current one, but we expect to have some advanced settings tool.
[17:02] <mmrazik> thomi: we would need the output of make doc to appear on some public site for mir :)
[17:02] <mmrazik> thomi: so I thought you are the right person for it :)
[17:03] <thomi> mmrazik: good thing we now have a nice way to do that
[17:03] <thomi> mmrazik: will fil a bug & assign it to me so I don't forget
[17:03] <mmrazik> thomi: but we still need some special user on some server, etc, right?
[17:03] <mmrazik> thomi: cool
[17:03] <mmrazik> alan_g: ^^
[17:03] <thomi> mmrazik: yeah - will talk to is
[17:03] <alan_g> alf_: ^^
[17:04] <thomi> all: do you have any ideas about where you'd like it?
[17:04] <alf_> alan_g: \o/
[17:04] <thomi> perhaps somewhere on unity.ubuntu.com?
[17:04] <thomi> unity.ubuntu.com/mir/ ?
[17:05] <AlanBell> woot mir runs today \o/
[17:05] <thomi> or rather:
[17:05] <thomi> unity.ubuntu.com/mir/api/ for the API docs
[17:05] <AlanBell> so, I have a green box with a scrolly bacteria or something in it
[17:05] <alan_g> thomi: works for me
[17:05] <thomi> sweetbix
[17:05] <AlanBell> how do I do something more interesting with it?
[17:07] <alf_> thomi: the plan is to have the whole project site be part of the docs, so the information is always up to date, but we will see how that turns out
[17:08] <thomi> alf_: for autopilot, we just finished configuring it so the docs get uploaded at the end of the autolanding  process
[17:09] <thomi> alf_: I assume something similar for mir would work well
[17:09] <alan_g> AlanBell: what are you interested in? At the moment mir is a body waiting for a brain (the unity shell)
[17:09] <alan_g> thomi: that would be great
[17:10] <alf_> thomi: alan_g: Yes, it would work great. The question that needs answering on our side, is whether the docs will be used for the whole mir "site" or just for the API reference.
[17:10] <AlanBell> alan_g: dunno really, can I put a QML surface in it and poke about with phone apps?
[17:12] <thomi> alf_: right, that will determine if we want the /api/ suffix or not
[17:12] <thomi> alf_: I guess I can push them to .../api/ and we can always change it later
[17:12] <alf_> thomi: sure
[17:13] <AlanBell> or can I implement windows 7 on it http://xkcd.com/528/
[17:13] <alan_g> thomi: alf_ that's probably easiest. We'd need to pull content in to make it the main page.
[17:16] <thomi> ok, rt filed.
[17:20] <alf_> alan_g: thomi: hmm, looking at unity.ubuntu.com, I don't think that the contents we want to put into mir/ will fit with the rest of the design. I am not sure how much of a problem this is.
[17:21] <thomi> alan_g: all those sections have a /api/ section as well
[17:21] <thomi> for example:
[17:21] <thomi> unity.ubuntu.com/autopilot/api/
[17:21] <kdub> AlanBell, thats a space station, not scrolly bacteria :)
[17:21] <alan_g> AlanBell: Sorry, trying to find someone that can advise on details
[17:21] <thomi> actually, that's a bad example, since we don't have a non-api section :)
[17:21] <thomi> alan_g: but you see what I mean, hopefully :)
[17:21] <AlanBell> kdub: ah, my scale was out slightly
[17:22] <kdub> AlanBell, phone demos on the desktop, a tricky to set up
[17:22] <kdub> not sure if anyone's done it yet
[17:22] <AlanBell> well, I am trying to do anything with it really
[17:22] <alf_> thomi: yes, thanks, I was mostly concerned about the visual differences but it seems it's not a problem (e.g. http://unity.ubuntu.com/autopilot/ is very different too)
[17:23] <kdub> AlanBell, i live mostly in the world of android headaches, not sure what precisely is possible on desktop these days...
[17:24] <thomi> alf_: yeah. We can always move things around if we need
[17:24] <kdub> racarr might be able to advise how to get those qml demos going
[17:24] <alf_> AlanBell: you need to get qmir from launchpad.net/qmir and build it (you need qt5)
[17:24] <alan_g> alf_: thomi there's quite a bit of tailoring we can do to L&F of doxygen output
[17:25] <thomi> yeah
[17:25] <alan_g> thomi: alf_ let's do the simplest thing (get what we have up) and iterate
[17:26] <thomi> agreed
[17:26] <AlanBell> alf_: oh, cool thanks
[17:26] <kdub> thanks alf_
[17:26] <alf_> AlanBell: then under mir you can run (m)any of the example qt5 applications by passing the "-platform mir" option to the qt app
[17:27] <alf_> AlanBell: note: no input yet
[17:27] <AlanBell> ok, so I can't make the eyes flash on ctrl+alt+del :(
[17:29] <AlanBell> no readme or makefile or anything in the qmir branch
[17:31] <alf_> AlanBell: unfortunately no, we are working on organizing the documentation as you may have noticed from the conversations here...
[17:54] <racarr> Met with Katie, nailing down focus concepts, "application focus" (for menu bar, launcher pips, etcs...) "window focus" and "stage focus" (input focus)
[17:54] <racarr> and "display focus" for shell components
[17:55] <racarr> very similar to how on the whiteboard in London but we wrote it down this time
[18:58] <FunnyLookinHat> Any talk regarding hybrid graphics with Mir?  Last I checked we were on the goal-line with using the X Stack ( ideally for a 13.10 support of Optimus w/ Binary Blobs ) -
[18:59] <bryce> there won't be a 13.10.
[19:00] <bryce> FunnyLookinHat, I don't know what you mean by on the goal-line, but we decided not to pursue hybrid support on the X side, aside from whatever comes from upstream.  There has been talk for how to  support it in Mir, and the design accounts for multi-gpu / multi-head / multi-hotplugging situations
[19:02] <FunnyLookinHat> bryce, Right right - I meant looking forward before all of the RR talk.
[19:02] <FunnyLookinHat> bryce, but that answers my question ( i.e. accounting for multiple gpu / head / hotplug ) - thanks :)
[19:34] <UbuPhillup> Question: will I be able to run Virtualbox full screen in Mir? Will the input handling stop the HUD stealing my alt key?
[19:37] <bryce> UbuPhillup, virtualization came up at yesterday's Mir talk, although I don't think it got a detailed answer (I'm not sure I could articulate what the answer is, at least).
[19:39] <UbuPhillup> bryce: thanks i will watch at the talk
[19:39] <bryce> regarding input handling, well we're looking at an entirely different stack.  But HUD behavior is going to be a shell  thing, so that might not be a question for Mir as much.
[19:40] <bryce> there's a long list of input issues which I gather folks hope Mir can give us better solutions
[19:41] <UbuPhillup> ;)
[19:50] <thiagoandrade> I'm following the instructions under HACKING.md and when I run 'cmake ..' I get a message "Cannot enable coverage targets because neither lcov nor gcovr are found. Configuring incomplete, errors occurred!"
[19:51] <thiagoandrade> Is there any other dependency I should install that is not covered in that document?
[20:06] <AlanBell> are you on raring thiagoandrade?
[20:07] <thiagoandrade> AlanBell, no
[20:07] <thiagoandrade> I'm on 12.04
[20:07]  * AlanBell is on raring, it worked eventually
[20:08] <AlanBell> don't recall seeing that error message, but I had some problems which were my system's fault
[20:10] <AlanBell> is there going to be a new window manager to run in mir?
[20:10] <thiagoandrade> It's strange to me because there is a "Getting dependencies" step that didn't got all the dependencies. And there is nothing telling that I need to be on raring to make Mir work.
[20:10] <AlanBell> to do the window decoration, title bar, borders etc
[20:11] <AlanBell> thiagoandrade: I dunno, you might be fine on 12.04 if you install the patched mesa from today
[20:12] <AlanBell> but raring is fine, I have been using it daily for months (even with raring-proposed accidentally enabled) and it is fine
[20:17] <TheMuso> AlanBell: As far as I understand things at this point, the unity shell in combination with MIR will do window management...
[20:17] <TheMuso> Somewhat similar to how GNOME shell integrates with mutter to handle window management.
[20:17] <TheMuso> Although probably more integrated.
[20:38] <bryce> TheMuso, btw Mir should not be all-caps.  (MIR might get confused with Main Inclusion Request).
[20:39] <TheMuso> bryce: Sorry, its party a typo,a dn party a habbit.
[20:39] <TheMuso> gah typing == bad.
[20:39] <TheMuso> Its partly a typo and partly a habbit.
[20:40] <bryce> habit?  ;-)
[20:44] <TheMuso> Yeah, dunno why, but it is. Probably from having to deal with main inclusion reports. :)
[20:45] <TheMuso> And writing the shorthand for that.
[23:36] <thiagoandrade> robertcarr, What can I do to help you with in process EGL work item?


[20:58] <assmanager_x> Heya
[20:59] <assmanager_x> I love Ireland
[20:59] <assmanager_x> Where are you from, people ?
[21:02] <assmanager_x> I see, here too everybody is sleeping.. cya later.


[08:58] <]Oscar> I like to duplicate an existing user: where are store all desktop preference? I got the new user with mythbuntu defaults and not the ubuntu ones :(
[09:10] <]Oscar> done: I found how to remove defaults from mythtv... :)
[17:30] <solvos> permisi, yang pake bahasa indonesia siapa ya?
[17:31] <solvos> duh susahnya regis di https://launchpad.net/+login, ada cara lain?


[03:17] <mup> Bug #1765661 changed: mode argument missing from snap <MAAS:Invalid> <https://launchpad.net/bugs/1765661>
[04:05] <mup> Bug #1766769 opened: [2.x, UI, enhacement] Add 'allow_proxy' to the UI per subnet basis <MAAS:Triaged> <https://launchpad.net/bugs/1766769>
[05:15] <mup> Bug #1766781 opened: [2.4, UI] Context menu regression <ui> <MAAS:Triaged by deadlight> <https://launchpad.net/bugs/1766781>
[12:14] <srihas> hi guys, we have an UCS environment. Inorder to control power from MaaS, we provide the API on the HTTPS but the problem is we have a selfsigned certificate and the MAAS is not making me add UCS power type. Is there a tweak that I can make?
[12:14] <srihas> thank you
[14:55] <mup> Bug #1765751 changed: django.db.utils.OperationalError: could not serialize access due to concurrent update during "migrate-conflicting-options" <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:Fix Released> <MAAS 2.3:Triaged> <https://launchpad.net/bugs/1765751>
[15:07] <mup> Bug #1703231 opened: Virsh Power address of VM changes by itself <maas> <MAAS:Incomplete> <https://launchpad.net/bugs/1703231>
[15:16] <mup> Bug #1703231 changed: Virsh Power address of VM changes by itself <maas> <MAAS:Incomplete> <https://launchpad.net/bugs/1703231>
[15:28] <mup> Bug #1703231 opened: Virsh Power address of VM changes by itself <maas> <MAAS:Incomplete> <https://launchpad.net/bugs/1703231>


[01:33] <vaibhav> I got a weird problem with eclipse, in ubuntu when I ran it, it only shows an empty dialog box


[03:32] <pmatulis> kom
[03:49] <pmatulis> i'm settin up a (jaunty) server for building packages for multiple releases and archs.  what is the recommended way for doing that?
[03:50] <RAOF> pmatulis: Both sbuild & pbuilder will do what you want, depending on how many archs "multiple" is.
[03:51] <pmatulis> RAOF: yet i do not want to install dependencies on my main host, i'd rather keep them contained.  is schroot (+pbuilder) what i'm after?
[03:53] <pmatulis> RAOF: archs would just be x86_32 and x86_64
[03:53] <hyperair> sbuild and pbuilder both install dependencies in a chroot and build the package
[03:53] <RAOF> pmatulis: Yeah, both sbuild & pbuilder build in a chroot.
[03:53] <adama> what does x86_32 mean?
[03:53] <hyperair> after building, the temporary installation is wiped clean
[03:54] <adama> i386? or more specific?
[03:54] <RAOF> adama: It's a longhand, nonstandard way of writing IA32
[03:54] <adama> that doesn't answer my question
[03:54] <adama> does it mean i386, or something more specific?
[03:54] <RAOF> Yes, it means what Debian & Ubuntu call "i386"
[03:55] <pmatulis> hmm, so as a test i tried to build a gnome app on my server and naturally i'm missing libraries
[03:56] <pmatulis> if i install them they are going to be on my system permanently no?
[03:56] <RAOF> Yes.
[03:56] <pmatulis> there you go, i'd rather avoid that
[03:56] <RAOF> So, you build the package with pbuilder or sbuild, which will build in a chroot for you.
[03:57] <adama> if only we had some mechanism to remove installed packages...
[03:57] <pmatulis> RAOF: yes, i used pdebuild
[03:57] <RAOF> pmatulis: Then your package is likely buggy.
[03:58] <RAOF> pbuilder will install all the dependencies you list as build-dependencies; if you package doesn't build because of a missing dependency, then you need to add it :)
[03:59] <pmatulis> RAOF: ok, and they are listed where?
[03:59] <RAOF> In particular, pbuilder cannot automatically determine what dependencies are required; I suspect the halting problem is reducible to that problem :)
[03:59] <RAOF> pmatulis: debian/control - Build-Depends
[03:59] <pmatulis> RAOF: ok, will look
[03:59] <lifeless> and build-depends-indep
[04:00] <pmatulis> RAOF: btw, i originally wanted sbuild but i got an error about a missing module (dm_snapshot?)
[04:00] <RAOF> Yeah, but hardly anyone has any build-depends-indep.  Arch-indep languages are, apparently, for the weak.
[04:01] <RAOF> pmatulis: That requires that you're using lvm, and have a bunch of free space in one of your VGs; unless you've deliberately set up your system for it, it's unlikely that you'll have accidentally got something that works.
[04:02] <pmatulis> RAOF: yes, i had space on my vg
[04:03] <RAOF> I think that mk-sbuild-lv.sh from ubuntu-dev-tools will actually load dm_snapshot if necessary.
[04:04] <RAOF> But I no longer use sbuild, because I've found it easier to build in a tmpfs with pbuilder.
[04:09] <pmatulis> RAOF: ok, thanks for the tips
[04:15] <pmatulis> RAOF: sorry, but the missing deps are indeed listed in the control file
[04:16] <RAOF> Then it's time for you to post a buildlog & the control file to a pastebin.
[04:21] <pmatulis> RAOF: http://pastebin.ca/1683208
[04:22] <RAOF> pmatulis: Aaah.  You don't have dpatch installed.  Since this is required when building a source package, you must install it.
[04:22] <pmatulis> RAOF: hmm
[04:23]  * RAOF has another look at that control file, and wonders what happened in dpatch version 1.21
[04:25] <pmatulis> k, something is happening over here  :)
[05:58] <mrooney> haha, lintian told me that both my postinst script was empty and ignored errors
[05:58] <mrooney> those warnings seem a little silly together
[06:00] <lifeless> plausible ;)
[06:30] <mannyv> StevenK, around?
[06:41] <StevenK> mannyv: Somewhat
[06:44] <mannyv> StevenK, I have modified my local version of requestsync so that I can specify a build log as an attachment when using the launchpad api, is that a patch you would be interested in?
[06:46] <mannyv> also i have modified grab-merge a little because it would sometimes try and grab the same source tar file several times if there are multiple entries for it in REPORT, now it checks to make sure the file doesnt exist before downloading
[06:48] <StevenK> To be honest, I don't maintain requestsync, it's maintained in a bzr branch, so I would make your changes in a branch and request a merge
[06:49] <mannyv> oh ok for some reason i had the impression it was you
[06:50] <mannyv> ok well i was going to do that i just figured i would scope out interest first, but I guess I can do it in the opposite order =)
[06:50] <mannyv> now im off to bed, good night
[07:13] <fabrice_sp> Hi. buildX versions will be autosync in lucid, right?
[07:14] <RAOF> Should be, yes.  IIRC those are special-cased by the autosync.
[07:15] <fabrice_sp> that was also my impression. Will invalidated bug 486393 then. Thanks RAOF
[07:59] <dholbach> good morning
[08:38] <\sh> moins
[08:44] <siretart`> hi \sh
[08:59] <ghostcube> https://bugs.launchpad.net/bugs/466935
[08:59] <ghostcube> anyone able to check this
[09:00] <ghostcube> still there and nothing changed
[09:00] <micahg> ghostcube: triaged means it's ready for a developer to look at, not that it's fixed
[09:18] <ghostcube> micahg: i know
[09:18] <ghostcube> i meant nothing changed in my settings
[09:20] <micahg> ghostcube: you'll want to check in #ubuntu-kernel
[09:20] <ghostcube> heh i had bothered them too i just thought anyone can confirm this
[09:20] <ghostcube> on an logitech
[09:20] <micahg> ghostcube: one of the maintainers already confirmed
[09:20] <micahg> that's why it was reopened
[09:21] <ghostcube> :)
[11:10] <AnAnt> LucidFox: Hello, did you try TL2009 ?
[11:10] <LucidFox> I did, yes.
[11:10] <AnAnt> how did it go with you ?
[11:11] <LucidFox> I still need to download texlive-latex-extra to verify my test document. It wants a .sty file apparently present there.
[11:11] <AnAnt> I see
[11:11] <AnAnt> I found that epstopdf is gone !
[11:12] <LucidFox> It compiled with the official distribution before, so I'll compare the output with the Debian version.
[11:12] <LucidFox> Weird, I have epstopdf installed.
[11:12] <AnAnt> did you upgrade texlive-extra-utils ?
[11:13] <LucidFox> I didn't have the old texlive installed by default.
[11:13] <AnAnt> hmm, wierd
[11:13] <LucidFox> sikon@maia-desktop:~$ dpkg -S `which epstopdf`
[11:13] <LucidFox> texlive-font-utils: /usr/bin/epstopdf
[11:13] <LucidFox> sikon@maia-desktop:~$ dpkg -s texlive-font-utils | grep Version
[11:13] <LucidFox> Version: 2009-1
[11:13] <AnAnt> ah, ok
[11:14] <AnAnt> thanks
[11:15] <LucidFox> Is there a more intuitive way to open manpages in yelp than Alt-F2 -> yelp man:<topic>?
[11:16] <highvoltage> (I guess "typing 'man topic' into a terminal" is not what you want to hear)
[11:16] <AnAnt> can you do a: dpkg -S `which texdoc` ?
[11:16] <LucidFox> highvoltage> I prefer GUI.
[11:17] <LucidFox> texlive-base: /usr/bin/texdoc
[11:17] <slytherin> LucidFox: type man topic in the search field in yelp.
[11:18] <LucidFox> I know about that, but yelp needs to be started for that. :)
[11:18] <LucidFox> When I just type man:<topic> in Alt-F2, yelp says that man:///topic cannot be opened.
[11:19] <slytherin> LucidFox: oh, so you want yelp to register a url handler for manpages?
[11:19] <LucidFox> It already is, just bugged, apparently.
[11:20] <LucidFox> At least from Alt-F2. It opens from Firefox without problems.
[11:20] <LucidFox> Looks like a bug in gnome-panel.
[11:22] <hyperair> gnome-help man:///irssi
[11:22] <hyperair> indeed that is
[11:24] <highvoltage> YDdraigGoch: I think you mean gnome-help man:irssi ?
[11:24] <highvoltage> sorry, I aimed that at hyperair
[11:24] <hyperair> highvoltage: sorry, i wasn't clear.
[11:25] <hyperair> highvoltage: i mean that's what gnome-panel launched.
[11:25] <hyperair> highvoltage: try it. alt+f2, type man:something, and then with yelp still open, ps -ef | grep gnome-help
[11:25] <hyperair> highvoltage: gnome-panel is adding unnecessary /s
[11:26] <highvoltage> hyperair: ah I see
[11:26] <AnAnt> LucidFox: did you try hyperref package ?
[11:26]  * LucidFox shakes her head
[11:29] <AnAnt> ok
[11:31] <LucidFox> Shame unicode-math isn't distributed.
[11:45] <slytherin> Can any java expert help to solve this problem - http://paste.ubuntu.com/326018/ ?
[12:01] <Crusher`> slytherin: it doesn't know what method you are trying to call, so you have to cast null to either the certificate or codesigner so it knows which method you are trying to use
[12:02] <LucidFox> slytherin> There are two overloaded methods, and the compiler doesn't know which one to use.
[12:07] <LucidFox> What's with autosync?
[12:07] <LucidFox> Some packages seem to never be updated.
[12:17] <siretart`> LucidFox: there is a blacklist for the auto-sync. perhaps its listed there?
[12:18] <LucidFox> I mean in lucid. dbus-c++ and x11vnc, for example, are not even in NEW.
[12:18] <LucidFox> Even though they were added to Debian before the lucid cycle, and they're not in the blacklist.
[12:20] <slytherin> LucidFox: Crusher`: I understood that. But I don't know how to cast null to some type.
[12:21] <Crusher`> slytherin: new CodeSource(thisURL, (java.security.cert.Certificate[]) null);
[12:21] <slytherin> Crusher`: Oh, that simple. I didn't know that. :-(
[12:21] <Crusher`> slytherin: hehe, its all part of learning :)
[12:31] <siretart`> LucidFox: you should probbly ask that pitti or seb128 in #ubuntu-devel
[12:31]  * LucidFox nods
[12:31] <siretart`> LucidFox: if these packages are already in dpkg source v3 format, then that's the reason
[12:32]  * LucidFox checks
[12:32] <LucidFox> Could be, didn't check.
[12:33] <LucidFox> dbus-c++ isn't. I'll ask.
[12:34] <LucidFox> Neither is x11vnc
[12:34] <LucidFox> On an unrelated note, why is ttf-droid not in Debian? License issues?
[12:35] <LucidFox> Hmm, there's an ITP for it... *reads*
[13:02] <geser> was the import of new packages in Debian already run for lucid?
[13:06] <siretart`> geser: please ask in #ubuntu-devel
[13:19] <geser> I'll let the archive admins clear the current NEW queue first before asking for more
[13:21] <flower> how do I backport packages for 64bit on 32bit?
[13:25] <\sh> for i in i386 amd64 ; do build lucid $i my-package_verson-release.dsc ; done ,)
[13:25] <geser> flower: you have a 32bit system and want to build a package for a 64bit system?
[13:25] <flower> geser: right
[13:27] <geser> you need a 64bit pbuilder (or similar where you can build 64bit packages) and your kernel needs to be able to run 64bit programs which the 32bit kernel can't
[14:15] <ghostcube> geser: i may check this evening the source aof arista video transcoder
[14:15] <ghostcube> to see wheere it calls this stupid icon
[14:15] <ghostcube> and if i can set an ghost one
[14:18] <ghostcube> have i mentioned i luv the one packaged libxine with jackd support in his ppa
[14:18] <ghostcube> :D
[15:34] <bddebian> Heya gang
[15:36] <siretart`> hi bddebian
[15:37] <bddebian> Heya siretart
[15:46] <fmarl> hi guys, I need to talk to someone regards pyclutter-gtk and pyclutter-gst packaging.
[15:47] <Elbrus> fmarl: you should just state your question, nobody now knows if they can help you...
[15:47] <fmarl> With pyclutter 1.0 they need to be packaged separately
[15:48] <fmarl> there's a bug: https://bugs.launchpad.net/ubuntu/+source/pyclutter/+bug/437578
[15:48] <fmarl> I've made some work to get it fixed but i need some help.
[15:49] <Elbrus> you do this for Debian?
[15:49] <Elbrus> see comment 1
[15:50] <fmarl> Elbrus, no i'm just a programmer for a project that needs them
[15:50] <dtchen> bddebian: hi, do you have any opposition to just backporting the ALSA and pulse bits (src/audio/{alsa,pulse}) from 1.2.14 into the existing libsdl source package?
[15:50] <fmarl> project name is Entertainer
[15:50] <Elbrus> so is this private packaging or for Ubuntu?
[15:51] <fmarl> Elbrus, the goal should be to push these packages at least to Ubuntu
[15:52] <Elbrus> it is better to start at Debian
[15:52] <fmarl> Elbrus, yeah I know.
[15:52] <Elbrus> it doesn't even have this bug reported as far as I can tell
[15:52] <bddebian> dtchen: Probably not
[15:53] <Elbrus> so whatever you figure out for the packaging, at least (also) submit it in the debian bugtracker (and link launchpad to it)
[15:53] <fmarl> Elbrus, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505918
[15:53] <Elbrus> so now your real question I guess
[15:53] <dtchen> bddebian: anyhow I already did it while chasing an alsa-plugins bug :-)
[15:54] <dtchen> bddebian: didn't ask for it to be sponsored into Ubuntu yet because I wanted to check with you about plans for libsdl in Debian
[15:54] <dtchen> cos it, uh, explodes the delta, understandably
[15:54] <Elbrus> fmarl: is there already a RFP bug?
[15:55] <fmarl> Elbrus, I don't know,probably not
[15:56] <Elbrus> and you are packing those?
[15:57] <fmarl> Elbrus, mine is an attempt
[15:57] <fmarl> Elbrus, https://code.launchpad.net/~francesco-marella/+junk/pyclutter-gtk
[15:57] <fmarl> https://code.launchpad.net/~francesco-marella/+junk/pyclutter-gst
[15:58] <bddebian> dtchen: Well I'm up for just about anything but the other members of the "team" aren't all that responsive. :(
[15:59] <Elbrus> fmarl: better start asking your real question I guess... I see the code but what is the problem
[16:02] <fmarl> Elbrus, there's someone here that can take this job?
[16:02] <Elbrus> which job, helping you?
[16:02] <Whoopie> jdong, siretart: Hi, now that we have a new VLC in lucid, could we do the SRU for karmic?
[16:02] <fmarl> job = review my work or start from scratch, submit it to debian
[16:02] <fmarl> Elbrus, sorry i'm not native-english
[16:03] <Elbrus> you could attach your packaging to the launchapd bug and mark it as a patch
[16:04] <Elbrus> better, if you are willing to maintain it, file a bug at debian (a ITP against the wnpp package)
[16:04] <fmarl> Elbrus, ok i'll do it
[16:04] <Elbrus> and search for a sponsor at mentors.debian.net /<EMAIL_ADDRESS>[16:05] <Elbrus> (please read the documentation at mentors.d.n first)
[16:05] <fmarl> Elbrus, to much work for a lazy programmer.. :p
[16:05] <Elbrus> well, you SHOULD file a bug at Debian than with RFP against wnpp with the packaging attached)
[16:06] <Elbrus> at least
[16:06] <Elbrus> and link the debian and ubuntu bugs to eachother
[16:06] <fmarl> Elbrus, ah ok
[16:06] <Elbrus> np
[16:06] <fmarl> Elbrus, thanks.
[16:07] <siretart`> Whoopie: I'm not in the SRU team, and I don't have the overview what bugs have been closed from 1.0.2 to 1.0.3
[16:09] <Whoopie> siretart`: I'm talking about https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/481448
[16:11] <jdong> Whoopie: prep a debdiff for review and I'll take a look in an hour
[16:11] <Whoopie> jdong: it's already in the bug report
[16:13] <jdong> you've got an ACK
[16:13] <jdong> edit the description of the bug with SRU verification procedures
[16:16] <Whoopie> jdong: where to find an example?
[16:23] <jdong> Whoopie: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[16:34] <Whoopie> jdong: do I have to upload it to karmic-proposed?
[16:36] <ScottK> Whoopie: You need a MOTU to do that.
[16:43] <Whoopie> ScottK: ok, thanks
[17:01] <waver_> hi guys, I want to push this package ( http://revu.ubuntuwire.com/p/hiawatha ) to Ubuntu
[17:03] <ScottK> waver_: If you are really interested in the package, you might want to consider getting it into Ubuntu via Debian and maintaining it there.  See mentors.debian.net for details on how.
[17:04] <waver_> Thanks ScottK, I'll have a look
[19:01] <ari-tczew> 8 requests left to 200 bugs in ubuntu-archive! yes!
[19:08] <AndrewGee> Hi all. Any MOTUs available to review my package in REVU, and hopefully give the second advocation? http://revu.ubuntuwire.com/p/gpxviewer - Thanks :)
[19:09] <dlm> hi all
[19:09] <dlm> What is the requierement for became a MOTU ?
[19:14] <ScottK> AndrewGee: If you are interested in maintaining the package, you might consider getting it into Ubuntu via Debian.  See mentors.debian.net for details.
[19:15] <ari-tczew> dlm: https://wiki.ubuntu.com/MOTU
[19:16] <dlm> ari-tczew: Thanks
[19:16] <ScottK> dlm: Also https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu%20Developers%20%28MOTU%29
[19:18] <dlm> Scottk: thanks for the link
[20:04]  * jdong scratches his head at the addition of a patchsys in a SRU debdiff.
[20:05] <ajmitch> that's not nearly as bad as switching to dh7-style debian/rules in a SRU
[20:05] <jdong> hahahahaha
[20:06] <jdong> well I suppose the patchsys won't hurt too much
[20:06] <ajmitch> usually it's only a couple of lines, but it's still not the best thing to do :)
[20:06] <jdong> yup
[20:06] <ScottK> IIRC adding a patch system is explicitly discouraged in SRUs.
[20:06] <ajmitch> something that the 3.0 (quilt) format is meant to help with once it's supported in LP :)
[20:07] <ScottK> ajmitch: Right, any patch system you want as long as it's quilt.
[20:07] <jdong> :)
[20:07] <ajmitch> exactly
[20:07] <ajmitch> though to be fair, there looks to be little interaction with quilt itself that you need to do
[20:08] <ScottK> If there's no existing patch system, I think that's correct.
[20:08] <ScottK> Although if you want to break your work into more than one patch, the way you do it is rebuild the source package.
[20:09] <ScottK> Seems a bit heavy to me.
[20:10]  * ajmitch stabs fetchmail
[20:10] <ajmitch> I should really redirect my mail through somewhere more reliable
[20:16] <highvoltage> hey ajmitch, how are things?
[20:17] <ajmitch> good, how are you?
[20:21] <fabrice_sp> fcuk112, there?
[20:22] <ari-tczew> anyone knows, whether can I do NMU in Debian only for update/add watch file?
[20:23] <Laney> no
[20:24] <ari-tczew> pfff sucks :P
[20:24] <ajmitch> that's a pretty trivial change, NMUs should be for release-critical bugs
[20:25] <highvoltage> ajmitch: also doing good thanks
[20:25] <ari-tczew> but maintainers doesn't care a lot of them packages
[20:33] <ajmitch> highvoltage: so did you manage to get to the latest UDS? :)
[20:37] <av`> ari-tczew, yes, but doing an NMU for a watch file will probably get you
[20:37] <av`> flamed
[20:41] <ScottK> And whoever would sponsor it would get roasted too.
[20:41] <ari-tczew> [19:56] <Laney> adding bureaucracy is not a way to encourage contribution
[20:41] <ScottK> File a bug with a patch
[20:41] <ari-tczew> ;-]
[20:42] <Laney> debian has package maintainers
[20:42] <ScottK> Debian has a different maintenance model than Ubuntu and NMUs for trivial fixes doesn't make sense
[20:42] <azeem> if the package is in collab-maint, you can checkin a fix I guess
[20:43] <ScottK> Yep.
[20:46] <ari-tczew> if Debian has a policy such as Ubuntu, we could do a lot for DEHS statistics
[20:48] <ajmitch> perhaps you could argue for it on debian-devel
[20:49] <cjwatson> that sounds guaranteed to go badly ...
[20:50] <ajmitch> it'd have about as much effect as discussing it here :)
[20:50]  * jdong hopes ajmitch meant that in sarcasm ;-)
[20:50] <jdong> the first statement, that is
[20:53] <Stormx2> Hi guys. Can I ask why grip is no-longer packaged?
[20:53] <ajmitch> was grip ever ported to gtk+ 2.0?
[20:54] <highvoltage> ajmitch: I participated remotely, US visas take too long :/
[20:55] <ajmitch> grip was removed from debian back in february, I believe removals from debian like that happen in ubuntu as well so that we don't carry too many old & unmaintained packages
[21:02] <fcuk112> fabrice_sp: i am here.
[21:05] <fabrice_sp> fcuk112, about the libavg upgrade: why did you deleted the building of testplayer?
[21:06] <fcuk112> fabrice_sp: when i did pbuilder build, it was failing because it ran an automatic test which required the framebuffer.
[21:07] <fabrice_sp> fcuk112, it wasn't possible to desactivate the test instead of desactivating the bianre?
[21:07] <Stormx2> ajmitch: grip was gtk2 afaik
[21:07] <fcuk112> fabrice_sp: i could not find where to disable the test.
[21:08] <fabrice_sp> also, I did some modifications, and now, I'm getting an error: dpkg-shlibdeps: error: couldn't find library avg.so.0 needed by debian/python-libavg/usr/lib/libColorNode.so.0.0.0 . Did yo uget this one also?
[21:08] <fabrice_sp> anyway, I'm building the package with your debdiff right now (wihout my modifications)
[21:11] <fcuk112> fabrice_sp: yea, i got the same error when i built via pbuilder, i got around it by adding to .pbuilderrc: export LD_LIBRARY_PATH=/usr/lib/python2.6/dist-packages/libavg:$LD_LIBRARY_PATH
[21:12] <fabrice_sp> fcuk112, ok: so you should have added that. or something similar in the debian/rules file
[21:15] <fabrice_sp> also, lintian is complaining about a missing README.source. Please add it, and update the Standards-version to 3.8.3
[21:15] <ari-tczew> fabrice_sp: is it not a Debian's package?
[21:16] <fabrice_sp> ari-tczew, it's an orphaned Debian package
[21:16] <fabrice_sp> why?
[21:18] <ari-tczew> we could not update Standards-Version if package is delivering by Debian first, right?
[21:18] <ari-tczew> but if it's orphaned package, ok
[21:18] <fcuk112> fabrice_sp: how to run the lintian command?  i just installed it.
[21:19] <ari-tczew> debuild -us -uc and at the end you should see warnings
[21:19] <fabrice_sp> or lintian <package.dsc>
[21:19] <fcuk112> fabrice_sp: also i am not sure where to update standards-version.
[21:20] <fabrice_sp> ari-tczew, we should not update the standard-versions of  a debian pacakge, but in this case, it will become an ubuntu version (0ubuntu1), so yes
[21:20] <fcuk112> fabrice_sp: when i run lintian on the dsc i get: internal error: command failed with error code 2
[21:20] <fcuk112> warning: could not unpack package to desired level
[21:20] <fcuk112> warning: skipping check of source package libavg
[21:22] <fabrice_sp> fcuk112, could you paste the full command you are running?
[21:23] <fcuk112> fabrice_sp: lintian libavg_0.9.0-0ubuntu1.dsc
[21:23] <ari-tczew> debian/control there you can bump Standards-Version
[21:25] <fcuk112> ari-tczew: thanks, ok i updated it.
[21:25] <fabrice_sp> fcuk112, can you pastebin the content of the dsc file?
[21:26] <fabrice_sp> to be able to update the standards-version, you need to add a debian/REAME.source file, as there is a patch system
[21:30] <fcuk112> http://pastie.org/711880
[21:31] <fcuk112> fabrice_sp: sorry what would the contents of debian/README.source be?
[21:31] <av`> fabrice_sp, I don't think a README.Source is really needed
[21:32] <fabrice_sp> fcuk112, the dsc file seems good
[21:32] <av`> if the patch system is either dpatch or quilt
[21:32] <ari-tczew> av' +1
[21:33] <fabrice_sp> av`, even with source format v1? The Debian policy still says that it's required
[21:33] <av`> fabrice_sp, looks to me that paste / copying the dpatch / quilt example files is pretty useles
[21:33] <av`> fabrice_sp, yes, someone proposed to remove its requirement for normal
[21:33] <av`> patch systems already
[21:33] <ari-tczew> what is connexion between Standards-Version and patchsystem?
[21:34] <fabrice_sp> av`, I know it's useless, but for the moment, it still required by Debian policy, no?
[21:34] <av`> actually the newer standards introduce new policies to follow
[21:34] <av`> and one of them is the patch-system one fabrice_sp told you before
[21:34] <av`> e.g adding a readme.source
[21:35] <fabrice_sp> it was added in 3.8.3?
[21:35]  * fabrice_sp looks at Debian polciy
[21:35] <av`> fabrice_sp, yes, it is, but since the package won't go to debian for now, I wouldnt add it
[21:35] <av`> fabrice_sp, don't remember
[21:36] <mannyv> im looking at a package that we have had to merge for about 4 releases because the source tar ball is missing a COPYING file and we keep adding it in.
[21:37] <mannyv> is this something I should talk with the debian maintainer about adding as well?
[21:37] <mannyv> and maybe upstream or ?
[21:37] <fabrice_sp> the README.source is recommended, not mandatory, so fcuk112, forget the READE.source file
[21:37] <av`> fabrice_sp, yes
[21:37] <fabrice_sp> mannyv, Should be upstream
[21:37] <av`> fabrice_sp, it's a warning not an error
[21:37] <av`> fabrice_sp, so it's up to the original maintainer
[21:38] <fabrice_sp> av`, I know, but I've seen warnings becoming error in later version
[21:38] <fabrice_sp> in this case, it's ok
[21:38] <av`> I don't think this will ever be an error
[21:38] <av`> :)
[21:38] <fabrice_sp> not with source format V3 :-)
[21:38] <av`> if not dak would reject tons of packages since it has lintian-based
[21:38] <av`> auto-rejects now
[21:38] <fabrice_sp> but I have to say that it should be mandatory for some non standard pacakges
[21:38] <fabrice_sp> right
[21:39] <av`> but yes, for particular packages would be nice to have
[21:39] <fcuk112> ok
[21:39] <av`> especially for NMUers
[21:39] <fabrice_sp> right
[21:39]  * mannyv swims upstream
[21:39] <fabrice_sp> or packages with source tarball inside the tarball
[21:40] <fabrice_sp> :-/
[21:41] <av`> like mozilla-extensions then
[21:41] <av`> that ships a .xpi file into the tar.gz :)
[21:41] <av`> but we have tools for that :)
[21:42] <fabrice_sp> av`, sure about the tools, but for a newcommer to the package, patching it as... hmmm....complex
[21:43] <av`> fabrice_sp, true, with tools I meant something like mozilla-devscripts
[21:43] <av`> don't know if you ever worked with them
[21:43] <fabrice_sp> av`, ohh yes :-) no: only saw them from far away
[21:43] <av`> for mozilla-extensions-related-stuff of course
[21:43]  * fabrice_sp avoids mozilla :-)
[21:43] <av`> good for you :)
[21:44] <fabrice_sp> lol
[21:44] <fabrice_sp> latelly, I only have time to review the sponsoring queue... :-)
[21:45]  * fabrice_sp should take care of his sync/merges...
[21:48] <av`> fabrice_sp, cleaning up the sponsoring queue is something great
[21:48] <av`> so that contributors don't have their work dropped somewhere
[21:48] <av`> so good work :)
[21:49] <fabrice_sp> av`, it's great: it also a way to learn a lot of new stuff (and discover new packages) :)
[21:49] <fabrice_sp> mannyv, about Bug #486181
[21:50] <mannyv> fabrice_sp, yeah?
[21:50] <fabrice_sp> shouldn't we wait one week, when 0.15.7 lands in testing? And avoid doing 2 merges?
[21:50] <fabrice_sp> (even if it's an easy one :-) )
[21:51]  * mannyv has been cherry picking the easy ones
[21:52] <mannyv> yeah that makes sense
[21:52] <mannyv> i didn't know that the new 0.15.7 would land in testing in 2 weeks
[21:52] <mannyv> how do you know that so I can know in the future =) ?
[21:52] <av`> mannyv, check the PTS :)
[21:53] <av`> mannyv, it has all informations you may need
[21:53] <fabrice_sp> a package in unstable, if everything is ok, lands in testing 10 days after
[21:53] <fabrice_sp> PTS is your friend, yes :-)
[21:53] <av`> mannyv, subscribe to a specific package and you gonna receive everything into your mail box!
[21:53] <av`> sweet!
[21:53] <mannyv> i checked in PTS
[21:54] <fabrice_sp> Too young, only 4 of 10 days old
[21:54] <mannyv> i jsut didint know when it moved from unstable to testing i guess
[21:54] <av`> mannyv, which one?
[21:54] <fabrice_sp> http://packages.qa.debian.org/p/piklab.html in this case
[21:54] <mannyv> i see now, i just didnt know to look for that
[21:54] <av`> yes, wanted to see what he meant for PTS
[21:55] <fabrice_sp> :-)
[21:55] <mannyv> av`, that is what i meant
[21:55] <fabrice_sp> one day for agg :-)
[21:55] <av`> fabrice_sp, already one day?
[21:55] <av`> time pass so fast
[21:55] <fabrice_sp> av`, my bad: only 1 of 10 days :-D
[21:56] <mannyv> so does that mean if there is a higher version in unstable we should just always wait, provided we 10 days before DIF?
[21:56] <av`> fabrice_sp, lol
[21:56] <av`> looked to me a bit strange that was going to migrate already
[21:56] <fabrice_sp> mannyv, if no serious bugs appears during that 10 days, yes
[21:57] <av`> all squeeze goals should be ok
[21:57] <av`> to migrate
[21:57] <mannyv> ok that is good to know =)
[21:57] <fabrice_sp> just too tired! That libavg upgrade + another merge killed me :-)
[21:57] <av`> if the packages FTBFS on a squeeze release goal arch it won't migrate :)
[22:00] <fabrice_sp> bed time. Bye all!
[22:04] <av`> have a good night :)
[22:32] <RoAkSoAx> hey guys. I;m merging a package and in Ubuntu we are adding -dev. So, since we are modifying configure.in, I have to rerun autogen.sh. So, if I'm already running autogen.sh do I have to add automake and libtool to Build-Deps?
[22:35] <azeem> RoAkSoAx: does it build if you don't?
[22:36] <RoAkSoAx> azeem, yes I believe so, but it shows a warning that there's no automake
[22:37] <kklimonda> RoAkSoAx: the official way as far as I can tell is to regenerate locally and then create patch for source
[22:37] <kklimonda> this way you don't have to add any additional dependencies
[22:37] <ari-tczew> yes! seb128 is working on syncs! MOTU go ahead!
[22:38] <RoAkSoAx> kklimonda, so I would just run autogen.sh again and then not add the dependecies on libtool and automake?
[22:39] <RoAkSoAx> kklimonda, or... adding the dependencies, and not running autogen.sh?
[22:41] <kklimonda> RoAkSoAx: again? you run it once, create diff between regenerated source and clean one and add it to debian/patches/
[22:44] <RoAkSoAx> kklimonda, yeah but... do I still have to add automake and libtool as build-deps?
[22:44] <kklimonda> no, the whole point of creating a patch locally is to avoid those dependencies
[22:44] <av`> RoAkSoAx, no
[22:45] <av`> RoAkSoAx, you gonna apply a patch, so no additional deps are needed
[22:45] <av`> apart quilt or dpatch or whatever you use
[22:45] <av`> if you use quilt, I would suggest you to give a try to quilt sheel
[22:45] <av`> * quilt shell
[22:45] <RoAkSoAx> av`, i was applying it directly because debian dropped the patchsystem and I'm not introducing one again
[22:46] <av`> don't know how sane it is applying an autotools patch directl
[22:46] <kklimonda> it's not
[22:47] <kklimonda> applying anything outside of debian/ subdirectory currently isn't really sane imho
[22:47] <av`> kklimonda, agreed, apart minor changes I'm with you
[22:47] <av`> minor = really minor changes
[22:48] <RoAkSoAx> so what would be your recommendation in this particular case?
[22:49] <kklimonda> well, autotools related patches are huge so I'd restore patch system
[22:49] <av`> adding a patch system
[22:49] <av`> and using quilt shell
[22:49] <kklimonda> (the patch for transmission is over 1MB)
[22:49] <av`> if you want your life to be easier
[22:50] <RoAkSoAx> ok cool, thanks for the tip :)
[22:50] <av`> np :)


[03:36] <damo22> anyone here?
[03:37] <damo22> i have a midi controller with built in patch selector, what program can i use to load different sounds using my controller?
[03:38] <tucemiux> mmm...
[03:39] <tucemiux> mixxx might work
[03:39] <damo22> basically i want to create a laptop dedicated to playing live
[03:39] <tucemiux> damo22, sounds like you want to use mixxx
[03:39] <damo22> like can i use my selector to load different sf2s?
[03:40] <tucemiux> damo22, if you go to mixxx right now i'm talking to a developer, if they dont currently support your controller you can actually request for support to be added
[03:40] <damo22> ok
[03:40] <tucemiux> #mixxx
[03:52] <damo22>  i dont think mixxx is what im looking for, im not a dj looking to beatmatch... i am searching for a program that will let me use extra features of my midi controller to load synths


[03:08] <jml> mwhudson, while you're still around, would you like to review my import warnings branch?
[03:08] <mwhudson> jml: definitely
[03:09] <jml> mwhudson, https://code.edge.launchpad.net/~jml/launchpad/fix-import-warnings/+merge/16965
[03:11] <mwhudson> jml: i wonder why those files imported things from _schema_circular_imports
[03:11] <jml> mwhudson, me too.
[03:11] <mwhudson> that just seems a bit odd
[03:11] <jml> mwhudson, my guess is that the module moving thingy did it
[03:11] <jml> mwhudson, I guess I could 'bzr blame'
[03:11] <mwhudson> jml: "+ # The bug turned to be security-related, subscribe the security"
[03:11] <mwhudson> jml: can you insert the missing "out" ?
[03:12] <mwhudson> it's in lib/lp/bugs/subscribers/bug.py
[03:12] <jml> mwhudson, done.
[03:14] <mwhudson_> jml: can you paste the link again
 mwhudson, https://code.edge.launchpad.net/~jml/launchpad/fix-import-warnings/+merge/16965
[03:14] <mwhudson_> ta
[03:14] <jml> last lines of convo...
 it's in lib/lp/bugs/subscribers/bug.py
 mwhudson, done.
[03:17] <mwhudson_> i actually saw those
[03:17] <mwhudson_> jml: i guess i should ask you to file a bug for those XXXs but i can forget to if you like
[03:17] <mwhudson_> otherwise, very much r=me
[03:35] <jml> mwhudson, can you please change some status on the MP?
[03:35] <mwhudson> ah right yes
[03:36] <jml> mwhudson, thanks.
[04:07] <jml> mwhudson, another branch for you
[04:08] <mwhudson> jml: ok
[04:08] <jml> https://code.edge.launchpad.net/~jml/launchpad/upcall-testcase/+merge/17002
[04:10] <mwhudson> jml: BRANCH.TODO still has quite a lot in it
[04:10] <jml> mwhudson, oops
[04:10] <jml> mwhudson, fixed
[04:12] <mwhudson> jml: it's almost like you have some automatic way of finding pep8 violations
[04:12] <jml> mwhudson, it's uncanny that you should mention it, because in fact it turns I out I have.
[04:13] <mwhudson> jml: also i guess that doing the super().setUp() style when you pass the user argument is theoretically a bit risky
[04:14] <jml> mwhudson, blame python
[04:14] <mwhudson> yeah
[04:15] <mwhudson> jml: approved
[04:16] <jml> mwhudson, thanks.
[04:52] <stub> https://code.edge.launchpad.net/~stub/launchpad/replication/+merge/16898
[05:00] <jml> stub, replied.
[05:03] <stub> Fixing now. Ta.
[05:13] <stub> jml: pushing now. Diff at https://pastebin.canonical.com/26350/ for the impatient.
[05:13] <jml> stub, it's spelled "separate".
[05:14] <jml> stub, other than that, r=jml
[05:14] <stub> Not when I spell it is isn't ;)
[05:14]  * stub needs misspelling highlighting in vim
[05:16] <jml> there was a terrible awful mnemonic on the wall in one of my classes in primary school
[05:16] <jml> smell "a rat" when you sep_arat_e
[10:18] <henninge> Hi adeuring! Bock auf'n review? ;-)
[11:00] <jtv> adeuring: didn't even see that you'd already reviewed my import policy violations fix... thanks!
[11:00] <adeuring> jtv: welcome :)
[11:01] <adeuring> henninge: sorry, didnt notice your request... Yes, I can of course do the review
[11:01] <henninge> adeuring: np ;)
[11:01] <henninge> thanks
[13:33] <bac> salgado: i just submitted a MP for a branch to fix bug 419930.  can you review it?
[13:33] <mup> Bug #419930: non-public email address shown after merge request <email> <merge> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/419930>
[13:34] <salgado> bac, sure!
[13:34] <bac> salgado: cool b/c you're the best one to do it.  thanks.
[13:42] <henninge> adeuring: Hi, how are you doing with the review? Any questions?
[13:43] <adeuring> henninge: I have one suggestion:
[13:44] <bac> salgado: it just arrived: https://code.edge.launchpad.net/~bac/launchpad/bug-419930/+merge/17015
[13:44] <adeuring> henninge: you list the the "SQL names" o the person objects in ILaunchpadCelebrities in l/c/l/doc/celebrities.txt. What do you think of listing instead the _attribute_ names of IPerson objects in ILauchpadCelebrities()?
[13:45] <adeuring> The latter is what you need in IPersonRoles
[13:47] <henninge> adeuring: yes, correct. This was the cheapest way to do it because the SQL names were already being collected.
[13:47] <adeuring> henninge: yes. But you can iterate over ILaunchpadCelebrities.names() to find those celebrities that implement IPerson.
[13:48] <henninge> adeuring: actually, I'd check for PersonCelebrityDescriptor
[13:48] <adeuring> henninge: OOPS, right
[13:48] <henninge> adeuring: but you're right, that shouldn't be too hard.
[13:48] <henninge> thanks for the suggestion.
[13:49] <adeuring> henninge: Then you could also get rid of the person_names attribute in ILPCelebs
[13:49] <adeuring> henninge: other that that; i found a few typos. I'll send the nitpicks via mail ;)
[13:50] <henninge> adeuring: how? I still need a way to get to the list of names - be they sql names or attribute names.
[13:52] <adeuring> henninge: right. You already use IPersonRoles.names() in a test; ILPCelebrities.names() should give you all celebrity names; and with IPersonCelebrity.providedBy(getattr(all_celebrities, attribute_name) you can check if you have a "relevant" celeb object, I think
[13:53] <henninge> adeuring: no doubt, but I want to do that in a test and to get to that in a test, it needs to be in an interface somewhere.
[13:53] <henninge> adeuring: PersonCelebrityDescriptor is not exported and I don't want to do it just for the test.
[13:56] <adeuring> henninge: OK, makes sense. Wat about adding a class attribute is_person_celebrity to CelebrityDescriptor and PersonCelebrityDescriptor?
[13:56] <adeuring> s/wt/what/
[13:58] <henninge> adeuring: I had thought about that but thought I could achieve the same thing just using isinstance (eventually I resorted to just counting).
[13:58] <henninge> adeuring: but if I do that *instead* of person_names, it makes more sense.
[13:58] <henninge> adeuring: I'll do that.
[13:59] <adeuring> henninge: OK, but there is even an attribute CelebrityDescrptor.interface. COuldn't you use that one?
[13:59] <henninge> and check for IPersonSet? possibly
[14:00] <henninge> hm
[14:01] <adeuring> henninge: right, that's a bit odd
[14:03] <henninge> adeuring: no, I think it's odder to add an attribute to a base class that is meant for one specific child class
[14:03] <henninge> which is_person_descriptor would be
[14:03] <adeuring> henninge: right...
[14:07] <henninge> adeuring: problem is, ILaunchpadCelebrities has attributes that are no descriptors at all
[14:07] <henninge> adeuring: so I'd have to check for existence of the "interface" attribute first, then check its value.
[14:08] <adeuring> henninge: right. But: reading the documentation of __get__() again, I think you can simply use IPerson.providedBy(celebrity)
[14:08] <henninge> oh, really? let me try that.
[14:40] <henninge> adeuring: ok, that works but I had to go through "getattr" for the Descritor to be invoked. I tried to loop through __dict__ first but that does not invoke __get__. And it looks ugly.
[14:40] <henninge> again something learned about Python
[14:42] <adeuring> henninge: yeah, getattr() was what I was thinking about ;)
[14:43] <henninge> adeuring: look http://paste.ubuntu.com/353497/
[14:49] <adeuring> henninge: looks good. But I think it you should also explicitly print the names of the "person celebrities", so that you see more clearly that you should change IPersonRoles when you add/remove/change an IPerson celebrity. (sorry to be such PITA...)
[14:51] <henninge> adeuring: np
[14:52] <adeuring> henninge: Or perhaps you could even create a sorted list of the person celeb names, prefixed with "in_" and compare that list with the corresoding list of attributes from IPersonRoles
[14:52] <henninge> adeuring: that is what I am doing now.
[14:52] <adeuring> henninge: cool!
[14:52] <henninge> just the other way round, I am removing the prefix from the IPersonRoles attribute names.
[14:52] <adeuring> henninge: yeah, sure ;)
[14:53] <henninge> adeuring: I meant, that is what the patch does.
[14:53] <adeuring> ok
[15:08] <adeuring> henninge: OK, now I get it; what I meant is: The comparison in line 64 is http://paste.ubuntu.com/353497/ is fine. But when something goes wrong, you need to figure out what goes wrong. It helps a little bit if you print also the content of person_celebrity_names
[15:08] <henninge> adeuring: working on that atm, using set
[15:08] <adeuring> henninge: great, thanks! otherwise, r=me, BTW
[15:09] <henninge> adeuring: cool, thank you!
[16:18] <salgado> bac, sorry for the delay on that review
[16:21] <bac> salgado: np
[16:23] <bac> salgado: to answer your question, if a duplicate person has hidden email addresses then you can merge them if you know the LP id.  is that problematic?
[16:24] <salgado> bac, no, I was just wondering if it's currently possible to merge a dupe account with hidden email addresses
[16:25] <bac> salgado: you cannot get the person via the picker but you can enter the id in the field
[16:25] <salgado> right
[16:26] <bac> thanks for catching the missing test and the suggested improvements
[17:42] <bac> salgado: fancy another?
[17:43] <salgado> bac, sure, why not?
[17:43] <bac> salgado: https://code.edge.launchpad.net/~bac/launchpad/bug-407604-proj-desc/+merge/17028
[17:44] <bac> salgado: i am about to leave for lunch and an appt so i won't be around to answer questions on IRC
[17:45] <salgado> that's fine
[19:22] <gary_poster> EdwinGrubbs: hey.  So, I'm still thinking about the vocabulary thing you pinged me about.  Even though I don't feel "done," I figure I'd share my thoughts so you could steer me or maybe provide an idea I would have missed.
[19:22] <gary_poster> To start trivially and less problematically (for me at least), I think lines 177-180 should be a "try: ... except UnauthorizedError: ..." rather than looking for launchpad.View.  IMO, you should never have to ask for a given permission.
[19:22] <gary_poster> (FWIW, zope.security.checker.canView would be better because it does what you want without having to specify a permission, and would incidentally Just Work without the secured vocabulary work you have done, but I agree with Francis that a security proxy is a better approach.)
[19:23] <gary_poster> EdwinGrubbs: huh
[19:23] <gary_poster> EdwinGrubbs: did you get everything I just wrote?  It ended with "lines 138-148, written in zcml for each vocabulary definition?"
[19:23] <EdwinGrubbs> gary_poster: No, I didn't see that line.
[19:23] <gary_poster> EdwinGrubbs: what was the last line you got?
[19:23] <gary_poster> before I said "huh"
[19:24] <gary_poster> (if any)
[19:25] <EdwinGrubbs> gary_poster: the last line I got ended with "security proxy is a better approach.)"
[19:25] <EdwinGrubbs> gary_poster: can I use canView() instead of the try/except UnauthorizedError?
[19:26] <gary_poster> EdwinGrubbs: you could.  Why do you want to?
[19:26] <gary_poster> When we finish this I guess I'll paste in the next item :-)
[19:27] <EdwinGrubbs> gary_poster: well, because exception handling is slow, and because I have seen canView() used elsewhere in launchpad but exception handling for permissions not so much.
[19:34] <gary_poster> EdwinGrubbs: slow: I'm skeptical.  I know the advice of which you speak, but I doubt exception handling is slow compared to calling another Python function.  I'd want to see a timeit test before that was a valid argument.  I think exception handling is slow compared to other single-Python-operation tasks.
[19:34] <gary_poster> exception handling for permissions: huh.  Of course, that's the principle for Zope's basic operation.  I think try: except is more appropriate here.  I'm OK with you using canView for now, and letting me bring this up in the reviewers meetings (are we even having those now that barry is gone?) if that's what you want.
[19:34] <gary_poster> I'll copy and paste my next point then.
[19:35] <gary_poster> Still staying easy, my next topic is the way you handled __getslice__ for ICountableIterator.  I prefer what you have done rather than modifying ICountableIterator, if I understand the situation properly.  Am I correct that this is necessary because Python will try __getslice__ before trying __getitem__?  If so, this is clearly a security issue, and the scribbling belongs where you have it, IMO.
[19:35] <gary_poster> If you are OK with that, I'll then copy and paste my last bits, which was where I wrote quite a lot.
[19:35] <gary_poster> well, more than the bit you read, anyway.
[19:36] <EdwinGrubbs> gary_poster: bac has taken over the reviewer meetings. I guess you missed the one on Wed.
[19:36] <gary_poster> EdwinGrubbs: cool.  Yeah, I was in Lean training with the OEM folks, since I wasn't with LP the first time around.
[19:37] <EdwinGrubbs> gary_poster: excuses, excuses
[19:37] <gary_poster> heh
[19:37] <EdwinGrubbs> gary_poster: __getslice__ is used because HugeVocabularyJSONView batches the results.
[19:38] <gary_poster> EdwinGrubbs: but the implementation handles slices in its __getitem__, right?
[19:38] <gary_poster> I mean, the vocabulary implementation
[19:39] <EdwinGrubbs> gary_poster: right
[19:39] <gary_poster> EdwinGribbs: cool.  Then are you OK with me being OK with what you have done there? :-)
[19:40] <EdwinGrubbs> gary_poster: as far as try/except for security exceptions. I have no problem with it, if that is preferred, but I can imagine getting questioned on it in the code review, so it would be good to bring it up at the next meeting.
[19:41] <gary_poster> EdwinGrubbs: cool, makes sense
[19:41] <EdwinGrubbs> gary_poster: yes, I approve of your approval. I guess I'm ready for the pasted text.
[19:41] <gary_poster> OK cool
[19:41] <gary_poster> Five chunks
[19:41] <gary_poster> Finally, the bigger and harder question is the first one you raised, about creating a new vocabularyutility directive rather than hacking securedutility. Honestly, I don't love either approach.
[19:41] <gary_poster> The securedutility approach is a kludge, as you said.  If we were going to pursue it, I'd like to try doing it a slightly different way, but we can talk about that later if necessary.  (Summary: register another directive in first phase of zcml processing rather than just doing it in the second stage.)
[19:42] <gary_poster> The vocabularyutility directive introduces yet another zcml directive, when I think that in practice one of zcml's failings is that it was never actually designed as a language but as a collection of automations.  (If I'm wrong, and the original intent was a language, then I think the intent was lost.)  Therefore, I don't want that one either.
[19:42] <gary_poster> I tend to think that what we need is to look at the problem you are trying to solve and step back.  We can introduce a new zcml directive, but if we do, I'd rather it be of more general usefulness.  It might not be possible, or possible within a short timeframe, but I still think we need to talk about it.
[19:42] <gary_poster> The problem you were trying to solve was "a ton of extra boiler plate".  I think I know what that boiler plate was, but do you have a full example, or can you easily construct it?  Am I right that it is lines 138-148, written in zcml for each vocabulary definition?
[19:42] <gary_poster> That's the end of the paste.
[19:43] <gary_poster> I'm pretty sure that the last para is right about lines 138-148.  I still don't have an answer I like. :-(
[19:43] <gary_poster> That is, I've tried to "step back" and I still don't see anything...
[19:46] <gary_poster> I believe the boiler plate is something on the order of this:
[19:47] <gary_poster> <allow interface="...IVocabularyFactory" /><allow interface="...IHugeVocabulary" />
[19:47] <EdwinGrubbs> gary_poster: exactly
[19:49] <EdwinGrubbs> gary_poster: If we don't want the zcml directive doing the work. One alternative that may or may not be considered even more kludgy would be to post process the registered utilities. Of course, I have absolutely no idea how to go about doing that.
[19:49] <EdwinGrubbs> gary_poster: I'm not sure what you meant about the first and second phase of zcml processing.
[19:55] <gary_poster> EdwinGrubbs: zcml processing has two rounds.  First, it parses the XML and registers directive classes with unique identifiers.  If it encounters a directive with the same identifier already registered, it pukes, and announces a conflict.  This is how zcml makes sure that two directives don't fight (or even duplicate) one another.  If the zcml processing gets through this phase, then it actually *performs* the zcml direc
[19:55] <gary_poster> In the case of your code, registering directives for the classes would make sure that you are not stomping on anything else.  It also would have caught the problem that made you use the _vocabulary_cache...though you might still have needed that solution, in order to avoid complaints.
[20:00] <gary_poster> EdwinGrubbs: OK after thinking about it maybe more than I should have, here's my opinion, which you might not like :-) .  I think you should make an interface that combines IVocabularyFactory and IHugeFactory into a single interface for convenience, and do <allow interface="...combined interface" /> for now.
[20:00] <gary_poster> Solving this is a matter for thought--and in fact, this is the kind of thought that the grok community has been pursuing.  That project is about reducing Zope boiler plate (and making it easier to start with Zope 3 technologies) and so I think we will want to use their approach for simplifying this kind of thing in the future.
[20:00] <gary_poster> For now, I don't think we should introduce a surprising kludge or Yet Another ZCML directive.
[20:00] <gary_poster> That's my take.
[20:08] <EdwinGrubbs> gary_poster: I just realized that I was wrong when I said that the boilerplate I was eliminating were just the two <allow> directives. I can't combine those two directives with a new interface, since one <allow> will be in <securedutility> and the other will be in <class>. See http://pastebin.ubuntu.com/353609/
[20:15] <EdwinGrubbs> gary_poster: I'm not sure how grok would make this situation better. Wouldn't require just as many extra configurations, or is it considered less tabu to create custom configuration directives, since it doesn't have the difficulty of trying to figure out where a zcml directive is actually defined or what it does?
[20:20] <EdwinGrubbs> gary_poster: it really seems like we need something like the <pages><page/></pages> hierarchical directives, so we can fill in redundant attributes. However, it wouldn't be quite as simple since there is both a <securedutility> and <class> directive to fill in.
[20:20] <gary_poster> EdwinGrubbs: So, first, for the "allow" concern, here's a reply: http://pastebin.ubuntu.com/353615/
[20:21] <gary_poster> EdwinGrubbs: oh...
[20:21] <gary_poster> EdwinGrubbs: you need to treat the IVocabularyFactory as something that the context provides
[20:22] <gary_poster> EdwinGrubbs: and you need to treat the resulting class as something that the context implements
[20:22] <gary_poster> EdwinGrubbs: that's why my idea doesn't work
[20:23] <gary_poster> I mean "you need to treat the IHugeVocabulary as something that the context implements"
[20:25] <EdwinGrubbs> gary_poster: yes, in lines 138-148, I had to use a separate ClassDirective instead of piling everything into self.allow()
[20:27] <gary_poster> EdwinGrubbs: grok better: I think you would be able to define the utility in a single line, and define the permission for the class in a single line.  It would not compress the two behaviors the way you have it here, but I suspect it would be both more readable/explicit and shorter.  (Moreover, if grok does not have support for secured utilities, we could add it.)
[20:28] <gary_poster> admittedly, you would still have to follow the "recipe" for a secured vocabulary, which is your point.
[20:30] <EdwinGrubbs> gary_poster: zcml seems anti-DRY. Maybe I could create a new paradigm, WET (We exemplify tediousness).
[20:30] <EdwinGrubbs> ;-)
[20:30] <gary_poster> lol
[20:32] <EdwinGrubbs> gary_poster: despite my negativity, if you think that being explicit in the zcml is the best way to go, I'll do that.
[20:35] <gary_poster> EdwinGrubbs: "convention over configuration": "convention" usually is not explicit.  configuration typically does not conform to DRY.  grok is about trying to get some of the zope benefits while bringing in some DRY ideas.
[20:35] <gary_poster> I'm not against your concerns, I'm just against trying to address them in a way that introduces another issue IMO (makes the zcml "language" bigger with more to learn) without some significant pushback.  I reconciled my position in my own mind by thinking "grok is the better way to reduce duplication".
[20:35] <gary_poster> I'll summarize my position like this:
[20:36] <gary_poster> 1) My primary vote is to just grin and bear it, and wait for grok and/or some deeper thought on how to reduce DRY in our code.
[20:37] <gary_poster> 2) If you feel strongly that you don't want to wait for some unspecified time in the future for this, I'm uncomfortably OK with you making a securedvocabulary (or <vocabulary secure="true" />?) directive.
[20:37] <gary_poster> 3) I'd really rather not see the kludge in securedutility.
[20:38] <gary_poster> EdwinGrubbs: fair enough?  I need to run go pick up a son from school
[20:38] <gary_poster> EdwinGrubbs: back in a bit
[20:38] <gary_poster> '
[20:39] <EdwinGrubbs> gary_poster: go ahead, I'm getting distracted in another channel.
[20:55] <gary_poster> EdwinGrubbs: back fwiw
[21:08] <gary_poster> EdwinGrubbs2: I
[21:08] <gary_poster> have been back for a while.  don't know if you saw that (I see you are having nick fun)
[21:12] <EdwinGrubbs2> gary_poster: I saw your 1/2/3 summary. It's ok. sed should make it easy enough.
[21:25] <gary_poster> EdwinGrubbs: cool
[22:43] <sinzui> flacoste: I replied with a two remarks. Do you want to change the security on featured projects? Do you want to run the doc tests on the DatabaseFunctionalLayer?


[00:24] <knome> pleia2, mm, that looks good
[00:25] <pleia2> digging up some links to include too
[00:25] <pleia2> then I'll email the three council members to get them to answer the questions ;)
[00:25] <knome> hehe
[00:25] <knome> maybe just ask them to reply on the pad
[00:26] <pleia2> yeah sure
[00:26] <knome> and maybe private mails
[00:26] <knome> otherwise you get all kinds of "council members" adding their answers
[00:27] <pleia2> I'm sending a private email directly
[00:27] <knome> goodie
[00:27] <pleia2> will give y'all a chance to read the article too ;)
[00:27] <knome> hehe
[00:28] <knome> i would probably word the last question a bit differently
[00:28] <knome> eg. "tell us a bit of yourself" instead of "...wish to share"
[00:29] <knome> but the question is better than "tell us about yourself", so you'll have to fix my wording further :P
[00:29] <knome> o hai bluesabre
[00:29] <knome> oh man, etherpad
[00:29] <pleia2> I want to keep it a question
[00:29] <knome> yes
[00:30] <bluesabre> hi knome, pleias
[00:31] <bluesabre> 2
[00:31] <bluesabre> :D
[00:37] <knome> :)
[00:40] <pleia2> ok, emailed knome, bluesabre and ochosi
[00:42] <knome> ta
[00:43] <bluesabre> thanks pleia2
[00:43] <pleia2> sure thing
[01:51] <knome> oki, time to go
[01:51] <knome> ttyl
[01:57] <pleia2> night knome
[12:25] <flocculant> bluesabre: at a guess nothing's likely to happen this side of next year with gstreamer and that bug
[15:00] <knome> pleia2, new code stuff in production and all new stuff in use, eg. no more manual updating of stuff \o/
[16:29] <krytarik> Stuff! \o/
[17:19] <knome> krytarik, yeah, like updating download mirror lists with endless stuff
[17:40] <pleia2> knome: yay, congrats
[17:41] <knome> thanks
[17:41] <knome> and to you too :P
[17:41] <knome> ok, bbl
[20:47] <knome> pleia2, https://xubuntu.org/?p=4171&preview=true <-- with changes
[20:48] <knome> pleia2, also, was thinking about moving system requirements under help & support
[20:48] <knome> pleia2, but i'm not sure
[20:48] <knome> maybe not


[01:11] -queuebot:#ubuntu-release- Unapproved: accepted calamares-settings-ubuntu [source] (disco-proposed) [30]
[01:11] -queuebot:#ubuntu-release- Unapproved: accepted qtwebkit-opensource-src [source] (disco-proposed) [5.212.0~alpha2-17ubuntu1]
[01:11] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (disco-proposed) [1:6.1.2-0ubuntu4]
[01:14] <infinity> LocutusOfBorg: What happened to the fixed slic3r you said you had?
[01:28] <tsimonq2> (Justification for clojure1.8 in Disco is in bug 1799075.)
[01:29] -queuebot:#ubuntu-release- Unapproved: clojure1.8 (disco-proposed/universe) [1.8.0-7ubuntu1 => 1.8.0-8] (no packageset) (sync)
[01:31] -queuebot:#ubuntu-release- Unapproved: accepted clojure1.8 [sync] (disco-proposed) [1.8.0-8]
[01:31] <tsimonq2> Oh, and bug 1799076 for leiningen-clojure. Should be all for now.
[01:32] -queuebot:#ubuntu-release- Unapproved: leiningen-clojure (disco-proposed/universe) [2.8.1-7ubuntu1 => 2.8.1-9] (no packageset) (sync)
[04:50] -queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (disco-proposed/universe) [0.182 => 0.183] (ubuntustudio)
[06:07] -queuebot:#ubuntu-release- Unapproved: accepted leiningen-clojure [sync] (disco-proposed) [2.8.1-9]
[08:17] -queuebot:#ubuntu-release- Unapproved: libsass-python (disco-proposed/universe) [0.14.5-1build1 => 0.14.5-2] (no packageset) (sync)
[08:18] -queuebot:#ubuntu-release- Unapproved: recoll (disco-proposed/universe) [1.24.1-2build1 => 1.24.1-4] (no packageset) (sync)
[08:29] -queuebot:#ubuntu-release- Unapproved: accepted libsass-python [sync] (disco-proposed) [0.14.5-2]
[08:29] -queuebot:#ubuntu-release- Unapproved: accepted recoll [sync] (disco-proposed) [1.24.1-4]
[08:29] <doko> infinity, LocutusOfBorg, Laney: anybody mass-giving back the s390x/unknown autopkg tests?
[08:33] -queuebot:#ubuntu-release- Unapproved: amp (disco-proposed/universe) [0.6-3build4 => 0.6.1-1] (no packageset) (sync)
[08:33] -queuebot:#ubuntu-release- Unapproved: breezy (disco-proposed/universe) [3.0.0~bzr7119-1build1 => 3.0.0~bzr7141-4] (no packageset) (sync)
[08:34] -queuebot:#ubuntu-release- Unapproved: healpy (disco-proposed/universe) [1.12.3-2build1 => 1.12.4-3] (no packageset) (sync)
[08:37] -queuebot:#ubuntu-release- Unapproved: accepted amp [sync] (disco-proposed) [0.6.1-1]
[08:37] -queuebot:#ubuntu-release- Unapproved: accepted healpy [sync] (disco-proposed) [1.12.4-3]
[08:37] -queuebot:#ubuntu-release- Unapproved: accepted breezy [sync] (disco-proposed) [3.0.0~bzr7141-4]
[08:52] -queuebot:#ubuntu-release- Unapproved: ruby2.5 (disco-proposed/main) [2.5.1-5ubuntu4 => 2.5.1-6ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
[08:56] -queuebot:#ubuntu-release- Unapproved: accepted ruby2.5 [source] (disco-proposed) [2.5.1-6ubuntu1]
[09:10] <doko> infinity: please have a look at the ruby2.5 timezone test failure in the build
[11:54] -queuebot:#ubuntu-release- Unapproved: rrdtool (disco-proposed/main) [1.7.0-1build3 => 1.7.0-1build4] (core)
[11:56] -queuebot:#ubuntu-release- Unapproved: libftdi1 (disco-proposed/universe) [1.4-1build2 => 1.4-1build3] (kubuntu)
[11:56] -queuebot:#ubuntu-release- Unapproved: eccodes (disco-proposed/universe) [2.8.0-4build1 => 2.9.0-1] (no packageset) (sync)
[11:58] -queuebot:#ubuntu-release- Unapproved: accepted eccodes [sync] (disco-proposed) [2.9.0-1]
[11:58] -queuebot:#ubuntu-release- Unapproved: accepted rrdtool [source] (disco-proposed) [1.7.0-1build4]
[11:58] -queuebot:#ubuntu-release- Unapproved: accepted libftdi1 [source] (disco-proposed) [1.4-1build3]
[12:18] <LocutusOfBorg> infinity, seems harder, the new "system library" has a different API
[12:18] <LocutusOfBorg> doko, .
[14:06] -queuebot:#ubuntu-release- Unapproved: zeroc-ice (disco-proposed/universe) [3.7.1-4ubuntu1 => 3.7.1-4ubuntu2] (cli-mono)
[14:10] -queuebot:#ubuntu-release- Unapproved: accepted zeroc-ice [source] (disco-proposed) [3.7.1-4ubuntu2]
[14:10] <doko> vorlon: any idea about https://launchpad.net/ubuntu/+source/matplotlib/2.2.2-4build2 ?
[14:29] -queuebot:#ubuntu-release- Unapproved: oca-core (disco-proposed/universe) [11.0.20180420-1 => 11.0.20180730-1] (no packageset) (sync)
[14:30] -queuebot:#ubuntu-release- Unapproved: accepted oca-core [sync] (disco-proposed) [11.0.20180730-1]
[15:35] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-7 (disco-proposed/main) [1:7-6 => 1:7-8] (kubuntu, ubuntu-desktop) (sync)
[16:39] <infinity> Release 2018f - 2018-10-18 00:14:18 -0700
[16:39] <infinity>   Changes to past timestamps
[16:39] <infinity>     The 1948-1951 fallback transitions in Japan were at 25:00 on
[16:39] <infinity>     September's second Saturday, not at 24:00.  (Thanks to Phake Nick.)
[16:39] <infinity>     zic turns this into 01:00 on the day after September's second
[16:39] <infinity>     Saturday, which is the best that POSIX or C platforms can do.
[16:39] <infinity> doko: ^
[16:40] <infinity> Not shockingly, ruby once again proves that treating tzdata as a static dataset is wrong.
[18:51] <doko> infinity: care to fix it? blocking perl and gdbm ...
[18:56] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-7 [sync] (disco-proposed) [1:7-8]
[19:03] <doko> LocutusOfBorg: llvm-defaults doesn't migrate
[21:02] <LocutusOfBorg> doko, I know, I want the new llvm being ready before understanding if this is a real issue or not
[21:03] <LocutusOfBorg> probably it is just confused by the new libs
[21:04] <mwhudson> 1140 packages in disco-proposed, nice
[21:05] <mwhudson> so many packages in the autopkgtest queue that /running takes 30s to render
[21:05] <mwhudson> maybe i should just go and walk in the sun and come back tomorrow :)
[21:09] <xnox> infinity, removing perl on s390x is not nice, during perl triggered autopkgtests... since the bootloader package depends on perl..... (fun)
[21:21] -queuebot:#ubuntu-release- Unapproved: dh-python (disco-proposed/main) [3.20180927ubuntu1 => 3.20180927ubuntu2] (ubuntu-desktop)
[21:25]  * mwhudson confuzzles
[21:25] <mwhudson> how the heck did this package http://autopkgtest.ubuntu.com/packages/a/aioprocessing/disco/amd64 pass tests when triggered by python3-defaults/3.7.1-1 ?
[21:26] <mwhudson> there is no evidence in the log that "python3" got updated to the one from the triggering package
[22:31] <infinity> xnox: Why would perl be removed?  That usually only happens when it's out of sync with arch:all, which didn't happen.
[22:31] -queuebot:#ubuntu-release- Unapproved: accepted dh-python [source] (disco-proposed) [3.20180927ubuntu2]
[22:36] <xnox> infinity, indeed. it is fine on other arches. i wonder if all the "regressions" without a version number triggered by perl should be retriggered.
[22:36] <xnox> maybe like publisher was slow, or something else in the base system was uninstallable at the time.
[22:36] <xnox> infinity, do you want to mass retrigger, or should i?
[22:36] <xnox> there is a script i can ran for that from the archive tools
[22:38] <infinity> xnox: Be my guest, I'm fixing ruby and heading for food.
[22:56] <xnox> hm
[23:16] -queuebot:#ubuntu-release- Unapproved: ruby2.5 (disco-proposed/main) [2.5.1-6ubuntu1 => 2.5.1-6ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
[23:18] -queuebot:#ubuntu-release- Unapproved: accepted ruby2.5 [source] (disco-proposed) [2.5.1-6ubuntu2]
[23:29] <jbicha> xnox: https://autopkgtest.ubuntu.com/packages/a/abi-compliance-checker/disco/s390x is complaining about zipl, do you have any idea what that's about?
[23:31] <jbicha> mwhudson: 2 years ago, I reguarly saw autopkgtests triggered too early but I hadn't seen it recently


[08:53] <LocutusOfBorg> apw, please sync kernel modules from virtualbox
[08:53] <LocutusOfBorg> 5.1.14 has important fixes
[08:54] <LocutusOfBorg> also the kernel that will go in 16.04.2 probably needs updates from here https://launchpad.net/ubuntu/+source/virtualbox/5.0.32-dfsg-0ubuntu<IP_ADDRESS>
[09:57] <LocutusOfBorg> apw, I'm back :)
[11:35] <apw> LocutusOfBorg, the .2 kernel will be the hwe kernel and has (in theory)
[11:35] <apw>     Vileda SuperMocio 3 Action Refill - Twin Pack by Vileda
[11:35] <apw> no not that
[11:35] <apw> 5.1.6-dfsg-2
[11:35] <LocutusOfBorg> tooo old
[11:35] <LocutusOfBorg> 5.1.14 has fixes
[11:35] <apw> that is what is _in_ yakkety, which is where the kernel comes from
[11:36] <LocutusOfBorg> so kernel 4.8?
[11:36] <apw> yes, it will be essentially yakkety's kernel
[11:36] <LocutusOfBorg> ok fine then
[11:36] <LocutusOfBorg> fixes are for kernel 4.9+
[11:37] <LocutusOfBorg> so, please apply them for zesty only
[11:52] <apw> ack
[11:58] <LocutusOfBorg> but question: most changes are build fixes for newer kernels, how do you handle them? I can't understand how you can update the kernel without updating vbox kernel modules too
[13:05] <jsalisbury> stgraber, I'll post a link to a test kernel in bug 1655842? shortly
[14:33] <montvid> hi there. i would like to ask for a kernel fix as written in http://askubuntu.com/questions/674179/ubuntu-device-flash-fails-on-nexus-7-2013-android-5-0-2-cant-copy-image-to the device is officialy supported but completly not installing for more than a year now. see bug https://bugs.launchpad.net/canonical-devices-system-image/+bug/1496756
[14:34] <montvid> how come a device that is supported officialy does not work at all for over a year?
[14:35] <montvid> i asked popey in ubuntu touch and he answered he has no idea what to do...
[14:38] <montvid> i see people in xda fixed their twrp recovery, made a kitkat boot image and are good. is there a possibility to merge these changes in ubuntu touch kernel?
[14:41] <montvid> because the nexus 7 device bought in 2015 and later do not install at all. How can it have support if it does not boot?
[14:43] <montvid> any ideas?
[14:43] <montvid> :)
[14:48] <LocutusOfBorg> montvid, the patch posted on askubuntu is already inside the kernel AFAIK
[14:48] <LocutusOfBorg> commit 6636bad839d9936e73e48c4841eda83a58fcdb53
[14:48] <LocutusOfBorg> $ git tag --contains 6636bad839d9936e73e48c4841eda83a58fcdb53 |head -n 1
[14:48] <LocutusOfBorg> v3.11
[14:48] <LocutusOfBorg> the first one was kernel 3.11, shipping that fix
[14:49] <montvid> but nexus 7 is on 3.4.0 as i understand?
[14:50] <LocutusOfBorg> so, the fix is already there
[14:50] <LocutusOfBorg> s/is/should be
[14:51] <montvid> is the fix applied to ubuntu recovery too? because yesterday it did not install. it installed with github files only.
[14:52] <montvid> https://github.com/ddagunts/UTCWM_N7_patch/blob/master/boot.img?raw=true
[14:53] <montvid> using this repo i could install ubuntu touch stable
[14:54] <montvid> i get the same error as in the bug link
[14:54] <montvid> if i try to use official builds of boot.img and recovery.img
[14:55] <montvid> thanks for the info LocutusOfBorg
[14:55] <LocutusOfBorg> I'm not an Ubuntu kernel developer unfortunately, so I don't know how they patch it
[14:58] <montvid> well android devices can not change kernel versions. they stay in the same branch nexus 7 2013 is in 3.4 branch and cant go to 3.5
[14:58] <montvid> or 3.11
[14:59] <montvid> can anyone change the bug status from high to critical?
[15:00] <montvid> because of this bug one cant install and run the system. seems critical :)
[15:06] <LocutusOfBorg> which bug?
[15:07] <montvid>  <montvid> hi there. i would like to ask for a kernel fix as written in http://askubuntu.com/questions/674179/ubuntu-device-flash-fails-on-nexus-7-2013-android-5-0-2-cant-copy-image-to the device is officialy supported but completly not installing for more than a year now. see bug https://bugs.launchpad.net/canonical-devices-system-image/+bug/1496756
[15:07] <montvid> sorry for the dublicate
[15:10] <LocutusOfBorg> mterry, ^^ seems that I can't change the bug severity :)
[15:10] <montvid> thanks for trying
[15:11] <montvid> maybe you could add a comment? i dont have a login...
[15:11] <LocutusOfBorg> it won't add much value :/
[15:15] <montvid> i understand.
[15:36] <caribou> smb: FYI, uploaded crash 7.1.7-1ubuntu1; autopkgtest found a bug which is fixed in post 7.1.7 so I have just uploaded a ubuntu2 with the upstream fix
[15:44] <smb> caribou, oh ok. I just recently saw some crash going to the archive but have not looked closely at the version numbers
[15:45] <caribou> smb: well, it got stucked into -proposed following a failure in DEP8 test
[15:45] <caribou> smb: the failure is specific to live crash session so I missed it by testing on a _real_ kernel crash
[15:46] <smb> caribou, Ah, but at least good to see the dep8 testing being good for something
[15:46] <caribou> smb: indeed; I should have run it before uploading though
[15:48] <smb> caribou, True, though I must admit that often I forget that part, too.
[15:59] <stgraber> jsalisbury: thanks
[15:59] <jsalisbury> stgraber, good timing.  The build just finished.  Once second, I'll scp it and drop a link
[16:01] <jsalisbury> stgraber, http://kernel.ubuntu.com/~jsalisbury/lp1655842/armhf/
[16:01] <stgraber> jsalisbury: thanks. I'll install that on one of the boards and see if it shows OOM over the next 24 hours (it's a jenkins runner)
[16:01] <jsalisbury> stgraber, thanks
[19:58] <setuid> Is there a way to parallelize update-initramfs on a test box with hundreds of kernels?
[19:58] <setuid> update-grub takes hours
[20:00] <setuid> It
[20:00] <setuid> It's a pipeline from a failed apt-get, so running dpkg --configure -a
[20:17] <setuid> This sort of works, but it's ugly: ls -1 /boot/vmlinuz* | cut -b9-40 | while read line; do sudo update-initramfs -c -k $line & done;