=== _salem is now known as salem_
=== salem_ is now known as _salem
=== RoozbehShafiee_ is now known as RoozbehShafiee
[07:21] <ari-tczew> slangasek: could you take a look on merge bug 1396381 please?
[07:21] <ubottu> bug 1396381 in gnu-efi (Ubuntu) "Merge gnu-efi 3.0v-5 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1396381
[07:36] <pitti> Good morning
[07:43] <ari-tczew> morning
[08:14] <dholbach> good morning
=== terrex is now known as xiterrex
[10:56] <pitti> xnox, cjwatson: ubiquity's upstart job emits "starting-dm", but I don't see anythign which would actually listen to that (I grepped the entire live system); I guess that's just obsolete now?
[10:56] <pitti> lightdm also doesn't emit this event
[11:09] <xnox> pitti: one sec.
=== _salem is now known as salem_
[11:12] <xnox> pitti: it used to be in the plymouth package, keybuk removed starting-dm event dependency in 5 years and 1 day ago.
[11:13] <loucura> Hi! Could someone check this bug in oneconf: https://bugs.launchpad.net/ubuntu/+source/oneconf/+bug/1165104 ? It prevents the Software Center package sync from working. The bug has a merge request waiting for review for some time now, and it seems that fix still works.
[11:13] <ubottu> Launchpad bug 1165104 in oneconf (Ubuntu) "oneconf is only showing the pc you are on in raring and isn't sharing to other machines" [High,Triaged]
[11:13] <xnox> pitti: plymouth boot splash used to stop upon "starting-dm" screen, this from before DMs would talk to plymouth and stop it themself.
[11:13] <xnox> s/screen/event/
[11:16] <LocutusOfBorg1> hi developerz
=== RoozbehShafiee__ is now known as RoozbehShafiee
[11:17] <LocutusOfBorg1> have a good bug hunting day :)
[11:32] <diwic> LocutusOfBorg1, thanks, I just hunted one down :-)
[11:33] <LocutusOfBorg1> well done :)
[11:34] <LocutusOfBorg1> I prepared right now the virtualbox upload on debian experimental
[11:34] <cjwatson> xnox: oh well found, I'd been failing to dig that up
[11:34] <LocutusOfBorg1> and next I'll ask probably a sync from there :)
[11:45] <brainwash> xnox: there seems to be no real progress re 1375893 . could xubuntu maybe opt-in for a simple solution (e.g. feh) instead of depending on xfdesktop4 to draw the background?
[11:45] <brainwash> bug 1375893
[11:45] <ubottu> bug 1375893 in xfdesktop4 (Ubuntu) "Black background to Try/Install Dialogue" [Medium,Confirmed] https://launchpad.net/bugs/1375893
[11:46] <pitti> tseliot: do you have a machine which needs gpu-manager?
[11:47] <pitti> tseliot: I'll add a systemd unit to ubuntu-drivers-common, and I'll verify that it starts properly, but it would be good to have a final test where some failure is "visible"
[11:47] <tseliot> pitti: sure
[11:48] <tseliot> pitti: it should always start on first boot. I can tell you how to simulate first boot, then you can check the log
[11:48] <pitti> tseliot: oh, your latest upload didn't build on arm64
[11:48]  * pitti retries the build
[11:49] <tseliot> pitti: but yes, if you have some packages, I'll test it here (I need to upgrade to vivid first)
[11:53] <xnox> brainwash: it's not just the background that's a problem. xfce4settings daemon ends up defunct.
[11:53] <xnox> brainwash: whilst background is the most visible thing, other little things have also stopped working under ubiquity.
[11:54] <xnox> brainwash: a regression in xfce4settings should be found, or things identified what makes it go boom - e.g. some environment or service missing etc.
[11:58] <brainwash> xnox: it should be quite easy to find something in the commit/package history, something like this does not happen out of nowhere.. or? :)
[11:59] <brainwash> I'll try to do some research
[12:01] <brainwash> xnox: can you maybe revert the importance of this bug back to "high"?
[12:02] <brainwash> xfsettingsd should not fail
[12:03] <brainwash> and I guess that we should change xfdesktop4 -> xfce4-settings
[12:13] <pitti> tseliot: oh, I know, I've seen this "calling: hwdb" before -- apparently the buildd has "debug" in its /proc/cmdline which switches udevadm to debug mode and prints that
[12:13] <pitti> debian bug 769228
[12:13] <ubottu> Debian bug 769228 in udev "udevadm shows debug messages by default on ARM" [Minor,Open] http://bugs.debian.org/769228
[12:20] <pitti> tseliot: ok, I pushed the FTBFS fix
[12:28] <pitti> tseliot: do you mind if I stop writing /var/log/gpu-manager.log? I just let it output to stdout/err, which will land in the journal
[12:28] <pitti> tseliot: so that you see it with "sudo systemctl status gpu-manager" (or in journalctl of course)
[12:37] <pitti> tseliot: I added the unit in https://github.com/tseliot/ubuntu-drivers-common/commit/c365141a7b4, works fine here
[12:37] <pitti> tseliot: 0.2.98.6 uploaded, this should also fix the FTBFS
[12:40] <cjwatson> doko_: could somebody have a quick look over bug 1398807, please?
[12:40] <ubottu> bug 1398807 in google-apputils-python (Ubuntu) "[MIR] google-apputils-python" [Undecided,New] https://launchpad.net/bugs/1398807
[12:50] <mvo> StevenK: hi, are you on archive admin duty today or is https://wiki.ubuntu.com/ArchiveAdministration outdated? NEW for ubuntu-sdk-libs-tools would be cool
[13:01] <_ruben> I'm trying to backport rrdtool 1.4.8 (or 1.4.9 for that matter) for 14.04. But debuild -S is failing for me, is this the proper place ask?
[13:02] <didrocks> mvo: I guess nobody is really following the AA duty anymore, binNEWed
[13:03] <mvo> didrocks: \o/
[13:05] <ScottK> I think the schedule is dead, but people do still look at New.
[13:08] <teward> _ruben: I think you should start by providing what 'error' you're seeing, there's here and #ubuntu-packaging as example places you can ask about having issues with building packages...
=== Trevinho_ is now known as Trevinho
[13:14] <_ruben> teward: let me pastebin what I get
[13:15] <_ruben> teward: http://paste.ubuntu.com/9354611/
[13:17] <tseliot> pitti: is there any way we can collect the log from apport?
[13:21] <cjwatson> _ruben: "debuild -S -nc" will let you build the source package without having to have build-dependencies installed; but I don't understand the sequence of commands you're running, what's the point in all that?
[13:22] <cjwatson> _ruben: to extract the source package, just use "dpkg-source -x rrdtool_1.4.8-1.1ubuntu1.dsc", don't mess about with applying the diff by hand
[13:23] <cjwatson> _ruben: and you would only need to use "debuild -S" after actually making some change to the source package, which there's no sign of in that transcript
[13:25] <_ruben> cjwatson: pretty much the only additional step I'd add after this would work would be using 'dch' to have it point to 'trusty' instead of 'utopic' (as I haven't found a way to fool mini-dinstall without that)
[13:26] <cjwatson> _ruben: that seems thoroughly unnecessary
[13:26] <doko_> cjwatson, done. although if it's cloud related, maybe the cloud team could subscribe as well
[13:26] <_ruben> cjwatson: primary goal: backport from utopic to trusty or even from upstream
[13:26] <cjwatson> _ruben: sbuild -d trusty will put "Distribution: trusty" in the resulting binary .changes file, which is all you'll need
[13:26] <_ruben> cjwatson: these steps are based on ancient research, and have worked fine thusfar ;) wouldn't surprise if there's other/better ways to deal with this
[13:27] <cjwatson> _ruben: well, your "apply diff by hand" thing is totally wrong, don't do it :)
[13:27] <cjwatson> that will break with many modern packages
[13:27] <_ruben> cjwatson: that one's on my todo list, as in: i noticed certain (newer?) package doing this automatically after dget'ing the source
[13:28] <cjwatson> _ruben: like I say, the One True Correct Way to unpack a source package is dpkg-source -x foo.dsc
[13:28] <cjwatson> anything else is bad and wrong
[13:28] <_ruben> cjwatson: will keep that in mind
[13:28] <cjwatson> (apt-get source, pull-debian-source, pull-lp-source, etc. all wrap dpkg-source -x at various points)
[13:29] <cjwatson> doko_: thanks
[13:29] <cjwatson> smoser: could some appropriate cloud team subscribe to google-apputils-python, perhaps?  cf. bug 1398807
[13:29] <ubottu> bug 1398807 in google-apputils-python (Ubuntu) "[MIR] google-apputils-python" [Undecided,Fix released] https://launchpad.net/bugs/1398807
[13:30] <cjwatson> and discussion above
[13:30] <cjwatson> _ruben: you might also look into the backportpackage tool
[13:30] <_ruben> (and I need to look into why dch refuses to use the info in ~/.devscripts some day)
[13:31] <_ruben> cjwatson: interesting, even includes the dput part. will definately look into that one
[13:36] <smoser> cjwatson, "i've subscribed foundations-bugs" you also want server subscribed ? that is fine, but just clarifying.
[13:36] <cjwatson> smoser: I'm just following up on 13:26 <doko_> cjwatson, done. although if it's cloud related, maybe the cloud team could subscribe as well
[13:36] <cjwatson> smoser: without knowing exactly which team is appropriate on your end
[13:38] <smoser> k. done.
[13:38] <smoser> ubuntu-server is subscribed
[13:40] <cjwatson> thanks!
[13:40] <cjwatson> hopefully this will let us start the protobuf transition.  (and clear another thing from "grep-merges cjwatson", which is my actual motivation ...)
[14:07] <mlankhorst> how do I start a full ubuntu desktop without lightdm?
[14:10] <pitti> hallyn: do you plan to merge samba soon? there is a new ldb in -proposed which samba-libs conflicts to, thus causing a lot of uninstallability
[14:10] <pitti> otherwise I can do a no-change upload, but I don't want to earn the samba merge with that
[14:22] <tseliot> pitti: does "sudo systemctl status gpu-manager" dump the log into a file? I need logs to be easy to attach to bug reports
[14:23] <pitti> tseliot: no, that shows the gpu-manager related bits from the journal
[14:23] <mardy> jdstrand: is there a way to check the profile label of a running PID, from the command line?
[14:24] <tseliot> pitti: then, if there's no alternative, we should keep writing the log to a file
[14:24] <pitti> tseliot: ah sorry, missed your question above
[14:25] <pitti> tseliot: ok; indeed you currently can't access the journal as user
[14:26] <tseliot> ok
[14:29] <pitti> tseliot: pushed/uploaded
[14:29] <tseliot> pitti: thanks
[14:47] <jdstrand> mardy: yes, ps -Z
[14:48] <jdstrand> mardy: or cat /proc/<pid>/attr/current
[14:48] <mardy> jdstrand: cooool!!
[14:49] <jdstrand> I find 'ps auxwwZ' handy
[14:53] <cjwatson> pitti: I notice you aborted the gutenprint autopkgtest - was it hanging or something?
[14:54] <pitti> cjwatson: on armhf/ppc64el; yes, they always hang there, and I needed to do some admin/reboot on these devcies
[14:54] <cjwatson> pitti: oh, it's always failed.  but I wonder if that's why it still shows as "test in progress" on excuses
[14:54] <pitti> cjwatson: did I kill an x86 one by accident?
[14:54] <cjwatson> pitti: looks like on x86 too
[14:54] <pitti> cjwatson: ah sorry, rerunning
[14:54] <cjwatson> thanks
[15:05] <cjwatson> doko_: re google-apputils-python, I mentioned in the MIR that it requires python-gflags which used to be in main but was moved to universe.  do you agree with my assessment that we can move it back to main based on the previous MIR?
=== roadmr is now known as roadmr_afk
[15:37] <mardy> jdstrand: FYI, I added some comments here and added apparmor-easyprof to the bug: bug 1219644
[15:37] <ubottu> bug 1219644 in Online Accounts setup for Ubuntu Touch "Account plugins should be made confinable by apparmor" [Medium,In progress] https://launchpad.net/bugs/1219644
[15:37] <zul> doko_:  ping
[15:39] <jdstrand> mardy: thanks. I'll also add a click-reviewers-tools task
[16:08] <pitti> sforshee: bug 1398458> yeah, not at all urgent any more, with the userland stub
[16:08] <ubottu> bug 1398458 in linux (Ubuntu) "kernel fails to load iwlwifi firmware - disable CONFIG_FW_LOADER_USER_HELPER" [Low,In progress] https://launchpad.net/bugs/1398458
[16:08] <pitti> mostly a cleanup thing for the futuer
[16:13] <sforshee> pitti: sure, but better to get it fixed before I forget about it ;-)
=== roadmr_afk is now known as roadmr
[16:38] <doko_> jdstrand, yes, always handled this way
[16:39] <doko_> now promoted
[16:39] <doko_> zul, here
[16:40] <zul> doko_:  have you seen this? bug 1348954, or bug 1367907 and bug 1382607
[16:40] <ubottu> bug 1348954 in python3.4 (Ubuntu) "update Python3 for trusty" [Undecided,Confirmed] https://launchpad.net/bugs/1348954
[16:40] <ubottu> bug 1367907 in python3.4 (Ubuntu Trusty) "Segfault in gc with cyclic trash" [Undecided,Triaged] https://launchpad.net/bugs/1367907
[16:40] <ubottu> bug 1382607 in python3.4 (Ubuntu Trusty) "[SRU] Backport python3.4 logging module backward incompatibility fix." [High,Triaged] https://launchpad.net/bugs/1382607
[16:40] <cjwatson> doko_: thanks
=== zyga is now known as zyga-afk
[17:33] <doko_> zul, yes, I filed at least the first one
=== salem_ is now known as _salem
[17:45] <bdmurray> hallyn: I'm unable to start a domain in virtual machine manager due to not being able to find kvm-spice. Any ideas?
[17:46] <zul> doko_:  any eta?
[17:51] <doko_> I still hope this year ... although time is running out for me with planned vacations
[17:52] <shadeslayer> pitti: autopkgtest question for you, how can I parallelize the build that's run by adt
[17:57] <cjwatson> mdeslaur,jdstrand: do you have any opinions on following Debian in /dev/fuse permissions, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733312 ?  We seem to have addressed a similar problem by making fusermount root:root 4775 instead, but I'm wondering whether we need to keep that delta
[17:57] <ubottu> Debian bug 733312 in fuse "fuse: Please reconsider the permissions on /dev/fuse and /bin/fusermount" [Normal,Fixed]
[17:58] <infinity> shadeslayer: You mean the automated build from a "build-needed" test?
[17:58] <shadeslayer> infinity: yes
[17:58] <infinity> shadeslayer: That should parallelise the same as a regular package build via DEB_BUILD_OPTIONS="parallel=" and if it's not, either pitti's runners don't have multiple cores or he's not exporting the variable, but it's entirely on his end, not yours.
[17:59] <shadeslayer> infinity: well, I'm writing my own tooling to run some autopkgtests on debian, and wanted to parallelize the build
[17:59] <shadeslayer> so yeah
[17:59] <infinity> shadeslayer: If you mean running adt locally, yeah, maybe it needs a fix to export the variable. ;)
[17:59] <shadeslayer> yep
[18:00] <shadeslayer> infinity: so something like export DEB_BUILD_OPTIONS="parallel=8" would work right
[18:00] <infinity> shadeslayer: The simplest solution is just "export DEB_BUILD_OPTIONS="parallel=$(nproc)"" somewhere before the build happens.
[18:00] <shadeslayer> roger
[18:00] <shadeslayer> works, thx
[18:00] <mdeslaur> cjwatson: the fuse device basically allows people to become root, having fusermount be 4775 is the right approach I believe
[18:01] <cjwatson> mkay, possibly somebody with more time should clue up the Debian maintainer :)
[18:02] <mdeslaur> cjwatson: I haven't look in a long time, but I don't currently have time to spend on refamiliarizing myself with all the changes
[18:02] <mdeslaur> cjwatson: It's probably best to leave it as-is for now if you don't mind
[18:03] <cjwatson> sure
[18:03] <cjwatson> just trying to get my merge list as far down as I can before switching to LP :)
[18:04] <shadeslayer> which reminds me
[18:05] <shadeslayer> cjwatson: who will I go to for all my live build issues now :(
[18:05] <cjwatson> I'm sure somebody can be found on #ubuntu-release
[18:05] <shadeslayer> ^_^
[18:05] <cjwatson> or here for that matter
[18:07] <infinity> shadeslayer: I suspect you'll find that stgraber and I end up fielding most of those questions initially, but do ask openly on #-release, rather than privately, so we can try to smear the ex-Colin tasks (and knowledge) around a bit.
[18:07] <shadeslayer> roger :)
[18:07]  * shadeslayer has a decent bit of lb knowledge now
[18:07] <shadeslayer> which usually comes down to "The documentation lies, read the code"
[18:07] <infinity> There's documentation?
[18:07] <shadeslayer> xD
[18:08] <infinity> I've only ever hacked lb using grep. :P
[18:08] <shadeslayer> http://live.debian.net/manual/unstable/
[18:08] <infinity> Anything else seems like a lost cause.
[18:08] <shadeslayer> infinity: hehe
[18:08] <shadeslayer> infinity: by documentation I meant how to use lb
[18:08] <shadeslayer> not code documentation
[18:09] <infinity> shadeslayer: Oh, sure.  Even "how to use" is something I deal with using grep, though. ;)
[18:09] <shadeslayer> hah
[18:09] <shadeslayer> infinity: yeah, best to keep doing it that way
[18:09] <infinity> shadeslayer: "I kinda want to do this weird thing we don't do, let's grep for possible things that might sort of do that and see."
[18:09] <shadeslayer> yep
[18:09] <shadeslayer> I actually have to figure out efi madness with lb sometime
[18:09] <shadeslayer> that'll be fun
[18:10] <infinity> shadeslayer: I still have this master plan (which I think it's clear I don't have time for *sigh*) to make lb produce images that are nearly identical to our debian-cd-wrapped infrastructure (minus the package pools, initially, but at least the same boot magic).
=== brainwash_ is now known as brainwash
[18:11] <shadeslayer> oh, that would be so awesome :3
=== _salem is now known as salem_
=== zyga-afk is now known as zyga
=== salem_ is now known as _salem
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr