[00:22] <kklimonda> is changing username or password (and doing other things like restarting handshaking process or logging out user from web ui because of the wrong credentials) in preferences windows immediately after GtkEntry widget looses focus a good practice?
[15:04] <jcastro> tedg: fagan found that the a-i docs you have on your people page have a bunch of 404's
[15:04] <jcastro> tedg: I will assign you the bug!
[15:06] <tedg> jcastro: Eh, we need to figure out how to generate those the right way...
[15:07] <jcastro> ok we'll use that as the tracking bug
[15:07] <Nafai> Hi guys
[15:07] <Nafai> Sorry I haven't got much done, yesterday my allergies got the best of me
[15:10] <seb128> Nafai, hey
[15:10] <seb128> Nafai, ok, the bluetooth update bug is on your todolist for today if your feel better then? ;-)
[15:12] <Nafai> Yes, I do
[15:12] <Nafai> That will be my first task :)
[15:13] <seb128> Nafai, second task for you if you have time would be to investigate notify-osd displaying wrong rhythmbox covers sometime
[15:13] <Nafai> Yeah, I was noticing that the other day actually
[15:13] <seb128> like on track changes when the new song doesn't have a cover you sometime get the previous track cover displayed for it
[15:14] <seb128> Nafai, you think you can add that to your todolist then?
[15:14] <Nafai> Yeah, is there a bug filed for that yet?
[15:14] <seb128> I will look at it now
[15:15] <seb128> there is quite some rhythmbox, artwork bugs
[15:17] <jcastro> Nafai: jpetersen: smithj: I'll send you guys a mail this morning, basically after you finish up the a-i tasks you have pending we're just going to assign you desktop bugs that need to be fixed.
[15:18] <jpetersen> jcastro, ok
[15:19] <seb128> Nafai, let's use bug #451086
[15:19] <ubot4> Launchpad bug 451086 in rhythmbox (Ubuntu Karmic) (and 6 other projects) "Rhythmbox Notification Bubble shows wrong cover art (affects: 33) (dups: 4)" [Low,Fix released] https://launchpad.net/bugs/451086
[15:20] <seb128> I'm wondering if bug #426329 is similar though
[15:20] <ubot4> Launchpad bug 426329 in rhythmbox (Ubuntu) (and 1 other project) "Rhythmbox fails to display cover image from id3 tag (affects: 8) (dups: 1)" [Low,Incomplete] https://launchpad.net/bugs/426329
[15:20] <seb128> it's probably not no
[15:23] <Nafai> jcastro: ok
[15:24] <Nafai> tedg: Were Jpetersen's changes going to go into a new indicator release today?
[15:26] <Nafai> jcastro: Darn, the Chrome theme you posted is for Ambiance, not Radiance :(
[15:27] <jcastro> maybe the guy will make another one!
[15:27] <Nafai> Hopefully
[15:29] <jpetersen> btw i have a patch which fixes the upstream gtk+ bug: https://bugzilla.gnome.org/show_bug.cgi?id=612574
[15:29] <ubot4> Gnome bug 612574 in uimanager/actions "GtkMenuItem does not emit notify::label when label is changed through GtkAction" [Normal,Unconfirmed]
[15:35] <tedg> Nafai: I believe so, I'll make sure though.
[15:35] <Nafai> thanks
[15:35] <tedg> jpetersen: Sweet.  bratsche, can you review jpetersen's patch ^
[15:37] <kklimonda> is bug 537049 something to be fixed in all applications affected or is it bug in appindicator?
[15:37] <ubot4> Launchpad bug 537049 in transmission (Ubuntu) (and 2 other projects) "Indicator menus should not use icons except for dynamic objects (affects: 1)" [Low,New] https://launchpad.net/bugs/537049
[15:38] <bratsche> Yeah
[15:45] <tedg> kklimonda: In applications.
[16:07] <jpetersen> I will be just away for dinner, will be back in an hour
[16:10] <qense> seb128: The issue with the menu of AppInd -- I'm thinking of the gnome-bluetooth bug -- not updating could be related to the fact that even though libappind does support menu updates there seem to be some issues when actions are used to draw the menu items; at least the label isn't updated in that case.
[16:11] <qense> Not sure whether that applies to gnome-bt as well, though.
[16:30] <seb128> qense, ok, thanks
[16:30] <seb128> Nafai, I've assigned bug #408294 to you too
[16:30] <ubot4> Launchpad bug 408294 in empathy (Ubuntu Lucid) (and 2 other projects) "Notifications do not merge when coming from the same contact (affects: 3)" [Wishlist,Confirmed] https://launchpad.net/bugs/408294
[16:30] <Nafai> Just noticed that one coming in too
[16:31] <Nafai> (in my inbox, that is)
[16:31] <seb128> Nafai, don't freak out, I'm just putting some stuff on your todolist in case you get borred, there is no hurry just tackle in order things you can ;-)
[16:39] <Nafai> Thanks :)
[16:40] <vish> mpt: hi.. did you try Bug #537381 , in a guest session?  it does not happen there , also I'm not sure why you thought it was a theme bug
[16:40] <ubot4> Launchpad bug 537381 in light-themes (Ubuntu) ""Applications" and session menus don't work at screen edge (affects: 1)" [Undecided,New] https://launchpad.net/bugs/537381
[16:42] <vish> mpt: it is a gnome-panel/gnome-main-menu bug [from what i understand] and probably due to cruft in the /home
[16:43] <mpt> vish, I just tried it in a guest session. The bug occurs in Ambience and in Human but not in Clearlooks.
[16:44] <vish> mpt: weird , doesnt happen for me in guest session.. ok..i'll leave it to ken ;)


