[08:10] <pwnguin> http://airlied.livejournal.com/61658.html
[08:19] <tjaalton> he also has a patch for fdo bug 14441 which I'll test shortly :)
[08:19] <tjaalton> u
[08:19] <tjaalton> h
[08:19] <tjaalton> fd.o bug 14441
[08:21] <tjaalton> ok, https://bugs.freedesktop.org/show_bug.cgi?id=14441
[08:21] <tjaalton> ..which is the only blocker left for mesa 7.1
[08:22] <tjaalton> huh, gdm tries to use /usr/X11R6/bin/X now?
[08:22] <tjaalton> which should work, but still..
[08:32] <soren> Do any of you guys have a clue about  https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-vmmouse/+bug/251473 ?
[08:33] <soren> brb
[08:38]  * soren 's back
[08:47] <tjaalton> soren: no idea, but seems like it _should_ be fixed..
[08:47] <soren> Well... It's not :)
[08:50] <tjaalton> yeah, so it seems :)
[23:17] <pwnguin> tseliot: excellente
[23:18] <tseliot> pwnguin: ;)
[23:18] <pwnguin> i still wish a formal parser was written, but i suppose its enough for me to be vindicated in the end ;)
[23:19] <tseliot> heh
[23:23] <pwnguin> as a Computer Scientist, it always frustrates me that people resort to regex and raw string chewing to handle something quite difficult


[01:02] <bdrung> chrisccoulson: btw, my ati driver problem with FF 4.0 is "solved".
[01:02] <bdrung> chrisccoulson: my graphic card died. now i am using the intel onboard graphics.
[01:03] <bdrung> discrete graphic cards tend to die after 25 months.
[01:05] <nikolam> Hm. I would get Nvidia anyway. I got frustrated with AMD killing closed fglrx support for my AMD integrated graphics on MoBo and killing 3D speed with Open support.
[01:07] <bdrung> nikolam: i was happy with the free ati driver. i won't buy nvidia again, because i want a free (floss) driver with 3d support.
[01:08] <bdrung> nikolam: four graphic cards (including mine) died last year, but this was not vendor specific.
[01:09] <bdrung> all dedicated graphic cards die often
[01:09] <nikolam> omg. bdmurray sorry to hear that. I might consider changing MoBoard or checking if Power supply is ok, too, since it seems to me a bit too much to kill 4 cards in a year
[01:10] <bdrung> nikolam: four in different computers. mine, my parents, one friend, and one acquaintance
[01:11] <bdrung> nikolam: all with different power supplies and they are located in three different house holds.
[01:11] <bdrung> and they were from different vendors and series
[01:19] <nikolam> bdrung, oh, that sounds scary. And they were all AMD? Were they connected to VGA or DVI-D monitors? What OS´es were they running on?
[01:20] <bdrung> nikolam: amd and nvidia. three via dvi and one via vga. OS were ubuntu and windows.
[01:22] <nikolam> bdrung, well, definitely something endemic about graphics card quality. Thanks for explaining.
[10:02] <dpm> fta, great post on the PPA stats, very interesting
[12:41] <fta> dpm, thanks
[12:45] <fta> dpm, fyi: http://codereview.chromium.org/6040007/
[12:47] <dpm> fta, thanks. I'm not familiar with the chromium development process. What do I see there? I understand it's a bug report to commit translations, but I thought the first batch had already been committed?
[12:47] <fta> dpm, it's not a bug report, it's a patch review system. and it's the 2nd batch
[12:47] <dpm> ok, gotcha
[12:48] <fta> still only 1 template though
[14:26] <micahg> chrisccoulson: I forgot there's a dynamic control file now :-/
[14:43] <micahg> chrisccoulson: is there any reason to keep using DEB_BUILD_ARCH instead of DEB_HOST_ARCH?
[15:51] <micahg> chrisccoulson: you around?
[16:57] <chrisccoulson> micahg - yeah, just got back from a shopping trip ;)
[16:57] <micahg> chrisccoulson: ah, sorry, was jumpy, but then realized another few hours won't hurt anything
[16:59] <micahg> well, my arm build didn't complete because the machine suspended, but it's passing the right -march now, so I figure it should work
[17:00] <chrisccoulson> cool, thanks
[17:01] <micahg> chrisccoulson: so, do you see any harm in switching from DEB_BUILD_ARCH to DEB_HOST_ARCH? lool said this should allow it to work when cross-compiling
[17:02] <chrisccoulson> hmmm, i thought it was the other way around
[17:02] <chrisccoulson> perhaps i'm confused
[17:02] <chrisccoulson> i thought DEB_BUILD_ARCH was the target arch, in which case, using that would be more correct wouldn't it?
[17:02]  * micahg thought so too, but DEB_HOST_ARCH seems to be suggested in the manpage for dpkg-architecture
[17:03] <chrisccoulson> oh, right, DEB_HOST_ARCH is the target then
[17:03] <micahg> right
[17:03] <chrisccoulson> in which case, some other parts in debian/rules are likely reversed ;)
[17:04] <chrisccoulson> i'd leave it for the time being, i will have a look at that in a bit
[17:04] <micahg> ok, the other suggestion was that armel won't match armhf
[17:04] <micahg> so maybe we should only match arm, but we can save that for later as well
[17:05] <micahg> ok, I'll upload then?
[17:10] <chrisccoulson> micahg - yeah, can do
[19:12] <gnomefreak> was thunderbird and seamonkey dailies moved to a new PPA? it has been over 2 weeks without updates to either of them
[19:17] <gnomefreak> latest tb i have is 3.1.8~hg20101223r5918+nobinonly-0ubuntu1~umd1  and seamonkey is 2.0.11+build1+nobinonly-0ubuntu2
[19:53] <micahg> chrisccoulson: for xul2.0b8-ubuntu3 (FTBFS fix), what should I do since there's no tag for ubuntu2
[19:57] <gnomefreak> was tb and sm dailies moved to a new PPA?
[19:58] <micahg> gnomefreak: we never had sm dailies and I still haven't gotten the trunk builds working, will get that up next week
[19:58] <gnomefreak> oh ok and you mean tb trunk builds?
[19:58] <micahg> gnomefreak: yeah, tb 3.1 dailies should be working
[19:59] <gnomefreak> latest tb build is from 12/23/2010
[20:00] <micahg> that would be bad :-/
[20:00] <fta> no change in that branch since
[20:00] <gnomefreak> 3.1.8~hg20101223r5918+nobinonly-0ubuntu1~umd1
[20:00] <micahg> ah, fta is right
[20:01] <gnomefreak> ah ok
[20:01] <fta> it's tracking http://hg.mozilla.org/releases/comm-1.9.2/
[20:01] <fta> that may be why
[20:02] <fta> http://hg.mozilla.org/comm-central/ is fresher
[20:02] <micahg> fta: right, I should have comm-central build ready next week, I need to take the changes that chrisccoulson made to the firefox branches and apply the appropriate ones to thunderbird
[20:03] <micahg> I was supposed to have more free time last month, but due to various reasons did not
[20:05] <gnomefreak> is there a way to turn off the ff data submit process?
[20:05] <gnomefreak> i dont recall the exact name of it
[20:05] <micahg> gnomefreak: just uncheck the box if it crashes, it's not required to submit
[20:06] <gnomefreak> its not crashing
[20:06] <micahg> what data submit process then?
[20:06] <chrisccoulson> test pilot, probably
[20:06] <micahg> ah, I'm not familiar with that
[20:06] <chrisccoulson> just switch off the extension ;)
[20:06] <chrisccoulson> but it exists for a reason
[20:06] <gnomefreak> not sure i was using ff it hink its b7 and it asks me to submit it
[20:06] <gnomefreak> ah ok thanks
[20:07] <chrisccoulson> micahg - oh, did i not push the latest comments for xr-2.0?
[20:07] <micahg> chrisccoulson: idk, there's no tag, but you imported the changelog
[20:08] <chrisccoulson> micahg - oh, the tag is there, but it's in the branch i merged from ;)
[20:08] <micahg> chrisccoulson: ah, ok
[20:08] <micahg> chrisccoulson: that works then, I'll dig it out and upload later tonight
[20:09] <micahg> thanks
[20:09] <chrisccoulson> thanks
[20:09] <gnomefreak> chrisccoulson: i dont have an extension for test pilot and i cant seem to find it in prefferences
[20:10] <chrisccoulson> gnomefreak, it's called "Feedback" in the addons manager
[20:11] <gnomefreak> chrisccoulson: i only have greasemonkey, ubuntu mods, and prism in extensions from addon manager
[20:12] <gnomefreak> wait a minute that was under b9 not b7 but b7 is the one i need
[20:12] <chrisccoulson> hmmm, not sure then. you'll need to describe what you're being asked to submit, I can't really guess that ;)
[20:14] <gnomefreak> it pops up under feedback so i think you are correct. checking now
[20:16] <gnomefreak> thats odd. with b7 greasemonkey, prism and ubuntu mods are not compatiable with b7 but with b9 they work fine
[20:18] <micahg> did you override the checks in the profile?
[20:18] <gnomefreak> profile? you mean addon manager?
[20:18] <chrisccoulson> on the subject of testpilot, i really need to figure out why ubufox breaks it :/
[20:19] <gnomefreak> in addon manager i dont have an option to enable or override
[20:22] <gnomefreak> nightly tester tool did not help it at all either
[20:24] <gnomefreak> addon compatiblity checking is disabled and can not be enabled, maybe that is why? let me update all packages and see if it helps
[22:25] <BUGabundo> evening


