=== mackie is now known as mackiesurfacepro
=== mackiesurfacepro is now known as mackie
[04:19] <DarinMiller> any chance I can help package Remmina 1.2 in the Zesty release cycle?  I do not know much about packaging I usually only have time to learn on weekends.  But if someone wil guide me I will be happy to do the work.
[04:43] <jbicha> DarinMiller: I believe you'd need a newer freerdp first
[04:47] <jbicha> ooh, it's in Debian's new queue https://bugs.debian.org/814676
[04:47] <ubottu> Debian bug 814676 in src:freerdp "freerdp: please update to latest upstream head(?)" [Important,Open]
[04:48] <Son_Goku> it's not going to happen unless Debian is okay with breaking a few other packages
[04:48] <Son_Goku> we had to make a rather difficult choice in Fedora and actually break guacamole because Remmina needs FreeRDP 2.0
=== JanC_ is now known as JanC
[04:49] <jbicha> Son_Goku: it looks like Debian is packaging it as 'freerdp2' in experimental
[04:50] <Son_Goku> ah yes, because upstream finally made the paths not conflict
[04:50] <Son_Goku> it's not in experimental yet, though
[07:18] <pitti> Good morning
[07:19] <pitti> mapreri: maintaining Testsuite-Triggers manually sounds fine -- dpkg just provides a  sane default
[07:19] <pitti> tsimonq2: 1647031> ah, thanks
[07:38] <cpaelzer> good morning pitti
[07:39] <pitti> hey cpaelzer, wie gehts? gut heimgekommen?
[07:39] <cpaelzer> pitti: a while ago you had good feedback on the sru review of bug 1546674
[07:39] <ubottu> bug 1546674 in libvirt (Ubuntu Xenial) "virt-aa-helper Apparmor profile missing rules for name resolution" [Medium,Triaged] https://launchpad.net/bugs/1546674
[07:39] <cpaelzer> pitti: the new version of the fix is in zesty and now waiting since 11 days for SRU - re-review - not sure how the process works to pick it up again - so *ping*
[07:39] <cpaelzer> pitti: ja war ja der einfachste Flug für mich (direkt)
[07:40] <cpaelzer> pitti: 30 Minuten parkhaussucherei, aber im Verhältnis zu den meisten Kollegen ist das ja nichts
[07:41] <pitti> cpaelzer: ah, will review
[07:41] <cpaelzer> pitti: thank you
[07:41] <pitti> cpaelzer: indeed, this now looks so much better
[07:43] <cpaelzer> pitti: was your way back smooth as well - or any travel-hickups on the way?
[07:44] <pitti> cpaelzer: no, all worked fine, just took a long time due to 4:30h layover in Madrid
[07:44] <pitti> but it was fine -- I hacked on apport, and almost forgot the time :)
[07:44] <pitti> had to run to my gate and was the last one to go through
[07:44] <cpaelzer> pitti: according to the messages I got US was a bit haunted by some storms and due to that delayed and cancelled connections - so in this case - happy EU trips
[07:44] <pitti> \o/
[07:45] <cpaelzer> pitti: work 'til you'll be left behind :-)
[08:51] <caribou> pitti: let me know if you want me to run stuff on my laptop for LP: #1647031
[08:51] <ubottu> Launchpad bug 1647031 in systemd (Ubuntu) "systemd-resolved’s 127.0.0.53 server does not follow CNAME records" [Low,Triaged] https://launchpad.net/bugs/1647031
[09:26] <pitti> caribou: are you sure you have the exact same problem? this bug has become a mush of "me toos" where everyone experiences something different
[09:26] <pitti> caribou: like, Anders' bug is that he does not have systemd-resolved.service actually running (apparently)
[09:27] <pitti> (will follow up on that shortly)
[09:32] <caribou> pitti: I can de-dup my previous bug if you prefer
[09:35] <pitti> caribou: yeah, might be better as long as it's unclera
=== jamespag` is now known as jamespage
[09:57] <ginggs> pitti: do you know if there is a size limitation on autopkgtest artifacts?
[09:57] <pitti> ginggs: not a technical one, but be reasonable; don't have tests spit out multi-megabyte artifacts all the time
[09:58] <ginggs> pitti: ack
[10:49] <bigon> are there plans to push libsnap-glib in debian?
=== vrruiz_ is now known as rvr
=== _salem is now known as salem_
=== hikiko is now known as hikiko|ln
[12:02] <xnox> bigon, maybe willcooke can answer that.
[12:04] <willcooke> bigon, no concrete plan of action more than "we should" at the moment.  Once it's settled down and matured a bit I think we'll do it then
[12:05] <bigon> I had to disable the snap plugin in my last gnome-software upload in debian
[12:05] <willcooke> bigon, best person to speak to is robert_ancell, you want his email address?
[12:06] <bigon> I have his address somewhere :)
[12:09] <willcooke> bigon, I might speak to him tonight, so I will find out for sure and let you know, but yeah, do direct to him if you like
=== hikiko|ln is now known as hikiko
[12:43] <kmadac> Hello guys, I'm new to Ubuntu contribution. I found a bug in package isc-dhcp-client and I would like to propose a fix. I  have read Ubuntu contribution guides, but I'm stucked in pulling sources from bazzar. I'm getting error Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/isc-dhcp-client/". Any ideas what i'm doing wrong?
[12:45] <Bluefoxicy> when is cmiller waking up :|
[13:06] <sladen> kmadac: ideally first file a bug report saying what the but is, and how to reproduce it (ie. show that the bug exists)
[13:06] <sladen> kmadac: then attach the fix as a diff to the bug report (so it doesn't get lost, and is findable by Google)
[13:07] <sladen> kmadac: then propose the fix, showing that when trying to reproduce the bug using the original instruction, it is no longer possible
[13:10] <kmadac> sladen: thanks for answer. What do you mean by propose the fix? Diff is the fix, isn't it?
[13:10] <sladen> kmadac: the diff/patch is how implementation of the proposed fix
[13:11] <sladen> kmadac: eg. the diff to apply the fix against different versions of the same software will often be slightly different, (eg. changes in line numbers)
[13:12] <kmadac> sladen: great, should I then wait till someone from ubuntu devs implement the fix?
[13:13] <kmadac> sladen: or can I send pull/merge request somewhere?
[13:13] <sladen> kmadac: please file the bug first, so that then you can say $bug is fixed by $proposed_pull_request
[13:14] <sladen> kmadac: ideally we try and get bug fixes applied by upstream first if possible, so that everyone benefits; not just Ubuntu or Debian users
[13:15] <sladen> kmadac: the bug report also allows keeping track of what communication with upstreams
[13:17] <kmadac> sladen: ok I will fill a bug, but can you please elaborate more about proposing pull request? Or can you point me to some documentation how to do it? Is it still done over bazaar as is stated in public documentation, or was it changed?
[13:19] <sladen> kmadac: http://stackoverflow.com/a/20273376/839696
[13:20] <sladen> kmadac: (you need the bug number, to link the metadata together for what the proposed fix is)
[13:21] <kmadac> sladen: thanks :), I'm going to fill the bug report
[13:29] <Bluefoxicy> I wish goa-daemon wouldn't time out and break evolution
[13:29] <Bluefoxicy> requiring a manual killall goa-daemon and then a run of /usr/lib/x86_64-linux-gnu/gnome-online-accounts/goa-daemon
[13:30] <Bluefoxicy> Bill Gates recommended rebooting frequently to avoid problems like this
[13:36] <cjwatson> kmadac: The Bazaar importer has been mostly decommissioned since it was too unreliable.  There's a Git version in progress but it's not completely done.  In the meantime you're better off simply sending patches.
[13:37] <cjwatson> I don't think sladen's link is going to help much nowadays.
[13:37] <cjwatson> (Unless there is an obvious upstream repository that you can propose a merge into.)
[13:53] <caribou> rbasak: when you have a minute, could you please review my last comment on LP: #1176046 ?
[13:53] <ubottu> Launchpad bug 1176046 in isc-dhcp (Ubuntu) "isc-dhcp dhclient listens on extra random ports" [High,In progress] https://launchpad.net/bugs/1176046
[13:57] <rbasak> caribou: I don't understand your comment.
[13:58] <rbasak> "...if isc-dhcp-ddns Breaks/Replaces isc-dhcp and Recommends isc-dhcp-ddns..."
[13:58] <rbasak> It would Recommend itself?
[13:58] <rbasak> I don't really follow what Breaks/Replaces would do here.
[13:58] <rbasak> isc-dhcp-ddns in Xenial supplies /sbin/dhclient with a divert.
[14:03] <mterry> slangasek: is Foundations willing to look after libsmbios in main?  And if so, can you subscribe ~foundations-bugs to its bugs?  (this is re: MIR bug 1603072)
[14:03] <ubottu> bug 1603072 in libsmbios (Ubuntu) "[MIR] libsmbios" [Undecided,In progress] https://launchpad.net/bugs/1603072
[14:26] <attente> hi, would it be possible to backport the bubblewrap package to xenial?
[14:28] <seb128> attente, hey, backport or SRU? any of those should be possible I think, depending why you need it
[14:29] <attente> seb128: i'm not sure the distinction tbh, it's needed so that the integration test for the snapcraft jhbuild plugin can pass there
[14:30] <seb128> do they have a ppa they are using where it could be added?
[14:30] <attente> seb128: the package doesn't seem to exist there atm, so it would be a new package in universe
[14:30] <seb128> I guess it's a question for the snappy team
[14:30] <seb128> like mvo should be able to guide you?
[14:30] <seb128> or ogra
[14:30] <attente> ok, thanks seb128, i'll ask there
[14:31] <seb128> I sort of pinged them
[14:31] <seb128> so maybe they reply here ;-)
[14:31] <attente> oh, right :)
[14:31] <mvo> attente: backport is trivial, just dput the package and target to xenial-backports in the changelog
[14:31] <mvo> attente: well
[14:32] <mvo> attente: or file a backport request, depends a little bit if it needs source changes or not
[14:32] <mvo> attente: see https://wiki.ubuntu.com/UbuntuBackports
[14:32] <mvo> attente: it should be pretty lightweight
[14:32] <mvo> attente: sru is a bit more work, you know the drill for this already I think :)
[14:32] <seb128> mvo, the question is rather from the snappy CI infra side
[14:33] <seb128> mvo, what env is used for snapcraft integration tests? does that include some ppas or backports?
[14:34] <mvo> seb128: snappy or snapcraft? snapcraft is a sergiusens question, I would assume they can easily use xenial-backports
[14:34] <attente> it's snapcraft
[14:34] <seb128> mvo, sorry, snapcraft indeed, should have bother sergiusens and not you ;-)
[14:34] <mvo> seb128: np
[14:34] <attente> i guess it's a backport since the package isn't there at all in xenial
[14:34] <seb128> sergiusens, ^ can snapcraft integration tests use xenial-backport or a ppa?
[14:35] <seb128> attente, well, you can SRU a package that was not there, we did it with snapd-xdg-open if you remember ;-)
[14:36] <seb128> but backport is an easier process
[14:36] <sergiusens> seb128 attente can adt? Maybe so, or maybe just disable the test for xenial and make your plugin query where it is running on
[14:37] <seb128> sergiusens, it means you are not using backports or a ppa? would be better to have things working rather than disabled...
[14:38] <attente> yeah, the integration tests seem to be passing on y and z already, so if we can just get the package on x too, that would be preferable
[14:38] <sergiusens> seb128 yeah, we are not using backports or PPAs, just xenial-updates
[14:39] <seb128> k
[14:39] <attente> should we sru it then?
[14:39] <seb128> sounds like it
[14:39] <seb128> or talk to sergiusens about enabling backports
[14:39] <seb128> or disable the test on xenial...
[14:39] <seb128> well maybe do that to unblock the landing
[14:39] <seb128> but then work on getting it SRUed
[14:40] <seb128> or change to use a tech which is available in xenial ;-)
[14:40]  * attente didn't hear the last one
[14:40] <seb128> lol
=== scottt is now known as Guest80391
[15:07] <xnox> pitti, google-chrome does not like to die, upon logout, under systemd user session with unity7
[15:07] <xnox> is there any trigger that kills chrome under upstart session? (e.g. does upstart use a bigger hammer, faster?)
[15:07] <xnox> also nm-applet appears to be "slow" under systemd.
[15:08] <xnox> it takes me good 10-15seconds for both indicator-network and nm-applet to appear.
[15:08] <xnox> (fixing the fact that they are duplicates)
[15:16] <dobey> xnox: chrome doesn't have an upstart job afaik. it's just gnome-session killing things i think, or maybe just when X dies
[15:19] <dobey> xnox: if nm-applet and indicator-network are both slow to appear, maybe something lower level like communications with network-manager being slow
[15:22] <xnox> dobey, upon logout everything dies but chrome stays alive, from tty2 i can see that chrome has become a child of the user systemd session and somehow is still alive.
[15:23] <xnox> given all the rectangular bubbles I see, i think the chrome "extensions/apps" are simply respawning.
[15:24] <xnox> so something somewhere is not given a chance to kill chrome "properly" e.g. gnome-session/bamf killed without it given a chance to kill chrome, or chrome catching signals and respawning.
[15:24] <xnox> ack. will debug more.
[15:24] <dobey> xnox: yeah, it's sounding like an issue with systemd stuff to me, i mean.
[15:25] <xnox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1649309
[15:25] <ubottu> Launchpad bug 1649309 in systemd (Ubuntu) "google chrome, is slow to die, upon systemd user session logout" [High,Confirmed]
[15:46] <slangasek> mterry: foundations-bugs subscribed to libsmbios
[15:47] <mterry> slangasek: oh thanks!
[15:55] <bregma> hey tjaalton is there an ETA for x.org 1.19 landing in Zesty?  I have some XMir bugfixes and I want to coordinate work
[15:59] <tjaalton> bregma: xmir needs to be ported first, and nvidia blobs need to support the new abi before it can land
[15:59] <tjaalton> bregma: so probably not before mid-january'ish
[16:00] <tjaalton> bregma: tseliot is out until then, and I'm off for two weeks as well
[16:02] <bregma> tjaalton, I have a 1.19 port for XMir already, but we need to land in 16.04 ASAP because it's blocking other stuff from landing
[16:03] <bregma> I can just SRU the patch short-term if a 1.19 landing is not imminent
[16:03] <xnox> dobey, tedg: what is unity-greeter-session-broadcast and is it needed in the all-snap world? and/or needs a rewrite for the all-snap world?
[16:03] <tjaalton> bregma: yeah it's not imminent
[16:04] <tedg> xnox: It handles sending messages from the greeter session to the user session.
[16:04] <dobey> xnox: no idea
[16:04] <tedg> xnox: Not sure it needs to be rewritten, but it should be in the U8 snap with the U8 greeter and U8 session.
[16:04] <tedg> xnox: It'll have to be a system service.
[16:05] <tjaalton> bregma: should git://git.launchpad.net/~xmir-team/xorg-server/+git/xmir have the latest? or haven't pushed there yet?
[16:05] <dobey> tjaalton: btw, did the mesa causing gtk+ (aka everything) to crash in zesty-proposed get fixed btw?
[16:05] <tedg> xnox: We're not entirely sure on the architecture there though, I imagine the greeter will be in the same snap as the session so we won't need any security stuff there.
[16:05] <tjaalton> dobey: yes
[16:05] <bregma> tjaalton, I haven't pushed there yet
[16:05] <tjaalton> bregma: gotcha
[16:05] <dobey> awesome
[16:05] <xnox> tedg, the things it does, have no systemd equivalent. e.g. one cannot start a systemd unit on per message (aka equivalent of the upstart-dbus-bridge events)
[16:06] <tjaalton> dobey: although it's still in proposed because of tests
[16:06] <xnox> tedg, and all i can see, it triggers url-dispatcher event.
[16:06] <tedg> xnox: Sure, it'll have to switch to be dbus-activation. So I guess it'll need refactoring, not rewriting.
[16:06] <xnox> tedg, a system thing that store greeter events and send them to session url-dispatcher make sense. I think it just needs to be done outside of systemd, just over dbus.
[16:07] <xnox> priviledged thing, that greeter talks to and stores "events" there, and then session which talks to priviledged thing to retrieve and action "events"
[16:07] <xnox> tedg, ack.
[16:07] <dobey> tjaalton: that's fine; it was blocking build of some stuff that runs binaries with gdk_init during tests
[16:07] <tjaalton> ubiquity, yes
[16:07] <dobey> tjaalton: so hopefully i can build now, and at least "land" a fix or two that we need for unity8 snap
[16:10] <jbicha> bigon: https://irclogs.ubuntu.com/2016/11/21/%23ubuntu-devel.html#t20:28
[16:17] <jbicha> (I'd rather not be the Debian maintainer for snapd-glib now)
[16:33] <bigon> jbicha: ok
[16:38] <seb128> bdmurray, hey, why did you assign bug #1647020 to our team? it seems a pretty random report without much details
[16:38] <ubottu> bug 1647020 in gnome-power-manager (Ubuntu) "Brightness resets to full when on/off battery" [Undecided,New] https://launchpad.net/bugs/1647020
[16:41] <bdmurray> seb128: because its from a canonical employee and seemed like a regression.
[16:42] <seb128> bdmurray, ok, thanks, I'm going to comment on it but it's more likely a kernel issue than a desktop one
[16:42] <bdmurray> seb128: okay, thanks for following up
[16:42] <seb128> yw!
[16:50] <caribou> rbasak: sorry, I missed your question and, indeed my comment is unclear
[16:51] <caribou> rbasak: I'll clarify my comment in the bug
[19:00] <rbasak> !dmb-ping
[19:00] <ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
[19:01] <rbasak> Need one more for quorum.
[20:49] <fossfreedom> Hi all - David Mohammed here - project lead for Ubuntu Budgie.  Just hoping that someone can have a look over our pull request for lp:ubuntu-cdimage ?
[20:49] <fossfreedom> https://bugs.launchpad.net/ubuntu-cdimage/+bug/1647862
[20:49] <ubottu> Launchpad bug 1647862 in Ubuntu CD Images "ubuntu-budgie proposal" [Undecided,New]
[20:54] <xnox> fossfreedom, have you considered to name this flavour "Bubuntu"?
[20:54] <xnox> =)
[20:55] <xnox> ikey would like that =)
[20:55] <fossfreedom> shudder
[20:55] <fossfreedom> no thanks!!
[20:55] <xnox> fossfreedom, hahaha =) fair enough! =)
[20:56] <xnox> fossfreedom, do you need and will you test i386 image? (btw it does not have uefi support, and e.g. ubuntu.com only advertises amd64 images across the board by default)
[20:57] <xnox> fossfreedom, official flavours should be teams by default, even if that team has a single person. As it's easier to manage ACL that way. E.g. said team will join ubuntu-devs and e.g. ubuntu core-devs will join the ubuntu-budgie-dev team etc.
[20:57] <fossfreedom> yep - there seems to be very few testers now who concentrate on i386 - would welcome any help once the ISO's start to be created.
[20:58] <fossfreedom> I've created a team here: https://launchpad.net/~ubuntubudgie-dev
[20:59] <xnox> fossfreedom, my question is kind of a devil's advocate - why not go amd64-only?
[20:59] <xnox> it's only 15 years old.
[20:59] <fossfreedom> Question really for the Ubuntu community - I know it has been recently floated again to drop i386.
[21:00] <jbicha> if Budgie goes amd64 only, Ubuntu GNOME might follow
[21:01] <fossfreedom> mind you - just today I had two people wondering if its possible to install the 386 version.  Answer given was to "try and let me know"
[21:01] <jbicha> I'm reluctant to have us do something like that if no other flavor is
[21:01] <cjwatson> fossfreedom: That's partly true, but there are different considerations that apply to adding a new flavour vs. changing existing flavours
[21:01] <cjwatson> They don't all have to be in sync
[21:02] <jbicha> supporting both i386 and amd64 is to some extent twice the work when testing iso release milestones
[21:02] <xnox> fossfreedom, removing an arch/image-type is pain; adding an arch/image-type if there is actual demand is trivial.
[21:02] <xnox> (ripping band-aid off versus putting one on)
[21:03] <fossfreedom> generally I soak in water first ... but yeah I know what you mean.
[21:03] <xnox> cjwatson, is it me, or the ubuntu-cdimage code is littered with lexical order comparison with all the self.config["DIST"] >= "xenial"
[21:03] <cjwatson> xnox: It's just you.
[21:03] <xnox> infinity, too ^
[21:03] <xnox> cjwatson, ok.
[21:03] <cjwatson> I was cleverer than that :-)
[21:03] <cjwatson> Look in lib/cdimage/config.py
[21:04] <cjwatson> Series is a magic thing that can do comparisons by series name but they're actually compared using their index in all_series
[21:05] <cjwatson> and self.config["DIST"] is a Series
[21:05] <xnox> nice =) you map them to index first, then compare.
[21:05] <cjwatson> Saves on a lot of verbiage
[21:05] <infinity> It's elegant in its perversion.
[21:05] <infinity> And best not examined too closely.
[21:07] <fossfreedom> jbicha - thanks for your kind thoughts BTW on my application.
[21:15] <jbicha> fossfreedom: I think lib/cdimage/tests/test_build.py shoudl be False, True
[21:18] <fossfreedom> ah - yes - good spot "unsupported" let me update
[21:21] <jbicha> honestly, I don't know what unsupported means
[21:24] <fossfreedom> corrected.
[21:27] <fossfreedom> hmm ... I don't remember "Ubuntu-Moblin-Remix" - what was that?
[21:28] <fossfreedom> ah - yes - netbook thingy
[21:59] <bdmurray> rbasak: Could you look at bug 1640823 again? Are you happy with what was most recently uploaded to -proposed?
[21:59] <ubottu> bug 1640823 in util-linux (Ubuntu Trusty) "[trusty] mount -o loop is limited to 8 loop devices" [Undecided,Fix committed] https://launchpad.net/bugs/1640823
[22:26] <fossfreedom> xnox re ~ubuntubudgie-dev - I have 'invited' ubuntu-devs to join
[22:27] <fossfreedom> xnox: re ~ubuntubudgie-dev - I have 'invited' ubuntu-devs to join
=== salem_ is now known as _salem
[22:33] <Bluefoxicy> Hooray, cmiller has arrived
=== JanC_ is now known as JanC
=== lilstevie_ is now known as lilstevie
[23:09] <Bluefoxicy> what's the appropriate way to ask for a package upgrade in Zesty?
[23:10] <Bluefoxicy> Monodevelop 6.1 supports Nuget 3 (finally) (6.2 supports Nuget 3.5, but it's not *stable* yet), and Zesty packages 5.10