[00:01] <Sarvatt> oh what am i talking about, thats a kernel patch :D
[12:44] <tjaalton> bryce: great, thanks. yeah that patch can be purged now
[12:53] <tjaalton> bryce: intel; debian-experimental has <IP_ADDRESS>, I'm willing to test that next week
[13:07] <Sarvatt> might be better off with 2.7.1, <IP_ADDRESS> snapshot in debian doesnt have any of the updates from 2.7.0 to 2.7.1 that fixed alot of crashes
[13:38]  * albert23 thinks <IP_ADDRESS> will break systems where dri is disabled, i.e. because they have width>2048 (it breaks on my 945 in that case)
[19:18] <bryce> do we have <IP_ADDRESS> in a ppa?  that probably ought to be sufficient for testing purposes for now
[19:57] <hyperair> bryce: if you're around, i'd like to bring your attention to the fact that dropping dh_installchangelogs completely in debian/rules ends up forgetting to install debian/changelog to /usr/share/doc/<pkg>/changelog.Debian.gz as well.
[20:02] <bryce> hyperair: I can't imagine many people care about that??
[20:03] <bryce> hyperair: anyway, file a bug, we'll look into it when there's time
[20:03] <hyperair> bryce: i do. i like to keep track of intel's driver progress, but really, i could just drop by launchpad and see
[20:04] <hyperair> it helps to... erm... increase my despair after having my hopes of a release without the memory leak + performance regression + stability issues thrashed.
[20:05] <bryce> I'll keep it in mind next time I merge.  upstream didn't put in the ChangeLog with the tarball
[20:05] <hyperair> yeah i noticed from debian/changelog.
[20:05] <bryce> sometimes I take the time to generate it myself, but this time was just copying another packager's work who had simply disabled installing it
[20:06] <bryce> hmm, I have a patch that supposedly should fix all that
[20:06] <hyperair> well yes, but the point here is that instead of # dh_installchangelogs ChangeLog, it should be just dh_installchangelogs
[20:07] <bryce> ah good point
[21:00] <hyperair> bryce: when you mentioend you have a patch that supposedly fixes all that, by all that, did you mean memory leak + performance regression + stability issues by any chance?
[21:00] <hyperair> =D
[21:00]  * hyperair has a hopeful look
[21:03] <bryce> right
[21:04]  * hyperair looks forward to seeing it in the ppa =)
[21:08] <bryce> I might post it to a ppa
[21:08] <bryce> to be honest the behavior of certain people on some of the freeze bug reports has really turned me off from working on it.
[21:10] <hyperair> i can understand.
[21:10] <hyperair> but this bug is one hell of a frustrating bug, as i'm sure you know
[21:10] <hyperair> i'm pretty sure most of the intel gpu users around are facing the memory leak problem at the very least
[21:11] <hyperair> i don't really mind the hangs. i'm used to them, and they're infrequent enough. but the memory leaks really get on my nerves.
[21:11] <hyperair> because i end up staring at my unblinking hard disk light for ~5 minutes at a time
[21:12] <hyperair> and eventually my swap reaches 100%
[21:12] <bryce> well, this patch probably doesn't fix that
[21:12] <hyperair> ah. =(
[21:12] <hyperair> what does it fix then?
[21:13] <bryce> inadvertent use of unallocated memory
[21:13] <bryce> which they think may help solve hang problems
[21:13] <hyperair> that would be a segfault, wouldn't it
[21:13] <hyperair> i see
[21:14] <hyperair> that would be a help (but i'd really love to see a fix to the memory leak)
[21:15] <bryce> I'm going to be tied up at conferences the next 2 weeks, so won't really be working on any bugs myself
[21:16] <hyperair> i'd love to work on them, but i don't think i'd understand the code.
[21:16] <bryce> also I need to focus exclusively on DRI2/UXA/KMS stuff going forward
[21:16] <hyperair> this is UXA stuff.
[21:16] <bryce> well, understanding code isn't really necessary
[21:16] <hyperair> the memory leak happens on UXA. and pretty badly too.
[21:16] <bryce> it's mostly just patching and testing
[21:17] <hyperair> hmm?
[21:17] <hyperair> you need to understand the code to write patches, don't you?
[21:17] <hyperair> unless you're saying that this patch is already upstream.
[21:17] <bryce> sure, but for the most part the trick is to analyze it from different angles, communicate what you find to upstream, and let them write the patches
[21:18] <hyperair> hmm
[21:18] <hyperair> what angles can i analyze it from?
[21:18] <bryce> well, there's an established collection of tools for analyzing memory leaks
[21:19] <bryce> so you'd run those, capture their output during leak behavior, and show anything interesting to jbarnes
[21:19] <bryce> of course, it is also useful to build and test against upstream's git tree
[21:19] <bryce> just in case there is already a fix.
[21:20] <bryce> if that works, then it is a matter of doing a git-bisect search to find the patch
[21:20] <hyperair> hmm, right.
[21:21] <hyperair> i doubt i could keep X running in valgrind anyway.
[21:21] <bryce> it's not really hard.  It's a bit technical to learn the first time through.  Mostly it's just kind of time consuming
[21:23] <hyperair> technical how?
[21:23] <hyperair> the compiling bit, the git bit, or something else?
[21:24] <bryce> compiling
[21:24] <bryce> if you've not done it before
[21:25] <hyperair> i run enough compilations a day to feel the pinch when my system screws up my i/o.
[21:25] <hyperair> i.e. swapping like crazy
[21:26] <hyperair> i'd probably just script the copying of the packaging bits to the upstream bits and then run debuild -b or something similar.
[21:26] <bryce> yeah that should work
[21:27] <bryce> probably you'd want to disable most of the patches in the package in that case (comment out the lines in debian/patches/series)
[21:27] <hyperair> however, considering that the memory being consumed doesn't seem to appear to origin from any processes in particular, and that around 1G of RAM is said to be free (according to free -m, +/- buffer/cache line) when it begins shoving everything into swap and filling it up..
[21:27] <hyperair> i'd actually reckon a guess taht the memory leaking bits are actually kernel-space.
[21:27] <hyperair> stuff leaking memory that's actually in xserver-xorg-video-intel would show up as Xorg's memory, yes?
[21:28] <bryce> definitely a possibility.  -intel has moved a lot of memory management code into the kernel
[21:28] <hyperair> mmhm
[21:28]  * hyperair groans
[21:29] <hyperair> there have been two particular pieces of software i've avoided touching the source code of in the past: X, its drivers, and the kernel (and its drivers).
[21:29] <hyperair> frankly speaking, they terrify me, simply because they work on a level i don't understand.
[21:30] <bryce> there's an easy way to solve that ;-)
[21:30] <hyperair> O_o?
[21:31] <bryce> X is not deep magic that people think it is
[21:31] <bryce> neither is the kernel really
[21:31] <bryce> there's advanced algorithms and stuff in there, but that's nothing unique
[21:32] <bryce> a lot of the code is just register poking in hardware
[21:32] <hyperair> yeah, and that's probably the deep magic part =p
[21:33] <bryce> if you have the docs that explain what the various registers are, it isn't that deep of magic ;-)
[21:34] <bryce> anyway, most of the bits I usually have to fuss with to fix bugs is not that complicated of code
[21:34]  * bryce shrugs
[21:34] <hyperair> hahah i see.
[21:35] <hyperair> well the PM parts of the kernel certainly look like deep magic to me =p
[21:35] <hyperair> i've been messing around with uswsusp recently
[21:35] <hyperair> the usplash patch that got removed.
[21:35] <hyperair> just when i thought i fixed it, the 2.6.30rc5 kernel blew it up with a stacktrace.
[21:35] <hyperair> and i gave up.
[21:44] <bryce> oh, I didn't notice, the patch I mentioned before is a kernel patch
[21:45] <bryce> so I couldn't ppa it even if I wanted to ;-)
[21:45] <crevette> hey good evening (or day)
[21:45] <bryce> heya crevette
[21:45] <hyperair> bryce: you could talk to the kernel-team to dump it in the kernel-ppa
[21:45] <hyperair> well it's not really a ppa, it's a folder on kernel.ubuntu.com
[21:46] <crevette> I've a small question is UXA activated as the default for karmic now, I owuld like to know if I can remove my xorg.conf
[21:46] <bryce> hyperair: nah, not without getting someone to verify it does indeed solve it
[21:47] <hyperair> crevette: Try It And See™
[21:47] <crevette> (I prefer to remove xorg.conf to stick with default behavior)
[21:47] <crevette> hyperair: :)
[21:47] <bryce> crevette: not yet, maybe after UDS
[21:47] <hyperair> bryce: i could, if you're willing to compile. i'd like to think that my kernel compiling days are over.
[21:47] <crevette> hyperair: I don't even know how to check if UXA is on or not :)
[21:48] <hyperair> crevette: grep UXA /var/log/Xorg.0.log
[21:48] <bryce> hyperair: sorry I have my hands full just building X packages for people ;-)
[21:48] <hyperair> bryce: i can understand ;)
[21:48] <bryce> hyperair: also technically I'm supposed to be taking the weekend off ;-)
[21:48] <hyperair> bryce: do you have a link to that patch anyway?
[21:48] <bryce> yeah https://bugs.freedesktop.org/attachment.cgi?id=25806
[21:48] <hyperair> ah right, it's weekend. i forgot people don't work on weekends =p
[21:48] <hyperair> normal people, thati s
[21:49] <bryce> heh
[21:50] <Sarvatt> bryce: that patch is already upstream and in 2.6.30-rc6
[21:51] <hyperair> =O
[21:52]  * hyperair wonders when it'll enter the kernel-pap
[21:52] <Sarvatt> why bother putting it in a ppa when the full kernel will probably be out in the next day or two? 2.6.30-6-7 that is :D
[21:53] <bryce> Sarvatt: sounds good
[21:54] <bryce> Sarvatt: scary how many of these "X" bugs are fixed by kernel changes...
[21:54] <crevette> :)
[21:54] <Sarvatt> yeah not a good thing for jaunty..