[07:42] <F41L> Having issues with 3.11 kernel. My 13.10 installation disc is even affected.
[07:43] <F41L> Possibly related to graphics? (AMD Radeon 7000 series) but recovery mode also locks up soon after entering.
[07:44] <F41L> booting 13.10 using 3.8 kernel appears to work somewhat normally, despite a KDE error on login.
[09:40]  * apw groans
[09:44] <ppisati> so, if you disable a feature in a pkg, and that feature built a file that was later referenced in a debian/*.install file, the build fails
[09:45] <ppisati> so the real question is: how do i know which feature build what? or it's just a tril and error process? i guess the second one...
[10:02] <apw> normally trial and error indeed
[10:09] <infinity> ppisati: You either be intimately familiar with the configure and Makefiles or you build the package and see what changed. :P
[10:14] <ppisati> and, let me guess, i can't reuse the ppaX id after a build failure
[10:21] <infinity> Nope.
[10:22] <infinity> Good thing there's an unlimited number of integers.
[10:22] <infinity> Also, good thing we have mechanisms for testing these things LOCALLY, so you don't have to look a fool with dozens of PPA test builds. :P
[10:22] <infinity> *hint, hint*
[10:26]  * ppisati thinks infinity is a peeper...
[10:26] <RAOF> Also, the ‘-nc’ option to debuild might be of interest to you.
[13:26] <apw> jodh, hey ... what is the startpar-bridge job for?  it seems to start a lot on my test box here
[13:28] <jodh> apw: sysvinit -> upstart transition-type stuff: slangasek's baby.
[13:38] <apw> jodh, oh ... hmmm i think
[13:38] <apw> jodh, it must run like 50 times on boot
[14:17] <brendand> cking, hi
[14:17] <cking> brendand, hi
[14:18] <brendand> cking, what you mentioned about getting the local time of cpu0
[14:18] <brendand> cking, is that accesible in /sys or /proc?
[14:18] <cking> brendand, why do you need this?
[14:20] <brendand> cking, we want to write a hook for pm-suspend that gets the clock time at the start of the suspend process
[14:20] <brendand> cking, and also at the end of resume
[14:23] <cking> brendand, how about the easy way: "echo PM-SUSPEND-HOOK-START" | sudo tee /dev/msg ... and at the end of the test grep for it in dmesg
[14:23] <cking> oops, I mean /dev/kmsg
[14:24] <brendand> cking, because fwts is rude and zaps kmsg
[14:24] <brendand> !
[14:24] <brendand> cking, :)
[14:25] <brendand> cking, we're using fwts to invoke the suspend (in order to get device-check etc) and it is clearing kmsg
[14:26] <brendand> cking, although i'm not positive that's after the hook runs
[14:26] <erle-> i just reported a bug with waking up after suspense to RAM
[14:26] <cking> brendand, why not file a bug against fwts and specify what you want and I can look into adding it
[14:26] <erle-> there is a crash report in /var/crash
[14:26] <erle-> is it save to just append it?
[14:26] <erle-> or may it contain private data?
[14:27] <brendand> cking, we want to measure the time from the beginning of suspend to when the system is suspended. then from when it is requested to resume until user space is resumed
[14:27] <brendand> cking, if that sounds doable i can file a bug
[14:29] <brendand> cking, we're trying to do it at the moment but it's a little rough around the edges
[14:29] <brendand> i mean we *are* doing it
[14:29] <cking> brendand, doesn't fwts already report the duration of the suspend?
[14:30] <brendand> cking, we're not interested in the time it slept for though
[14:30] <brendand> cking, and does it report those things seperately or only the total duration?
[14:31] <cking> brendand, yup, it does not do what you require, I could add that though
[14:32] <brendand> cking, well, i don't want you to do my job for me, but if it would be more suitable to add it to fwts then i'd take you up on it
[14:32] <cking> and/or not make it nuke the kernel messages
[14:33] <cking> brendand, when do you require a solution?
[14:34] <brendand> cking, well we want to get this fixed for 12.04.4
[14:34] <brendand> cking, let me file a bug
[14:34] <erle-> bjf, crash report is coming :)
[14:34] <cking> brendand, file a bug and I will mull over it and get back to you on monday if it is easily do-able or not
[14:38] <brendand> cking, https://bugs.launchpad.net/bugs/1241638
[14:38] <ubot2> Launchpad bug 1241638 in Firmware Test Suite "FWTS to measure the time from invoking suspend to suspend, then the time from waking system to user-space resume" [Undecided,New]
[14:39] <cking> ack
[15:35] <slangasek> apw: yeah, startpar-bridge triggers an awful lot
[15:35] <slangasek> apw: it becomes obsolete once everything is managed by upstart and not by sysvinit
[15:41] <apw> slangasek, with --debug on my test rig here (read a very slow machine) it is seemingly vomiting as the predominant output
[15:41] <slangasek> yes, it will do that
[15:41] <slangasek> its rules is 'start on started JOB!=startpar-bridge or stopped JOB!=startpar-bridge
[15:41] <slangasek> '
[15:41] <slangasek> s/rules/rule/
[15:41] <slangasek> so that's an awful lot of starts and stops, unfortunately
[15:42] <apw> so that starts and checks if yo umeant an oldstyle script i assume
[15:45] <erle-> jsalisbury, hi, i am the guy with the suspend bug
[15:45] <erle-> jsalisbury, i tried 3.12 and it works
[15:46] <jsalisbury> erle-, which bug number is it?
[15:46] <erle-> will saucy get kernel 3.12 or are you just planning to backport the fix?
[15:46] <erle-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1241582
[15:46] <ubot2> Launchpad bug 1241582 in linux (Ubuntu) "system freezes after suspend to RAM" [High,Confirmed]
[15:47] <jsalisbury> erle-, thanks.  Saucy will stay on the 3.11 kernel.  The next step is to identify the commit in 3.12 that fixes this and see if it was already sent for inclusion in the stable tree.
[15:48] <jsalisbury> erle-, we should probably test the latest 3.11 stable kernel first to see if it's already fixed there.
[15:48] <erle-> you mean upstream 3.11?
[15:48] <jsalisbury> erle-, if it's not, we can perform a reverse bisect to find the fix in 3.12
[15:49] <jsalisbury> erle-, correct.
[15:49] <jsalisbury> erle-, I'll post the links to upstream 3.11 in the bug report.
[15:49] <erle-> this?
[15:49] <erle-> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.5-saucy/
[15:49] <erle-> kernel.org says 3.11.5 is latest
[15:50] <jsalisbury> erle-, yup, that's it.
[15:50] <jsalisbury> erle-, it would be great if you can test that one
[15:51] <erle-> i would like a statement about the safety of apport in regards to privacy, i am somewhat curious
[15:51] <erle-> also about the files in /var/crash
[15:52] <ogra_> erle-, apport isnt developed by the NSA ... does that suffice ?
[15:52] <ogra_> (selinux is)
[15:52] <erle-> ogra_, i mean, does it take care of not to include potentially private information into reports?
[15:52] <erle-> like passwords in memory dumps
[15:53] <erle-> i dont like my passwords dumped on launchpad, you know? :)
[15:53] <jsalisbury> erle-, there is some info here: https://wiki.ubuntu.com/Apport
[15:53] <ogra_> oops, sorry i  mistook apport with apparmor
[15:53] <ogra_> (since this is the kernel channel my brain tripped over this)
[15:54] <apw> erle-, we don't take memory images from crashes in the normal case
[15:55] <erle-> jsalisbury, just another reboot and we will know
[15:55] <jsalisbury> erle-, great
[15:57] <erle-> jsalisbury, works
[15:57] <erle-> jsalisbury, and yes, i made sure that grub picked the right one
[15:58] <jsalisbury> erle-, thats good news.  that means the fix will make it into Saucy when it gets the 3.11.5 updates.
[15:59] <erle-> jsalisbury, yes
[15:59] <erle-> and i personally will just keep this one now
[15:59] <erle-> but i will purge the 3.12rc
[15:59] <jsalisbury> erle-, ok
[16:00] <bjf> erle-, those commits should hit -proposed towards the end of next week and -updates in approx. 3 weeks
[16:00] <erle-> bjf, don't you think that this will hit a lot of users with certain hardware?
[16:01] <erle-> 3 weeks seems long
[16:03] <bjf> erle-, it takes 3 weeks to work though our stable process there are quite a few (197) commits in the next update and we like to do a little testing before just putting it out
[16:06] <erle-> bjf, yes, i understand that, it was just a comment
[16:51]  * apw will be calling it a week in about half hour
[17:07] <rtg_> ppisati, can you have a look at bug #1239800 ?
[17:07] <ubot2> Launchpad bug 1239800 in linux (Ubuntu) "Soft lockup when running bonnie++ only at 1600 mt/s" [Medium,Incomplete] https://launchpad.net/bugs/1239800
[17:22] <erle-> jsalisbury, do you have any link to a kernel changelog that refers to my problem?  (you don't have to look for one, but if you found one already i would be interested)
[17:25] <jsalisbury> erle-, I didn't do any searching on what specific commit fixes the bug
[17:26] <erle-> jsalisbury, ok
[17:26] <erle-> will 3.11.3 or something come into ubuntu release before 3.11.5 or wont it come at all?
[17:26] <erle-> maybe even a earlier version than 3.11.5 fixes the issue
[17:27] <erle-> but i dont want to try them all now
[17:29] <jsalisbury> erle-, 3.11.0-11.17 was already rebased to 3.11.3.  So there is always the possibility it was fixed in 3.11.4
[17:36] <rtg> jsalisbury, saucy master-next is up to 3.11.5
[17:36] <jsalisbury> rtg, ack.
[17:37] <jsalisbury> erle-, so the next saucy release will be based on 3.11.5
[17:38] <erle-> thank
[17:38] <erle-> and that means the 3 weeks you mentioned, right?
[17:38] <jsalisbury> correct
[17:39] <erle-> and if anybody asks for help with this, i will propose updates-proposed for the meantime
[20:19]  * rtg -> EOW
[21:11] <sn0wb1rd> Hello geeks, I have the "3.2.0-49-virtual" version of kernel on my 12.04 Ubuntu virtual machine. I am experiencing some issues with xfs with and found that this commit https://github.com/torvalds/linux/commit/3948659e30808fbaa7673bbe89de2ae9769e20a7 fixes the problem in 3.4 version of the kernel. There is no virtual kernel available for 3.4 or anything higher than "3.2.0-49-virtual". How do I backport the change and rebuild my kernel to include
[21:11] <sn0wb1rd> this fix?
[21:12] <sn0wb1rd> Also is it possible to request for virtual kernel images for recent versions of kernel?
[21:27] <bjf> sn0wb1rd, that looks like a pretty trivial fix. please file a bug and add that information to the bug
[21:29] <sn0wb1rd> bjf: that is awesome. filing a bug now.
[21:29] <sn0wb1rd> bjf: Is this about getting virtual kernel images for recent versions of kernel?
[21:32] <bjf> sn0wb1rd, no, that will help get the fix into the kernel. then we'll roll out new kernels.
[21:32] <sn0wb1rd> Ok, I'll file a bug with the information I have.
[21:32]  * bjf is now afk
[21:46] <sn0wb1rd> bjf: https://bugs.launchpad.net/ubuntu/+bug/1241848
[21:46] <ubot2> Launchpad bug 1241848 in Ubuntu "Request for updated Ubuntu virtual kernel images" [Undecided,Confirmed]


[15:00]  * barry waves
[15:06]  * tumbleweed is here to chair a DMB meeting, if we do one
[15:06] <tumbleweed> but it sounds like we have nothing to dicuss
[15:06] <tumbleweed> https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
[15:06] <barry> i'm happy skipping it
[16:31] <jdstrand> hi!
[16:31] <jdstrand> #startmeeting
[16:31] <meetingology> Meeting started Mon Aug 26 16:32:03 2013 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:31] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:31] <jdstrand> The meeting agenda can be found at:
[16:31] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[16:33] <jdstrand> [TOPIC] Weekly stand-up report
[16:33] <jdstrand> I'll go first
[16:33] <jdstrand> I'm on triage this week
[16:33] <jdstrand> I have several pending updates I'm working on
[16:34] <jdstrand> I plan to test/sponsor tyhicks' saucy uploads this week
[16:34] <jdstrand> I have a couple of august work items to do
[16:34] <jdstrand> and participate in vUDS
[16:34] <jdstrand> mdeslaur is not here today. sbeattie, you're up
[16:35] <sbeattie> I'm again working on apparmor testing this week, looking at IPC issues
[16:35] <sbeattie> I need to review work items, and make sure I don't have anything outstanding
[16:35] <sbeattie> as well as attend vUDS.
[16:36] <sbeattie> that's it for me, tyhicks?
[16:36] <jdstrand> sbeattie: how is the IPC testing going?
[16:36] <sbeattie> slow
[16:36] <sbeattie> making progress but slow.
[16:37] <jdstrand> sbeattie: you have one work item for august that I left for you. please focus on IPC
[16:37] <sbeattie> jdstrand: okay, will do
[16:37] <tyhicks> sbeattie: are you writing tests? if so, do you plan on incorporating the simplified socketpair() testcase that I wrote last week?
[16:37] <tyhicks> (or should I do that?)
[16:37] <jdstrand> sbeattie: it is the device-specific accesses. I may try to do soemthing with that, but will likely want to discuss it with you
[16:37] <sbeattie> tyhicks: yeah, I can take that.
[16:37] <jdstrand> might just postpone the work item. we'll see
[16:38] <jdstrand> tyhicks: please proceed
[16:38] <jdstrand> (with your status update)
[16:38] <tyhicks> I'll be handing jdstrand a couple debdiffs and test results for saucy uploads this morning
[16:39] <jdstrand> \o/
[16:39] <tyhicks> there's still one known bug in dbus, around how we're handling eavesdropping, I'll be working on fixing this this week
[16:40] <tyhicks> then I'll probably take a look at the 'update apparmor_parser to add v3 open rules to v2 policy' work item
[16:41] <tyhicks> I also need to spend a little time getting ecryptfs ready for the next merge window
[16:41] <jdstrand> tyhicks: so, you addressed the dbus rules in abstractions issue with the tools?
[16:41] <tyhicks> and I need to test jj's fix for a socketpair() labeling bug that I came across last week
[16:41] <tyhicks> jdstrand: yes - I need to send that patch out to the list
[16:42] <tyhicks> jdstrand: apparmor - 2.8.0-0ubuntu24+dbusdev4 contains the fix
[16:43] <jdstrand> tyhicks: iirc, there were some test-dbus.py failures. is that the socketpair() issue?
[16:44] <tyhicks> jdstrand: that was one issue
[16:44] <jdstrand> ok, let's back up
[16:44] <tyhicks> ok
[16:44] <jdstrand> tyhicks: you are going to give me pacakges to upload. it sounds like there are bugs that are known to exist. what are they?
[16:45] <tyhicks> jdstrand: the known bug remaining is around eavesdropping
[16:45] <tyhicks> jdstrand: when we grant permissions in policy, we imply some permissions
[16:46] <tyhicks> jdstrand: so when you have permission to send a message, you implicitly have permissions to receive a method_return or error message from the peer that you can send a message to
[16:46] <tyhicks> jdstrand: our short-circuit code in dbus to allow the method_return or error messages to slip through is too loose
[16:47] <jdstrand> I see
[16:47] <tyhicks> jdstrand: it also allows eavesdroppers to see those messages
[16:47] <jdstrand> so no problem uploading to saucy. we'll just fix that in the next upload
[16:47] <tyhicks> exactly
[16:47] <tyhicks> the only time that someone would see it is if they used dbus-monitor
[16:48] <tyhicks> it is a very important bug to fix, but it doesn't affect day to day use
[16:48] <jdstrand> yes
[16:48] <jdstrand> tyhicks: ok, I'm done. please proceed :)
[16:48] <tyhicks> I think that's it for me
[16:48] <tyhicks> jjohansen: you're up
[16:49] <jjohansen> I'm working on apparmor this week, specifically the ipc work items
[16:50] <jdstrand> tyhicks: btw, after we upload to saucy, can you file a bug on the eavesdropping issue?
[16:50] <tyhicks> jdstrand: yes
[16:51] <jdstrand> jjohansen: sorry for interrupting
[16:52] <jjohansen> jdstrand: heh thats fine
[16:53]  * jjohansen will coordinate with tyhicks and sbeattie to get more testing of a couple of fixes I pushed out last week
[16:53] <jjohansen> I'll dump a bunch of kernel and parser patches for sarnold to review
[16:55] <jjohansen> hrmmm, I have some compatibility patches to update for 3.10, and 3.11 but some how I don't think I will get to that this week
[16:56] <jjohansen> to preempt jdstrand's question on how ipc is going, its slow once I get a major crash bug fixed we should be able to start playing with several parts of it this week
[16:57] <jdstrand> well, I wasn't going to ask this week-- you only worked last friday :)
[16:57] <jjohansen> that is other people can start playing with
[16:57] <jdstrand> jjohansen: but thanks! that sounds agreat :)
[16:57] <jjohansen> oh? I did?
[16:57] <jdstrand> jjohansen: ok, I was only aware that you worked one day last week
[16:58] <jdstrand> jjohansen is a sneaky one
[16:58] <jjohansen> vacation was last week? sigh that is so depressing
[16:58] <sarnold> take two they're small
[16:59] <jjohansen> alright so it feels like Its been a few weeks since vacation, anyways thats it for me sarnold your up
[16:59] <sarnold> I'm on community this week
[17:00] <sarnold> I'm also on MIR duty this week, I'm the blocker for six or seven audits.
[17:01] <sarnold> and I've got an apparmor parser patch to prepare for SRU for precise, the features buffer size problem -- and I'm curious if I should prepare packages for all releases or just precise, which is the current problem for kernel team preparing saucy-on-precise LTS kernels..
[17:01] <jjohansen> sarnold: precise is the important one
[17:02] <sarnold> jjohansen: okay, sounds good to me :)
[17:02] <sarnold> will any saucy-kernel installed on precise poke the problem?
[17:02] <jjohansen> sarnold: if you find yourself without something to do poking the other releases would be nice
[17:03] <jjohansen> sarnold: yes it will
[17:03] <sarnold> jjohansen: oh I don't think I'll be in that position this week, feature freeze is soon and I owe a lot of people ACKs or NACKs on MIRs..
[17:03] <sarnold> jjohansen: cool. thanks :)
[17:04] <jjohansen> err, that is any saucy kernel after the alpha4 apparmor sync, so all future saucy kernels
[17:05] <sarnold> jjohansen: would e.g.  3.11.0-3.8 do the job?
[17:06] <jjohansen> sarnold: yes that kernel will cause things to fail nicely
[17:06] <sarnold> jjohansen: woot! \o/
[17:07] <sarnold> okay, I think that's me finished, and chrisccoulson has time'd out, so jdstrand, back to you
[17:13] <jdstrand> thanks, sorry, got pulled aside
[17:13] <jdstrand> [TOPIC] Highlighted packages
[17:13] <jdstrand> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[17:13] <jdstrand> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[17:14] <jdstrand> normally at this point I would provide a list of packages, but python-apt broke UCT so I don't have them atm.
[17:14] <jdstrand> I will update https://wiki.ubuntu.com/SecurityTeam/HighlightedPackages once I fix that
[17:14] <jdstrand> [TOPIC] Miscellaneous and Questions
[17:14] <jdstrand> Does anyone have any other questions or items to discuss?
[17:24] <jdstrand> sbeattie, tyhicks, jjohansen, sarnold: thanks!
[17:24] <jdstrand> #endmeeting
[17:24] <meetingology> Meeting ended Mon Aug 26 17:24:46 2013 UTC.
[17:24] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-08-26-16.32.moin.txt
[17:24] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-08-26-16.32.html
[17:24] <tyhicks> thanks!
[17:24] <jjohansen> thanks jdstrand
[17:24] <sarnold> thanks jdstrand! :)
[17:25] <sbeattie> thanks, jdstrand
[19:59] <soren> o/
[20:00]  * soren checks calendar
[20:01] <soren> https://wiki.ubuntu.com/TechnicalBoardAgenda is fairly out-of-date (very likely my fault), but today should be a meeting day.
[20:27] <stgraber> soren: 2013-08-05 + 2 weeks == 2013-08-19 (last week) + 2 weeks == 2013-09-02 (next week)
[20:40] <soren> stgraber: Your arithmetic is impeccable.
[20:40] <soren> stgraber: Unlike mine.


[01:09] <a1fa> andyrock: +1 nice!
[02:30] <Trevinho> pitti: patch updated again.
[04:53] <hikiko> hi
[06:06] <pitti> Good morning
[06:16] <seb128> good morning desktopers!
[06:19] <pitti> bonjour seb128 !
[06:20] <seb128> hey pitti, happy friday!
[06:20] <seb128> how are you?
[06:20] <pitti> and to you! I'm fine, thanks, how about yourself?
[06:20] <pitti> whoa, where did all my armhf boxes go
[06:21] <seb128> I'm good thanks ;-)
[06:44] <seb128> happyaron, hey!
[06:44] <happyaron> seb128: hi
[06:44] <seb128> happyaron, how are you? happy friday!
[06:45] <happyaron> great, :)
[06:48] <seb128> happyaron, how are those nm updates going? ;-)
[06:49] <happyaron> met a problem on rebasing the policy patches to nm 1.2.2, still working on that
[06:50] <seb128> k
[06:50] <seb128> maybe it would make sense to do the -gnome update first?
[06:50] <seb128> it fixes some issues and should be more trivial
[06:50] <happyaron> yep I meant the applet package
[06:50] <seb128> oh well, we are not going to SRU things on friday and it's almost w.e time for you
[06:51] <seb128> oh, right, stupid me, 1.2.2 was already uploaded to y- :p
[06:51] <happyaron> already done the merge with nm itself
[06:51] <happyaron> :)
[06:51] <seb128> yeah
[06:51] <seb128> I'm not fully awake yet it seems ;-)
[06:51] <happyaron> haha
[06:51] <seb128> happyaron, k, let me know if you need help with something
[06:54] <happyaron> ty
[07:26] <seb128> time for a coffee break, bbiab
[08:01] <Laney> morning
[08:01] <Laney> it's fririririrday
[08:07] <willcooke> morning
[08:08] <willcooke> appstreamcli is using 100% CPU this morning
[08:08] <davmor2> Morning willcooke
[08:10] <seb128> hey Laney, willcooke
[08:11] <seb128> happy friday!
[08:11] <seb128> how are you?
[08:11] <willcooke> \o/
[08:11] <willcooke> Ready for a weekend
[08:11] <seb128> willcooke, do you use it manually? or are we spawning that command in bg?
[08:11] <willcooke> seb128, must be running it in the bg
[08:11] <seb128> hum, k
[08:12] <willcooke> I killed it, but...
[08:13] <willcooke> ay 20 09:10:50 malfunctioning-eddie sudo: pam_ecryptfs: pam_sm_authenticate: /home/will is already mounted
[08:13] <willcooke> May 20 09:10:50 malfunctioning-eddie org.debian.apt[955]: Terminated
[08:13] <willcooke> May 20 09:10:50 malfunctioning-eddie gnome-session[1981]: (gnome-software:2122): Gs-WARNING **: failed to call gs_plugin_refresh on apt: apt transaction returned result exit-failed
[08:13] <willcooke> May 20 09:10:50 malfunctioning-eddie AptDaemon.Worker: INFO: Finished transaction /org/debian/apt/transaction/09c0faa447d24743841046c745027e17
[08:13] <willcooke> May 20 09:10:50 malfunctioning-eddie org.debian.apt[955]: 09:10:50 AptDaemon.Worker [INFO]: Finished transaction /org/debian/apt/transaction/09c0faa447d24743841046c745027e17
[08:13] <willcooke> May 20 09:10:50 malfunctioning-eddie gnome-session[1981]: (gnome-software:2122): Gs-WARNING **: failed to get updates: no results to show
[08:16] <willcooke> smells like this:  https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1583845
[08:16] <willcooke> so might have been my internet connection crapping out for a moment
[08:16] <willcooke> correction, this:  https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1579712
[08:17] <willcooke> which is fixed
[08:17] <willcooke> in proposed
[08:17] <andyrock> morning all
[08:17] <willcooke> hey andyrock
[08:19] <seb128> hey andyrock, happy friday!
[08:20] <seb128> willcooke, if you can reproduce you might want to verify the SRU ;-)
[08:20] <andyrock> seb128: hehe :D
[08:23] <Laney> hey seb128 & willcooke & andyrock
[08:23] <seb128> willcooke, though it seems that bug got enough users verifying it
[08:23] <willcooke> seb128, I think so.  Just trying to recreate it now
[08:24]  * willcooke eyes the dropbox repo
[08:25] <willcooke> hrm, not that
[08:25] <willcooke> ah, backports
[08:25] <willcooke> strange
[08:26] <seb128> that's what others say on the bug as well
[08:26] <willcooke> yeah, just seen that
[08:26] <seb128> I wonder if something changed
[08:26] <seb128> because it's several people who have issues with backports today
[08:26] <willcooke> this could be an issue for upgrading then
[08:27] <seb128> does it block the apt index refresh for ever?.
[08:27] <seb128> in which case it indeed a problem
[08:27] <willcooke> seb128, running it manually now, let's see...
[08:28] <willcooke> sudo appstreamcli refresh --verbose --details --force
[08:28] <willcooke> ** (appstreamcli:5082): DEBUG: Refreshing AppStream cache
[08:28] <willcooke> ** (appstreamcli:5082): DEBUG: Reading: /usr/share/app-info/xmls/org.freedesktop.fwupd.xml
[08:28] <willcooke> ** (appstreamcli:5082): DEBUG: Reading: /var/lib/app-info/yaml/gb.archive.ubuntu.com_ubuntu_dists_xenial-backports_main_dep11_Components-amd64.yml.gz
[08:28] <willcooke> ** (appstreamcli:5082): DEBUG: Reading: /var/lib/app-info/yaml/gb.archive.ubuntu.com_ubuntu_dists_xenial-backports_restricted_dep11_Components-amd64.yml.gz
[08:28] <Laney> debugging a fixed bug?
[08:28] <willcooke> Laney, issue is that I wont get the fix because appstream cli hangs forever(?)
[08:28] <seb128> Laney, no, trying to reproduce to verify the SRU fix
[08:28] <seb128> Laney, also wondering how we get the fix to users if the bug prevent them to get updates
[08:29] <Laney> release it
[08:29] <seb128> well, still
[08:29] <seb128> if they can't apt-get update
[08:29] <seb128> their apt is never going to list the update
[08:29] <seb128> no?
[08:29] <seb128> so they are never going to see/be able to get it
[08:29] <Laney> you prevent updaters from getting it
[08:30] <seb128> you mean?
[08:31] <seb128> well, if people running release can't refresh their package index due to it, how do they get the fix?
[08:31] <Laney> If you release it then nobody new will get the bug
[08:31] <Laney> Don't knwo
[08:31] <seb128> I was wondering if there is a specific issue with backports that triggers the bug
[08:31] <Laney> I doubt it
[08:31] <Laney> they are empty of appstream
[08:32] <seb128> k, just seemed a weird coincidence that several people mention backports as being an issue today
[08:32] <Laney> Maybe it's an interaction with something else
[08:32] <seb128> like there are some on the bugs, willcooke and jtaylor on #ubuntu-devel
[08:32] <Laney> It doesn't mean it's backports itself
[08:33] <seb128> but yeah, the SRU is 7 days old and verified
[08:33] <seb128> need SRU team to copy it over
[08:33] <Laney> Someone who has the bug could find out why
[08:33] <Laney> and then we might be able to manipulate the appstream data somehow
[08:33] <Laney> Otherwise, if it just started today, get the SRU out there
[08:33] <seb128> well those comments on the bug suggest that disabling backport "fixes" it
[08:34] <seb128> pitti, ^ can you get the xenial appstream SRU copied over to updates?
[08:34] <Laney> That doesn't help for an apt update
[08:34] <pitti> seb128: can do; I'm normally not doing SRU releases on Friday, but if that's safe, sure
[08:34] <seb128> pitti, well see backlog
[08:34] <seb128> pitti, we are concerned that the bug hits more users and block them to get updates
[08:34] <pitti> bug 1574896 isn't verified yet
[08:35] <seb128> including the fix
[08:35] <pitti> but I suppose that's ok -- most importantly it shouldn't regress
[08:35] <Laney> looks v-done to me
[08:36] <Laney> but very recently so maybe the report didn't refresh
[08:37] <pitti> right
[08:37] <pitti> released
[08:37] <seb128> pitti, tahnks
[08:37] <Laney> merci
[08:38] <seb128> Laney, I don't understand your " That doesn't help for an apt update" comment
[08:38] <seb128> btw I can confirm here
[08:38] <Laney> You can't make 'update' disable backports
[08:39] <seb128> right, that's not what I meant
[08:39] <seb128> just that backport creates the issue
[08:39] <seb128> confirmed here, enabling backport and I can't finish an apt-get update now
[08:39] <seb128> :-/
[08:39] <seb128> disabling and it's good again
[08:40] <Laney> https://paste.ubuntu.com/16517854/
[08:40] <Laney> backports is empty
[08:41] <seb128> maybe that's what confuses it?
[08:41] <Laney> It's always been empty
[08:41] <seb128> in which case unsure why it started today :-/
[08:41] <Laney> That's what I'm asking to find out :-)
[08:42] <Laney> main was published yesterday so maybe that did something
[08:42] <seb128> unsure how to debug that, but you probably can if you want, just enable backport with the xenial version and try to refresh apt :p
[08:42] <Laney> I have that enabled and it works :(
[08:42] <seb128> you don't have the SRU version?
[08:43] <Laney> 0.9.4-1
[08:43] <seb128> :-(
[08:43] <Laney> mirror is still refreshing
[08:43] <Laney> maybe when that finishes it starts
[08:44] <willcooke> ahh, Laney has a local mirror
[08:44] <seb128> that's cheating :p
[08:44] <Laney> otherwise go gdb for you
[08:44] <seb128> disable your mirror and see if you get it?
[08:44] <seb128> I'm happy to help debugging
[08:44] <seb128> but I've no knowledge of the codebase/project
[08:44] <Laney> could get a trace though
[08:44] <seb128> so learning curve is going to take some time
[08:45] <seb128> yeah, that's easy
[08:45] <seb128> let me do it
[08:48] <willcooke> is this anything?  http://paste.ubuntu.com/16517887/
[08:48]  * willcooke is trying to work gdb
[08:48] <willcooke> although this is probably just debugging the fixed bug
[08:49] <Laney> might be able to stop it happening for everyone
[08:50] <seb128> willcooke, install libappstream3-dbgsym for bonus points
[08:52] <seb128> #1  0xb732d998 in as_yamldata_parse_distro_data (ydt=0x9c72290 [AsYAMLData], data=0x9c73f88 "---\nFile: DEP-11\nMediaBaseUrl: http://<IP_ADDRESS>/media/restricted\nOrigin: ubuntu-xenial-backports-restricted\nVersion: '0.8'\n\210", error=0xbfef1544) at /build/appstream-XJqxY1/appstream-0.9.4/src/as-yamldata.c:1861
[08:52] <seb128> seems to stuck there
[08:53] <Laney> I know how to fix it
[08:53] <seb128> \o/
[08:53] <Laney> edit that file and add "Priority: 40" at the bottom
[08:53] <Laney> see if it fixes it for you
[08:54] <seb128> let me try that
[08:54] <Laney> have to do it for all the backports ones
[09:00] <seb128> Laney, yeah, that works
[09:01] <seb128> did those files change recently/in which way?
[09:01] <Laney> backpots/main got a backport
[09:01] <Laney> which made the file regenerate with a Priority value
[09:02] <Laney> I guess that tickles the bug
[09:02] <Laney> waiting for the current run to finish then will make it regenerate for the other components
[09:37] <seb128> happyaron, do you have a 3g stick or some hardware to have a look to that n-m applet/3g icon issue?
[09:38] <willcooke> if you don't please get one and expense it
[09:39] <willcooke> they're not expensive
[09:41] <seb128> oem team seems to be very eager to see that one moving
[09:41] <seb128> Dell seems to wait on it
[09:41] <seb128> happyaron, that should probably be higher importance that the version updates
[09:42] <seb128> or maybe we can get cyphermox to have a look today
[09:42] <seb128> I'm pretty sure he has hardware for it
[09:44] <seb128> shrug, and of course bugzilla.gnome.org is down when I want to upstream it
[09:46] <willcooke> heh
[09:48] <davmor2> willcooke, seb128: I noticed that my laptop was spinning up still after a hangout and not calming down turns out appstreamcli is running and using 100%cpu
[09:49] <willcooke> davmor2, indeed.  known issue.  Fix in the works
[09:49] <seb128> davmor2, see channel backlog
[09:50] <seb128> ok, since bugzilla is down and I'm done with what I was looking at let's do early lunch and continue with other things after that
[09:50] <seb128> bbiab
[09:50] <davmor2> willcooke, seb128: ah awesome was busy in a meeting so hadn't kept an eye in here :)
[09:50] <willcooke> l8r seb128
[09:50] <willcooke> davmor2, nw
[09:54] <Laney> ok appstream.ubuntu.com is updated
[09:54] <Laney> the archive should get it soon
[09:54] <Laney> hmm, or will it
[10:04] <pitti> Laney: would that affect installs of xenial-release too?
[10:05] <Laney> yes they have backports by default
[10:05] <pitti> Laney: I'm currently tryigng to install it into a VM (final image) and it hangs on apt-get update
[10:05] <Laney> talking in #launchpad about a republish
[10:05] <pitti> ah, ok
[10:05] <happyaron> seb128: no I don't have
[10:12] <willcooke> happyaron, please get one, I think it will be useful
[10:12] <willcooke> just expense it
[10:13] <willcooke> I picked up a ZTE MF112 on ebay for < 10 GBP
[10:15] <happyaron> willcooke: will do, ty
[10:38] <tjaalton> willcooke: hi, is there someone assigned to work on bug 1417980?
[10:38]  * willcooke reads
[10:39] <willcooke> ah, lib input
[10:39] <willcooke> tjaalton, noone assigned yet, but it's on our list:  https://trello.com/c/4F2urkpx
[10:40] <tjaalton> willcooke: ok cool, I'm not on trello but good to know :)
[11:02] <Laney> archive should be fixed now
[11:07] <willcooke> thanks Laney!
[11:08] <willcooke> davmor2, and we are fixed! ^
[11:13] <davmor2> willcooke: we are indeed
[11:24] <seb128> Laney, good job!
[11:27] <Laney> blop
[11:31] <seb128> tjaalton, do we need that to happen? it's on our list but I doubt we are going to get to it this cycle
[11:32] <seb128> well we might
[11:32] <seb128> but we have quite some backlog and resources for y "feature" work is limited
[11:32] <seb128> it's likely going after packagekit 1 and gnome-software improvement and snap work
[11:32] <davmor2> Laney: what caused the issue in the end and is there a safeguard we can put in place to prevent it happening again?
[11:33] <seb128> which means I wouldn't count on it
[11:33] <Laney> the bug is fixed
[11:34] <seb128> davmor2, I'm unsure appstream has a testsuit/an easy way to create and feed him the config that created the bug to make sure that's not coming back in a futur version, if that's what you ask
[11:35] <davmor2> seb128: right okay so we could randomly have this happen any time a new package it uploaded then
[11:36] <seb128> well usually fixed bugs don't reappear
[11:36] <Laney> The same way you could randomly have a bug in anything
[11:36] <seb128> but I guess it's a possibility that some future change lead to new bugs
[11:36] <Laney> This particular bug is fixed
[11:36] <tjaalton> seb128: ok, kde & gnome will have it in y
[11:36] <seb128> tjaalton, good for them
[11:36] <tjaalton> gnome needs to depend on the driver
[11:36] <seb128> they can deal with the early adopter bugs
[11:36] <Laney> If you want to contribute a testsuite I'm sure ximion wouldn't say no
[11:36] <tjaalton> they dropped the old stuff
[11:37] <tjaalton> debian switched already :)
[11:37] <seb128> tjaalton, wasn't that already the case in xenial?
[11:37] <tjaalton> no
[11:37] <tjaalton> 3.20
[11:37] <davmor2> seb128, Laney: ah sorry I thought it was just a broken app profile that broke it
[11:37] <seb128> I though GNOME had dropped !libinput a while ago
[11:37] <Laney> no
[11:37] <tjaalton> xenial has 3.18 still
[11:38] <seb128> tjaalton, ah, they added libinput support a way back but kept the old thing as well, just dropped that in 3.20
[11:38] <seb128> I see
[11:38] <tjaalton> yeah
[11:38] <seb128> thanks for the head up
[11:38] <seb128> if you want to work on the u-c-c fixes that would be welcome
[11:39] <seb128> but if you are too busy then back to what I said before
[11:39] <seb128> it's on the list but low enough that I'm unsure we are going to get to it this cycle
[11:39] <tjaalton> some of it is in mutter now
[11:39] <tjaalton> aiui
[11:39] <seb128> yeah, I expect for us it's going to be u-c-c/u-s-d only
[11:39] <seb128> I hope at least that there are no compiz changes needed
[11:40] <tjaalton> right
[11:42] <Laney> tjaalton: the desktop team is hiring ;-)
[11:42] <Laney> this is my new troll version of patches welcome
[11:42] <tjaalton> Laney: hehe :)
[11:43] <seb128> :-)
[11:44] <tjaalton> is there any syncing done to u-c-c/u-s-d from upstream=
[11:44] <tjaalton> ?
[11:45] <seb128> no
[11:45] <tjaalton> yeah input config is all in mutter now, so it's not easy to port
[11:45] <seb128> well nothing regular/organized
[11:45] <tjaalton> ok
[11:45] <tjaalton> not that it would help here anyway
[11:46] <seb128> we do cherrypick changeset and backport fixes
[11:46] <seb128> in principle those changes shouldn't be too difficult right?
[11:46] <seb128> change some X calls by others
[11:47] <tjaalton> maybe
[12:13] <Trevinho> Laney: hey, could you publish https://requests.ci-train.ubuntu.com/#/ticket/1419 ?
[12:13] <Trevinho> It was blocked by the fact that unity is not built on the s390x again, but I think we need to whitelist this case again for yakkety (who can do that?)
[12:29] <seb128> Trevinho, why is usd still in there?
[12:30] <seb128> Laney, pitti, tedg, https://mail.gnome.org/archives/desktop-devel-list/2016-May/msg00005.html ... good timing ;-)
[12:44] <Trevinho> seb128: is listed, but not in the ppa
[12:45] <Trevinho> seb128: I did remove that from the list, but there are no packages to land
[12:45] <seb128> I think the silo needs to be reconfigured
[12:45] <seb128> you are going to hit an error on publishing
[12:45] <seb128> it still thinks usd is part of it
[12:45] <Trevinho> seb128: I've made a build, but nothing changed and sil2100 told us that there was nothing else to do
[12:45] <Trevinho> let me try to remove it again
[12:46] <seb128> well, maybe it's going to work
[12:46] <seb128> but it looks wrong
[12:47] <Trevinho> seb128: let's see if it works, in case it won't I try to rebuild the whole thing
[12:47] <Trevinho> seb128: you can publish too?
[12:47] <seb128> Trevinho, yeah, but unsure about the s390x issue
[12:47] <seb128> what is that?
[12:47] <Trevinho> seb128: basically unity never built in that arch, because the nux tests aren't passing in that arch
[12:48] <Trevinho> when it comes to use X to do some headless tests
[12:48] <seb128> but https://launchpad.net/ubuntu/+source/unity/7.4.0+16.04.20160415-0ubuntu1 has s390x build/binaries?
[12:48] <seb128> https://launchpad.net/ubuntu/+source/unity/7.4.0+16.04.20160415-0ubuntu1/+build/9586999
[12:48] <Trevinho> so, we could maybe try to disable the tests there, but really thre's no need for unity there...
[12:49] <pitti> seb128: heh yes, I saw that the other day
[12:51] <seb128> Trevinho, https://launchpad.net/ubuntu/+source/nux/4.0.8+16.04.20160209-0ubuntu2
[12:51] <Trevinho> seb128: mh, i see these artifacts http://pastebin.ubuntu.com/16520312/
[12:51] <seb128> Trevinho, when doing what?
[12:51] <seb128> that seems a shotwell issue?
[12:52] <Trevinho> seb128: that's in the brightray excuses
[12:52] <seb128> britney?
[12:52] <Trevinho> seb128<EMAIL_ADDRESS>[12:52] <Trevinho> yeah, sorry :-D
[12:52] <Trevinho> brightray is something electron related :-D
[12:53] <seb128> where is the britney page for that silo?
[12:53] <Trevinho> seb128: https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-028/excuses.html
[12:58] <seb128> Trevinho, "s390x: Always failed" so that's not a blocker
[12:59] <seb128> the issue is that you failed to build on s390x
[12:59] <seb128> Trevinho, " Missing build dependencies: libupstart-dev "
[12:59] <Trevinho> seb128: I know, but still I'm getting "red ci-train" which isn't nice :-)
[12:59] <seb128> on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028/+build/9756725
[13:00] <seb128> somebody retried upstart on https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu24
[13:00] <seb128> oh, no, that seems stalled
[13:01] <Trevinho> seb128: oh, actually the error on s390x is different from the one I had in the past: "Missing build dependencies: libupstart-dev"
[13:01] <Trevinho> so it's another thing
[13:01] <seb128> Trevinho, read what I just said
[13:01] <seb128> :p
[13:02] <seb128> see -devel
[13:03] <seb128> Trevinho, seems like you are blocked on xnox/slangasek to fix upstart build on s390x :-/
[13:03] <Trevinho> seb128: yeah, sorry...
[13:04] <Trevinho> in the mean time I noticed that there has been another direct push to nux, without ci-train :-/
[13:05] <seb128> doko, of course
[13:05] <seb128> feel free to tell him off on #ubuntu-devel
[13:06] <Trevinho> seb128: yeah... But sil2100 fixed it in the branch... Same happened for compiz in yakkety.  At least that was the policy I was thought, but I can basically prepare the same silo for X right nwo
[13:28] <Trevinho> now*
[13:28] <Trevinho> (almost the same)
[13:28] <seb128> it's the policy yes
[13:28] <seb128> but it's ready for y
[13:28] <seb128> it's just blocked by upstart on s390x
[13:29] <seb128> I think we can talk the SRU team into taking the xenial upload
[13:29] <seb128> though probably not today
[13:29] <seb128> they don't like friday uploads
[13:29] <seb128> monday is fine
[13:30] <Laney> they don't release to updates on friday
[13:30] <Laney> proposed is ok
[13:30] <Laney> afaik
[13:30] <seb128> k
[13:30] <seb128> some SRU team members are a bit conservative with that as well I think
[13:30] <seb128> but anyway we can get it in the queue
[13:30] <seb128> when they review it is their business then ;-)
[13:31] <seb128> Trevinho, also we need to deal better with important issues, that missing menus one should have been more prioritized and probably got its own silo, it doesn't make sense to block it on unity things to get fixed...
[13:31] <seb128> like we could have landed bamf to fix menus in y and x
[13:32] <seb128> it's a much easier thing to land than compiz+unity
[13:33] <Trevinho> seb128: I agree, it's just that the "fix" is probably not complete... And also I got some emails about not using tooo many silos (I had three around, because of trusty SRUs sitting there for months... And really I don't like bothering people about clearing the queue)
[13:33] <Trevinho> basically I did this: silos with 1,2 sru fixes... but this is not liked.
[13:34] <seb128> don't bother about that
[13:34] <seb128> the infra is there to be used
[13:34] <seb128> if they don't want silo to be stucked they can nag SRU team for reviews
[13:34] <seb128> I agree we shouldn't abuse silos
[13:35] <Trevinho> seb128: I'd like to know what's the best way to ping SRU team for reviewing a ci-train branch. Because it seems they don't get properly notified by sync queu elemenents
[13:35] <seb128> but fixing menus of LTS users is for sure justify using some CI resources
[13:35] <Trevinho> and they tend to stay there forever
[13:35] <seb128> they do
[13:35] <seb128> it's just that the diff are not generated by the queue
[13:35] <seb128> so they need to go back to ppa, fetch the package, etc
[13:36] <seb128> more manually work
[13:36] <seb128> pitti, ^ right?
[13:36] <seb128> Trevinho, also we don't need to use CI train to land, we can manually upload and merge
[13:36] <seb128> in fact I did bypass the train for the u-c-c/u-s-d SRUs I did to xenial
[13:37] <seb128> too much annoyance to use it
[13:37] <Trevinho> seb128: eh, yeah... you can. But I don't have the powers
[13:38] <Trevinho> seb128: I would like to use the silo to build, then get someone who can just upload those
[13:38] <seb128> why do you need the silo to build?
[13:38] <seb128> well it's going to have a test build/ppa
[13:38] <seb128> but yeah, we can force merge then and manually dput
[13:39] <seb128> Trevinho, you should apply for a ppu for the unity stack so you could dput ;-)
[13:40] <Trevinho> seb128: Ok, let me see... That isn't included if I apply for ~ubuntu-desktop, right?
[13:42] <seb128> Trevinho,
[13:42] <seb128> ubuntu-archive-tools/edit-acl query -s unity -S xenial
[13:42] <seb128> == All uploaders for package 'unity' ==
[13:42] <seb128> Archive Upload Rights for ubuntu-desktop: archive 'primary', package set 'ubuntu-desktop' in xenial
[13:42] <seb128> Archive Upload Rights for ubuntu-core-dev: archive 'primary', component 'main' in xenial
[13:42] <seb128>
[13:42] <seb128> Trevinho, it is in desktop set
[13:49] <seb128> tjaalton, do you know how to tell if libinput is enable?
[13:50] <seb128> tjaalton, I'm trying to use the libinput tests and I get "../../src/check_msg.c:80: No messaging setup" errors, unsure why
[14:00] <Trevinho> seb128: that means that if you can get me in, I don't need the ppu, right?
[14:00] <seb128> Trevinho, yes, let's see next week
[14:01] <Trevinho> ok
[14:02] <Laney> Still think that you could become a lander for unity/compiz/bamf just by talking to sil2100
[14:02] <Trevinho> sil2100: ^, make me a lander :-)
[14:02] <seb128> Laney, he can, but we were just saying that we want to not use the train forSRUs maybe
[14:03] <Trevinho> So i can freely break the desktop experience of everyone without having Laney to be my evil accomplice :-D
[14:03] <Trevinho> (without know it)
[14:04] <Laney> k
[14:16] <tjaalton> seb128: the x driver? from the xorg log
[14:17] <tjaalton> and basically just installing it means that it's used for mice/touchpads/touchscreens
[14:18] <seb128> k, any idea why the tests give me that error?
[14:20] <cyphermox> seb128: get me to look at what?
[14:20] <seb128> cyphermox, hey
[14:20] <seb128> cyphermox, bug #1571574
[14:20] <seb128> oem is nervous about it
[14:21] <seb128> and nobody in our team seems to currently have hardware
[14:22] <cyphermox> oh right
[14:23] <cyphermox> yeah, I suppose that might be broken, lemme try it here real quick
[14:25] <cyphermox> indeed, it's broke
[14:26] <seb128> cyphermox, any chance you could try to have a poke to it today?
[14:26] <cyphermox> that's what I'm doing now, I think I know exactly what's wrong
[14:26] <seb128> or do you know if I can easily emulate a 3g connection using dbusmock?
[14:26] <seb128> great
[14:26] <seb128> cyphermox, beer+=3
[14:26] <seb128> :-)
[14:26] <cyphermox> 3?
[14:27] <cyphermox> is that adjusted to drinker size? ;)
[14:27] <Laney> one drink per g
[14:29] <cyphermox> can we go with one mL per g instead?
[14:29] <Laney> but you're only fixing 3G
[14:29] <Laney> go for LTE then you can have a little bit more
[14:30] <cyphermox> it will fix LTE too
[14:30] <Laney> 4 drinks!
[14:30] <cyphermox> eep
[14:30] <cyphermox> OH
[14:30] <cyphermox> *those* Gs.
[14:31] <Laney> haha
[14:31] <cyphermox> I thought you meant the Gs that usually follow ks. :)
[14:32] <Laney> KO follows too many Gs of C2H5OH
[14:32] <cyphermox> looks like I had already spent some of this limited brainpower on my internet issues this morning
[14:32] <cyphermox> Laney: indeed
[14:33] <cyphermox> that applies to most C**OHs anyway.
[14:34] <tjaalton> seb128: no idea
[14:34] <Laney> some funky stuff in there
[14:34] <seb128> tjaalton, no worry, thanks
[14:35] <cyphermox> yeah. for instance C12H22O11 gets you diabetes, which will get you KO too
[14:43] <cyphermox> seb128: ok, fixed it; I'll build to see but it's stuff that was missing upstream from their merge of my indicator patch
[14:43] <seb128> cyphermox, \o/
[14:43] <seb128> cyphermox, going to make oem happy, thanks a lot!
[14:51] <pitti> seb128: silo SRU review> right, takes a bunch of clicks to see the real diff, otherwise the mechanism is the same
[14:54] <cyphermox> seb128: I raise you https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1583075
[14:54] <seb128> pitti, k, what I though
[14:55] <cyphermox> was just brought up to me by a friend, it looks like p12 is already in the extensions but something else may be amiss
[14:55] <seb128> cyphermox, https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1575614
[14:55] <seb128> cyphermox, backport https://git.gnome.org/browse/network-manager-applet/commit/?h=nma-1-2&id=037c5721d89b20c46ecc53e05d9867fd4d969412 with your fix
[14:55] <seb128> happyaron is looking at updating to 1.2.2 and I asked him to backport that
[14:56] <seb128> but we might want to do an upload with your fix + that
[15:06] <cyphermox> seb128: ok, 3g signal thing fixed although the icons we ship look like wifi, but that's not new.
[15:07] <seb128> cyphermox, \o/
[15:07] <seb128> cyphermox, want to maybe upload to y? we can handle SRU next week
[15:08] <cyphermox> yeah, I'll upload in a moment, just doing the p12 fix now
[15:15] <seb128> cyphermox, you saw the commit I pointed?
[15:16] <seb128> cyphermox, just checking if you "doing" means backporting or redoing :-)
[15:17] <cyphermox> backporting
[15:17] <cyphermox> I don't write code if I can avoid it ;)
[15:19] <ximion> Laney: looks like the strup issue in appstreamcli became a big hit overnight :P
[15:19] <ximion> not sure which cosmic fluke was responsible for users seeing it now, but fortunately the update is out now
[15:20] <seb128> tjaalton, just for the record my issue was permissions, need to use sudo
[15:20] <seb128> ximion, see channel backlog from earlier today if you want some details
[15:21] <seb128> but seems it was triggered by an update being published to backports
[15:21] <Laney> fun one
[15:21] <ximion> seb128: is the backlog stored somewhere?
[15:21] <Laney> ximion: you get your "broke ubuntu" badge :P
[15:21]  * ximion wasn't in the channel earlier
[15:22] <ximion> Laney: I would also need to get a "fixed Ubuntu before he broke it" badge ^^
[15:22] <seb128> ximion, http://irclogs.ubuntu.com/2016/05/20/%23ubuntu-desktop.html#t08:53
[15:22] <seb128> though I guess the discussion doesn't have much details on what Laney did
[15:23] <ximion> Laney: the priority value triggered it? Weird!
[15:24] <ximion> previously, no user experienced this bug, and it was in the code for a long time and run by users at Debian ^^
[15:24] <cyphermox> seb128: fyi: https://mail.gnome.org/archives/networkmanager-list/2016-May/msg00066.html
[15:25] <seb128> cyphermox, https://bugzilla.gnome.org/show_bug.cgi?id=766709 btw
[15:25] <seb128> I had it forward
[15:25] <seb128> sorry I didn't mention, but the launchpad bug had the bug watch
[15:25] <cyphermox> ah, sorry
[15:25] <seb128> cyphermox, thanks :-)
[15:25] <cyphermox> I'm updating the bug
[15:26] <seb128> thanks
[15:28] <ximion> seb128: thanks!
[15:28] <ximion> btw, we have an unittest for this bug upstream for a while now :-)
[15:28] <seb128> davmor2, ^
[15:30] <davmor2> seb128: oh nice
[15:32] <ximion> Laney: maybe important to know: this bug can *still* be triggered, even with the patch, if you feed appstream malformed YAML
[15:32] <ximion> we resolved this upstream too, and Yakkety should be completely safe
[15:33] <Laney> sounds like a good one to backport
[15:33] <ximion> since there usually is no broken YAML, triggering this bug should not happen though (you need to be root to install busted YAML)
[15:34] <ximion> yes, might still be useful to have
[15:34] <Laney> generator bug or third party repo
[15:34] <ximion> background is that the YAML parser wasn't checked correctly for errors which occur due to malformed YAML files, which sends appstreamcli into an infinite loop
[15:35] <ximion> jap
[15:35] <Laney> the apt hooks are a bad place to have a program hanging
[15:35]  * ximion agrees
[15:35] <Laney> since the repository can't give you a package to get you out
[15:35] <ximion> oh, it can - but only if you don't refresh the cache before attempting to upgrade :P
[15:36] <Laney> ._.
[15:36] <ximion> https://github.com/ximion/appstream/commit/f5a2f4da6e1bdce89124858d672e9ddea051b172 is the thing
[15:37] <ximion> it grew a bit bigger, because I wanted to fix other things too
[15:38] <ximion> when that other bug in appstream-glib is fixed, there should be no way to bring AppStream down anymore
[15:54] <ximion> PK >> 1.0 in Yakkety, nice :-)
[15:55] <seb128> not quite yet
[15:55] <seb128> it's in proposed like it was previous cycle
[15:56] <seb128> let's see if doko deals with aptdaemon and the other things in breaks
[16:01] <ximion> seb128: IMHO it would make a lot of sense to just drop the pkcompat layer from aptdaemon
[16:01] <seb128> yeah, probably, we discussed that before xenial
[16:01] <ximion> have stuff which uses PK use PK, and things which use the aptd API use aptd - aptd mimicking PK is just a source of bugs
[16:01] <seb128> I don't remember what issues we had with changing that though
[16:02] <ximion> seb128: those would be interesting to know, because if they are easy to accomodate to on the PK upstream side, we might just do the changes
[16:02] <seb128> I think it was more distro technical debt
[16:03] <seb128> or fixing things that depends on the compat layer
[16:03] <ximion> there's stuff depending on the compat layer?
[16:03] <ximion> that'd be weird... (since everything is using it via libpackagekit-glib2...)
[16:07] <seb128> well, depends in the debian/control sense
[16:07] <ximion> right, that is a different thing
[16:07] <seb128> I think I remeber why we didn't drop it in xenial
[16:08] <seb128> it's because we said it wouldn't make sense to replace it by the outdate/buggy pkgkit 0.8 code
[16:08] <ximion> (but then I would argue that fixing a few packages is less work than adapting aptd - at least in Debian, there is only one package depending on aptd at time, which means everything doing so in Ubuntu must be due to Ubuntu-specific patches)
[16:08] <seb128> and we couldn't update packagkit because of click
[16:09] <seb128> now for y we decided to ignore click
[16:09] <seb128> so we can update packagekit
[16:09] <seb128> and probably drop the aptdaemon compat
[16:09] <ximion> yeah, GNOME Software with PK << 1.0 just doesn't work at all :P
[17:01] <Laney> happy weekend!
[17:01] <Laney> flexiondotorg: I should probably share my CSS changes with you at some point, will give you that soon
[17:01]  * Laney laters
[17:02] <Trevinho> Laney: have nice WE
[17:10] <seb128> Laney, have a good w.e!
[17:13] <flexiondotorg> Laney, great.
[17:13] <flexiondotorg> Laney, https://github.com/flexiondotorg/ubuntu-mate-themes
[17:14] <flexiondotorg> That is where we are adapting the MATE themes to 3.18 for MATE 1.14 built against GTK3.
[17:14] <flexiondotorg> When that is done, we'll branch and start work on 3.20 in the same repo.
[17:40] <willcooke> EOW!  night all, have a great weekend
[17:44] <seb128> have a good w.e desktopers!
[21:12] <Beret> so
[21:12] <Beret> how does one fix the gnome software rubbish in 16.04? :)