=== JanC_ is now known as JanC === jamesh_ is now known as jamesh [06:21] morning all [06:22] Morning willcooke [06:22] hey duflu! [06:23] duflu, L_aney has a fix for the sound issue - "sudo touch /usr/share/sounds" [06:23] worked here [06:23] would be interested to know if it does for you too [06:23] so quit settings, touch that file, re-open settings - set to mono, test [06:26] willcooke, Yes that worked. Why?? :) [06:27] :) [06:27] " so if you tried to play it before it existed, it caches the not found" [06:28] willcooke, So maybe a new update that does a touch too? [06:29] Laney: eek, sorry; fixed (force-pushed) [06:30] duflu, I'll wait to speak to L_aney later and see what the best idea is. Will keep you posted. [06:31] I'm not too bothered about any bug that won't ever happen with the final release [06:32] I am however bothered by this headache. Time to go to the chemist [07:33] Just noticed I have an Ubuntu Control centre in my launcher-thingy in Shell. I assume this is because it's my old Artful machine, but just wanted to check that was covered by the migration? [07:45] morning [07:45] https://popey.com/blog/posts/ubuntu-artful-desktop-july-shakedown.html [07:46] you might get some new people drop by with feedback this week [08:03] morning [08:09] hey u.k people (and other desktopers too) [08:09] how are you? had a good w.e? [08:11] willcooke, it's migrated to gnome-control-center. [08:11] willcooke, so it depends when you upgraded to artful [08:11] jibel, thought so, so it's just my "old" install [08:11] jibel, nod - thanks [08:13] old install should have been migrated but there was a bug in the .desktop name iirc [08:13] so maybe you caught the wrong version of the script [08:13] should work for those upgrading today [08:13] seb128, the first migration script didn't upgrade u-c-c to g-c-c [08:13] then there was a typo iirc [08:14] then there was a typo [08:14] now if should be working though [08:14] yup, it does [08:14] unsure if it's worth doing more work for the few people who upgraded in that slot where things were buggy [08:19] dont think so [08:20] Heh. PulseAudio backlog: May=1427, today=414 [08:21] duflu, woot, well done [08:22] :D [08:24] Also, only three crashes (two bugs) in the artful pulseaudio release. None of which are regressions of what was fixed [08:25] Morning Laney duflu seb128 jibel [08:25] Morning flexiondotorg [08:28] hey flexiondotorg [08:29] hi flexiondotorg [08:29] o/ [08:30] monring alls [08:31] hi flexiondotorg [08:31] you good? [08:31] Laney yah :-) [08:32] I need some advice later though. [08:32] I had the chance to look at indicator-session at the weekend. [08:32] You're right, it warns. [08:32] hey andyrock, how are you? [08:32] I wasn't able to find a way to cast that string. [08:32] andyrock o/ [08:33] flexiondotorg: (const gchar * const *) is ok [08:33] C sucks there [08:33] hey seb128 jibel andyrock too [08:34] seb128: in Tuscany sprinting with Trevinho [08:34] you? [08:34] hi seb128, Laney [08:34] duflu, when I've a BT speaker paired, the test sound from sound settings goes to the speaker, but there is no sound when I play from totem or vlc. Any idea what could be wrong? [08:35] jibel: give pavucontrol a try [08:35] Laney ty. I'll try in a bit. [08:35] jibel, also check the Appilcations tab in the sound control panel [08:36] I've never had that problem but it's worth checking if apps are muted [08:36] jibel, it is however possible, even likely, you're playing videos without the required audio codecs installed too [08:37] hey Trevinho [08:37] Although totem would complain if that was so [08:37] andyrock, nice relaxing w.e here ;-) [08:38] in pavucontrol the output for vlc was internal audio. I switched to the speaker and it works [08:44] jibel, did you start the app before creating the BT audio device? [08:44] If so it may stick with the internal speaker [08:49] duflu, no, I rarely use totem. [10:09] Laney made that change, it triggers a warning elsewhere now. [10:13] https://launchpadlibrarian.net/329253635/buildlog_ubuntu-artful-amd64.indicator-session_17.3.20+17.10.20170613-0ubuntu1~artful4.2_BUILDING.txt.gz [10:16] Laney I originally styled have_mate_program() after have_unity_control_center() [10:16] http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk.16.10/view/head:/src/backend-dbus/actions.c#L841 [10:17] Would it be acceptable to revert have_mate_program() to follow a similar implementation to have_unity_control_center()? [10:22] flexiondotorg: where's the elsewhere? [10:22] I don't think you have to fix warnings you didn't introduce :-) [10:34] Well the warning are still in have_mate_program() [10:34] Search "warn" in the build log above. You'll see it. [10:35] Then you mislead me by using the word 'elsewhere' [10:35] Where's the code? [10:36] misled* [10:38] Laney This is the line that now warns - http://bazaar.launchpad.net/~ubuntu-mate-dev/indicator-session/mate-integration/view/head:/src/backend-dbus/actions.c#L107 [10:39] thx [10:39] desktop_names = g_strsplit (xdg_current_desktop, ":", 0); [10:40] http://paste.ubuntu.com/25111231/ [10:43] flexiondotorg: http://paste.debian.net/976884/ I think that [10:50] Laney thanks. I'll give that a whirl. [10:59] seb128: can you please ack this https://code.launchpad.net/~3v1n0/unity-control-center/lowgfx-listens-compiz-profile/+merge/327400 ? [11:39] laney@social-mite:~$ cat /etc/X11/default-display-manager [11:39] /usr/sbin/gdm3 [11:40] #noprompt [11:59] Trevinho, k for the review [12:04] Laney thanks for your help. Warning free and tested - https://code.launchpad.net/~ubuntu-mate-dev/indicator-session/mate-integration/+merge/325600 === oscar___ is now known as KlavKalashj [12:05] flexiondotorg: ok, nice, looks good now [12:23] jibel: will Ubuntu be opting in to any of the milestones before Final Beta this cycle? [12:25] that's not likely [12:25] iirc the previous discussions about that [12:26] were there discussions about this cycle in particular? [12:28] no, is this cycle particular? [12:28] yes ;) [12:28] jbicha, have you seen the blog from p_opey? [12:28] today [12:29] yes [12:29] I think that's rather that sort of calls for testing that you can expect [12:29] the alpha&co involves freezes etc and that's too much overhead [12:30] jbicha, no, we'll do like previous releases [12:31] ok, thanks [12:31] jbicha, as seb128 said we'd rather do targeted testing when something major lands [13:08] plans change eh [13:08] I never knew that the idea to do Alpha 2 has been canned [13:14] https://irclogs.ubuntu.com/2017/04/18/%23ubuntu-desktop.html#t16:07 [13:37] jbicha, you seem to like to dig IRC logs and take them as statements written in stone :-) [13:38] I think opting for a2 is fine if it some people want to handle the paperwork and if it doesn't block others in their work [13:41] I probably forgot some discussion [13:41] * Laney isn't that bothered actually [13:42] seb128: I had the same impression Laney did that we were participating in A2 (based on the first big cycle meeting) but I asked today to confirm since it seemed like my impression was wrong [13:44] it's not a big deal for me but it might be useful if it can be done without burdening Canonical QA much [13:44] right [13:45] I didn't remember that discussion now [13:45] but my position is the same as when we discussed it back then [13:45] I remembered it as the goal was to get a basic GNOME session usable by A2, which we have done [13:45] if somebody wants to do the work and it doesn't block others to do their things feel free [13:45] right [13:46] that call for testing from p_opey is covering that [14:11] jbicha, actually there is more value in p_opey's cft than an alpha. We are not really interested in people manually checking that the iso is installable, it is already covered by automated tests. [14:12] and a release even for an alpha is 2 to 3 days of work [14:12] besides I'll be on holidays for alpha2 [14:14] and it's during GUADEC [14:30] heber, upgrade tests are green again. I'll merge your stuff. If it's all red tomorrow, you'll know why ;) [14:30] https://popey.com/blog/posts/ubuntu-artful-desktop-july-shakedown.html #julyshakedown [14:31] jibel, okay ;) [14:31] What is the link to see all of the #julyshaedown bugs in launchpadd ? [14:33] What is the link to see all of the #julyshakedown bugs in launchpadd ? [14:42] chrisccoulson: probably should have CCed you on orginal email, oops. Any thoughts on dropping some archs that Firefox builds on? (https://lists.ubuntu.com/archives/ubuntu-desktop/2017-July/005040.html) [14:44] gQuigs, you are asking the wrong person :-) [14:45] the people who care about building on those archs are rather in foundation team [14:49] seb128: so I should figure out who maintains it's arch I think we might want to drop and see if they care about Firefox on that arch? [14:49] yes [14:50] but basically ask infinity I would say [14:51] alright, thanks [14:51] he's the one who argued in favor of keeping those builds previous cycle and said he would prefer to be asked to help fixing build than having archs removed [14:52] still cannot find the bugs with the hashtag #julyshakedown ? https://launchpad.net/ubuntu/+search?text=%23julyshakedown [14:52] Dadprimeday, search by tag in advanced search [14:52] https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.struc [14:52] tural_subscriber=&field.component-empty-marker=1&field.tag=julyshakedown&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_no_package.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_bl [14:52] ueprints.used=&field.has_no_blueprints=on [14:52] err [14:53] one sec [14:53] urgh, don't use that URL [14:54] Go to search -> advanced search -> tag = "julyshakedown [14:54] " [14:54] there aren't any at the momnet [15:00] infinity: hi there, any chance you've changed your mind about not dropping archs in Firefox? (discussion above) [15:02] infinity: for example, the worst (modern) case is s390x which appears to have last been built on Firefox 47 [15:05] that firefox on s390x does not exec [15:05] well, it execs but segfaults shortly after (the 47 one) [15:06] It was dropped on s390x ages ago. [15:11] infinity, xenial-release pocket?! [15:12] I definitely still see it trying to build - https://launchpad.net/ubuntu/+source/firefox , not sure if could have been dropped somewhere else [15:14] xnox: We don't remove things from the release pocket. [15:14] gQuigs: "Trying to build" doesn't mean the arch is shipped. [15:14] gQuigs: And it's not a bug to try to build things. [15:15] infinity: k, so how do I see what archs are blocking Firefox 54 from being updated in artful? (or is it something else?) [15:16] gQuigs: Looks like armhf and ppc64el. excuses would tell you. [15:17] But "Oh, it's FTFBFS, we should just remove it" is not a mantra we should live by. [15:18] infinity: that's not my manta.. mine is if we provide a security sensitive package like a browser it should be up-to-date - if it's not we are putting the people who use it at risk [15:19] how have I never seen excuses before, that's really useful [15:28] infinity, well, at the same time if nobody uses them on those archs and it's blocking the updates on the archs where it has users then it's an issue [15:28] seb128: Who decides if it has users? [15:29] that's not something to be decided [15:29] we don't vote users [15:29] Then it's not a useful statement. :P [15:29] neither is yours [15:29] in practice how many people are using firefox on ubuntu ppc64el do you think? [15:30] I have no idea. [15:30] neither do I [15:30] armhf, on the other hand, we know is quite used. [15:31] but I'm ready to bet that it's a magnitude lower than our most used desktop archs [15:31] seb128: Well, yes, but I could use that same argument for dropping glibc on all but x86. [15:31] Non-x86 is an order of magnitude fewer users, period. [15:31] I'm pretty sure glibc is useful to people using s390x machines [15:32] I've to see a report from a s390x desktop user yet [15:32] seb128, we have had IBM qa doing ssh -X and expecting to launch firefox [15:33] seb128, and i'm like... why would you not use firefox on your machine you do ssh -X from... [15:33] seb128, and the person was like but i need to access internal localhost website..... [15:33] seb128, i gave them links about port forwarding [15:34] infinity, glibc - there are command-line tools available with it. [15:39] xnox: Commandline versus desktop has nothing to do with the "number of users" argument that was being made. [15:39] If we argue by "number of users", we should drop all non-x86 ports. But we don't. [15:39] Certain parts of the OS aren't more or less sensitive to the "number of users" argument. [15:44] Laney, i want to fix debhelper to be better. [15:44] e.g. do not install upstart jobs even if present; do not install init.d script if systemd unit is present [15:45] infinity: if we weren't able to provide security updates to apache on ppc64el would we drop it from that arch? [15:46] gQuigs, we would not. [15:46] gQuigs, as otherwise there would be no point in shipping universe [15:47] gQuigs: Are we unable to provide security updates for firefox? [15:47] I see updates in zesty-security. [15:48] xnox: apache is in main.. [15:48] Anyhow, the real answer here is that we should talk to IBM and ARM and see what THEIR carefactor is, and what they're willing to do. [15:48] gQuigs: And no, we wouldn't drop apache on ppc64el, we'd fix it. Because there's no sane argument for apache on ppc64el to not work except "someone can't program in C". [15:49] Web browsers live in this "special" world where, apparently, portably programming isn't hip and cool. But I don't think that should be the new normal. :P [15:49] s/portably/portable/ [15:50] infinity: ppc64el Firefox last release was 52, so it's 2 releases behiind [15:50] I know. [15:50] Two releases isn't that long in firefox land. [15:50] gQuigs, weather we can provide security support is tangentile to which components something is in; and what arches it is available in. Just because we cannot provide security support for something, does not mean we will not ship something. [15:55] I think there is more value in keeping firefox updated for armhf, that might be worth the investment in the maintenance [15:55] just not sure I can say the same for s390x and ppc64el [15:56] but even armhf isn't going to have a huge user base, but there are users with armhf laptops out there [16:02] infinity: my real issue is that we are providing a disservice to anyone running the dev release, we aren't testing the latest Firefox on amd64,etc (unless people know to grab the PPA themselves) [16:02] I'm open to any other options that would fix that... [16:05] gQuigs: So, the obvious solution to that (which I was doing in the tail end of zesty or yakkety) is to copy those to artful-security. I might do that again. [16:06] But I really think we need to be talking to our partners here about their upstream issues. [16:08] infinity: +100 if we can do that regularly (and not just right before the release) I think that works [16:15] kenvandine And chrooting Ubuntu on phones and tablets. Plus some builds of Ubuntu on assorted SBCs. [16:23] infinity, xnox, well, another way to look at it is that whatever team which has staff working on the s390x support should help resolving firefox build issues on that arch [16:23] s390x is a straw man here, as it's already not blocking anything. The s390x binaries were removed. [16:24] But yes, I'll poke IBM again about ppc, and ARM about armhf. [16:24] This time around (because of the rust interaction), it may indeed need their involvement. [16:25] The flipside is that we've had many failures in the past where the fixes were trivial, and just not investigated because "we don't care", which isn't how we'd deal with an FTBFS in any other package, so I don't see why firefox would get a free pass. [16:27] infinity, thanks [16:37] thanks all! [16:41] anyone with experience with snapping desktop apps and fixing up the path to the icon? [16:41] + prepare: [16:41] + sed -i.bak -e 's|=org.gnome.clocks$|=${SNAP}/meta/gui/org.gnome.clocks.png|g' data/org.gnome.clocks.desktop.in [16:41] i'm doing that and copying the icon into that directory, all seems to work fine [16:41] but [16:41] it breaks this [16:42] desktop: usr/share/applications/org.gnome.clocks.desktop [16:42] if i don't sed it in prepare, it doesn't complain there [16:42] * kenvandine scratches head [16:44] i guess i probably need to wait for didrocks [16:55] well wtf... now it's working :) [16:55] no idea what i did to fix it... but now i have an icon and a launcher :-D [16:56] * kenvandine ships it [17:32] seb128: did you give a look to that branch? :) [17:34] Trevinho, by weather you mean whether right? ;-) [17:35] seb128: eheh yeah :) [17:35] Trevinho, looks fine otherwise [17:46] seb128: thanks, I've fixed the typo [17:47] thanks [18:49] flexiondotorg: could you use bileto for your indicator-session upload? [18:49] (sponsoring isn't really an #ubuntu-release question) [18:50] jbicha Ummm. Maybe, me checks... [18:54] jbicha OK, quick skim of the wiki. Looks possible. Not sure if I have permission, will find out... [18:55] you have the permission to build with bileto, but maybe you're supposed to ask someone else to do the publishing for things you don't have upload rights for [19:16] jbicha I was extended those permission a few weeks ago. [19:16] I'm now learning the ropes... [19:31] jbicha So at some point I'll get to this point "In the event that you do have either packaging changes or manual sources, it is your responsibility to find a core dev to publish the PPA for you." [19:52] jbicha My packaging diff requires an ACK. Can you do that? https://bileto.ubuntu.com/#/ticket/2869 [19:59] "core dev" is a simplification, ~ubuntu-desktop usually has upload rights to Unity-related packages [20:00] or MOTU now even [20:04] Thanks jbicha [20:54] seb128: could you 'bzr add' your recent patch for evolution and e-d-s? [22:24] jamesh, can you commit your snap launch logic from master to the gnome-3-24, gnome-3-22 and gnome-3-20 branches? [22:24] I'm queing up the next SRU.. [22:35] jamesh, the 3.20 changes should go into wip/ubuntu-3-20