[14:02] <nik90> hello hello :)
[14:02] <monmien> hi :)
[14:03] <timp> hello :)
[14:03] <popey> Hi
[14:05] <faenil> o/
[14:05] <alexabreu> hi
[14:05] <justCarakas> Hi
[14:06] <justCarakas> we can see you
[14:06] <justCarakas> QUESTION will  there be something included like react or angular to make it easier to create apps ?
[14:06] <alexabreu> justCarakas, you'll have  to wait a bit we talk about that in the presentation :)
[14:07] <justCarakas> ok nice :d
[14:07] <popey> uhm
[14:08] <popey> you guys in the wrong channel? :)
[14:08] <nik90> uhm wrong channel?
[14:08] <nik90> justCarakas, ^^
[14:08] <justCarakas> this is the channel under the video http://summit.ubuntu.com/uos-1605/meeting/22677/webapps-update/
[14:08] <nik90> justCarakas, you might want to inform the presenter that it is the wrong irc channel they are using
[14:09] <justCarakas> what channel should it be
[14:09] <nik90> justCarakas, I think #ubuntu-uos-core
[14:09] <justCarakas> no this is about webapps so not code
[14:09] <justCarakas> core
[14:10] <nik90> justCarakas, oh wait..its the webapps session that is scheduled for the next hour
[14:11] <cant_snail> where is Mark? :|
[14:11] <popey> mark's q&a is later
[14:11] <nik90> cant_snail, that plenary is scheduled for 18:00 UTC..4 hrs from now :)
[14:12] <nik90> QUESTION: Does the design team have the resources to handle weekly q&a / design sessions?
[14:12] <cant_snail> 4h, cant_wait
[14:12] <nik90> Personally, I think it is a great idea :)
[14:14] <justCarakas> +1
[14:16] <cant_snail> QUESTION: what software and OS do you use for designs?
[14:16] <nik90> popey, (comment), it would be nice to hold consistent sessions so that it becomes predictable. It can be twice a month or whatever frequency the design team can handle, but the important point being "regular/consistent"
[14:17] <nik90> popey, (comment), If there are no app submissions, then it would be nice to show tiny presentation of stuff they are working on.
[14:17] <justCarakas> Awesome react news
[14:17] <cant_snail> inkscape is great! sometimes i find illustrator harder to use
[14:19] <nik90> popey, (comment) once I get a blog post link, I can also announce it in the ubuntu-app-dev telegram channel
[14:19] <aquarius_> QUESTION: when talking about stuff you're working on, it's often really useful to hear *why* a certain decision was made, and which approaches were rejected -- we app devs can see what design decisions have been made, once they're released, but we often don't know the reasoning behind those decisions, or know that they're coming until they arrive. Is this something that you can use the sessions to speak abou
[14:19] <aquarius_> t, or is that stuff all secret?
[14:20] <aquarius_> would be lovely lovely lovely if more design team members could hang out in the telegram Ubuntu Apps channel for real-time conversation, too :)
[14:21] <popey> nik90: can you link to the telegram group here?
[14:21] <popey> telegram.me/ whatever
[14:21] <nik90> popey, https://telegram.me/ubuntuappdev
[14:21] <popey> thanks
[14:22] <nik90> faenil, yw :)
[14:22] <aquarius_> (I should note that faenil does an excellent job already, but more voices are always welcome :))
[14:22] <nik90> popey, yes, more admins would be great. At the moment there are only 2 admins.
[14:22] <faenil> aquarius_: awww :)
[14:23] <timp> nik90: it maybe a nice place to make UITK announcements too, usually just a link to a blog post
[14:23] <nik90> timp, I have started doing that as well.. Anything dev related is announced in that channel.
[14:23] <timp> nik90: okay, great :)
[14:23] <nik90> timp, I started just a month ago only.
[14:25] <nik90> popey, (comment) It would be super awesome to create a youtube playlist of these design sessions. App devs can quickly go through them and would help avoid duplicate questions in the future. An archive of these cool design sessions.
[14:26] <aquarius_> I don't think I'm suggesting that you publish everything instantly -- I understand the concern about putting misleading information out there! But once a decision is made, it's useful to know about the stuff you rejected too, because it's helpful to know which directions we *won't* be going in.
[14:26] <aquarius_> yes. Good call popey; that's exactly right.
[14:27] <miv0ligo> example: why notifications are white?
[14:27] <cant_snail> white? o_O
[14:28] <faenil> miv0ligo: at the same time, explaining and going through everything creates the risk of spending too much time preparing for those presentations :D then community goes "why is it white? I like it, I don't like it, that's bad, that's good"
[14:29] <faenil> I agree that it's nice to have headsup about what's changing in design, but preparing an explanation for every visual design change..doesn't scale :)
[14:29] <aquarius_> QUESTION: can some design resource be devoted to the developer experience? What it's like to develop apps, how the IDE looks, how easy and understandable the process is and how it can be improved?
[14:29] <aquarius_> That would be a great thing to go over in little bits as part of a number of design sessions, and it might help community people make small incremental improvements to the DX.
[14:30] <nik90> faenil, that is inevitable imo..that needs to be happen to ensure community and canonical designers are on the same page :) ..
[14:30] <nik90> faenil, and that might even help the community to defend these decisions when someone else questions them.
[14:30] <miv0ligo> faenil: but if you guys keep quiet, people will think all decisions are based on current mood of designers
[14:31] <bzoltan_> aquarius_: +1 :)
[14:31] <dbarth> hey, for webapps questions, can you re-paste questions so we can address them when we're done with the general pres.?
[14:31] <aquarius_> faenil, "preparing an explanation for every visual design change..doesn't scale" -- you have _already prepared_ those explanations; you must have had those discussions and decisions in order to arrive at a conclusion. It's a question of telling outsiders about them, not about making new ones up :)
[14:31] <dbarth> i know there's been a few while i was not on the chan
[14:33] <faenil> aquarius_: I'm not a designer so don't take my word for it, but I wouldn't be surprised if a designer told me that he changed something because he thought it looked better
[14:34] <aquarius_> that's a perfectly fine explanation
[14:34] <faenil> aquarius_: I mean, waht can you do? design is a very subjective matter. As long as you follow the style and the patterns, which they do
[14:34] <miv0ligo> QUESTION: does anyone from the design team use an Ubuntu phone as the only phone?
[14:34] <faenil> miv0ligo: me :)
[14:34] <aquarius_> but knowing whether something was changed because it just looks better, whether it was changed because it's part of a bigger upcoming set of changes that will make the whole platform look better, or it was changed because of something else is really useful
[14:35] <miv0ligo> faenil: good to hear :)
[14:35] <timp> faenil: which one?
[14:35] <aquarius_> I know I keep going on about this, but a set of brilliantly reasoned changes where we don't know the reasons are indistinguishable from a set of completely arbitrary changes which were made by dice rolls. :)
[14:35] <aquarius_> Thank you faenil, JamesJM, popey!
[14:35] <faenil> miv0ligo: been using it since it was released, krillin
[14:35] <nik90> popey, thanks for the sessions..looking forward to interacting more with the design team
[14:36] <miv0ligo> thanks guys!!
[14:36] <popey> \o/
[14:36] <timp> faenil: ah, I'm using the same. But I need it often for testing, so I'm considering to get another one
[14:36] <popey> Thanks for all the questions!
[14:36] <popey> I just ordered a Meizu pro 5
[14:36] <popey> No idea when it will turn up
[14:36] <miv0ligo> popey: gold?
[14:36] <timp> I like the size of the first BQ for a phone. I'm not a big fan of those huge ones to carry in my pocket
[14:37] <timp> if the meizu was smaller I would consider it
[14:38] <popey> miv0ligo: yes
[14:38] <miv0ligo> timp: same here, the size of e4.5 is perfect for me. Screen could be a bit bigger though
[14:40] <faenil> yeah, I don't like huge phones :/
[14:40] <faenil> always difficult to find 4-5" phones nowadays
[14:43] <miv0ligo> faenil: true, that's why some of my friends got iPhones although they prefer Androids
[14:50] <timp> miv0ligo: I was wondering how big the fairphone2 is
[14:51] <timp> and I'm not sure if/when we can run ubuntu on that
[14:51] <justCarakas> QUESTION when will we be able to use React for our apps ?
[14:51] <alexabreu> justCarakas, it is in alpha now, very very early alpha, it should be available in beta in the next few month and ideally released during the summer
[14:52] <alexabreu> justCarakas, we will do some posts on the ubuntu-phone mailing list
[14:52] <miv0ligo> timp: I've no idea. I guess popey have or had that phone ;)
[14:52] <justCarakas> ok then I'll wait for that for my new apps :)
[14:53] <popey> timp: mariogrip is porting to FP2
[14:53] <timp> popey: how big is it?
[14:54] <alexabreu> justCarakas, or we can get in touch before that to use your apps as test bed and test their support :)
[14:54] <popey> timp: no idea, I don't have one - join #ubuntu-touch and ask mariogrip :)
[14:54] <alexabreu> justCarakas, the more the better
[14:54] <timp> popey: okay, thanks
[14:54] <justCarakas> Im open for that alexabreu
[14:55] <alexabreu> justCarakas, you can join us on #ubuntu-webapps
[14:55] <alexabreu> justCarakas, do you have project pages up somewhere ?
[14:58] <aquarius_> am very confused; the webapps talk is finished? shouldn't it just be starting?
[14:59] <justCarakas> alexabeu not yet it will be an app for my phone provider, was going to start on friday but now I might wait a bit
[14:59] <dbarth> aquarius_: it just finished in fact
[14:59] <justCarakas> aquarius_: I think there was a timezone mistake
[15:00] <dbarth> aquarius_: there's a roadmap update you may want to look at:
[15:00] <dbarth> https://docs.google.com/presentation/d/1eECjnPmq2MSHYA8oggxdCMg7Gjg9c9fG22HpWxVNzUs/edit#slide=id.g7b91e8120_14
[15:00] <dbarth> slides here ^^
[15:00] <aquarius_> ah! ok. Oops. I'll read the roadmap and see if it answers my two questions :)
[15:00] <dbarth> it's all about snaps!
[15:00] <aquarius_> dbarth, document is restricted, not public
[15:00] <dbarth> and then there's a pretty cool reactnative alpha port that justinmcp is releasing
[15:00] <dbarth> aquarius_: ah, let me correct that
[15:01] <aquarius_> react native will be cool
[15:01] <dbarth> there you go
[15:01] <dbarth> aquarius_: it's getting there
[15:02] <dbarth> you get 2048, tictactoe and the movie explorer example
[15:02] <aquarius_> my two questions are: will we be able to add to homescreen from the browser and have that create a "webapp", and how close are we to supporting progressive web apps as Chrome/Opera/Edge/Firefox do?
[15:02] <dbarth> ie, you can start w/reactjs a webviews, and once ready to optimize for native, you can port quickly to react native, knowing there is an ubuntu port
[15:02] <dbarth> aquarius_: installable webapps is the 1st answer, and yes that's getting closer
[15:03] <dbarth> i think snappy is making that a lot more likely to happen
[15:03] <dbarth> if that makes sense
[15:04] <aquarius_> hrm. what's an "installable webapp"? the document suggests that it's a click/snap installed from the app store, which is not what I'm talking about
[15:04] <dbarth> progressive webapps i'm not sure, but i guess that's a step in the same direction
[15:04] <aquarius_> perhaps I have misunderstood!
[15:04] <dbarth> still reading on what that takes technically
[15:04] <aquarius_> the idea behind PWA is exactly that you don't need to make a separate downloadable distribution package of anything
[15:05] <dbarth> aquarius_: it's not a click/snap, it's a tab/url; but the snap interface would make that a lot more direct and native than having to support a new app type
[15:05] <aquarius_> it's the actual web; it's not just web technologies being used inside a packaged up app
[15:05] <aquarius_> OK. I'll try to find some time to review the session
[15:05] <dbarth> we're saying the same thing
[15:08] <dbarth> ie, PWA or what i understand it is about turns tabs into top-level app windows, with a launcher, right?
[15:08] <dbarth> that's what i feel our container turned into a snappy interface can provide
[15:14] <aquarius_> dbarth, cool. I think I'm thinking of this as a browser thing -- the browser offers UI to turn this site into a thing which appears in my app list, and possibly only shows that UI if the app meets certain criteria -- so I don't really mind _how_ it's implemented (whether it makes a snap and installs it, or what)
[15:40] <fruity> hello
[15:50] <fruity> hello charles
[15:55] <aquarius_> it's the popular exciting Callé scopes design showoff session :-)
[15:56] <sbt> :D
[15:56] <davidcalle> marcustomlinson: pstolowski https://plus.google.com/hangouts/_/hoaevent/AP36tYeC30Zp15qUEeHTp2ZAzZCAhdhCKIeGNMfQG1JhqenGyux7Jw
[15:56] <aquarius_> davidcalle, the scopes design thing is now, right? your G+ post says it's 1800UTC
[15:57] <davidcalle> aquarius_: it is!
[15:58] <nealmcb> are the slides for this presentation available somewhere?  put it in tht topic??
[16:00] <davidcalle> nealmcb: will ask during the presentation
[16:01] <davidcalle> We'll start in a few sec
[16:03] <davidcalle> Make sure you prefix your questions with QUESTION
[16:05] <sbt> Mac OS :D
[16:09] <ChloeWolfieGirl> Filters look awesome :D
[16:11] <miv0ligo> QUESTION: when on my phone????!!!!
[16:11] <ChloeWolfieGirl> QUESTION: Can you still scroll left to right through scopes on the phone or have to use the bottom edge to move between scopes?
[16:11] <sbt> QUESTION: After JavaScript scopes, what about python scopes?
[16:11] <ChloeWolfieGirl> OOOOOOH That score looks amazing <3
[16:12] <ChloeWolfieGirl> *Store
[16:14] <ChloeWolfieGirl> These new scopes and these new looks look amazing AF.
[16:15] <kalikiana> +1
[16:15] <ChloeWolfieGirl> <3 theres a considerable amount
[16:16] <ChloeWolfieGirl> QUESTION: With the new scopes has there been thoughts for themes or background images, so people don't have to see white if they'd rather see a darker colour maybe because its late, or to make there phone more there own?
[16:17] <sbt> +1
[16:18] <ChloeWolfieGirl> <3
[16:19] <DS-McGuire> QUESTION: ETA of these scopes?
[16:21] <sbt> +1 for cards in UUITK
[16:23] <dobey> someone's child seems to have a question
[16:23] <marcustomlinson> :P
[16:23] <davidcalle> dobey: :)
[16:23] <ChloeWolfieGirl> @dobey haha
[16:24] <faenil> miv0ligo: I'll be doing the scopes card component, if everything goes as planned :)
[16:24] <davidcalle> (He is already complaining about the new design)
[16:24] <pamarsan> I have one question: how about implementing an optional dark theme? It is much more comfortable for the eye to read everything, above all at night. Thanks! :)
[16:24] <CHeeseburg> Was the link put up already?
[16:24] <micah68> QUESTION: Has there been any thinking about discrete "pages" of content rather than continuous scroll? For apps I believe that this is what customers expect and is easier to get where you want by muscle memory.
[16:25] <miv0ligo> faenil: I'm dancing in my head now :)
[16:25] <faenil> miv0ligo: haha, I hope that's a positive sign :)
[16:26] <redboxez> QUESTION: why are so many tech sites confused about scopes?
[16:26] <miv0ligo> faenil: it is for sure :D
[16:28] <redboxez> QUESTION: what are your favorite scopes and why?
[16:28] <tedg> Clearly no one should use OSX, it has issues :-)
[16:30] <pstolowski> tedg, i think she is not, her laptop got stolen some time ago and she switched to ubuntu
[16:30] <miv0ligo> QUESTION: why you don't use Ubuntu at least for this presentation? It makes me sad :(
[16:30] <dobey> davidcalle, dizzypaty: not pagination exactly, but presention as pages like android/ios apps grid
[16:30] <sbt> QUESTION: does the design team use ubuntu in ther workflow at all ;)
[16:30] <tedg> pstolowski: I thought when she minimized the browser it was OSX
[16:30] <redboxez> QUESTION: what should be a scope and what should be an app? what is the advantages of making a scope instead of an app
[16:30] <davidcalle> Sorry for the happy mess :)
[16:30] <pstolowski> tedg, oh, didn't notice, maybe she got a new one then
[16:30] <dobey> lol no sound
[16:32] <davidcalle> Aaand we are back
[16:32] <tedg> pstolowski: https://youtu.be/flOYkk-4zvQ?t=20m57s
[16:32] <CHeeseburg> Next UOS there should be test presentation on hangouts with all presenters to make sure all this sound issues are sorted out
[16:32] <dobey> pstolowski: pagination doesn't solve the apps grid problem either
[16:33] <dobey> the main issue is people want to arrange their apps in a way that most suits their usage, and they want to see their wallpaper behind the apps grid
[16:33] <dobey> like ios/android
[16:34] <kazord> hi everyone
[16:34] <tedg> dobey: For the record, I want neither of those :-)
[16:34] <dobey> CHeeseburg: there's really no testing that sound works with hangouts. it might work one second and not the next
[16:34] <dobey> tedg: you aren't people :)
[16:34] <pamarsan> QUESTION: how about implementing an optional dark theme for scopes? Like Music App (much more comfortable for the eye, above all at night)
[16:35] <kazord> hangouts need some seconds to find a good way, after connected i had bad sound for like 20s then good
[16:36] <dobey> i think the problem here is that someone's laptop doesn't have properly working mic or something, and three people in the same glass room makes it confusing when the wrong person mutes
[16:37] <dobey> marcustomlinson: as long as the only thing you're doing, is consuming and displaying data, anyway
[16:37] <marcustomlinson> dobey: sure, which is a very common situation in app development
[16:37] <pstolowski> right. many interactions -> better make an app
[16:38] <dobey> right, but a lot of people start out with scopes, and then they want to add more and more interactions
[16:38] <kazord> when stop interaction ?
[16:38] <dobey> nobody likes the store scope? :(
[16:39] <kazord> for exemple: i'm app developper and made rssreaderscope, not really easy to had rss feed, but it really need this feature
[16:39] <d0od> I get the impression no-one actually uses scopes... lol :P
[16:39] <kazord> if you dont want to go though webservice for that (like tt-rss)
[16:40] <sbt> QUESTION: Do you use Ubuntu phones as your daily drivers?
[16:40] <kazord> MX4
[16:40] <miv0ligo> d0od: maybe not no-one but ...
[16:41] <dobey> everyone uses the apps scope
[16:41] <kazord> app luncher for me ...
[16:41] <kazord> (side shortcut)
[16:42] <dobey> you can't pin apps until you open them from apps scope though; unless you only ever use the default pinned apps
[16:42] <kazord> yeah, one a while, for store too
[16:42] <miv0ligo> ok ok, we believe you ;)
[16:43] <kazord> QUESTION:plans for more widget ? like list selection ?
[16:44] <sbt> QUESTION (I asked above, but it was skipped): What about a python scopes api?
[16:44] <sbt> ok :) I almost guessed
[16:44] <miv0ligo> need to go, thanks for great session and awesome new designs guys and gals o/
[16:45] <sbt> Python is not just a language either :P But yeah sure ;)
[16:45] <dobey> kazord: if you need that much, you should probably write an app
[16:45] <user20> QUESTION: In the past it was possible to show the twitter trends in the today scope. Any plans to bring this feature back?
[16:46] <pstolowski> i need to leave and drop from the HO
[16:46] <kazord> dobey: an app for configuration the scope ?
[16:46] <davidcalle> Thanks pstolowski !
[16:46] <dobey> kazord: yes
[16:47] <kazord> dobey can i call the app from scope ? (needed for my scope rssreaderscope)
[16:48] <dobey> kazord: you can register your app as a url handler for rssreaderscope:// and have an action which opens such a url, and it should open the app, yes
[16:49] <kazord> any doc/tutos about that somewhere ? :)
[16:49] <dobey> i'm not sure
[16:49] <marcustomlinson> https://bugs.launchpad.net/today-scope
[16:49] <user20> thanks
[16:50] <dizzypaty> https://docs.google.com/presentation/d/1V-oHHYj-I-tZAWpdbKbkmngyyqENsNAe0g74Ubh2v6I/edit#slide=id.ge741bf13b_2_215
[16:50] <marcustomlinson> user20: seems odd that it went missing
[16:51] <faenil> dizzypaty: it's not public
[16:51] <ChloeWolfieGirl> QUESTION: will the new scope things like, removing of faves, the new bottom edge, be something thats easy to get used to those who are used to using todays scopes intergration? IS there still swiping left to right with scopes you want to keep open and have them all open from boot? My set up is I have the today scope then picture scope then app scop
[16:51] <ChloeWolfieGirl> e, I wouldn't go to the picture scope if I didn't have to reach the app scope, I have it there to see updates of images, its just nice, like stopping to smell the flowers on your way to work, will I have o activly go out to see the image scope so I'm less likely to use it or will it be the same as the current scope version?
[16:52] <davidcalle> dizzypaty: can you make the presentation public? thanks :)
[16:52] <kazord> QUESTIONS: about scope nav, why you didn't make dot clickable (to navigate faster to specific scope)
[16:52] <redboxez> .kick udsbotu
[16:53] <redboxez> .slap udsbotu
[16:53] <dobey> redboxez: stop being rude
[16:54] <redboxez> it's just a bot..
[16:54] <redboxez> doesn't have feelings
[16:55] <dobey> it's just a bot, so there's no need for you to attack it and cause a distraction in the channel
[16:55] <redboxez> ok
[16:55] <marcustomlinson> kazord: There won't be dots any more with the browser style appearance: http://i.imgur.com/oHBvNQu.png
[16:55] <kazord> yeah no more, i'm sad about that
[16:56] <kazord> always wanted to touch&move from dotline to go faster to the end
[16:56] <marcustomlinson> kazord: I think it's a fair middleground
[16:56] <redboxez> bye and thanks for your time
[16:56] <marcustomlinson> you swipe up then tap the bottom scope
[16:57] <dobey> marcustomlinson: that's only favorited scopes, or all "installed" scopes?
[16:57] <marcustomlinson> dobey: right same situation as dots
[16:57] <dobey> ok, that's good
[16:57] <kazord> swipe&tap vs swipe (on specific zone) not really the same, but in term of dev and UI new design should see less lags
[16:58] <dobey> kazord: old swipe was really not nice if you had more than 2-3 scopes
[16:58] <kazord> dobey, i now :) cause to laggy to move 1 to 8th
[16:58] <kazord> but if only we could touch & move from dot1 to dot8
[16:59] <kazord> before UI move
[16:59] <kazord> could had been a nice feature (too late now as UI change)
[16:59] <dobey> the dots are too small a target
[16:59] <marcustomlinson> kazord: design is really a tricky thing. I guess there will always be some people for and against certain aspects
[17:00] <kazord> small to click yes
[17:01] <kazord> but to drag for exemple
[17:01] <marcustomlinson> I think the guys have come up with a cool solution considering how difficult their job is
[17:01] <kazord> marcustomlinson, agree, in term of dev & ui animation, should be good
[17:01] <kazord> i'm just 1year too late :)
[17:02] <marcustomlinson> ;)
[17:03] <dobey> kazord: seems like you'd need a long press to zoom, and then a tap or a drag/release, to do what you're describing. so not any faster than a swipe and tap really :)
[17:03] <kazord> dobey, imagine that dotbar is touchable zone, when you press, it record position, if u move left/right, it change scope
[17:03] <dobey> also the tabs will probably work better for kb/mouse interaction
[17:03] <kazord> until you move enough to release
[17:04] <dobey> kazord: but then you still have the same problem as just swiping left/right in the main view
[17:04] <kazord> and any icon/indicaiton on top of the bar can help you to stop on scope you wanted
[17:05] <dobey> also easy to run out of left/right movement in that case, if you have many scopes favorited
[17:06] <dobey> anyway, session over; gotta do real work for a while now :)
[17:06] <kazord> left -> position divided in scope number on left, position -> right divied in
[17:06] <kazord> is scope source code somewhere ?
[17:06] <dobey> unity8 is yes
[17:07] <dobey> ubuntu is open source, the code is in the archives, and projects hosted on launchpad
[17:08] <kazord> yeah but sometimes hard to find an app inside a full project
[17:09] <kazord> (like scope inside unity8)
[17:09] <kazord> i will search this dotline :)
[17:11] <dobey> cheers :)


