=== _salem is now known as salem_
=== salem_ is now known as _salem
=== RoozbehShafiee_ is now known as RoozbehShafiee
ari-tczewslangasek: could you take a look on merge bug 1396381 please?07:21
ubottubug 1396381 in gnu-efi (Ubuntu) "Merge gnu-efi 3.0v-5 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/139638107:21
pittiGood morning07:36
dholbachgood morning08:14
=== terrex is now known as xiterrex
pittixnox, 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
pittilightdm also doesn't emit this event10:56
xnoxpitti: one sec.11:09
=== _salem is now known as salem_
xnoxpitti: it used to be in the plymouth package, keybuk removed starting-dm event dependency in 5 years and 1 day ago.11:12
loucuraHi! 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
ubottuLaunchpad 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
xnoxpitti: plymouth boot splash used to stop upon "starting-dm" screen, this from before DMs would talk to plymouth and stop it themself.11:13
LocutusOfBorg1hi developerz11:16
=== RoozbehShafiee__ is now known as RoozbehShafiee
LocutusOfBorg1have a good bug hunting day :)11:17
diwicLocutusOfBorg1, thanks, I just hunted one down :-)11:32
LocutusOfBorg1well done :)11:33
LocutusOfBorg1I prepared right now the virtualbox upload on debian experimental11:34
cjwatsonxnox: oh well found, I'd been failing to dig that up11:34
LocutusOfBorg1and next I'll ask probably a sync from there :)11:34
brainwashxnox: 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
brainwashbug 137589311:45
ubottubug 1375893 in xfdesktop4 (Ubuntu) "Black background to Try/Install Dialogue" [Medium,Confirmed] https://launchpad.net/bugs/137589311:45
pittitseliot: do you have a machine which needs gpu-manager?11:46
pittitseliot: 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
tseliotpitti: sure11:47
tseliotpitti: it should always start on first boot. I can tell you how to simulate first boot, then you can check the log11:48
pittitseliot: oh, your latest upload didn't build on arm6411:48
* pitti retries the build11:48
tseliotpitti: but yes, if you have some packages, I'll test it here (I need to upgrade to vivid first)11:49
xnoxbrainwash: it's not just the background that's a problem. xfce4settings daemon ends up defunct.11:53
xnoxbrainwash: whilst background is the most visible thing, other little things have also stopped working under ubiquity.11:53
xnoxbrainwash: a regression in xfce4settings should be found, or things identified what makes it go boom - e.g. some environment or service missing etc.11:54
brainwashxnox: it should be quite easy to find something in the commit/package history, something like this does not happen out of nowhere.. or? :)11:58
brainwashI'll try to do some research11:59
brainwashxnox: can you maybe revert the importance of this bug back to "high"?12:01
brainwashxfsettingsd should not fail12:02
brainwashand I guess that we should change xfdesktop4 -> xfce4-settings12:03
pittitseliot: 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 that12:13
pittidebian bug 76922812:13
ubottuDebian bug 769228 in udev "udevadm shows debug messages by default on ARM" [Minor,Open] http://bugs.debian.org/76922812:13
pittitseliot: ok, I pushed the FTBFS fix12:20
pittitseliot: 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 journal12:28
pittitseliot: so that you see it with "sudo systemctl status gpu-manager" (or in journalctl of course)12:28
pittitseliot: I added the unit in https://github.com/tseliot/ubuntu-drivers-common/commit/c365141a7b4, works fine here12:37
pittitseliot: uploaded, this should also fix the FTBFS12:37
cjwatsondoko_: could somebody have a quick look over bug 1398807, please?12:40
ubottubug 1398807 in google-apputils-python (Ubuntu) "[MIR] google-apputils-python" [Undecided,New] https://launchpad.net/bugs/139880712:40
mvoStevenK: hi, are you on archive admin duty today or is https://wiki.ubuntu.com/ArchiveAdministration outdated? NEW for ubuntu-sdk-libs-tools would be cool12:50
_rubenI'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:01
didrocksmvo: I guess nobody is really following the AA duty anymore, binNEWed13:02
mvodidrocks: \o/13:03
ScottKI think the schedule is dead, but people do still look at New.13:05
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...13:08
=== Trevinho_ is now known as Trevinho
_rubenteward: let me pastebin what I get13:14
_rubenteward: http://paste.ubuntu.com/9354611/13:15
tseliotpitti: is there any way we can collect the log from apport?13:17
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:21
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 hand13:22
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 transcript13:23
_rubencjwatson: 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:25
cjwatson_ruben: that seems thoroughly unnecessary13:26
doko_cjwatson, done. although if it's cloud related, maybe the cloud team could subscribe as well13:26
_rubencjwatson: primary goal: backport from utopic to trusty or even from upstream13:26
cjwatson_ruben: sbuild -d trusty will put "Distribution: trusty" in the resulting binary .changes file, which is all you'll need13:26
_rubencjwatson: these steps are based on ancient research, and have worked fine thusfar ;) wouldn't surprise if there's other/better ways to deal with this13:26
cjwatson_ruben: well, your "apply diff by hand" thing is totally wrong, don't do it :)13:27
cjwatsonthat will break with many modern packages13:27
_rubencjwatson: that one's on my todo list, as in: i noticed certain (newer?) package doing this automatically after dget'ing the source13:27
cjwatson_ruben: like I say, the One True Correct Way to unpack a source package is dpkg-source -x foo.dsc13:28
cjwatsonanything else is bad and wrong13:28
_rubencjwatson: will keep that in mind13:28
cjwatson(apt-get source, pull-debian-source, pull-lp-source, etc. all wrap dpkg-source -x at various points)13:28
cjwatsondoko_: thanks13:29
cjwatsonsmoser: could some appropriate cloud team subscribe to google-apputils-python, perhaps?  cf. bug 139880713:29
ubottubug 1398807 in google-apputils-python (Ubuntu) "[MIR] google-apputils-python" [Undecided,Fix released] https://launchpad.net/bugs/139880713:29
cjwatsonand discussion above13:30
cjwatson_ruben: you might also look into the backportpackage tool13:30
_ruben(and I need to look into why dch refuses to use the info in ~/.devscripts some day)13:30
_rubencjwatson: interesting, even includes the dput part. will definately look into that one13:31
smosercjwatson, "i've subscribed foundations-bugs" you also want server subscribed ? that is fine, but just clarifying.13:36
cjwatsonsmoser: I'm just following up on 13:26 <doko_> cjwatson, done. although if it's cloud related, maybe the cloud team could subscribe as well13:36
cjwatsonsmoser: without knowing exactly which team is appropriate on your end13:36
smoserk. done.13:38
smoserubuntu-server is subscribed13:38
cjwatsonhopefully this will let us start the protobuf transition.  (and clear another thing from "grep-merges cjwatson", which is my actual motivation ...)13:40
mlankhorsthow do I start a full ubuntu desktop without lightdm?14:07
pittihallyn: do you plan to merge samba soon? there is a new ldb in -proposed which samba-libs conflicts to, thus causing a lot of uninstallability14:10
pittiotherwise I can do a no-change upload, but I don't want to earn the samba merge with that14:10
tseliotpitti: does "sudo systemctl status gpu-manager" dump the log into a file? I need logs to be easy to attach to bug reports14:22
pittitseliot: no, that shows the gpu-manager related bits from the journal14:23
mardyjdstrand: is there a way to check the profile label of a running PID, from the command line?14:23
tseliotpitti: then, if there's no alternative, we should keep writing the log to a file14:24
pittitseliot: ah sorry, missed your question above14:24
pittitseliot: ok; indeed you currently can't access the journal as user14:25
pittitseliot: pushed/uploaded14:29
tseliotpitti: thanks14:29
jdstrandmardy: yes, ps -Z14:47
jdstrandmardy: or cat /proc/<pid>/attr/current14:48
mardyjdstrand: cooool!!14:48
jdstrandI find 'ps auxwwZ' handy14:49
cjwatsonpitti: I notice you aborted the gutenprint autopkgtest - was it hanging or something?14:53
pitticjwatson: on armhf/ppc64el; yes, they always hang there, and I needed to do some admin/reboot on these devcies14:54
cjwatsonpitti: oh, it's always failed.  but I wonder if that's why it still shows as "test in progress" on excuses14:54
pitticjwatson: did I kill an x86 one by accident?14:54
cjwatsonpitti: looks like on x86 too14:54
pitticjwatson: ah sorry, rerunning14:54
cjwatsondoko_: 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?15:05
=== roadmr is now known as roadmr_afk
mardyjdstrand: FYI, I added some comments here and added apparmor-easyprof to the bug: bug 121964415:37
ubottubug 1219644 in Online Accounts setup for Ubuntu Touch "Account plugins should be made confinable by apparmor" [Medium,In progress] https://launchpad.net/bugs/121964415:37
zuldoko_:  ping15:37
jdstrandmardy: thanks. I'll also add a click-reviewers-tools task15:39
pittisforshee: bug 1398458> yeah, not at all urgent any more, with the userland stub16:08
ubottubug 1398458 in linux (Ubuntu) "kernel fails to load iwlwifi firmware - disable CONFIG_FW_LOADER_USER_HELPER" [Low,In progress] https://launchpad.net/bugs/139845816:08
pittimostly a cleanup thing for the futuer16:08
sforsheepitti: sure, but better to get it fixed before I forget about it ;-)16:13
=== roadmr_afk is now known as roadmr
doko_jdstrand, yes, always handled this way16:38
doko_now promoted16:39
doko_zul, here16:39
zuldoko_:  have you seen this? bug 1348954, or bug 1367907 and bug 138260716:40
ubottubug 1348954 in python3.4 (Ubuntu) "update Python3 for trusty" [Undecided,Confirmed] https://launchpad.net/bugs/134895416:40
ubottubug 1367907 in python3.4 (Ubuntu Trusty) "Segfault in gc with cyclic trash" [Undecided,Triaged] https://launchpad.net/bugs/136790716:40
ubottubug 1382607 in python3.4 (Ubuntu Trusty) "[SRU] Backport python3.4 logging module backward incompatibility fix." [High,Triaged] https://launchpad.net/bugs/138260716:40
cjwatsondoko_: thanks16:40
=== zyga is now known as zyga-afk
doko_zul, yes, I filed at least the first one17:33
=== salem_ is now known as _salem
bdmurrayhallyn: I'm unable to start a domain in virtual machine manager due to not being able to find kvm-spice. Any ideas?17:45
zuldoko_:  any eta?17:46
doko_I still hope this year ... although time is running out for me with planned vacations17:51
shadeslayerpitti: autopkgtest question for you, how can I parallelize the build that's run by adt17:52
cjwatsonmdeslaur,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 delta17:57
ubottuDebian bug 733312 in fuse "fuse: Please reconsider the permissions on /dev/fuse and /bin/fusermount" [Normal,Fixed]17:57
infinityshadeslayer: You mean the automated build from a "build-needed" test?17:58
shadeslayerinfinity: yes17:58
infinityshadeslayer: 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:58
shadeslayerinfinity: well, I'm writing my own tooling to run some autopkgtests on debian, and wanted to parallelize the build17:59
shadeslayerso yeah17:59
infinityshadeslayer: If you mean running adt locally, yeah, maybe it needs a fix to export the variable. ;)17:59
shadeslayerinfinity: so something like export DEB_BUILD_OPTIONS="parallel=8" would work right18:00
infinityshadeslayer: The simplest solution is just "export DEB_BUILD_OPTIONS="parallel=$(nproc)"" somewhere before the build happens.18:00
shadeslayerworks, thx18:00
mdeslaurcjwatson: the fuse device basically allows people to become root, having fusermount be 4775 is the right approach I believe18:00
cjwatsonmkay, possibly somebody with more time should clue up the Debian maintainer :)18:01
mdeslaurcjwatson: I haven't look in a long time, but I don't currently have time to spend on refamiliarizing myself with all the changes18:02
mdeslaurcjwatson: It's probably best to leave it as-is for now if you don't mind18:02
cjwatsonjust trying to get my merge list as far down as I can before switching to LP :)18:03
shadeslayerwhich reminds me18:04
shadeslayercjwatson: who will I go to for all my live build issues now :(18:05
cjwatsonI'm sure somebody can be found on #ubuntu-release18:05
cjwatsonor here for that matter18:05
infinityshadeslayer: 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
shadeslayerroger :)18:07
* shadeslayer has a decent bit of lb knowledge now18:07
shadeslayerwhich usually comes down to "The documentation lies, read the code"18:07
infinityThere's documentation?18:07
infinityI've only ever hacked lb using grep. :P18:08
infinityAnything else seems like a lost cause.18:08
shadeslayerinfinity: hehe18:08
shadeslayerinfinity: by documentation I meant how to use lb18:08
shadeslayernot code documentation18:08
infinityshadeslayer: Oh, sure.  Even "how to use" is something I deal with using grep, though. ;)18:09
shadeslayerinfinity: yeah, best to keep doing it that way18:09
infinityshadeslayer: "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
shadeslayerI actually have to figure out efi madness with lb sometime18:09
shadeslayerthat'll be fun18:09
infinityshadeslayer: 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).18:10
=== brainwash_ is now known as brainwash
shadeslayeroh, that would be so awesome :318:11
=== _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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!