[06:00] <hikiko> hello!
[06:15] <pitti> Good morning
[07:31] <om26er> Hi! I upgraded to Zesty and things are not looking good. unity' DPI scaling is not working for my gtk apps, also app menus are shown in both window and in menubar.
[07:31] <om26er> Also this issue does not happen when I live boot zesty, only shows itself after install
[07:33] <om26er> http://i.imgur.com/cLN4NSS.png
[07:39] <duflu_> Hmm I never thought to try U7 in zesty. Only testing U8  :)
[07:40] <pitti> om26er: that sounds familiar
[07:41] <pitti> om26er: probably bug 1637758
[07:41] <ubot5`> bug 1637758 in lightdm (Ubuntu) "lightdm greeter session not properly shut down at login" [High,In progress] https://launchpad.net/bugs/1637758
[07:41] <pitti> I have a fix, but didn't get a review yet
[07:41] <pitti> I'll probably just upload it to zesty before landing in trunk, as it does break a lot
[07:42] <duflu> pitti: I've been wondering how hard it would be to start the Unity7 session (or anything X) with $DISPLAY pointing to Xmir (inside Unity8)...
[07:42] <duflu> ?
[07:43] <duflu> Xmir is my domain at the moment but I don't know how to launch an arbitrary session
[07:44] <pitti> a session within a session? won't that make a lot of things 'orribly confused? (settings-daemon, different $DESKTOP_SESSIONs in different processes, etc.)
[07:44] <duflu> pitti: That's what I feared. But in theory the graphics and input is ready and would work
[07:45] <pitti> duflu: as a first approximation you can try "systemctl --user start ubuntu-session.target" (which is u7)
[07:45] <duflu> pitti: OK, thanks
[07:45] <pitti> duflu: oh, and before that systemctl --user set-environment DISPLAY=something
[07:46] <duflu> I already know Compiz will run happily hardware accelerated in an Xmir window so it would be interesting
[07:46] <pitti> duflu: but which u{7,8} will actually render the background, launcher, and panel  then?
[07:46] <pitti> oh, nevermind
[07:47] <duflu> pitti: Windowed :)
[07:47] <pitti> you weren't talking about u8, just u7 underneath mir
[07:47] <duflu> U7 in a U8 window
[07:47] <pitti> so Xephyr/Xnest-like?
[07:47] <duflu> I guess so
[07:48] <duflu> Although the lag is even higher then. I need to continue working on that first
[08:00] <Sweet5hark> moin
[09:00] <willcooke> good morning all
[09:01] <pitti> hey willcooke, how are you?
[09:01] <willcooke> hey pitti.   Reserving judgment.
[09:05] <pitti> hey flexiondotorg, hey Laney, hello hikiko
[09:06] <pitti> wow, at 10:00 this channel explodes with life \o/
[09:06] <pitti> we went to a "Bluegrass Jamboree" in our local theater last night, was great -- nice selection of bands again
[09:07] <hikiko> 11 for me :)
[09:09] <Sweet5hark> morning flexiondotorg, pitti, duflu, hikiko, slightly overcooked willcooke
[09:10] <duflu> Morning, morning
[09:10] <pitti> moin moin Sweet5hark
[09:13] <om26er> pitti: I installed lightdm 1.20.0-0ubuntu3 but it does not fix the issue that I am seeing. i.e. app-menu of gtk apps is shown twice(in top panel and in window itself). Font size changes have no effect to gtk apps
[09:14] <pitti> om26er: hm, ok; you rebooted afterwards?
[09:15] <om26er> pitti: no, just logged out
[09:15] <pitti> om26er: sudo loginctl terminate-user lightdm
[09:15] <pitti> om26er: then log out/back in again
[09:16] <pitti> om26er: there were probalby some lingering lightdm sessions around; the patch fixes those, but it doesn't kill old sessions from previous lightdm versinos
[09:17] <seb128> good morning desktopers!
[09:17] <flexiondotorg> seb128, g'day
[09:18] <pitti> bonjour seb128
[09:18] <om26er> pitti: reboot did fix it.
[09:18] <pitti> great
[09:23] <davmor2> Morning all
[11:59] <flocculant> willcooke:you one of those youngsters refusing to make people use jumpers till the window has ice on it then :p
[11:59] <willcooke> flocculant, damn right.  You're cold? Run around
[12:01] <flocculant> but but - you had the heating on :p
[12:04] <Laney> in the office only
[12:04] <Laney> which nobody is allowed in so they wouldn't know
[12:23] <flocculant> oh well that's ok then :p
[14:31] <qengho> I need help with app icons for snapped applications. How is BAMF_DESKTOP_FILE_HINT supposed to work?
[14:44] <seb128> qengho, hey, read #snappy backlog Trevinho and jdstrand were discussing that a bit earlier
[14:45] <seb128> qengho, bug #1643910
[14:45] <ubot5`> bug 1643910 in bamf (Ubuntu) "BAMF_DESKTOP_FILE_HINT not set in correct place for unity7" [Undecided,Triaged] https://launchpad.net/bugs/1643910
[14:45] <Trevinho> qengho: basically if you define that in the wrapper script, BAMF will use that .desktop file to match the child windows...
[14:45] <Trevinho> if the app windows have WM_PID, but that should happen 99% of the time
[14:48]  * Trevinho is not sure wether he would prefer realtime logs from launchpad builders, and stop hitting F5, or just the way they are as he would stay stearing at them the whole time otherwise
[14:49] <seb128> do something else and come back to it later!
[14:53] <didrocks> Trevinho: no downtime slacker! :-)
[14:54] <Trevinho> seb128: no, it's just that... I love looking at logs of biulders when they come :-D
[14:54] <Trevinho> so I've to resist
[15:06] <willcooke> seb128, sorry to spring this on you...
[15:06] <willcooke> seb128, school just phoned and after-school club is cancelled, so I need to go and pick up Boy#1.  Could you run the meeting for me?
[15:06] <willcooke> or any other desktoppers ^
[15:06] <willcooke> I'll forward the email notes from those who can't make it
[15:06] <seb128> willcooke, sure, no problem
[15:07] <willcooke> thanks seb128, feel free to delegate :)
[15:07] <seb128> no need for that, i'm around and happy to do it
[15:08] <desrt> Sad to miss the meeting, but I will be boarding in a moment.
[15:09] <willcooke> safe travels desrt
[15:09] <seb128> desrt, safe travel!
[15:10] <desrt> danke
[15:10] <desrt> Spending 1 night in Barna.  I love Europe.
[15:10] <seb128> :-)
[15:29] <Laney> ahh sebmeetings
[15:30] <seb128> :-)
[15:30] <seb128> #startmeeting
[15:30] <meetingology> Meeting started Tue Nov 22 15:30:37 2016 UTC.  The chair is seb128. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:30] <meetingology> Available commands: action commands idea info link nick
[15:30] <seb128> Roll call: andyrock, attente, desrt (out),  dgadomski, fjkong (out), flexiondotorg, happyaron (out), hikiko, laney, qengho, seb128, sweet5hark, themuso (out), tkamppeter, trevinho, robert_ancell (out)
[15:30] <flexiondotorg> o/
[15:30] <Sweet5hark> aye
[15:30] <didrocks> o/
[15:31] <attente> didrocks: joining the meeting?
[15:31] <hikiko> oh seb128 I forgot and I was about to leave, could I go first if the others dont mind?
[15:31] <seb128> didrocks! ;-)
[15:31] <didrocks> attente: tried to see if people noticed :)
[15:31] <desrt> Hi from the apron
[15:31] <attente> lol
[15:31] <seb128> k, let's get started then
[15:31] <hikiko> I forgot to email the bullets I mean
[15:31] <seb128> #topic hikiko
[15:31] <seb128> hikiko, your turn!
[15:31] <hikiko> thank you :)
[15:32] <seb128> yw ;-)
[15:32] <seb128> you can go and paste your update...
[15:32] <hikiko> low gfx stuff in ucc and tools and today started working on chromium-mir stuff too
[15:32] <hikiko> eof
[15:32] <hikiko> thank you :) +sorry
[15:32] <seb128> thanks hikiko
[15:32] <seb128> let's continue with our special guest
[15:32] <seb128> #topic didrocks
[15:33] <seb128> didrocks, hey :-p
[15:33] <didrocks> hey! :)
[15:33] <didrocks> * created face detection snap on armhf
[15:33] <didrocks> * snaps are awesome, snap the world, snap the desktop !
[15:33] <didrocks> EOF
[15:33] <seb128> wooot
[15:33] <flexiondotorg> :-)
[15:33] <seb128> thanks didrocks ;-)
[15:33] <seb128> #topic andyrock
[15:33] <seb128> let's resume normal order!
[15:33] <seb128> andyrock, hey
[15:35] <seb128> oh, he's off until thursday
[15:35] <seb128> sorry I forgot about that
[15:35] <seb128> #topic attente
[15:35] <seb128> attente, your turn then!
[15:35] <attente> :o
[15:35] <attente> i was off friday
[15:35] <attente> snapcraft jhbuild plugin ready now, submitted a PR
[15:36] <attente> content-hub-glib and gtk copy-paste debugging under xenial, need someone to review the gtk part once the content-hub side lands
[15:36] <attente> (which should be very soon)
[15:36] <attente> (eof)
[15:36]  * desrt has new work for attente :)
[15:36] <seb128> nice work on the jhbuild plugin!
[15:36] <flexiondotorg> Indeed!
[15:36] <seb128> (on the copy-paste as well)
[15:36] <seb128> thanks attente
[15:36] <attente> just hoping it merges upstream...
[15:37] <seb128> we can convince them I'm sure ;-)
[15:37] <seb128> #topic desrt
[15:37] <seb128> desrt, still around, want to paste your update or should I do it?
[15:38] <desrt> Please paste
[15:38] <desrt> I'm on my phone, in the plane
[15:38] <seb128> k
[15:38] <seb128> - work continues on dconf proxy
[15:38] <seb128> - finally have it under version control as wip/proxy branch on upstream
[15:38] <seb128> dconf
[15:38] <seb128> - the security stuff is now fully sorted (+ thanks to snap team for
[15:38] <seb128> adding xdg subdir support to snappy)
[15:38] <seb128> - put a fair amount of effort into starting to "robustify" the code
[15:38] <seb128> (since this is a security component)
[15:38] <seb128> - security-related aspects of support for flatpak-based clients is in
[15:38] <seb128> place (again, with caveat about signal broadcasts not being filtered by
[15:38] <seb128> flatpak)
[15:38] <seb128> - now we really need to get apparmor support working (hopefully attente
[15:38] <seb128> can chase up the security guys again for this)
[15:38] <seb128>
[15:38] <seb128> thanks desrt ;-)
[15:38] <seb128> #topic dgadomski
[15:38] <seb128> dgadomski, hey
[15:38] <dgadomski> hey
[15:38] <desrt> Thanks Seb :)
[15:38] <dgadomski> no updates this week, I'm recovering from the sprint last week ;)
[15:38] <dgadomski> eof
[15:39] <seb128> thanks dgadomski
[15:39] <seb128> #topic FJKong
[15:39] <seb128> fixed and upload package to debian
[15:39] <seb128> #1575353 Gnome Software catalog entry missing for CQRLOG
[15:39] <seb128> #1593244 Gnome Software catalog entry missing for Xnec2c
[15:39] <seb128> #1575356 Gnome Software catalog entry missing for Fldigi
[15:39] <seb128> firefox:
[15:39] <seb128> #1498972 #1639863 is on progressing
[15:39] <seb128> #topic flexiondotorg
[15:39] <seb128> flexiondotorg, hey!
[15:39] <flexiondotorg> Hi
[15:39] <flexiondotorg> · Background reading about Bileto.
[15:39] <flexiondotorg> · Attended UOS sessions Tuesday/Wednesday afternoon/evening.
[15:39] <flexiondotorg> · Researched this weeks candidates for the Snap Upstream Blitz and updated their Trello board.
[15:39] <flexiondotorg> · Unity 8 desktop snap testing.
[15:39] <flexiondotorg> · Filed a bug (previously thought fixed) while building Python snaps on Launchpad (LP: #1642281)
[15:39] <flexiondotorg> · Completed the ISV Upstream on-boarding.
[15:39] <ubot5`> Launchpad bug 1642281 in Snapcraft "Unable to build python based snap on Launchpad" [Undecided,New] https://launchpad.net/bugs/1642281
[15:39] <flexiondotorg> · Updated some example GTK3+ snaps to current standards.
[15:40] <flexiondotorg> · Friday/Saturday/Sunday UbuCon Europe - which was excellent!
[15:40] <flexiondotorg> · Impromptu Raspberry Pi 3 server hosting for _didrocks. Thank goodness for fibre!
[15:40] <flexiondotorg> · Have started contacting upstreams and ISVs (everyday) to advocate snapping of their projects/products.
[15:40] <flexiondotorg> · Positive contact with uGet project to use snaps and adopt the GTK3 platform snap when it is available.
[15:40] <flexiondotorg> 🎬
[15:40] <seb128> thanks flexiondotorg
[15:41] <seb128> #topic laney
[15:41] <seb128> Laney, hey
[15:41] <Laney> hej
[15:41] <Laney> • gstreamer 1.10 & rebase sru that got trumped by a security update (please verify if you're on x, it's been sitting for a while)
[15:41] <Laney> • deployed new asgen to production, some final fixes, got commit access, just need to switch dns now to make it used
[15:41] <Laney> • some -proposed gardening
[15:41] <Laney> • new glib @ debian/zesty & testfixes for that
[15:41] <Laney> • worked on a glib trash bug fix, asked reported to test proposed patch
[15:41] <Laney> • some proposed-migration babysitting
[15:41] <Laney> 🙎
[15:42] <didrocks> thanks flexiondotorg for the rpi3, that really helped! :)
[15:42] <flexiondotorg> yw
[15:42] <seb128> thanks Laney
[15:43] <seb128> Laney, speaking of glib we got some launchpad request to update yakkety to 50.1, unsure if that's on your list (it fixes some trash issue)
[15:43] <seb128> anyway not a meeting topic, let's keep moving
[15:43] <seb128> #topic qengho
[15:43] <seb128> qengho, hey
[15:43] <qengho> * done; updated LTS chromium to fix TLS expiration. skipped yakkety for 54...
[15:43] <qengho> * in-progress: Cr 54. 32-bit memory exhaustion at link. run-time crash in blink, perhaps memory allocator again?
[15:43] <qengho> * in-progress: Helping Tor project adopt snaps for reproducible builder and browser.
[15:43] <qengho> Away for national holiday on Thursday, maybe also Friday.
[15:44] <qengho> EOF
[15:44] <Laney> seb128: yes I know
[15:44] <seb128> thanks qengho
[15:44] <seb128> Laney, good :-)
[15:44] <seb128> #topic seb128
[15:44] <seb128> • UOS - watched/participated in some sessions
[15:44] <seb128> • learnt a bit more about the langpack-o-matic infrastructure to be able to co-maintain it
[15:44] <seb128> • some NEW reviews
[15:44] <seb128> • had a look at the suggested dbus snapd interface (needed to unblock some GNOME components)
[15:44] <seb128> • tried to help did_rocks debugging some snap/alsa interactions
[15:44] <seb128> • worked a bit with att_ente on the roadmap for gtk-mir
[15:44] <seb128> • read a bit more about snap content sharing to prepare the gtk platform snap work

[15:44] <seb128> #topic Sweet5hark
[15:44] <seb128> Sweet5hark, hey
[15:45] <Sweet5hark> - TDF budgeting, team priorities
[15:45] <Sweet5hark> - collecting lose ends: finish/upgrade gbuild-to-ide
[15:45] <Sweet5hark> - some networking/lobbying bits, filing various expenses
[15:45] <Sweet5hark> - finished trusty backport, looking into precise
[15:45] <Sweet5hark> - prep for 5.3 beta1
[15:45] <Sweet5hark> - next week: will need to look in various gtk3/snap stuff
[15:45] <Sweet5hark> EOF
[15:45] <seb128> thanks Sweet5hark
[15:45] <seb128> #topic TheMuso
[15:45] <seb128> * Started looking at the patches provided in bug 1641954 for Xenial, to provide a better experience around the use of HDMI audio to a monitor/TV. Haven't been able to reproduce yet, work continues.
[15:45] <seb128> * Started looking into how input event processing for assistive technologies could be implemented in Mir and Wayland compositors/shells. Since we need this for Unity 8, it is my hope that I can start a discussion with developers of Mutter/GNOME Shell, and KDE, as well as Unity 8 devs to work out a cross-desktop solution. It will probably be a DBus API, but more may be needed, possibly along the lines of validating that the
[15:45] <seb128>  process registering for input events is who they say they are, for security reasons.
[15:45] <seb128> * Continued looking into bluetooth profile related issues now that the fix for bug 1574324 is in yakkety and xenial.
[15:45] <ubot5`> bug 1641954 in pulseaudio (Ubuntu) "Output switches from HDMI speakers to internal speakers on DPMS off" [Undecided,New] https://launchpad.net/bugs/1641954
[15:45] <ubot5`> bug 1574324 in pulseaudio (Ubuntu) "pulseaudio crashes when connecting to bluetooth headphones (due to ubuntu changes?)" [High,Fix released] https://launchpad.net/bugs/1574324
[15:46] <seb128> #topic tkamppeter
[15:46] <seb128> tkamppeter, hey
[15:46] <tkamppeter> - We have support for AirPrint now! Around 2600 models, many did not work with Linux before. Works only if printer is network-connected (WiFi, Ethernet).
[15:46] <tkamppeter> - cups: Got upstream answers to PPD-generator related bug reports and these got fixed for 2.2.2. In addition, 2.2.2 will have Apple Raster support (is in upstream GIT now), so AirPrint printers (around 2600 models, many did not work with Linux before) should work without driver and auto-generated PPDs, too. Tested on three HP printers and it actually works.
[15:46] <tkamppeter> - cups-filters: Synced PPD generator in cups-browsed with the one in CUPS, added auto-creation of print queues for AirPrint printers.
[15:46] <tkamppeter> - Chat with Aveek Basu from Lexmark, he want to help on print dialog development, find GSoC students, and test IPP Everywhere and AirPrint printers from Lexmark.
[15:46] <tkamppeter> - Bugs.
[15:46] <seb128> nice work tkamppeter, thanks!
[15:46] <seb128> #topic Trevinho
[15:47] <seb128> Trevinho, your turn :-)
[15:47] <Trevinho> · Fixed sni-qt, appmenu-qt5, libappindicator to support $SNAP environment
[15:47] <Trevinho> · Created indicator-<toolkit> snap remote parts for snap inclusions (and desktop-launchers)
[15:47] <Trevinho> · Created examples for indicators in snap environment: https://github.com/3v1n0/indicators-examples-snaps
[15:47] <Trevinho> · Reviewed the Window Decorations Document for u8, Gtk+ is going to be problematic again (especially in a snappy world), so I think we'd need to find a solution
[15:47] <Trevinho> · Landed new unity8 indicators (and new calendar) - after fixing various aspects
[15:47] <Trevinho> · Some design reviews of indicators
[15:47] <Trevinho> · Fixed a small indicator-datetime bug causing wrong events showing
[15:48] <Trevinho> seb128: sorry for the delay
[15:48] <seb128> no worry
[15:48] <Trevinho>  /eof
[15:48] <seb128> good/busy week again, well done Marco!
[15:48] <seb128> #topic robert_ancell
[15:48] <seb128> - (short week due to leave)
[15:48] <seb128> - Working on lightdm / unity8-system snap
[15:48] <seb128> - LightDM and snapd-glib fixes / improvements
[15:49] <seb128> #topic aob
[15:49] <seb128> does anyone has some other topic to discuss?
[15:49] <attente> should we talk about the gtk platform snap?
[15:49] <attente> or after the meeting maybe?
[15:50] <seb128> we can
[15:50] <seb128> after meeting is fine
[15:50] <seb128> no need to keep everybody, those interested can stay around
[15:50] <seb128> k, let's wrap and discuss that?
[15:50] <seb128> thanks everyone!
[15:50] <attente> sure
[15:50] <flexiondotorg> Yep.
[15:50] <seb128> #endmeeting
[15:50] <meetingology> Meeting ended Tue Nov 22 15:50:48 2016 UTC.
[15:50] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2016/ubuntu-desktop.2016-11-22-15.30.moin.txt
[15:51] <didrocks> do you need help? I gave some advice for the ubuntu-app-platform side and did the desktop-launcher work for it
[15:51] <didrocks> we can base on this
[15:51] <attente> can we re-use that one instead of having a new separate platform snap?
[15:51] <flexiondotorg> didrocks, Does the approach differ much from how the KDE team are doing things?
[15:51] <seb128> attente, re-use like?
[15:51] <Sweet5hark> so what gtk version will the snap be? how will transitions work?
[15:51] <didrocks> unsure about the KDE team platform snap, I never saw it
[15:52] <seb128> I think we wanted to do something similar
[15:52] <seb128> just with a different list of stage-packages
[15:52] <seb128> no?
[15:52] <flexiondotorg> That is my thinking.
[15:52] <seb128> Sweet5hark, we decided to snap the distro version
[15:52] <attente> like instead of having a separate snap, contribute gtk-related libraries, themes, etc to the ubuntu-app-platform snap
[15:52] <seb128> so I guess we are going to have a xenial-3-18
[15:52] <flexiondotorg> Would be interested to know how the ubuntu-app-platform snap is constructued.
[15:52] <seb128> and a yakkety-3-20
[15:53] <seb128> flexiondotorg, yeah, me too
[15:53] <didrocks> pretty easily, it's just a list of stage-packages
[15:53] <seb128> I need to look at it more
[15:53] <seb128> especially how they export the libs
[15:53] <didrocks> they didn't version the content interface though, despite what I asked multiple times
[15:53] <didrocks> and in the dekstop launcher, we detect a fix directory
[15:53] <seb128> I guess they mount it under a new dir that they prepend to the LD_LIBRARY_PATH?
[15:53] <didrocks> and if there, we change some of LD_LIBRARY_PATH, wrappers to run and such
[15:54] <Sweet5hark> seb128: ok, and one is expected to use the platform snap matching the build system (well or what one selected in launchpad) then I assume?
[15:54] <didrocks> https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/qt/launcher-specific#L12
[15:54] <didrocks> and exports are in https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/qt/launcher-specific#L35
[15:54] <didrocks> + some other functions later on that I refactored
[15:54] <didrocks> like https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/qt/launcher-specific#L109
[15:55] <seb128> Sweet5hark, the toolchain topic is going to be a bit tricker/not something we are looking at currently
[15:55] <Sweet5hark> seb128: k
[15:56] <seb128> but I think we are going to have versioned snaps by serie as didrocks suggested
[15:56] <seb128> like x-3-18
[15:56] <seb128> y-3-20
[15:56] <flexiondotorg> I think so too.
[15:56] <didrocks> sounds good to me (it's the content-interface "content" name)
[15:56] <seb128> didrocks, the application side is just a plug and making sure the target dir exists for the mount?
[15:57] <seb128> like $SNAP/usr/gtk-x-3-18
[15:57] <didrocks> seb128: right + using the desktop launcher, but that's it
[15:57] <didrocks> yeah, I suggest a subdir
[15:57] <didrocks> and you put everything under it
[15:57] <didrocks> we stated on $SNAP/platform for Qt
[15:57] <didrocks> would be good to require the same directory name for documentation purpose
[15:58] <seb128> hum
[15:58] <seb128> you mean in the platform snap?
[15:58] <didrocks> no, in the app
[15:58] <didrocks> the app mount the platform snap inside
[15:58] <didrocks> it's a bindmount
[15:58] <seb128> what if the app needs to mount both qt and gtk?
[15:58] <didrocks> is that really a use case ?
[15:58] <seb128> they can't have the same name?
[15:58] <didrocks> if so, they are on their own, meaning:
[15:59] <didrocks> - they need to use their own launcher
[15:59] <flexiondotorg> The KDE platform and -dev snap are in Harold Sitters github - https://github.com/apachelogger?tab=repositories
[15:59] <didrocks> - but they can use both content interfaces
[15:59] <flexiondotorg> Some elegant solutions in there.
[15:59] <didrocks> it's the plug deciding where to mount $things
[15:59] <didrocks> (the app plug)
[15:59] <didrocks> but our default launchers won't be able to support $RANDOM_DEST_DIR
[15:59] <seb128> k, fair enough
[16:00] <seb128>  if [ ! -d $SNAP/ubuntu-app-platform/usr ] ; then
[16:00] <seb128> in your github url
[16:01] <didrocks> (sorry, it's ubuntu-app-platform) indeed
[16:01] <didrocks> I don't remember how much we did iterate on this :)
[16:01] <seb128> :-)
[16:01] <didrocks> so, yeah, do something similar
[16:01] <seb128> would it be misleading having gtk under that name?
[16:01] <didrocks> preferably with -platform suffix
[16:01] <didrocks> I don't think so
[16:01] <seb128> ah, I see what you mean
[16:01] <seb128> like ubuntu-gtk-platform
[16:01] <didrocks> yeah
[16:01] <seb128> or gtk-platform
[16:01] <seb128> attente, why did you want to reuse the same?
[16:02] <seb128> or include gtk in the ubuntu-app-platform ?
[16:02] <seb128> those probably have different targets and cycles
[16:02] <attente> i might've misunderstood, but yeah, including gtk in u-a-p
[16:03] <seb128> why?
[16:03] <seb128> you probably don't want to pull in the whole uitk for a gtk software
[16:03] <seb128> what's your usecase?
[16:04] <attente> at the same time all of ubuntu-core is already pulled in the moment you install a snap, no?
[16:04] <seb128> or what do you think we would win?
[16:04] <seb128> ubuntu-core yes
[16:04] <seb128> but that's the base image
[16:04] <seb128> like libc type of content
[16:05] <seb128> that's things going to be useful for any sort of install or almost
[16:05] <didrocks> (/!\ but as I reported multiple time to upstream, installing a snap, even with default-provider, doesn't install the content-interface snap for you, nor it does autoconnect it)
[16:05] <didrocks> can be useful in your testing ^
[16:05] <seb128> right
[16:05] <attente> ok
[16:05] <seb128> thanks for pointing it out
[16:05] <seb128> I think that's something gnome-software is going to need to do for us
[16:06] <seb128> well that's the plan afaik, robert_ancell had some discussions with the snappy team about there where they agreed that's the wanted solution
[16:06] <didrocks> that would be good :)
[16:06] <didrocks> (unsure about pure CLI usage though)
[16:07] <seb128> you use the CLI you need to know what you are doing ;-)
[16:07] <seb128> well, at least you made the wrapper give hints from what I see
[16:07] <flexiondotorg> didrocks, What is the current status of who can connect to a content snap?
[16:07] <didrocks> well, you can argue apt doesn't force you to install deps ;)
[16:08] <didrocks> flexiondotorg: everyone from the same provider
[16:08] <flexiondotorg> What about Canonical published platform snaps?
[16:08] <didrocks> reported last week as well. I don't see that status moving soon though
[16:08] <didrocks> same
[16:08] <didrocks> you need to publish your apps as canonical to connect to the canonical platform snaps
[16:08] <flexiondotorg> So if we have a Canonical published GTK platform snap, it can not be reused by Xubuntu for example?
[16:09] <seb128> those are problem to resolve for the snappy team
[16:09] <seb128> and known limitations atm
[16:09] <seb128> I think we should start by building our platform snap
[16:09] <flexiondotorg> Yes, but just making sure my understanding is correct.
[16:09] <seb128> right
[16:09] <didrocks> right now, indeed
[16:10] <flexiondotorg> Just to be clear, it will not be possible for upstream to use the Canonical published GTK platform snap?
[16:10] <didrocks> not right now
[16:10] <flexiondotorg> Bother.
[16:46] <seb128> flexiondotorg, when you say they have sole elegant solutions for kde, anything specific you are thinking about?
[16:47] <seb128> my view is a bit naive I guess but isn't the build mostly going to be a stack of stage-packages and some organize rules to move things in a common dir?
[16:47] <seb128> like is there more to it?
[16:48] <flexiondotorg> They technique they are using to make both a platform (runtime) snap and also the -dev snap to using in build-packages.
[16:48] <seb128> (I didn't think much about the -dev side I've to say, but we sort of agreed that build has to be done on the distro/that's the best/easiest env for that sort of things still)
[16:50] <flexiondotorg> Yes, indeed.
[16:50] <flexiondotorg> I can't find the repo now, but I will.
[16:51] <flexiondotorg> What they created is a means to provide all the build-packages via one "meta" snap.
[17:58] <seb128> k, enough for today
[17:58] <seb128> have a nice evening desktopers
[17:58] <seb128> see you tomorrow
[17:58] <willcooke> night seb128
[17:58] <willcooke> thanks for running the meeting
[17:58] <seb128> yw!
[17:58] <flexiondotorg> Night, catch you tomorrow.
[17:58]  * willcooke bails too
[17:58] <willcooke> ta ta
[18:04] <Laney> laters


[01:10] <callmepk> good morning
[01:46] <duflu> Morning callmepk
[01:46] <callmepk> morning
[02:06] <callmepk> morning duflu
[06:53] <didrocks> good morning
[06:59] <jibel> morning all
[07:03] <didrocks> salut jibel
[07:07] <jibel> Salut didrocks, ça va? le déménagement est terminé?
[07:10] <didrocks> jibel: tout dépend de la définition de terminé. Il reste encore plein de choses à faire comme la peinture, les plinthes et régler avec le constructeur les problèmes qui se sont avérés (mais il est encore en vacance cette semaine)
[07:10] <didrocks> ah, et aussi recevoir les derniers bouts de cuisine explosé en 8 envoies séparés
[07:11] <jibel> didrocks, bon, ça fait partie des joies d'une nouvelle maison :)
[07:11] <didrocks> (beaucoup de livraison non reçus, dont le frigo qui est arrivé après 5 appels au SAV et 13 jours de retard…)
[07:11] <didrocks> bref, compliqué :)
[07:11] <didrocks> et toi ?
[07:12] <jibel> ça va bien. rien de spécial.
[07:13] <duflu> Morning didrocks and jibel
[07:16] <didrocks> hey duflu
[07:19] <jibel> hi duflu
[07:31] <duflu> didrocks, wrong day? :) https://discourse.ubuntu.com/t/desktop-team-updates-monday-03rd-august-2020/17595/11
[07:54] <didrocks> duflu: not wrong day, but I had this in cache before going on holidays and realized I hadn’t post it
[07:54] <duflu> Oh, fair enough
[08:06] <Laney> ANYBODY WANT SOME UPDAWG?
[08:06] <didrocks> hey hey Laney
[08:11] <Laney> wb didrocks!
[08:11] <Laney> what percentage complete are you now?
[08:13] <didrocks> Laney: hard to estimate, still a long way to go to have a decent kitchen and such :)
[08:14] <didrocks> complexity is dealing with Martin while still having things to be done and handling the old appartement before selling (we need to do a big cleaning there)
[08:16] <Laney> yeah, few years and he could assist with painting :>
[08:16] <didrocks> right :p
[08:16] <didrocks> the issue is that he wants to assist right now instead of playing with his games :)
[08:17] <didrocks> at least, today, we receive our bin, finally!
[08:18] <Laney> \o\
[08:20] <duflu>  /o/
[08:21] <seb128> goood morning desktopers
[08:21] <duflu> Hi seb128
[08:22] <seb128> hey duflu , how are you? had a good w.e?
[08:24] <duflu> seb128, I'm 80%. Lots of family and a birthday on the weekend. Almost normal although people should probably be more socially distant than they are... You?
[08:25] <seb128> I'm alright! weekend was not the most relaxing, packed and took the road again for another corner of France
[08:25] <didrocks> hey seb128
[08:25] <duflu> seb128, sounds nice
[08:26] <duflu> seb128, btw was there a reason we still ship gdm3 3.34?
[08:26] <duflu> Other than it was never branch-tagged upstream correctly
[08:26] <duflu> There is a gnome-3-36 branch with tags
[08:27] <duflu> Looks like we miss out on some interesting fixes
[08:29] <seb128> duflu, 3.36 tarballs came after 3.36.1 iirc
[08:29] <duflu> yeah
[08:29] <seb128> http://ftp.acc.umu.se/pub/gnome/sources/gdm/3.36/
[08:29] <seb128> from june
[08:29] <seb128> so just that we moved to other things than GNOME updates in between june and now
[08:30] <seb128> I expect we will get it update as we deal with 3.37 twhich started)
[08:30] <duflu> ok
[08:30] <seb128> duflu, it's listed on https://trello.com/b/sdyPskaS/gnome-338
[08:31] <seb128> could one for L_aney if he has some slots to help with updates this week
[08:42] <seb128_> bah, internet disconnect and I didn't notice for a while
[08:55]  * marcustomlinson opens IRC
[08:55] <marcustomlinson> morning desktoppers
[08:55] <didrocks> hey marcustomlinson
[08:56] <marcustomlinson> welcome back didrocks
[08:58] <seb128_> hey marcustomlinson , wb didrocks! doing alright today?
[09:01] <marcustomlinson> seb128_: doing fine, you?
[09:01] <duflu> Hi marcustomlinson
[09:01] <marcustomlinson> hey duflu
[09:02] <didrocks> seb128_: doing well, despite a lot of things to do here for the coming weeks I guess :)
[09:02] <didrocks> thanks marcustomlinson
[10:02] <Trevinho> Hola!
[10:10] <didrocks> hey Trevinho
[10:10] <Trevinho> hi didrocks, you also back from hols!
[10:16] <didrocks> yes :) even if I would call that "holidays" (moving to the new house, finishing/building things :p)
[10:32] <seb128> Trevinho, hey, how are you? had a good week off?
[10:33] <Laney>  moin marcustomlinson seb128 Trevinho
[10:34] <Trevinho> hi Laney
[10:34] <Trevinho> seb128: yeah, discovered a pretty nice area of Spain (Javea -> Calp), quite unexpected beauties over there
[10:35] <Trevinho> even better this year as the Brits didn't come :-D :-D
[10:36] <Laney> WHAT
[10:37] <marcustomlinson> hey Laney
[10:37] <Trevinho> ahah, I mean, less crowded... more naturalistic :P
[10:41] <didrocks> meaning that the Brits are artificials? :p
[10:42] <Laney> it sounds like jealousy that these people discovered the beautiful place first to me 😤
[10:42] <Laney> tbh, not far from Benidorm, ... ¬_¬
[10:43] <Trevinho> Well Benidorm is nice, but it's even too much "America" to me, I prefer the areas in between Calp and Javea where they keep the Mediterranean style of 1-2 floor houses.
[10:43] <Trevinho> well, mostly villas, but still, at least they didn't ruin the coast.
[10:44] <jibel> xnox, hi, what it the option again to skip install media check during boot on ubuntu desktop?
[10:44] <Trevinho> however, I can't blame the Brits there given that the Cousin of a guy that was with me in Bali runs a bar there and they invited me and Dayana for some free drinks :D
[10:45] <Laney> this guy has been a good contact for you!
[11:26] <GunnarHj> Hi Trevinho, saw that you assigned bug #1890875 for bionic to yourself. Are you aware that there is already a fix in the bionic queue?
[11:48] <Laney> k, finally, I think the u-m stuff is good enough to hand over
[11:48]  * Laney cleans up & pushes a branch
[11:53] <didrocks> (and turn around without ever looking again :))
[11:59] <Laney> ideally
[11:59] <Laney> that only works if you didn't create any bugs though
[11:59] <Laney> which I definitely did not!
[12:46] <Trevinho> GunnarHj: hey, yes it was a mistake... I set it back and updated again, also I've updated the cvs with that
[12:47] <KGB-1> gnome-shell signed tags 58212e1 Marco Trevisan ubuntu/3.28.4-0ubuntu18.04.5 * gnome-shell Debian release 3.28.4-0ubuntu18.04.5 * https://deb.li/XHfM
[12:47] <KGB-1> gnome-shell ubuntu/bionic 9c38922 Marco Trevisan * pushed 6 commits (first 5 follow) * https://deb.li/ikvij
[12:47] <KGB-1> gnome-shell ubuntu/bionic cdb5222 Marco Trevisan (Treviño) debian/ (6 files in 3 dirs) * Import Debian changes 3.28.4-0ubuntu18.04.3 * https://deb.li/tHGA
[12:47] <KGB-1> gnome-shell ubuntu/bionic ed7d95c Gunnar Hjalmarsson debian/ changelog patches/series patches/keyboardManager_apply-added-input-sources-instantly.patch * Import Debian changes 3.28.4-0ubuntu18.04.4 * https://deb.li/3rvWi
[12:47] <KGB-1> gnome-shell ubuntu/bionic 315ef3c Marco Trevisan (Treviño) debian/patches/ series keyboardManager-Avoid-idempotent-calls-to-meta_backend_se.patch * d/p/keyboardManager-Avoid-idempotent-calls-to-meta_backend_se.patch: Fix tagging * https://deb.li/yfM0
[12:47] <KGB-1> gnome-shell ubuntu/bionic 167f949 Marco Trevisan (Treviño) debian/patches/ series shell-global-Make-saving-of-persistent-state-asynchronous.patch * debian/patches: shell-global: Make saving of persistent state asynchronous * https://deb.li/3M0L2
[12:47] <KGB-1> gnome-shell ubuntu/bionic d0541e7 Marco Trevisan (Treviño) debian/changelog * Update changelog * https://deb.li/I0ys
[12:48] <KGB-1> gnome-shell tags 0410be8 Marco Trevisan ubuntu/3.28.4-0ubuntu18.04.3 * Debian release 3.28.4-0ubuntu18.04.3 * https://deb.li/3mHZU
[12:48] <KGB-1> gnome-shell tags 2295ada Marco Trevisan ubuntu/3.28.4-0ubuntu18.04.4 * Debian release 3.28.4-0ubuntu18.04.4 * https://deb.li/3Uw4n
[12:50] <GunnarHj> Trevin
[12:52] <GunnarHj> Trevinho: But since you apparently had other things pending, wouldn't it be better to drop my upload and do one SRU round only?
[12:53] <Trevinho> GunnarHj: I can't drop it from the queue, so I've just added one, but indeed we can ask anyone with permissions to delete the duplicated one. My changes files include yours, so sure the first one in queue, can be deleted.
[12:54] <Trevinho> There's some community contribution to get the dock to have the unity7-style app windows selection (so using the overview): https://github.com/micheleg/dash-to-dock/pull/1253
[12:54] <Trevinho> Is it something we could be interested in having as default, or are we happy with the menu?
[12:56] <GunnarHj> Trevinho: Probably the SRU team will ignore my upload anyway. Otherwise.. seb128, can you possibly drop my 3.28.4-0ubuntu18.04.4 upload of gnome-shell from the bionic queue?
[12:57] <Trevinho> GunnarHj: yeah they normally do that, but if someone arrives earlier enough, better :)
[13:11] <juliank> hey guys, have you considered seeding sane-airscan so we get driverless scanning out of the box?
[13:12] <juliank> Imagine just loading a live disk and connecting to wifi and being able to print and scan on the network without any effort :)
[13:34] <jibel> it's only useful if your printer or scanner is not already driverless
[13:35] <jibel> i've an HP all in one printer and had nothing to do on the client
[13:57] <xnox> jibel:  http://manpages.ubuntu.com/manpages/groovy/en/man7/casper.7.html#recognized%20boot%20options => third one down document skip the filesystem
[13:58] <xnox> also groovy is not in the title bar, i wonder why
[14:34] <hellsworth> good morning desktopers
[14:38] <didrocks999> hey hellsworth
[14:38] <hellsworth> o/
[14:39] <hellsworth> hope you had a nice weekend didrocks999 :)
[14:39] <didrocks999> too many 9 :p
[14:39] <didrocks> week-end and "holidays" were nice, but not relaxing :)
[14:39] <didrocks> you?
[14:40] <hellsworth> same. hanging out with a toddler is busy but fun
[14:42] <didrocks> and try that while finishing paintings, kitchen and flooring building, I can tell you this is the next challenge :p
[14:46] <hellsworth> wow well didrocks i hope you can take a nap one day :)
[14:50] <jibel> xnox, thanks
[14:57] <didrocks> hellsworth: planned in a few years :p
[14:57] <hellsworth> :)
[15:14] <hellsworth> Laney: ricotz i have an armhf build of 7.0 with gcc 9 now: https://launchpad.net/~hellsworth/+archive/ubuntu/libreoffice8/+packages
[15:14] <KGB-1> mozjs ubuntu/focal 4d8c001 Marco Trevisan . * branch deleted
[15:15] <Trevinho> Laney: it works! :)
[15:15] <Laney> ^_^
[15:15] <Laney> to you both
[15:15] <Laney> hellsworth: I tried a 10 build again, and for some reason it compiled this time: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4206/+packages
[15:15] <Laney> go figure?
[15:16] <hellsworth> haha so this is how the week is going to be :)
[15:16] <hellsworth> that's wild. why the heck would it pass now?
[15:17] <Laney> https://lists.ubuntu.com/archives/groovy-changes/2020-August/thread.html something in there fixed it?
[15:17] <Laney> guess the next test is if the autopkgtest works or that URP thing happens again
[15:17] <hellsworth> righto
[15:18] <hellsworth> if the urp failure shows up again, i can't even
[15:23] <hellsworth> Laney: i'm copying your passing 6.4.5 binaries to my ppa and then will run autopkgtests with all fingers and toes crossed
[15:23] <Laney> hellsworth: no need, it's already running
[15:23] <Laney> bileto has that shizzle built in
[15:23] <hellsworth> oh
[15:23] <Laney> https://bileto.ubuntu.com/excuses/4206/groovy.html
[15:25] <hellsworth> i've not known about bileto so neat
[15:25] <hellsworth> well i can't wait to hear how it goes then :)
[15:26] <ricotz> hellsworth, hi, please see my email
[15:26] <Laney> refresh that page in many hours from now :>
[15:27] <ricotz> https://launchpad.net/%7Elibreoffice/+archive/ubuntu/libreoffice-prereleases/+sourcepub/11529591/+listing-archive-extra
[15:27] <ricotz> please just pick up 7.0.1~rc1 for groovy
[15:27] <Laney> ricotz: with 10?
[15:27] <Laney> gcc
[15:28] <ricotz> with gcc 9 on armhf
[15:28] <Laney> mmm
[15:29] <Laney> can you just throw an armhf/10 into some random ppa please? i'm interested that 6.4.5 started working again
[15:29] <Laney> or if it fails then there's a source that I can build myself interactively to get something to give to do_ko
[15:30] <ricotz> Laney, the gcc ICE happened randomly and together with test failure (timeout) is failed constantly
[15:31] <ricotz> suprisingly debian didn't hit this issue with gcc 10
[15:31] <Laney> not for 6.4.5 any more, I got like 3 successful builds in a row now
[15:31] <ricotz> interesting
[15:32] <ricotz> did some toolchain change sneak in lately
[15:32] <Laney> infuriating, I wanted to get the ICE in my sbuild build :p
[15:33] <ricotz> Laney, you could copy libreoffice - 1:7.0.1~rc1-0ubuntu<IP_ADDRESS> source from -prereleases ppa into an armhf ppa of your choice
[15:33] <ricotz> for testing
[15:34] <ricotz> the packaging of it should not go into groovy as is
[15:34] <Laney> ok, I'll use 4206 once that finishes
[15:35] <ricotz> Laney, https://launchpad.net/~libreoffice/+archive/ubuntu/libreoffice-prereleases/+copy-packages?field.name_filter=libreoffice&field.status_filter=&field.series_filter=groovy
[15:35] <Laney> ty
[15:58] <Laney> right
[15:58] <Laney> let's do a package update
[15:58] <Laney> see if I remember how
[16:24] <juliank> jibel: That's not because it's driverless, but because we ship HP drivers
[16:25] <juliank> jibel: Driverless printing/scanning, printing we have by default, enables you to print/scan to Brother devices, for example
[16:25] <juliank> Basically this adds support for any scanner we don't have an explicit driver for
[16:26] <juliank> [this is re sane-airscan from 3h ago]
[16:27] <juliank> I think Canon is another vendor that benefits
[16:28] <juliank> I think a bunch of others too
[16:28] <juliank> HP obviously not much given that we install hplip
[16:31] <juliank> it doesn't have any extra deps we don't already have, so it's a really smart move to include and get scanning on a lot more devices out of the box
[16:31] <juliank> :D
[16:31] <juliank> [Depends: libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16), libc6 (>= 2.17), libgnutls30 (>= 3.6.12), libjpeg8 (>= 8c), libpng16-16 (>= 1.6.2-1), libxml2 (>= 2.7.4)]
[16:32] <juliank> Not sure what the status is, people are all super excited about it, there was talk about merging it into sane-backends, but it might have a faster release cycle atm
[16:34] <Laney> You probably want to talk to tkamppeter when around
[16:39] <juliank> Laney: Right
[16:40] <juliank> Laney: He isn't, I thought maybe someone else is super excited and wants to push this :)


[01:09] <krytarik> I'll just paste this here, in case any of you didn't notice yet:-
[01:09] <krytarik> [21:38] <slangasek> http://releases.ubuntu.com/include/style.css - san-serif
[01:09] <krytarik> [21:38] <slangasek> who's been putting serifs on my SAN
[01:09] <tsimonq2> That was the result of Raf filing a bug.
[01:10] <krytarik> Ah, ok!
[01:10] <tsimonq2> krytarik: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1748014
[01:11] <tsimonq2> But yeah, I did notice :D
 Invalid bug. Ubuntu is not provided server side. I don't know why 3 computers failed to use the font, but it's not a bug. Meaning, that Windows users will see Arial.
 Right.
 That doesn't explain why Times was rendered. It's still a mystery for me.
 And I can't reproduce the error.
 https://ubuntuforums.org/showthread.php?t=2384552
 I'm aware of that.
 It's a known bug.
 Please ping me when the default settings hit a daily ISO, I'm pretty sure some settings will not work ...
 @julienlavergne, The default settings already hit the dailies yesterday.
 I know things are still broken.
 I did some preliminary patching locally yesterday that fixed things, and that involved forking startlxqt
 (i.e. having it insert the custom Lubuntu XDG settings into the env var)
 It would be good to finally have this fixed @julienlavergne


[00:01] <stgraber> tjaalton: so the sssd upstart fix ends up taking 100% of CPU... I found an alternative that seems safe, will upload that now...
[00:07] <jdstrand> can someone also look at oxide-qt? it was approved earlier
[00:07] <jdstrand> if you tell me to just do it, I can myself
[00:12] <cjwatson> I don't suppose there's any chance of bug 1297804 being approved?
[00:12] <ubot2> Launchpad bug 1297804 in libpipeline (Ubuntu) "FFe: libpipeline 1.3.0" [Wishlist,New] https://launchpad.net/bugs/1297804
[00:14] <stgraber> cjwatson: approved
[00:15] <cjwatson> oh, that was quick, thanks :)
[01:02] <infinity> stgraber: That sssd exec is icky...
[01:05] <stgraber> infinity: does the trick, though I agree that upstream is just buggy there and should be fixed to not fail or eat all your CPU when using a sane stdin...
[01:05] <infinity> stgraber: Why not just start it with -D and expect fork?
[01:05] <infinity> Or expect daemon.
[01:05] <infinity> Whatever.
[01:05] <stgraber> infinity: because sssd is also buggy in that case
[01:06] <infinity> stgraber: Err, srsly?
[01:06] <stgraber> infinity: as in, it'll daemonize before it's done parsing your config
[01:06] <stgraber> so if your config isn't valid, it daemonized, then exits before the second fork, confusing the hell out of upstart in the process
[01:06] <stgraber> and you end up with upstart thinking it's running when it's not, with the only solution to fix the state being a reboot of the system
[01:06] <infinity> stgraber: util/server.c seems to imply and attempt to make that not happen. :/
[01:07] <stgraber> clearly failing :)
[01:07] <infinity> Bleh.
[01:07] <infinity> Seems like it would be worth fixing correctly instead of working around weirdly.
[01:08] <stgraber> setup sssd to use a krb5 ticket to authenticate, forget to setup said ticket before starting sssd => boom, upstart thinks it's running but sssd exitted
[01:09] <stgraber> totally agree that having sssd be a bit more sane when running in either foreground or background would be nice, though it's not something I have much time to debug and resolve properly right now, so the hackish upstart job at least does the trick and make things work reliably
[01:10] <stgraber> (sssd basically spawns 5-6 sub-daemons, all of which read their part of the config, failure from any of those may cause the main daemon to exit. So making sure that the daemonizing case is sane may be a bit challenging...)
[01:12] <infinity> Wow, it actually scans stdin.  That explains why /dev/zero drove it nuts.
[01:12] <infinity> And it reads an EOF as an explicit kill.
[01:12] <infinity> WHO WRITES SOFTWARE LIKE THIS.
[01:12] <cjwatson> Running stuff in the foreground is generally the right answer with modern inits anyway ...
[01:12] <infinity> cjwatson: It is when it's not written by nutters.
[01:12] <cjwatson> Well yes
[01:13] <infinity> stgraber: With /dev/null as stdin, did you get "EOF on stdin - terminating"?
[01:17] <infinity> Oh, FFS, how do I configure this to run it? :P
[01:22] <infinity> stgraber: Erm.   I'm happy to have someone else do it too of course
[01:39] <stgraber> infinity: well, the question then is whether there's a case where something spawns sssd and actually wants to feed it stuff on stdin or kill it by closing it
[01:39] <infinity> jdstrand: Is it identical to what I reviewed in your PPA before?
[01:39] <jdstrand> yep
[01:40] <stgraber> infinity: that'd seem pretty unlikely, but upstream did write those lines and the stdin handler for some reason after all...
[01:40] <jdstrand> bit for bit
[01:40] <infinity> jdstrand: Then go nuts.
[01:40] <jdstrand> thanks! :)
[01:40] <jdstrand> (it was just a binary pocket copy)
[01:40] <infinity> stgraber: I'd guess it's for debugging.  Not even the testsuite uses it, can't fathom why a user would.
[01:40] <infinity> stgraber: Besides, Ctrl-C still works.
[01:41] <infinity> stgraber: Take it or leave it.  If you think the mangled upstart job is better, I can confirm that also works, I just think it's awful. :P
[01:42] <stgraber> infinity: so I think I'd rather stay away from distro changes to the upstream code at this point and bring this upstream, then hopefully the next point release will contain their fix and we can use that and drop the upstart job hack
[01:42] <stgraber> though tjaalton is the one who does most of the work on sssd in Debian/Ubuntu so he may have a different opinion
[01:43] <infinity> tjaalton: ^
[01:43] <infinity> stgraber: Does either of you have a good relationship with upstream?
[01:43] <infinity> (Given that upstream seems to be very Fedora-centric, I can't see how this hasn't also been an issue with systemd... Does systemd play differently with FDs by default?)
[01:44] <stgraber> yeah, we have a pretty good relationship with upstream and they tend to be pretty quick at fixing issues (like that samba4 crash we reported and got fixed within the hour earlier today)
[01:45] <infinity> stgraber: So, I think they should fix their buggy -D implementation, but I imagine that will take Serious Thought(tm).  But making -i not bugger stdin should be trivial.
[01:45] <infinity> stgraber: And I can honestly see no reason why it does, except for debugging convenience.
[01:45] <infinity> But.. *shrug*
[01:46] <infinity> stgraber: I'll accept your upstart job fix for now, I confirmed that it works.  I'm just going to register my formal grumpiness with it being poop. ;)
[01:48] <stgraber> infinity: I'll file an upstream bug report now so I can forward your grumpiness where it belongs ;)
[01:52] <infinity> Okay, based on commit messages, looks like they're using -D under systemd, which would be why this weird -i behaviour isn't biting them.
[01:53] <infinity> And it could just be luck of job timing that they're not seeing the bug you do with -D.
[01:53] <stgraber> bug filed upstream
[01:53]  * infinity washes his hands of it.
[02:15] <slangasek> bdmurray: yeah, early release of 1286161 seems ok to me
[02:16] <slangasek> hmm, was qtbase-opensource-src auto-accepted, or did someone else review that?
[02:18] <cjwatson> I think I accepted the symbols changes
[02:18] <cjwatson> well, not the gles thing if that's been uploaded
[02:19] <cjwatson> the previous change
[02:19] <slangasek> stgraber: do you know why the logind upstart job is in a Multi-Arch: same pam package instead of in systemd-services - and why the service doesn't get started on install?
[02:19] <slangasek> stgraber: I ask because I happened to have my system in a state affected by bug #1302264 and found myself needing to reboot... NM was unhappy :P
[02:19] <ubot2> Launchpad bug 1302264 in systemd (Ubuntu) "systemd-logind assert failure: error.c:319: Assertion failed in nih_error_get: context_stack != NULL" [Critical,Fix released] https://launchpad.net/bugs/1302264
[02:20] <slangasek> cjwatson: ah, ok - yeah, it's only the gl side that's been uploaded for now
[02:20] <stgraber> slangasek: I don't know why the packaging was made this way... pitti may know.
[02:20] <slangasek> ok
[02:21] <slangasek> the first part seems to have been bug #1156074
[02:21] <ubot2> Launchpad bug 1156074 in systemd (Ubuntu Raring) "installing systemd-services without libpam-systemd loses device ACLs" [High,Fix released] https://launchpad.net/bugs/1156074
[02:27] <slangasek> the second part is a bug introduced in saucy when trying to avoid restarting logind on upgrades
[03:47] <rsalveti> slangasek: ^ for qtdeclarative
[03:49] <slangasek> rsalveti: so libqt5quick5's exported ABI doesn't change with the gles switch, but two variants need to be built because it will depend on GL-specific symbols when built against it?
[03:49] <slangasek> (just confirming that my understanding of the patch matches your intent)(
[03:50] <rsalveti> slangasek: 2 things, it'll depend on gl directly and will also depend on the packages built with gl by default, but they export the same abi
[03:51] <slangasek> ok
[03:51] <slangasek> accepting
[03:51] <rsalveti> one thing we need to better investigate later is what to do when a package depends on a common set of gl/gles symbols
[03:51] <rsalveti> I know in linaro we had a small library that could do runtime detection and decide gl/gles in runtime
[03:52] <rsalveti> but not so sure why nobody put a lot of more effort on that
[03:52] <slangasek> because glue libraries are messy :-)
[03:52] <rsalveti> but in this qt case, we might just follow directly with qt upstream, as they are doing a similar check in trunk (but currently just on windows)
[03:52] <rsalveti> yeah :-)
[04:52] <tjaalton> stgraber, infinity: heh, so it wasn't just the old upstart job that was buggy.. good to know. And I'm fine with the current workaround
[04:59]  * infinity curses component-mismatches trying to yank random universe kernels in again.
[08:01] <seb128> hey release
[08:02] <seb128> could somebody review bamf/compiz/nux in the queue?
[08:09] <dbarth> good morning, so today i'm trying to land a few things:
[08:09] <dbarth> account-plugins
[08:09] <dbarth> webbrowser-app
[08:09] <dbarth> and libunity-webapps and related (they come from silo 8)
[08:20] <seb128> Laney, so, nobody reviewed that bamf changes during the night :/
[08:21] <Laney> I imagine it'll get cleared out before final freeze
[08:21]  * Laney will look at other things now
[08:23] <seb128> k, fair enough
[08:42] <sil2100> seb128: I see compiz, nux and bamf still in the queue - any hope those will move out of UNAPPROVED soon? :)
[08:42] <seb128> sil2100, I do as well
[08:42] <seb128> I pinged about that earlier
[08:43] <seb128> seems like the US team didn't get to those during their shift, let's see if the europeans do
[08:43] <sil2100> o/ Thanks
[08:44] <seb128> stgraber, infinity, slangasek; did you guys reviewed the queue during your day/kept those on hold for a reason, or it's just that nobody has slots for reviews?
[08:48] <infinity> seb128: Did some, but not many.  I'll do a few more before I head to bed.
[08:49] <infinity> seb128: Hard freeze tomorrow (well, tomorrow for me) anyway, so it should slow down after that. :P
[08:50] <seb128> infinity, thanks ... and yeah, "should", I don't see that really happening though
[08:50] <seb128> well, a part of the uploads is going to turn into SRU
[08:50] <seb128> but I can see a steady flow of SRUs between release and .1
[08:51] <infinity> Inevitably, yeah.  Seems to be the way with LTSes.
[08:55] <maclin> slangasek，hi， I am maclin from Ubuntu Kylin.  I have push new source code of software center to launchpad. All the problems you found have been modified except python2. Could you help to review it?
[08:59] <JackYu> slangasek, maclin means the FFe bug #1293299.
[08:59] <ubot2> Launchpad bug 1293299 in Ubuntu Kylin "[FFe]upload ubuntu-kylin-software-center into archive" [High,Confirmed] https://launchpad.net/bugs/1293299
[09:37] <seb128> sil2100, ^ things got accepted, we should have some silos we can m&c in the next publisher runs
[09:37] <seb128> (thanks to whoever did the reviews btw!)
[09:37] <cjwatson> yw
[09:38] <cjwatson> would be nice if somebody could review libpipeline (it has an approved ffe now) so that I can sync man-db
[09:40] <Laney> ha, gexiv2 was what I was referring to in #ubuntu-devel
[09:40] <cjwatson> oh, whoops
[09:40] <cjwatson> sorry
[09:40] <cjwatson> I was motivated by seeing several things in p-m that were blocked on it ...
[09:40] <Laney> never mind, fixable
[09:40] <cjwatson> it'll hit NEW anyway, so you have a chance :)
[09:42]  * cjwatson suppresses his "auto-NEW stuff from Debian" twitch
[09:44] <sil2100> \o/
[09:44] <sil2100> Thanks guys!
[09:44] <sil2100> Can't wait for those to migrate out of proposed ;)
[09:56] <cjwatson> libpipeline> thanks
[09:56]  * infinity tips hat.
[09:57]  * infinity falls asleep in hat.
[10:30] <infinity> ^-- Can someone do a quick review of that flash-kernel?
[10:31] <infinity> I'm told it's tested to DTRT, and I verified the strings are correct.
[10:32] <cjwatson> infinity: LGTM
[11:55] <Riddell> possible kde-l10n spam ahead
[12:03] <doko> jibel, pitti: https://jenkins.qa.ubuntu.com/job/trusty-adt-python3.4-armhf/22/?  looks like the armhf test is run too early. the armhf build is not yet available as you can see from the log
[12:05] <jibel> doko, it's possible, armhf are triggered when x86 tests pass. I'll restart it.
[12:06] <jibel> (when the build is available)
[12:06] <doko> need to fix the aarch64 build anyway
[12:28] <jpds> Can someone please poke ima-evm-utils through NEW?
[13:58] <jamespage> could the neutron upload in proposed be rejected please - I missed a bit
[13:58] <infinity> jamespage: Done.
[13:58] <jamespage> infinity, thanks
[14:14] <didrocks> Laney: sorry to nag you, we have a regression fix from today's landing in webbrowser-app which is really needed for next image
[14:14] <didrocks> Laney: it should be easy enough to review :)
[14:14] <didrocks> https://code.launchpad.net/~dbarth/webbrowser-app/notitle/+merge/215166
[14:14] <didrocks> (and there is a new unity8 coming which will need a bump in the fauxpackage)
[14:18] <Laney> didrocks: ok, sec
[14:20] <didrocks> thanks man :)
[14:37] <didrocks> Laney: lost in space and time? :p
[14:39] <Laney> have patience my child
[14:42] <didrocks> thanks Laney
[14:43] <Laney> np!
[14:50] <bdmurray> slangasek: did you want to release ubuntu-release-upgrader to saucy-updates or shall I?
[14:50] <slangasek> bdmurray: please go ahead
[14:54] <jamespage> infinity, neutron with missing bits included now in the queue
[14:55] <infinity> jamespage: I assume that means you added bits, not that more are missing? :P
[14:55] <jamespage> infinity, I did indeed add the missing bits :-)
[15:04] <zequence> Any core-dev around, that could lend us some upload rights? Bug 1291675
[15:04] <ubot2> Launchpad bug 1291675 in lmms (Ubuntu) "[FFe] LMMS 1.0.0" [Wishlist,Triaged] https://launchpad.net/bugs/1291675
[15:04] <zequence> This package has some major improvements to the released one. Has been tested and is pretty much ready to go.
[15:15] <infinity> zequence: Wasn't ScottK asking you about that last night?
[15:16] <zequence> infinity: Yep. He approved it as a FFe. There was a repackaging since
[15:24] <Laney> I probably ought not to review gnome-screensaver since it's my own
[15:24] <Laney> Would appreciate it being looked at
[15:26] <cjwatson> accepted gnome-screensaver
[15:27] <Laney> Cheers
[15:27] <Laney> happy mostly working lockscreen
[15:27] <cjwatson> that fixes the double-lock?
[15:27] <Laney> unity mainly, but that has a hand
[15:28] <Laney> It takes over the D-Bus interface from gnome-screensaver, but g-s needed patching to allow itself to be replaced on the bus
[15:28] <Laney> (Which is quite a neat facility in D-Bus that I wasn't familiar with)
[15:28] <cjwatson> right
[15:44] <slangasek> maclin, JackYu: is someone taking care of sponsoring ubuntu-kylin-software-center?  I doubt I will have time to review it today, the best thing is to get it uploaded and get it reviewed by whoever's available at the time
[15:44] <slangasek> roaksoax: why is bug #1294323 private?  public bugs only for FFes, please
[15:45] <JackYu> slangasek, hi, we don't have the rights to upload it.
[15:46] <JackYu> slangasek, and neither happyaron...
[15:46] <slangasek> JackYu: understood; so you don't have any sponsor lined up for this?
[15:47] <JackYu> slangasek, yep, that's the situation:(
[15:47] <slangasek> ok
[15:47] <slangasek> let me see what I can do about that
[15:47] <JackYu> slangasek, great, thanks.
[15:49] <JackYu> slangasek, we are waiting for ubuntu-kylin-software-center and ubuntukylin-keyring being uploaded. Then we could upgrade the ubuntukylin-default-settings, so that these two packages would be included into the distribution.
[15:49] <slangasek> JackYu: right.  I've uploaded ubuntukylin-keyring, it's in the NEW queue now and should get review from another archive admin
[15:50] <slangasek> infinity: ^^ could you slot that in maybe?
[15:50] <infinity> Phrasing.
[15:51] <infinity> slangasek: So, this is the keyring with the agreed-upon generated-by-IS key?
[15:51] <slangasek> infinity: that's what I'm claiming
[15:52] <infinity> slangasek: Can I independently validate this key in the DC somewhere?
[15:52] <roaksoax> slangasek: yeah I filed a different public bug
[15:52] <slangasek> infinity: you can check it against the RT
[15:52] <slangasek> infinity: RT #69080
[15:52] <infinity> slangasek: Ta.
[15:57] <infinity> slangasek: Is this just a cargo-cult of ubuntu-keyring?
[15:58] <slangasek> infinity: yes, as noted in the linked FFe bug
[15:58] <infinity> Oh, who reads bugs?
[15:59] <infinity> slangasek: I was just going to whine about the lack of build-* targets, but if it's derived, I don't much care.  debdiffing against ubuntu-keyring to see how close they are.
[16:08] <infinity> slangasek: Is it expected that installing this keyring makes apt trust it, or will an installer mangle that?
[16:13] <slangasek> infinity: isn't that what the postinst does? (apt-key update)
[16:14] <infinity> slangasek: You'd think.
[16:14] <infinity> slangasek: Maybe it doesn't like ascii armored keys and wants an actual keyring?
[16:14] <slangasek> JackYu: xnox is reviewing ubuntu-kylin-software-center now for sponsorship
[16:14] <slangasek> infinity: ah; I would think that and did think that, but did not in fact test it
[16:15] <JackYu> slangasek, xnox, thanks. maclin and I are here waiting for your questions:).
[16:18] <xnox> JackYu: so far it's ok, one minor dependency is missing which i'll fix up before uploading.
[16:19] <xnox> JackYu: and i'm writting up review comments on the bug report.
[16:19] <xnox> JackYu: no blocking issues found yet, but i'm not done reviewing.
[16:19] <Saviq> who do I bribe to push unity8 through to release? ;)
[16:19] <xnox> Saviq: as per topic "we accept payment in cash, check or beer" and https://launchpad.net/~ubuntu-release/+members#active for the list of people
[16:20] <infinity> Saviq: I'll sort it.
[16:20] <Saviq> infinity, awesome, thanks, infinity.beer++
[16:20] <JackYu> xnox, got it.
[16:21] <infinity> I'll take a raincheck on the beer.
[16:22] <apw> the xen and libvirt combination are best viewed together and are a fix for the migration of machine definitions on upgrade
[16:26] <JackYu> xnox, sorry for my bad understanding, you mean you will upload it now and review it later, or you just upload it and we should find another sponsor to review it?
[16:27] <slangasek> JackYu: he is reviewing and once he is done reviewing, if there are no blocking problems, he will upload
[16:28] <JackYu> slangasek, ah:).
[16:30] <infinity> slangasek: Okay, so.  Two things.  It does seem to want to be a gpgp keyring, not an ascii art masterpiece.  But, also, I can't seem to get apt-key update to add it to trusted.gpg.  I *think* it only looks at archive.gpg
[16:30] <infinity> slangasek: Shipping it in /etc/apt/trusted.gpg.d/ubuntukylin-archive-keyring.gpg works, though.
[16:31] <infinity> slangasek: So, perhaps a symlink in postinst from /etc/apt/trusted.gpg.d/ubuntukylin-archive-keyring.gpg to /usr/share, and skip the other bits?
[16:31] <slangasek> infinity: ok.  Since you've looked at this and understand what's needed, do you want to reject, change, and bounce it back in my direction for counter-review, or do you want me to fix it up and resubmit?
[16:31] <infinity> slangasek: Sure, I can do that.
[16:39] <slangasek> infinity: do you intend to generate the binary keyring at build time, OOI?
[16:40] <infinity> slangasek: We don't seem to for ubuntu-keyring.
[16:42] <slangasek> infinity: yeah; I would argue that this is a bug in ubuntu-keyring too :)
[16:42] <infinity> slangasek: Perhaps, yeah.  But I'm not sure it's one I want to fix this instant.
[16:42] <infinity> slangasek: We can do both together some day.
[16:42] <slangasek> yep
[16:42] <infinity> slangasek: Not like an .asc is really any more readable than a .gpg, it's just more vi-friendly.
[16:42] <slangasek> just makes it a little harder for me to review and make sure you're not MITMing me ;)
[16:44] <cjwatson> grub2 won't be until early tomorrow morning I suspect, by the time I've built this, uploaded to Debian, and synced
[16:47] <cjwatson> The grub2 patch will be http://paste.ubuntu.com/7231546/ unless something goes horribly wrong for some reason
[16:48] <cjwatson> I guess I could hack the .changes and upload the exact same thing to Ubuntu if people think I should
[16:48] <cjwatson> Would be nicer to have the proper audit trail though
[16:49] <infinity> cjwatson: Letting the sync happen $later seems fine.
[16:53] <slangasek> I think it's unfortunate that the better we do at keeping things in sync with Debian, the slower it makes our updates in Ubuntu during critical times
[16:53] <slangasek> considering Debian was discussing reducing dinstall back down to daily, we should probably think about getting better syncing support from incoming
[16:54] <cjwatson> Yes, I agree on that
[16:56] <infinity> To sync securely from incoming, all we need is access to the buildd repo.
[16:57] <cjwatson> Incoming is signed these days, isn't it?
[16:57] <infinity> We probably just have to ask nicely, and retool the LP sync stuff.
[16:57] <infinity> cjwatson: incoming isn't, but incoming/buildd is.
[16:57] <cjwatson> Oh, right
[16:57] <cjwatson> Dunno if it would need that much retooling, it could just be another suite?
[16:58] <infinity> slangasek: Okay, try that one on for size.
[16:58] <cjwatson> I assume incoming/buildd is only private so that the world doesn't add it to their apt sources
[16:59] <slangasek> infinity: I have a call now, it'll be a couple hours before I can look at it - is that ok?
[16:59] <infinity> slangasek: Doesn't bug me.
[17:00] <infinity> cjwatson: Yeah, pretty sure that was the reasoning.  And so we could unaccept if really, really necessary.
[17:00] <infinity> cjwatson: But I don't think the unaccept case matters for Ubuntu syncing, we'd just sync a newer version in that strange case.
[17:00] <infinity> (or revert manually, or whatever)
[17:01] <cjwatson> Right, so auto-sync should still work off unstable, and we could shove it into Debian/incoming and people could use syncpackage -d incoming if they're in a rush
[17:01] <infinity> cjwatson: Yeah, that seems ideal to me.
[17:01] <cjwatson> gina will do its usual tracking of what's in what suites without much trouble AFAICS
[17:02] <cjwatson> wgrant: ^- any qualms with the above?  otherwise I can go ask ftpmaster
[17:03] <infinity> cjwatson: Assuming we poll something not too unfriendly, I can't see that they'd mind.  I hope.
[17:04] <cjwatson> I was thinking hourly
[17:04] <infinity> cjwatson: (And, really, buildds hit those Packages/Sources files constantly, one more buildd-like machine only hitting Sources.gz every 15-60m or something would be nothing)
[17:04] <infinity> The queue runs every 15 or 20, doesn't it?
[17:04] <infinity> I always forget.
[17:04] <cjwatson> And it'd be debmirror, but could be debmirror over HTTP if buildds don't get rsync
[17:04] <cjwatson> Not sure
[17:05] <infinity> cjwatson: Well, we could check a cached Sources for freshness, then trigger a mirror, I assume.
[17:05] <infinity> Though, I imagine debmirror has such a facility anyway.
[17:05] <cjwatson> debmirror fetches Packages/Sources and only grabs what it doesn't have
[17:05]  * infinity nods.
[17:05] <infinity> And we only want Sources, so just that.
[17:06] <cjwatson> Er right
[17:06] <cjwatson> So --arch=none
[17:07] <infinity> If we could get a push trigger, that would be even better, but I won't push my luck.  A shortish poll would still be way ahead of our current situation.
[17:08] <infinity> And unless they've gone high tech since I ran a Debian buildd, if we want to do polling, it's literally just them generating a u/p pair for us in htaccess and letting us loose.
[17:08] <cjwatson> Could just ask what's reasonable, indeed.
[17:09] <infinity> Possibly also IP limited, now that DSA demands buildds not be on sketchy cable modems. :P
[17:10] <xnox> slangasek: JackYu: given the time constraints I have sponsored the package, with a few changes which are proposed for merging back into trunk at https://code.launchpad.net/~xnox/ubuntu-kylin-software-center/14.04-release/+merge/215258
[17:11] <infinity> Ahh, phew.  "Good" news.  That testsuite regression on POWER8 isn't a regression.  Breaks in the old version too.
[17:11] <JackYu> xnox, got it, thanks.
[17:16] <apw> Laney, whoopsie-preferences as requested
[17:16] <Laney> fanx
[17:17] <JackYu> xnox, since it is in the NEW queue already, should I request another sponsor to review and accept it?
[17:18] <infinity> JackYu: We'll get to it.
[17:19] <JackYu> infinity, wow, great!
[17:29] <Laney> apw: Soz, LP's having a little nap and now I've got to go
[17:29] <Laney> Someone else'll probably get to it
[17:29] <apw> yep, np
[17:30] <Laney> or me if I come back on later
[17:30] <Laney> see you
[17:37] <jamespage> please could the neutron upload for trusty be accepted - I'd quite like to cycle that through our test lab with the rest of the rc packages today
[18:54] <infinity> slangasek: In light of your previous verbal agreement on pulling the IBM branch, can you review the above? ^^
[18:54] <infinity> slangasek: It was tested in a PPA on all arches and then independently on POWER8 as well.
[19:05] <slangasek> infinity: will queuediff eventually give me a diff for that or do I need to download the whole schleblottle?
[19:05] <infinity> slangasek: I see a diff in the queue...
[19:06] <infinity> slangasek: Missing -Q unapproved?
[19:08] <slangasek> infinity: queuediff doesn't take a -Q
[19:09] <slangasek> infinity: ok, diff has shown up now
[19:16] <infinity> cjwatson: Is https://bugs.launchpad.net/maas/+bug/1306164 relevant to partman as well?
[19:16] <ubot2> Launchpad bug 1306164 in MAAS "MAAS fast-path EFI install creates ESP that's too small" [Critical,Fix committed]
[19:17] <rsalveti> slangasek: ^ another simple one (qtlocation-opensource-src)
[19:17] <slangasek> rsalveti: ICMP redirect infinity; I have a few reviews on my plate already
[19:17] <infinity> ;)
[19:19] <rsalveti> slangasek: sure np, just a heads up as this is related with the gl/gles topic
[19:24] <tjaalton> slangasek: I'll reply to the mesa sru email in a bit, but another matter is that I pushed a change to pam adding pam-configs/mkhomedir, disabled by default. it's in bzr
[19:26] <tjaalton> slangasek: it's not of much use for any automatic setup, since pam-auth-update doesn't know how to enable such configs
[19:26] <tjaalton> uninteractively, there's a bug for that I'll try fixing soon
[19:30] <cyphermox> could any archive admin check on the archive machine where the cupstream2distro code runs, to see if it has received a file like "packagelist_rsync_landing-018-trusty" recently?
[19:30] <cyphermox> ci train publishes don't seem to be working atm
[19:30] <cyphermox> robru: ^
[19:31] <cyphermox> I'm currently unable to provide a clearer indication of where this data is supposed to end up though :(
[19:33] <robru> cyphermox, the two logs showing publication are https://ci-train.ubuntu.com/job/landing-018-2-publish/7/console and https://ci-train.ubuntu.com/job/landing-018-2-publish/8/console
[19:33] <robru> but that package hasn't shown up anywhere
[19:33] <robru> cyphermox, also https://ci-train.ubuntu.com/job/landing-019-2-publish/1/console
[19:34] <robru> basically we're looking for phablet-tools and indicator-keyboard, they should have been published but got lost in the ether
[19:34] <cjwatson> infinity: people's usual complaint about partman's are that they're too large, so I don't think so
[19:35] <cjwatson> infinity: partman-auto has the minimum set to 512M
[19:35] <cjwatson> infinity: although there might be a decimal confusion there ...
[19:35] <Laney> cyphermox: I guess it's /home/ubuntu-archive/cu2d/incoming on snakefruit, which is empty
[19:35] <infinity> cjwatson: Oh, if it's already 512M in partman, then this curtin upload matches that.
[19:35] <cjwatson> infinity: I think we may be using 512MB rather than 512MiB though
[19:36] <cjwatson> infinity: but don't have time to investigate tonight
[19:36] <infinity> cjwatson: I think the changelog claimed 100, and I didn't go digging.
[19:37] <cjwatson> Somebody should check whether we're at least 512MiB rather than just MB.  If nobody else does then I will tomorrow.
[19:38] <cyphermox> Laney: thanks
[19:39] <cyphermox> Laney: any idea if something appears to be stuck running there, or something?
[19:39] <Laney> cyphermox: only vaguely educated guess though ...
[19:39] <cyphermox> Laney: it seems reasonable anyway
[19:40] <Laney> sec
[19:41] <cyphermox> Laney: I'm trying to figure out what part is breaking that makes the packages not get really published, so if there's nothing in the incoming directory (seems the right one) on snakefruit, then maybe the jenkins instance is unsuccessful at pushing the rsync files
[19:41] <cjwatson> There's eight auto-accepts running, which is kinda odd
[19:41] <cjwatson> But unrelated
[19:41] <cyphermox> aye
[19:42] <Laney> snakefruit pulls the files
[19:42] <cyphermox> Laney: could you check if maybe the crontab got deleted?
[19:42] <cyphermox> assuming it's as I expect, a cron job running to do this
[19:42] <Laney> it did not
[19:42] <cjwatson> I think LP had a hiccup and a job got stuck
[19:42] <robru> LP certainly had a hiccup...
[19:42] <cjwatson> Just checking, please excuse slow network
[19:42] <Laney> there's an instance of it running
[19:42] <cjwatson> 20814 17:20:01      \_ /usr/bin/python /home/ubuntu-archive/cu2d/cupstream2distro//copy2distro --no-filter
[19:42] <cjwatson> elderly
[19:42] <cyphermox> ah
[19:43] <cyphermox> could well be that yeah
[19:43] <cjwatson> I've killed it
[19:43] <cyphermox> thanks
[19:43] <robru> cyphermox, so do we have to republish now?
[19:43] <cyphermox> robru: let's wait, I expect the next run to pick up the files... hopefully
[19:43] <robru> cyphermox, ok
[19:43] <cjwatson> please don't republish until we've traced
[19:43] <cjwatson> unfortunately I'm uploading grub2 over wet string at the same time ...
[19:44] <cyphermox> cjwatson: in the meantime I'm trying to check which packages we're expecting to see published by citrain that haven't made it yet
[19:44] <robru> cyphermox, it's phablet-tools and indicator-keyboard
[19:46] <cjwatson> ha, there, it hadn't pulled because an old job was stuck
[19:46] <cyphermox> yup
[19:46] <cjwatson> so kill old job -> next one runs and pulls
[19:46] <cjwatson> good
[19:46] <cyphermox> thanks!
[19:47] <robru> cjwatson, Laney, cyphermox: thanks
[19:48] <cjwatson> Laney: sorry if I stepped on your toes, I think I took a while to remember that you had access and I was IRC-lagged ...
[19:48] <cjwatson> (and was half-expecting to have to check the package copy job logs, which are more restricted)
[19:48] <Laney> No worries, glad it was easy enough to sort out
[20:00] <infinity> slangasek: Unsure if thorough review or distracted vorlon.
[20:00] <slangasek> ELUNCH
[20:00] <slangasek> or maybe that's SIGLUNCH
[20:00] <slangasek> back now though
[20:00] <infinity> ELUNCH is so 1998.  It's iLunch now.
[20:02] <infinity> HAHAHA.    My turn for lunch.
[20:12] <elfy> infinity: aah - good, so we're not releasing Saucy Salamander again then :)
[20:13] <infinity> elfy: We could try.
[20:37] <wgrant> cjwatson: That's probably fine.
[20:39] <infinity> slangasek: Oh, there's also the kylin-keyring there that I ping-ponged back to you.
[20:39]  * infinity lunches harder.
[20:39] <slangasek> infinity: yah, am reviewing it now; was just comparing to how other things set up shop under /etc/apt/trusted.gpg.d
[20:40]  * slangasek gets very confused by the output of 'mk-build-deps' telling him this package has no build-deps
[20:40] <infinity> slangasek: I'm not sure if there's a precedent here.  There's apt-add-repository which adds keyrings directly to the directory, but that's cause it's only mangling config, not shipping packaged files.
[20:41] <infinity> slangasek: Shipping in /usr/share and having a non-dpkg-owned symlink felt right to me, since deleting the symlink should be preservable configuration IMO.
[20:41] <slangasek> infinity: debian-archive-keyring installs files directly under /etc, but I don't /like/ that precedent
[20:42] <slangasek> infinity: your maintainer scripts aren't set -e
[20:42] <slangasek> what happens if ln -s fails!
[20:43] <slangasek> (accepting anyway; you can fix it in postproduction :P)
[20:43] <slangasek> infinity: if you happen to have a chance to throw a bzr mp at lp:~ubuntukylin-members/ubuntukylin/ubuntukylin-keyring, I'm sure JackYu and maclin would appreciate it
[20:43] <infinity> Well, now I hope it does fail, just to spite you.
[20:44] <infinity> slangasek: If by "MP", you mean "commit directly, because core-dev obviously has rights", sure!
[20:44] <slangasek> infinity: or that
[20:45] <infinity> Hey neat, did someone just upload firefox in my name? :P
[20:45]  * infinity was holding off on that to batch up some porting fixes, but... Whatever.
[20:46] <robru> any chance we could get unity, indicator-session, and webbrowser-app in before the freeze? they're all bugfixes
[20:46] <robru> (published in citrain earlier today)
[20:47]  * infinity really wishes the queue told me who signed uploads, it's disconcerting to see uploads from me that arent.
[20:54]  * slangasek blinks at the linux package in the queue
[20:55] <infinity> slangasek: You said you wanted half the base system.
[20:55] <infinity> slangasek: We live to give.
[21:01] <cyphermox> infinity: I ship you beer to which address re: this 11-second-late indicator-bluetooth upload? :)
[21:02] <infinity> Looks like you might owe slangasek a beer.
[21:02] <cyphermox> indeed
[21:03] <stgraber> cyphermox: you owe me a beer now, I was the one ignoring the time and clicking accept ;)
[21:04] <slangasek> yeah, wasn't me
[21:04] <cyphermox> stgraber: yeah, but I was obvious telling you about it when it showed up here
[21:04] <cyphermox> stgraber: next lunch at McKibbins ;)
[21:04] <stgraber> sure :)
[21:19] <bdmurray> slangasek: shouldn't we disable apport sending crash reports to launchpad now?
[21:19] <stgraber> 20 minutes ago would have been better, but yes, we should
[21:20] <bdmurray> I'm sorry I was slow thinking about someone else's thing
[21:21] <bdmurray> Anyway, shall I upload it?
[21:22] <Noskcaj> Is https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfburn/bugfixes/+merge/215094 safe to upload? it's a new bugfix release for xfburn
[21:29] <bdmurray> uploaded apport
[21:30] <stgraber> Noskcaj: that package is seeded and we are in final freeze, so my guess would be, no
[21:31] <Noskcaj> ok
[21:31] <slangasek> bdmurray: hmm, did we never get to the point where we keep whoopsie enabled throughout the cycle but keep launchpad disabled by default throughout the cycle?
[21:32] <slangasek> this is probably one of those questions I ask every 6 months and then forget the answer
[21:32] <slangasek> so what's the story with the linux in the queue?  Is that for the first SRU?
[21:32] <bdmurray> slangasek: there is still a fair bit of development that needs to happen on errors for that to be the case
[21:33] <slangasek> bdmurray: ok - sounds like something we should talk about immediately after opening unctuous umbrellastand
[21:34] <gilir> any chances to accept lxsession + lubuntu-default-settings ? They fix some annoying bugs on the lubuntu ISO
[21:36] <stgraber> gilir: so lubuntu-default-settings seems to introduce a new package, yet I don't see anything depending/recommending it, what's the purpose of this?
[21:36] <barry> uvular uakari
[21:37] <gilir> stgraber, it's a new binary to add only on the ISO, it should be only on the seed
[21:37] <gilir> stgraber, it only adds a .desktop to disable light-locker on the ISO
[21:42] <stgraber> ok, accepted that one and will binNEW the package to universe when it's built
[21:43] <infinity> slangasek: No, that's for the archive.
[21:43] <infinity> slangasek: Just not bothering to accept until all the binaries roll in.
[21:44] <stgraber> gilir: lxsession is realistically impossible to review because for a bugfix release it's pretty massive. I assume you tested it well before upload?
[21:44] <gilir> stgraber, thanks
[21:45] <gilir> stgraber, yes, sorry about this, I tested it during last days and it's working fine
[21:46] <Riddell> KDE incoming!
[21:47] <stgraber> gilir: ok, the .vala seems vaguely sane, so I'll accept it
[21:47] <gilir> stgraber, if it's easier, you can check the git tree directly, it's the last 7 commits : http://git.lxde.org/gitweb/?p=lxde/lxsession.git;a=shortlog
[21:48] <stgraber> nah, the diff is fine once you ignore all the generated .c files
[21:48] <stgraber> Riddell: you're aware you're past final freeze right? :)
[21:48] <stgraber> Riddell: you'll owe us at least one beer per package
[21:48] <Riddell> stgraber: too late, kde4libs was in before freeze and so the rest must follow
[21:48] <gilir> stgraber, ok, thanks :-)
[21:49] <slangasek> gilir: while we're at it, there's a lubuntu-artwork in the queue; I don't understand the changelog entry, there are no bugs listed, and we're at the deadline - what should be done with this?
[21:49] <slangasek> Riddell: er, how does it follow that they must be accepted because kde4libs was?
[21:50] <slangasek> infinity: ok, *why* is there a new kernel in the queue, post-kernel-freeze?
[21:50] <slangasek> infinity: since when are we playing fast and loose with the kernel freeze deadlines?
[21:51] <infinity> slangasek: You'd have to ask the kernel team why they felt it was appropriate, but it seemed sane enough (well, sane as can be) when I reviewed it, at least.
[21:52] <gilir> slangasek, it's not critical for the release, just moving a directory in the same binary package (from 1 theme to another), it can be SRUed if you prefer
[21:52] <slangasek> infinity: but the kernel freeze doesn't just exist for the benefit of the kernel team, revving the kernel also impacts the rest of the team during a critical window (because we have to futz with d-i etc)
[21:52] <infinity> slangasek: we have to upload d-i anyway, to be fair.
[21:53] <slangasek> gilir: I don't see how "moving a directory in the package" qualifies under either the SRU or freeze guidelines, maybe you could explain this in terms of user-facing impact?
[21:53] <slangasek> infinity: oh, do we?  For grub, or?
[21:53] <infinity> slangasek: eglibc, grub, flash-kernel, kmod...
[21:53] <slangasek> infinity: heh, ok.
[21:53] <infinity> slangasek: There've been a fair few udebs changed since the last build.
[21:54] <infinity> udev...
[22:01] <stgraber> roaksoax: hey, so you know we're past final freeze right?
[22:01] <gilir> slangasek, basically, metacity theme is currently in an inherited theme, not the main artwork theme. This commit moves the metacity theme to the main artwork theme, so both themes have the settings available (main and inherited). It's not critical because we don't use metacity by default on lubuntu.
[22:02] <stgraber> seems to me kinda late to land new maas features
[22:03] <slangasek> stgraber: there was an FFe request before final freeze, with discussion that took until now to converge on an upload
[22:03] <stgraber> slangasek: ok
[22:04] <slangasek> gilir: ok, so if "it's not critical" I would say it's best to reject this and leave it for 14.10 entirely, unless you want to argue otherwise?
[22:04] <stgraber> slangasek: hmm, the FFe was never acked
[22:04] <stgraber> slangasek: bug 1305839
[22:04] <ubot2> Launchpad bug 1305839 in maas (Ubuntu) "FFe: Support for Third Party Driver Installation" [Critical,New] https://launchpad.net/bugs/1305839
[22:04] <gilir> slangasek, no, I'm fine with rejecting it
[22:05] <slangasek> gilir: ok, rejecting - thanks
[22:06] <slangasek> stgraber: not sure if the FFe ack happened outside the bug, but infinity was involved in the discussion
[22:06] <slangasek> (in fact, he was the one driving the changes required)
[22:08] <stgraber> slangasek: ok, I'll let infinity deal with the upload then
[22:26] <jamespage> is anyone in the release team looking at the neutron upload I put in the queue ~8 hrs ago?
[22:30] <xnox> looks like kubuntu will be bug-free rock-solid by thursday =)
[23:03] <slangasek> jamespage: I'm looking at it now
[23:03] <slangasek> xnox: are you cherry-picking bug #1303891 in?
[23:03] <ubot2> Launchpad bug 1303891 in upstart "new initctl should fallback to old reload signal semantics, if pid1 doesn't export reload dbus method" [High,Triaged] https://launchpad.net/bugs/1303891
[23:21] <xnox> slangasek: yes, had a volleyball match, now back to complete upstart upload.
[23:22] <slangasek> xnox: no spiking the packages over the queue
[23:23] <xnox> =))))))))))))))))))))))))
[23:23] <xnox> slangasek: i dig what you did there.
[23:24] <slangasek> jamespage: looking at this neutron upload, I'm concerned you may have some missing Replaces between neutron-common and neutron-*-agent; conffiles have moved between the packages, but neutron-common doesn't Replace the previous owners
[23:38] <slangasek> jamespage: I've reuploaded neutron with proper breaks/replaces, I think I'd like someone else to review it now before it goes in to make sure I didn't screw anything up
[23:40] <roaksoax> s
[23:41] <roaksoax> slangasek: are we good to accept maas too?
[23:41] <slangasek> tjaalton: yes, I saw your mkhomedir commit, launchpad told me ;)  and yeah, there's no noninteractive way to enable profiles, that's been a longtime request and something it would be great to see fixed
[23:42] <slangasek> roaksoax: I think we were going to let infinity review maas since he's already familiar with the pending changes
[23:42] <slangasek> stgraber: if you're around and can review the neutron reupload, I'd appreciate it
[23:44] <xnox> slangasek: i'm treating all uploads from now on as SRUs, thus requiring bug # references and sru template / test-case in good standing. E.g. would help in case an upload doesn't make into "release" but gets re-diverted to be an SRU.
[23:45] <xnox> infinity: "final release of Saucy Salamander in a week." looks like it's not just timezone challenged =)))))
[23:46] <slangasek> xnox: that will certainly make the release team's job easier when reviewing
[23:57] <JackYu> hi, release team, good morning:)
[23:58] <xnox> JackYu: i still didn't sleep yet =)
[23:59] <JackYu> xnox, I see. You are very busy today. Hope you have a nice weekend:)


[10:07] <melodie> hi
[10:07] <melodie> can I announce my new Ubuntu remix here?
[10:07] <melodie> Bento Openbox 64bits
[16:37] <senan> balloons, hi
[16:42] <balloons> hello
[16:42] <DanChapman> :-O
[16:43]  * DanChapman waves to balloons
[16:44]  * balloons waves back
[16:44] <balloons> car repair time, bum finger and all
[16:44] <DanChapman> oh yeah i saw you G+ post. Ouch!!
[16:44] <balloons> yea, it's looking much worse now, lol, it's all purple
[16:45] <balloons> guess it's gonna take some time to heal up
[16:45] <DanChapman> well at least we all now know not to try it :-)
[16:57] <senan> balloons, if I run 6 tests, 6 temp directories will be created ?
[16:57] <balloons> senan, yes
[16:57] <balloons> they be created at start and destroyed at the end
[16:58] <balloons> I mean, it does depend on how you setup your test, but yea that's the idea
[16:59] <senan> balloons, also the returned directories will be /tmp/xxxxx right
[17:00] <balloons> yes
[17:00] <senan> balloons, so Instead of using /home I can use the fake directory
[17:00] <balloons> did you see the code I left?
[17:01] <balloons> use os.env("HOME")
[17:01] <balloons> it will use your fake home
[17:02] <senan> balloons, yes..  It will fail. but can you take a look at the code ?
[17:17] <senan> balloons, please check and let me know..I'm sure I missed something
[17:18] <balloons> i will, do the tests work?
[17:19] <senan> balloons, 3 failures..but I just need to know the way I am doing things is correct or not..\
[17:39] <balloons> senan, patch before you launch the app
[17:39] <balloons> self.home = self.patch_home() before self.app = self.launch_test_application('baobab')
[17:41] <senan> balloons, Do I need to add some files to dir ?
[17:47] <senan> balloons, also in line 209, I'm doing one validation..that is broken bcz I'm using the mock
[17:54] <balloons> senan, yes, move whatever you need into your new temporary home
[17:55] <balloons> or create files.. whatever you need for the test
[17:55] <senan> balloons, that will be automatically deleted right
[17:55] <balloons> yep
[17:55] <balloons> the + self.addCleanup(shutil.rmtree, temp_dir) does this
[18:14] <senan> balloons, can we specify the launched application to display in the middle of the screen.. here the Ok, and Cancel buttons are showing below screen and autopilot fails to click
[18:25] <senan> balloons, or else can I maximize a window ?
[18:33] <disc0tech> Actually I would also be keen to know how to maximise a window, I've found sometimes that helps with stability - I couldn't figure out a way to do it
[18:52] <senan> DanChapan, Is there any way to maximize a window
[19:16] <balloons> that's odd.. the window is launched offscreen?
[19:20] <senan> balloons, I just pushed my latest code..can you please review it ?
[19:20] <balloons> looks fine -- running now?
[19:25] <senan> balloons, having one issue
[19:25] <senan> balloons, the file chooser dlg's open button is way below my screen..so autopliot is not clicking it
[19:27] <senan> balloons, just want to know is it possible to maximize the baobab window... in that case that issue wont happen
[19:32] <balloons> http://unity.ubuntu.com/autopilot/api/process.html
[19:33] <balloons> should be accessible under self.process_manager
[19:36] <balloons> if not leave a message in the merge, I'll reply later
[19:37] <senan> balloons, ok..I'm going to sleep ..its 1 AM here :)
[19:37] <balloons> good night senan !
[19:38] <senan> balloons, Good Night


[18:32] <arielsanflo> hello
[18:32] <arielsanflo> help
[19:48] <lifeless> !ask | arielsanflo
[19:48] <ubot2`> arielsanflo: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
[20:05] <arielsanflo> hello