[15:28] <h00k> oi
[15:33] <h00k> I was all "Hey, Unity isn't showing the bar!" and then I remembered I put Maverick back on this guy.
[17:48] <h00k> Anyone have experience with embedded linux hardware like a sheevaplug or beagleboard?
[17:48] <h00k> I hear the SheevaPlug has heat issues
[18:03] <h00k> Someone in identica just recommended a FOX board, this looks pretty coool


[05:14] <Ionic> hi
[05:14] <Ionic> stupid question: how do I get the build logs for packages built on launchpaid?
[05:14] <Ionic> s/paid/pad/
[05:16] <Ionic> hm, maybe via the "built" link in a package detail view
[05:16] <Ionic> ah, indeed, there's a buildlog
[10:11] <rbasak> pitti: in bug 1347859, there's a claim that systemd is doing things to do with biosdevname in addition to the biosdevname package on some distributions. Do you know if this is accurate for Ubuntu?
[10:18] <rbasak> cjwatson: looking at ^^ bug. Am I right in understanding that the intention was to never introduce biosdevname interface renaming on distribution upgrades? The reporter seems to claim it happened, but I see no relevant code that was cause it to happen. Presumably he shouldn't have had biosdevname installed before the upgrade and not after either, as the only thing that installs it is the installer?
[10:19] <mantas-baltix> hi devs ;)
[11:11] <tseliot> Riddell: so, I've filed LP: #1443364 , which only affects hybrid graphics and systemd. All users should be affected, regardless of the desktop environment. I wrote about a manual workaround in LP: #1428328
[11:13] <Riddell> bug 1443364
[11:47] <ogra_> pitti, poke ...
[11:54] <mantas-baltix> Hi, I stuck on important issue with building packages from recipe - can't build package imported from GIT - bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository
[11:54] <mantas-baltix> This issue exists for few months and other people also are affected, see https://answers.launchpad.net/launchpad/+question/264781
[11:54] <mantas-baltix> and bug #1433680
[12:04] <mantas-baltix> bug is reported a month ago, 2 answers are asked, what should I do?
[13:14] <cjwatson> rbasak: I haven't looked at the details, but I don't *think* we meant to introduce this on upgrades
[13:17] <rbasak> cjwatson: thanks. I don't see how we might have introduced it on upgrades either, but I might have missed something.
[13:18] <pitti> Good morning!
[13:18] <pitti> rbasak: in Debian/Ubuntu we disable the predictable interface names (similar, but not identical to biosdevname) by default; you can enable them wit net.ifnames=1
[13:19] <rbasak> pitti: OK. Thanks!
[13:19] <rbasak> I'll write an initial response in the bug.
[13:20] <pitti> rbasak: I'll have a look at the bug and follow up there
[13:21] <pitti> ogra_: hey
[13:22] <ogra_> pitti, so i just wasted half my day waiting for a one line fix in initrd to migrate from -proposed ... what is the reason we do two fill kernel builds as part of the migration test ?
[13:22] <ogra_> initramfs-tools shouldnt have anything to do with kernel builds ...
[13:23] <ogra_> pitti, also, while watching that, i was looking at the boot test on krillin ... it doesnt seem like we ever actually boot the initrd that gets produced by the package ... what are we testing there ?
[13:24] <pitti> ogra_: ah, in urgent cases you can certainly ask the RT to push that through faster
[13:24] <pitti> ogra_: apparently initramfs-tools depends on kernel packages, we do reverse dep testing
[13:24] <ogra_> pitti, by doin a complet binary build of the dep ?
[13:24] <ogra_> that seems the wrong way round
[13:25] <pitti> ogra_: ah yes, that certainly isn't necessary for initramfs-tools uploads
[13:25] <ogra_> right ... do we have some kind of overrdie file that we could add this to ?
[13:25] <pitti> ogra_: we added that mostly for the purpose of testing gcc, binutils, glibc uploads
[13:26] <pitti> ogra_: not right now; we can add a "reason why this test is running" once we have non-retarded infrastructure to run these tests, and indeed the linux triggers come up every other week
[13:26] <pitti> but not with our current CI system, I'm afraid :(
[13:26] <ogra_> :(
[13:26] <ogra_> ok
[13:26] <ogra_> pitti, what about the boot tests ... what do they actually test ?
[13:27] <pitti> ogra_: these are vila's; I think they mostly just instsall the proposed package on a touch image and see that it still boots and ends up in unity
[13:27] <ogra_> i dont see anything replace the initrd on the device (and it wouldnt be possible on krillin without a complete device tarball build)
[13:27] <pitti> (I don't know what exactly they do, I'm afraid)
[13:27] <ogra_> ah
[13:27] <ogra_> so for initramfs-tools that would be pointelss as well
[13:28] <ogra_> (at leats on phones)
[13:34] <pitti> ogra_: I thought boot tests are triggered by packages which are installed on touch; is it?
[13:34] <pitti> ogra_: but perhaps CI has a blacklist for such cases
[13:35] <ogra_> yeah, that would be nice
[13:35] <ogra_> currently that test (in case of initramfs-tools) is just uselessly wasting time
[13:40] <pitti> rbasak: oh, that bug is old, and not systemd specific; so it's rathe specific to ubuntu server which has installed biosdevname for a while?
[13:43] <rbasak> pitti: looking back (I've linked from the bug), all our alternate installers have been installing biosdevname for a while.
[14:16] <pitti> tseliot: the u-d-c fix was just accepted by the RT team FYI
[14:16] <tseliot> pitti: great. Thanks again!
[14:16] <tseliot> Riddell: the fix for the hybrid graphics issue ^
[14:40] <pitti> smoser, infinity: all the wolfe VMs seem to be AWOL; do you have a minute to have a look?
[14:42] <fionnan> Anyone getting `ERROR: Could not generate AppArmor profile for docker_docker_<IP_ADDRESS>.json...` when installing docker on a fresh snappy instance?  Traceback here: http://pastebin.com/ChQmLUmq
[14:51] <seb128> pitti, I don't remember now, did you see/reply to my ping about langpack updates in vivid?
[14:51] <pitti> seb128: I don't think so
[14:52] <pitti> seb128: but anyway, they should be fine again now; we just got a new export from LP
[14:52] <pitti> seb128: so the next cron run (Tue morning CET) ought to work
[14:52] <seb128> pitti, Colin said on friday you need to trigger an export
[14:52] <pitti> seb128: it's on my radar
[14:52] <seb128> oh ok
[14:52] <seb128> great
[14:52] <seb128> thanks
[15:19] <flexiondotorg> ricotz, Do the new versions of Plank/Docky have the zoom animation when you hover/move over the dock?
[15:34] <ricotz> flexiondotorg, hi, no ( btw there is #plank )
[15:38]  * flexiondotorg joins #plank
[18:49] <elopio> cyphermox: when you have some time, can you please take a look at https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1441893 ?
[19:07] <caribou> Laney: I have just rechecked Bug #1442235 regarding InDep depencancies
[19:07] <Laney> caribou: It's uploaded
[19:08] <caribou> Laney: oh, great. I reran the tests only to find out that I was overriding build_arch_all in my .rc file
[19:08] <caribou> Laney: thanks a lot !
[19:10] <Laney> caribou: It's a difference in which rules targets are called between precise & trusty - search for "debian/rules" in the build logs to see
[19:10] <Laney> no problem!


[00:14] <phillw> pleia2: have you got the links from the meetingbot in #ubuntu-quality-chat ?
[00:23] <pleia2> phillw: yes, those are the ones I used in the post
[19:21] <phillw> hi Noskcaj :)
[19:21] <Noskcaj> hello phillw
[23:07] <philwyett> Hi. Tested the 12.04.2 ISO (alternate) today. The LTS quantal kernel is being installed, but ot the xorg, mesa etc. packages as part of the stack. Is this known? A work in progres?
[23:07] <philwyett> s/ot/not


[07:33] <pitti> xnox: hmm, systemd's new "root-unittest" fails on armhf in test-copy; it works on s390x in lxc, so I wonder if that's an artifact of lxd or an actual bug on armhf; perhaps you can have a quick look what's going wrong, otherwise I'm happy enough to blacklist the test on armhf or lxd (whichever is right) for now
[09:14] <cpaelzer> pitti: hi, I see in the autopkgtest history of systemd that the "storage" test failed rather often on ppc64el
[09:15] <cpaelzer> pitti: I' currently ran into the same as well, since it failed/worked so often without any visible difference - are these just "retried until passing"
[09:15] <cpaelzer> pitti: or is there some background to learn?
[09:15] <cpaelzer> FYI - issues like in<EMAIL_ADDRESS>[09:16] <pitti> cpaelzer: indeed, "reload ioctl on temporary-cryptsetup-5254 failed" -- that ioctl seems to be unreliable in cryptsetup somehow
[09:16] <pitti> that should be easy enough to reproduce outside the systemd test suite too, for a kernel bug report
[09:17] <pitti> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/tests/storage#n74 is the cryptsetup luksFormat call
[09:17] <cpaelzer> pitti: ok, so in proposed retrying til pass and in a test env trying to debug and understand
[09:17] <cpaelzer> pitti: thanks
[09:18] <cpaelzer> depending which of both is faster the debugging might resolve the retrying :-)
[09:18] <pitti> the test uses scsi_debug as a drive, I suggest to try with both that and a simple loop device to see whether that makes a difference
[09:18] <cpaelzer> thank you, I will do so
[09:19] <pitti> cpaelzer: y and x seem fine, so might be a regression of linux 4.11?
[09:20] <pitti> actually it started failing with trigger linux-meta/<IP_ADDRESS>.10
[09:20] <pitti><EMAIL_ADDRESS>was the last successful one, with autopkgtest [01:48:28]: testbed running kernel: Linux 4.9.0-15-generic #16-Ubuntu SMP Fri Jan 20 15:28:49 UTC 2017
[09:20] <cpaelzer> yeah I see that this was the "date" it started
[09:20] <pitti> i. e. 4.9 → 4.10
[09:20] <cpaelzer> former fails had other errors
[09:21] <pitti> so apparently 4.10 got promoted with ignoring that regression :(
[09:22] <cpaelzer> smb: ^^ did you hear (or could you ask around in the kernel team) anything about this?
[09:23] <smb> cpaelzer, a) no b) might do
[09:24] <cpaelzer> smb: ok, once (if) I have found a bit more debug data I'll show up in the kernel Teams chan as well then
[10:30] <bdrung_work> hi, since a recent ubuntu 16.10 package update, the mod4 keyboard layer does not work any more for numbers. e.g. when i press mod4+j, it should result in number 4, but the mouse moves instead. do you have any hint at which package i should look at for this behaviour?
[10:30] <bdrung_work> mod4 works correctly on the lightdm
[10:31] <xnox> pitti, we have started to whitelist systemd/armhf failures which are only seen during adt tests but not during package build time
[10:31] <bdrung_work> (i am using the german neo2 layout)
[10:32] <xnox> pitti, i have not debugged it yet, and my wild guess that it has something to do with the fact that we run those on arm64 hardware
[10:32] <xnox> (arm64 kernel)
[10:33] <pitti> xnox: more interestingly, we run the unittests as root during that autopkgtest but as user during package build, so they skip a lot of stuff
[10:37] <pitti> xnox: armhf buildds are the same: armhf chroots on the exact same kind of arm64 cloud instances
[10:38] <xnox> pitti, aha, so that test has never run (on builders); and always failed (during adt); hence steve considered it as a non-regression
[10:38] <pitti> right, that's plausible
[10:38] <xnox> so it can be treated as "you shall never pass" unit test. Should be digged into why not, though.
[10:38] <pitti> but would still be interesting to see what fails, to make sure it's just an lxd limitation and not an actual bug somewhere
[10:39] <xnox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1670313
[10:52] <cpaelzer> pitti: for the systemd ppc test error after some debugging I can confirm a kernel bug which I reported in bug 1670311
[10:54] <pitti> cpaelzer: nice work!
[11:16] <cpaelzer> tyhicks: FYI bug 1670311 also blocks your latest apparmor in zesty-proposed
[13:41] <coreycb> rbasak, hi, I responded to bug 1645772
[13:47] <rbasak> coreycb: you still haven't reported the package versions you tested?
[13:48] <rbasak> coreycb: doing it automatically is fine, but surely that automation provides that information in its output?
[13:49] <rbasak> "If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested..."
[13:49] <coreycb> rbasak, thanks i've tested sru's before :) i'll add the versions tested.
[13:50] <rbasak> coreycb: thanks. I'm not asking just for the sake of it. I have been involved in at least one severe stable release regression in the past when the package version tested wasn't the one released. I don't want to be responsible for causing that kind of thing.
[13:50] <rbasak> coreycb: and I figure that our process is good enough to detect that, if only we all followed the process. So I insist on it.
[13:53] <coreycb> rbasak, ok i've added the versions tested
[13:53] <rbasak> Thanks I'll take a look.
[13:54] <coreycb> rbasak, thanks
[14:11] <rbasak> coreycb: there are some autopkgtest failures in pending-sru on s390x - please could you check? http://autopkgtest.ubuntu.com/packages/n/neutron/yakkety/s390x
[14:11] <rbasak> Only for neutron.
[14:12] <coreycb> rbasak, sure
[14:18] <rbasak> coreycb: I'm happy to release the others now if you would like.
[14:18] <rbasak> (or I can wait until you've checked/fixed neutron)
[14:18] <coreycb> rbasak, sure that'd be fine.  I'll let you know when neutron is fixed.
[14:18] <rbasak> OK
[14:20] <rbasak> Done
[14:23] <coreycb> rbasak, thanks.  if i upload a new version of neutron with a dep8 test fix, should i use a new bug # or use the sru bug #?
[14:26] <rbasak> coreycb: no need for a bug and paperwork for a dep8 fix. So don't refer to a bug at all in your new changelog message (unless there is one already). But do use -v when uploading the replacement, so that the new upload still lists the previous bug as fixed.
[14:27] <rbasak> coreycb: so I think you'll be uploading a  2:9.1.1-0ubuntu2, source built with -v2:9.0.0-0ubuntu<IP_ADDRESS>, with one changelog entry added over  2:9.1.1-0ubuntu1 and no new bug references. Does that make sense?
[14:30] <coreycb> rbasak, ok yes that makes sense. thanks.
[15:44] <tyhicks> cpaelzer: thanks for the headsup on that bug
[15:46] <xnox> rbasak, coreycb: is this not one more ordering bug of the units; where incorrect dependency/ordering is specified, and things do come up if one simply waits?
[15:47] <xnox> but we have also been fixing the tests to come up the right way around.
[15:47] <xnox> (in other openstack components)
[15:52] <cpaelzer> tyhicks: yw
[15:52] <cpaelzer> tyhicks: I see you have other  blockers as well still
[15:52] <cpaelzer> tyhicks: but at least one less to debug
[15:53] <cpaelzer> tyhicks: fyi the fix is enqueued for the next kernel upload already
[15:54] <tyhicks> cool, that is helpful
[17:09] <smoser> Laney, you tyhere?
[17:09] <Laney> hey smoser
[17:09] <Laney> for you, always!
[17:10] <smoser> your changtes are good.
[17:11] <smoser> https://code.launchpad.net/~smoser/software-properties/trunk.lp1670399/
[17:11] <smoser> i just did those same changes
[17:11] <smoser> https://code.launchpad.net/~smoser/software-properties/trunk.lp1670399/+merge/319105
[17:11] <smoser> but showed a bit more context. and i like my changesn to run-tests better .
[17:11] <smoser> but lets get this fixed.
[17:12] <Laney> smoser: ok, as you prefer
[17:12] <Laney> MP mail sucks, eh?
[17:14] <smoser> just slow.
[17:14] <smoser> i didnt see yours
[17:15] <Laney> bit of a shame that we both spent time debugging it, but eh
[17:15] <Laney> you go ahead
[17:16] <smoser> yeah
[17:16] <smoser> i open3d a bug.
[17:16] <smoser> did you see that/
[17:16] <Laney> nope
[17:16] <Laney> I don't think it existed on Thursday when I submitted the patch
[17:16] <smoser> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1670399
[17:17] <smoser> sorry. slow. i wish i'd seen your mp
[17:17] <Laney> s'ok
[17:17] <caribou> would someone have time to have a look at a small config change to the tftpd-hpa package I'm preparing ? http://paste.ubuntu.com/24125880/
[17:17] <caribou> I haven't done much manging with upgrades of config params
[17:18] <caribou> s/manging/mangling/
[17:19] <caribou> I stripped the modification of the i18n .po files out of the debdiff btw
[17:20] <smoser> Laney, http://paste.ubuntu.com/24125897/
[17:20] <smoser> look goood ?
[17:20] <Laney> smoser: sure, but spell my name right please :P
[17:20] <smoser> no deal
[17:20] <smoser> doh!
[17:23] <smoser> Laney, uploaded. thanks.
[17:23] <seb128> smoser, "This (lp...)"?
[17:23] <seb128> was that missing some text?
[17:23] <seb128> oh well, if it's uploaded
[17:25] <coreycb> rbasak, zul has a new version of neutron in the review queue for yakkety, so if you don't mind rejecting that, i'll upload it again with the dep8 fix.
[17:25] <Laney> yeah it said "fixes a testsuite failure."
[17:25] <Laney> oh well
[17:25] <smoser> seb128, yeah. :-(
[17:25] <smoser> fail smoser
[17:26] <coreycb> xnox, rbasak: i think we need to use needs-recommends in debian/tests/control to ensure neutron-plugin-ml2 is installed.
[17:26] <smoser> i noticed that too
[17:26] <smoser> after dput
[17:30] <rbasak> ddebs missing for some packages on Trusty. IIRC this is a known thing? I have a bug report about it, not sure what to tell the reporter.
[17:30] <rbasak> bug 1668299
[17:31] <rbasak> Ah, I found 1465777
[17:31] <rbasak> bug 1465777
[18:11] <nacc> sarnold: is LP: #1582990 still an issue for you?
[18:12] <sarnold> nacc: good question
[18:12] <sarnold> nacc: yes
[18:13] <nacc> sarnold: ok, thanks -- the debian report seems for an older version, so just wanted to double-check
[19:09] <cpaelzer> nacc: are you working on the bug you asked sarnold about?
[19:09] <cpaelzer> nacc: or were you only cleaning up and I shall put it on my list?
[19:10] <nacc> cpaelzer: was only asking
[19:10] <nacc> cpaelzer: triage duty
[19:10] <nacc> cpaelzer: i figured i'd ping you about it at somep oint
[19:18] <cpaelzer> nacc: ok, I put it on my list
[19:18] <nacc> cpaelzer: thanks!
[19:34] <stryderc> anybody here able to point me on the path to discerning the logic behind the Dash type down filtering?
[19:41] <rharper> jgrimm: slangasek:  In attempting to verify resolvconf for yakkety; ran into an issue; I've updated the comments, looking for agreement on how to resolve; https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1649931
[20:02] <slangasek> rharper: isn't systemd-resolved entirely an optimization of the DNS config?  Before systemd-resolved comes up, any DNS servers received should just be added to /etc/resolv.conf directly, and DNS resolution should proceed normally
[20:02] <slangasek> systemd-resolved integrates with resolvconf, it doesn't supplant it
[20:03] <rharper> slangasek: I don't know for certain; let me read a bit more
[20:04] <slangasek> rharper: ok.  As far as I'm concerned systemd-resolved should not have to be running before network-online.target
[20:04] <slangasek> i.e. it's not a requirement for DNS resolution - but we might choose to enforce this to work around some issue somewhere
[20:12] <rharper> slangasek: going to confirm but my understanding for yak/zesty is that resolvconf is hook only;  it runs under ifupdown hook, and dhclient (which is for networking/ifupdown services);  in a networkd space, those (ifupdown) hooks don't matter; and systemd-resolved is decorated with pre/post execs to point to systemd-resolved caching namesever (<IP_ADDRESS>);
[20:13] <rharper> we'll have nothing in /etc/resolv.conf prior to systemd-networkd coming up; and if that includes DNS settings, I believe those should be applied via having systemd-resolved unit run before we get to network-online.target;
[20:14] <slangasek> rharper: ah.  that's an unfortunate outcome of the lack of support for hooks, yes
[20:14] <slangasek> rharper: in that case, +1 for changing the ordering constraints on systemd-resolved, though I would argue it shouldn't need to hold up the resolvconf change
[20:15] <rharper> slangasek: agreed;  it's been a bit sticky to separate the networking/ifupdown path vs. systemd path since we don't have a non-ifupdown path by default
[20:16] <rharper> the verification has been a matrix of xenial, yakkety * ifupdown/networking,networkd
[20:16] <rharper>  * the two packages involved (systemd and resolvconf)
[20:16] <rharper> and forgetting all of those parts from time to time
[20:17]  * slangasek nods
[20:58] <nacc> slangasek: Just to confirm, I need a FFe for the fix for LP: #1668940, where we are not b-d on a library that provides the headers needed to build the .so in question -- even though we ship a manpage documenting the feature? That is, it's a feature introduction in practice?
[21:08] <slangasek> nacc: yeah, I would say that should get a look-sie for an FFe
[21:16] <smoser> hey. in zesty, the libc6-x32 is supposed to "just work" for 32 bit libc stuff ?
[21:17] <smoser> i have a executable that works on 32 bit.
[21:17] <smoser>  $ ldd /usr/bin/brprintconf_mfc9125cn	linux-gate.so.1 =>  (0xb770d000)
[21:17] <smoser> 	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7548000)
[21:17] <smoser> 	/lib/ld-linux.so.2 (0x8006d000)
[21:17] <slangasek> smoser: libc6-x32 is for x32 binaries, of which there are approximately zero in the wild
[21:17] <smoser> oh. well, yeah. that'd do it.
[21:18] <slangasek> you preferably want to install libc6:i386 (multiarch cross-install of the i386-arch package)
[21:18] <smoser> i was hoping to avoid i386 packages. and i thiought that might e what that was.
[21:19] <smoser> i just dont want to add the 32 bit arch to dpkg.
[21:23] <smoser> well, libc6-i386 worked for me.
[21:24] <smoser> and didn't need foreign arch
[21:41] <smoser> slangasek, my cloud-init uploads are back in the xenial and yakkety queue now.
[21:47] <jgrimm> \o/
[21:55] <nacc> slangasek: ack, thank you!
[23:10] <nacc> rbasak: would you be able to review: LP: #1669831 ?
[23:13] <sarnold> rbasak: <3 1610765 :)
[23:16] <nacc> sarnold: ah thanks!


[14:09] <maclin> Hi jzheng_afk & ypwong, I sent out a email about the hardware adaptation. Can you help to review the problems? Thanks:)


[17:14] <Mekaneck> waveform: was nice to see the face behind the name in the live stream :)
[17:15] <waveform> didn't crack the camera ;)
[17:15] <Mekaneck> jawn-smith: too ;)
[17:15] <Mekaneck> hehehe
[17:16] <Mekaneck> waveform: before i forget, i switched to anothe nick, i was known as Maik on freenode ;)
[17:16] <waveform> ahh, that I recognize! thanks :)
[17:16] <Mekaneck> np :)
[17:31] <Mekaneck> waveform: you know by chance of a bug in 21.04 Pi which causes the desktop to go a few pixels off on the left side of the screen?
[17:32] <Mekaneck> it's like the desktop is more to the right. it's not a resolution issue afaik
[17:36] <Mekaneck> waveform: this is from Ubuntu Unity 21.04 on the Pi, but Ubuntu 21.04 has exactly the same issue: https://i.imgur.com/ClvNbW6.jpg
[17:41] <ogra> waveform, FYI you are op in the new -arm channel ... (I didnt want to be the only one)
[17:43] <Mekaneck> ogra: new -arm channel?
[17:43] <ogra> the "libera" #ubuntu-arm channel
[17:43] <Mekaneck> oh, right. thanks
[17:44] <Mekaneck> i was thinking i'm in the wrong channel
[17:44] <ogra> hah
[17:44] <Mekaneck> :)
[17:44] <ogra> no, this is the perfectly right channel fo yu 🙂
[17:44] <ogra> *for
[17:44] <Mekaneck> phew... thanks
[18:06] <jawn-smith> Thanks for watching Mekaneck!
[18:08] <Mekaneck> yw and keep up the great work you guys do.
[18:08] <Mekaneck> :)
[18:33] <waveform> ogra, thanks for the heads up!
[18:35] <waveform> Mekaneck, yes -- I've noticed the 1-pixel offset; it's on my list to go bug the wayland guys about (I should open an issue for it but my bug-list is already ... rather large!)
[18:36] <Mekaneck> waveform: it's also on Xorg/X11
[18:36] <Mekaneck> the normal main Ubuntu desktop version isn't affected afaik, only the Pi image
[18:37] <waveform> yup - it's definitely just the pi image -- I hadn't noticed it on xorg though (under groovy). Hmm, wonder if I just missed that or if it was something that came about under hirsute
[18:38] <Mekaneck> Groovy is fine, it's only on Hirsute :)
[18:40]  * Mekaneck is running Groovy on the Pi 4 at the moment