[00:26] jdstrand: there is a AppArmorProfile= stanza [00:26] http://www.freedesktop.org/software/systemd/man/systemd.exec.html [00:26] is that what you are looking for? === mbiebl_ is now known as mbiebl [00:26] (v204 doesn't have that yet, though) [00:27] needs at least v211 iirc [00:27] actually, it's v210 === broder_ is now known as broder === _salem is now known as salem_ === FlannelKing is now known as Flannel === salem_ is now known as _salem [04:55] stgraber: util-linux> ah, I'll add a pointer to the patch; I asked the reporter before whether he'll test it on stable [04:55] ogasawara: phonesim-autostart> sorry, no, it does need dbus-launch; but that fixed Xsession.d/ script has been in utopic since yesterday, so it should be harmless now? [04:56] Good morning [05:00] pitti: Good morning! [05:01] pitti: Do all programs that we switched to use an upstart job need their sysvinit script restored? [05:01] pitti: Would you be able to run a colord build on a mips porter box? I'd like to know whether some changes fix the build. [05:03] ScottK: at least all which are dependencies of other init.d scripts [05:04] OK, but not leaf packages then. [05:04] ScottK: right; it often lowers the delta to Debian to put it back anyway, but it's not required [05:04] and of course it'll make things work under systemd [05:05] RAOF: yes, can do [05:05] The package I'm worried about is already forked, so no rush. [05:15] pitti: If you'd kindly run a arch-dependent only build of the tip of colord.git that'd be aces. [05:17] pitti: Oh, also, does autopkgtest set an environment variable containing the build path anywhere? ADTTMP is not what I'm after; I want to be able to cat the test logs so that the automake test runner can output marginally useful messages. [05:18] RAOF: that should just be pwd; if you change directory in your test you could just save the original dir? [05:19] * RAOF goes to check the location of the logs. [05:22] Hm, no. [05:23] pitti: Running “make -C lib/colord check; cat lib/colord/test-suite.log” in a normal build tree works fine, but in the adt test can't find test-suite.log? [05:25] hmm, no immediate idea; this should certainly work [05:25] RAOF: btw, why is this 'build needed' *and* you call make check again? [05:25] oh, the build-needed would also run ./configure [05:26] pitti: Because make check isn't run during the build? [05:26] *nod* [05:27] RAOF: so you get failures, but no test log written? I have no idea whre they'd go, given that you call "make check" in the cwd where the package is [05:27] Oh. [05:28] You know what? I should try --shell-fail and see where they are! [05:28] but the ones in jenkins succeed [05:28] The ci.debian.org ones don't. [05:28] (I'm not sure whether automake's test runner also writes the logs on success) [05:29] See lib/colord/test-suite.log [05:29] yeah, it should indeed be just there [05:29] RAOF: build deps installing on the mips porter box, btw; this just takes rather long [05:30] pitti: Well, the 1.2.0-3 *build* seems to time out after 300 minutes, so I'm perfectly prepared to believe that installing the dependencies is also slow :) [05:31] urgh [05:31] I should have started that in screen [05:31] As long as you don't build the arch:all packages it should no longer take that long. [05:31] * pitti restarts the whole thing, better now than wasting half a day :) [05:32] :) === tsimpson_ is now known as tsimpson [05:42] * pitti NEWs ubuntu-app-launch to untangle the autopilot uninstallability [05:54] RAOF: debuild started now [05:55] With just binary-arch, right? [05:59] RAOF: dpkg-buildpackage -us -uc -B -j8 [05:59] Sweet. [06:00] Just making sure. Otherwise you get wait for the process that consumes gigabytes of memory and takes ages :) [06:00] ah, this box only has 2 GB [06:00] but 16 cores :) [06:01] so i want to make an upload to debian of a package that fixes an ubuntu bug. do i make a changelog entry to close it or will the ubuntu people/ubuntu changelog do that? and what is the format for the entry? [06:02] i should add that debian also exhibits the ubuntu bug, i'm not completely crazy [06:02] richardus: If you add (LP: #bugnumber) to the changelog it'll get automatically closed when the package is imported. [06:03] Or when it's merged manually, if we've got Ubuntu-local changes to it. [06:04] xnox: The systemd beep seems to be related to brltty, when I purged that the beep sounded. [06:05] indeed, I don't have brltty installed [06:05] Unit193: where "sounded" means "stopped", or "it sounded differently"? [06:06] pitti: Sounded = the system made the beep. [06:06] Unit193: interesting; so I don't have brltty installed and don't hear a beep; but that might also be because my notebook might not have a PC speaker (or whatever beeps there) [06:06] Unit193: so you get this as well? [06:07] pitti: Yes I do, but I can't technically comment as I'm using trusty and a slightly custom setup. Might get it on the netbook, I don't remember. [06:08] Unit193: so if you install brltty the beep goes away? that'd be a very interesting data point indeed [06:08] would be interesting to compare boot/syslogs with and without brltty, etc. [06:10] Bah! Why does --shell-fail never actually spawn a shell on failure :( [06:10] ls [06:11] RAOF: it's certainly supposed to, I'm using it all the time; except for bug 1317078, are you using --output-dir? [06:11] bug 1317078 in autopkgtest (Ubuntu) "--shell does not work with --output-dir" [Medium,Triaged] https://launchpad.net/bugs/1317078 [06:11] pitti: Maybe it doesn't work with the lxc container method?L [06:13] adt-run: - - - - - - - - - - running shell - - - - - - - - - - [06:13] root@adt-virt-lxc-wpfpjv:/tmp/adt-virt-lxc.shared.mXhWW7/downtmp/ubtree0-build/real-tree# [06:13] RAOF: hm, works here; can you please file a bug with the exact command you are calling? [06:13] pitti: Sure. [06:14] $ ./run-from-checkout --shell -B ~/ubuntu/tmp/testpkg// --- lxc -es adt-utopic [06:14] RAOF: I used that [06:14] RAOF: sorry, where ./run-from-checkout == adt-run [06:14] Hm. You don't need root? [06:14] I'm aware of --output-dir messing things up (need a better way to find the real stdout/err with output redirection) [06:14] RAOF: lxc's -s switch calls lxc through sudo [06:14] Ah. [06:15] $ sudo ./run-from-checkout --shell -B ~/ubuntu/tmp/testpkg// --- lxc -e adt-utopic [06:15] works as well, though [06:15] RAOF: does it have any error message, about /dev/stdout blabla not found, or similar? [06:15] you should at least get the "- - running shell" bit [06:15] pitti: I'll try that command again and get some clean logs. [06:21] pitti: Nono, if I *purge* brltty, the system will beep because it's stopping the service before removal. [06:22] Unit193: do you also get it beeping when rebooting if you have brltty installed? [06:22] Yep. [06:24] Unit193: nice, that sounds exactly like bug 1316804 then [06:24] bug 1316804 in systemd (Ubuntu) "loud pc-speaker like beep when rebooting under systemd" [Undecided,Confirmed] https://launchpad.net/bugs/1316804 [06:25] My point exactly. [06:25] brltty has a systemd unit, I wonder if this behaves any different than the init.d one; it does not have an upstart job [06:26] brendand: could you try rebooting or purging with removing /lib/systemd/system/brltty.service ? [06:26] sorry, Unit193 ^ [06:26] Unit193: this might even be something semi-deliberate, like indicating to the blind user that brltty is starting/stopping/etc. [06:26] but certainly not supposed to happen on reboot [06:27] pitti: In the init.d script for brltty, we set thigns up via /etc/default to disable brltty by default way back, as it leaked memory. Not sure if it does any more, but most people do not need it running by default, and it runs sytem wide so is a security issue, which really needs fixing anyway., [06:27] aah! [06:27] RUN_BRLTTY=no [06:27] we don't start it by default [06:27] No. [06:27] Scripts were written for the installer to enable it explicitly if a user requests it. [06:27] TheMuso: right, that'd explain it then -- brltty is causing the beep as a kind of notification, and as we never started it in the past few people noticed [06:28] Longer term, brltty needs to become a user session service. [06:28] But thats a whole ball of wax. [06:29] pitti: Added brltty back, and service brltty stop does make the beep. [06:29] TheMuso: so in the short term, the systemd unit should probably read the /etc/default file? [06:30] Unit193: thanks for confirming [06:30] pitti: Or however is best to implement stuff. I am happy to change things elsewhere to tweak things however they need to be for systemd units... [06:30] pitti: No problem! [06:30] pitti: i.e if we want to move away from /etc/default, now is as good a time to do so. [06:30] TheMuso: I mean, it is intended to not run brltty by default? [06:30] pitti: Correct, we do want to keep that behavior. [06:31] TheMuso: yeah, enabling/disabling services with default files works really badly with the unit model, so we need some hacks if we want to continue using default files that way [06:31] Debian runs it if brltty is installed, so this is an Ubuntu change which I am happy to keep. [06:31] pitti: I am happy to adopt whatever better method for systemd units there is. [06:32] TheMuso: the usual way is to enable/disable services using "systemctl enable" (or disable) [06:32] pitti: Ok, sounds clean enough. [06:32] TheMuso: I'm interested in why we install brltty by default but not enable it; most packages are enabled on installation [06:33] TheMuso: do we have that so that you can enable/disable brltty in the live environment, i. e. the package shoudl be installed always? [06:33] TheMuso: anyway, I'll adjust the unit file; we do the same in whoopsie [06:34] pitti: If the user has a USB display, brltty is also activated via udev. [06:34] The only time the user needs to explicitly enable brltty is if they use a serial or bluetooth display. Mind you the bluetooth setup is not done through the GUI... [06:34] it looks odd in systemctl status as brltty will appear as "failed" when disabled, but can't help that for now [06:34] TheMuso: ah, thanks for the heads-up [06:35] xnox: so, mystery solved for bug 1316804 :) [06:35] bug 1316804 in brltty (Ubuntu) "loud pc-speaker like beep when rebooting under systemd" [Undecided,Triaged] https://launchpad.net/bugs/1316804 [06:35] pitti: Thanks. Long term brltty needs to be beaten into submission as a user session service. [06:35] Too much stuff still runs as root for blind/vision impared users. [06:35] And that needs to change. [06:35] TheMuso: *nod* until then we'll just need to live with the unit appearing as "failed" when it's disabled; mostly cosmetical === smb` is now known as smb [06:41] If it weren't for users demanding braille, I'd chcuck brltty out of main... I dare say an audit would find many a security hole... [06:41] Its one of those packages thats been in main from the beginning, and probably really hasnt' had a proper going over, and has changed internally a fair bit over the years. [07:00] TheMuso, xnox, Unit193: I uploaded https://launchpad.net/ubuntu/+source/brltty/5.0-2ubuntu3 which ought to fix the beep (more precisely, respect the /etc/default/brltty file) [07:05] good morning [07:06] pitti: Ok thanks. [07:07] cjwatson: hi! Do you know if the user click hook "Exec"'d processes have access to the D-Bus session? Looks like that when I run them with "sudo click install..." they don't, but I wonder if they do when an app is installed via the UI [07:08] RAOF: so each ../../client/cd-create-profile takes some 20 minutes or so; I wish they'd parallelize :) [07:10] They're trivially parallelisable, but if you --enable-print-profiles each one takes over a GiB of memory, so upstream disabled parallel building there :) [07:10] ah, makes sense [07:11] On the basis that eating ~20GiB of RAM isn't going to be particularly conducive to exploiting your cores :) [07:13] pitti, i myself have the problem with bltty [07:13] pitti, i was ignoring it so far [07:13] brendand_: oh, are you also already running with systemd? [07:14] pitti, at least the symptoms match xnox's [07:14] pitti, i am [07:14] brendand_: wow [07:14] brendand_: I mean, I sometimes get the wrong addressee in IRC pings, but I never actually happened to pick someone who was affected by the very same topic :) [07:15] brendand_: you are running it because you are interested, or still a leftover from last week's sysvinit debacle? [07:15] pitti: Netbook thinks it's a good idea to make a loud beep when you unplug it or plug it in. >_< [07:16] pitti, leftover - i guess i can remove it now? [07:16] brendand_: well, not remove in the package sense, but disable again if you want [07:16] pitti, yeah - i mean remove the init= from grub [07:16] yes [07:17] brendand_: make sure you are fully updated, though :) [07:17] pitti, yeah i thought of that :) [07:23] RAOF: OOI, are the color profiles arch dependent? [07:24] pitti: No, they're not. I've picked the low-hanging fruit there (--enable-print-profiles is only passed when building arch-indep), but with a little extra work I could not build the rest when building arch-indep. [07:27] RAOF: they are so small, it almost seems like an upstream release ought to ship them pre-generated, similarly to HTML documentation :) [07:27] pitti: They get translations merged in at build time. Otherwise, yeah. [07:27] with appropriate .icc : .xml rules so that they are rebuilt on modifications [07:27] RAOF: ah, ok [07:28] they are just 4 KB, didn't look like they'd have much stuff in them [07:29] I mean, they still could be generated at release time, but then we'd need to do some magic if we wanted to do translation bugfixes... [07:38] RAOF: ideally they should depend on the .po files too, so if you patch those the profiles should just get rebuilt; but yes, theory :) [07:39] xnox, you there? [07:39] may I know if this package is suitable for debian? https://launchpad.net/ubuntu/+source/mediascanner [07:40] also this one https://launchpad.net/ubuntu/+source/lucene++ [07:40] is needed in the new poedit upstream release [07:40] we might benefit from uploading directly in debian and then autosync, right? === brendand_ is now known as brendand [07:44] apw: u around boss ? :) [07:55] salut didrocks - ça va? [07:55] dholbach: ça va bien, et toi ? [07:55] didrocks, très bien, merci! :-) [07:56] didrocks, t'as un petit peu de temps la prochaine semaine de parler un peu de "how contributions make it into Ubuntu"? :-) [07:57] stgraber: Added SRU information to LP #1310715, thanks [07:57] Launchpad bug 1310715 in ubuntu-touch-meta (Ubuntu Trusty) "Provide final 14.04 frameworks" [High,New] https://launchpad.net/bugs/1310715 [07:57] didrocks, I was thinking we could do a session together at Ubuntu Online Summit - I could talk a bit about "getting a fix for a package in" and you could talk a bit about how a fix for some touch project makes it onto an image? [07:59] dholbach: I'm not in charge of the touch project CI process anymore. I can still talk about it, but I would prefer just to "participate" to the session to not bringing confusions on who is now in charge :) [07:59] dholbach: sil2100, robru are the ones leading this now [07:59] ok cool - thanks didrocks :) [08:00] yw ;) [08:00] didrocks, any other session you'd like to give? either demo or discussion sessions are fine (http://fridge.ubuntu.com/2014/05/28/calling-for-ubuntu-online-summit-sessions/) :-) [08:02] dholbach: I need to think about it, having filed and abused the schedule a lot in the past, not sure I have anything valuable to discuss (yet). I'll follow and participate mostly to the cloud devops sessions at least [08:03] hello :), is there a reason why there are no trusty daily iso-builds? (like it is done for precise) [08:06] didrocks, ok cool [08:17] chrisccoulson: that would be me, but that bug seems hard :P [08:19] mlankhorst, yeah. I have absolute faith in you though :) [08:24] mardy: hi, was wondering if you'd heard anything regarding the Vimeo API bug? [08:24] pete-woods: yes, they acknowledge the bug, and said they'll fix it soon [08:24] mardy: cool, thanks :) [08:25] pete-woods: I'll forward you their email [08:25] cheers [08:25] pete-woods: done [08:26] LocutusOfBorg1: lucene++ probably yes, but it FTBFS in ubuntu at the moment. I don't think mediascanner would be useful in Debian, as development has moved on to mediascanner2 and it is at the moment Ubuntu specific package (needs unity scopes/gallery to consume scanned media) [08:30] sil2100, how are you doing? do you think you'd have some time during UOS next week to give a demo session together with me? (I talked about it with Didier above already) :) [08:32] dholbach: hey! Let's have a chat in some moments :) [08:33] sil2100, rock and roll :) [08:36] mardy: as a further question, now I've upgraded to utopic, I just get a black pane instead of the embedded browser in the online accounts settings, is this something you're aware of? [08:36] pete-woods: on the desktop? [08:37] mardy: yes [08:37] hmm, I don't seem to have signon-ui installed [08:37] pete-woods: yes, that's certainly the issue [08:38] mardy: bit strange that it's not installed by default [08:39] installing it makes all happy again, though :) [08:39] pete-woods, what is not installed by default and where? [08:40] seb128: I just had to manually install signon-ui to get online accounts to work [08:40] pete-woods: the last ubuntu-system-settings-online-accounts version can't be installed at the same time as signon-ui [08:40] pete-woods, desktop or touch? [08:40] this is on a pretty recent utopic desktop (last week) [08:41] mardy, why not? [08:41] pete-woods, http://cdimage.ubuntu.com/daily-live/current/utopic-desktop-i386.manifest [08:41] signon-ui 0.16+14.04.20140304.is.0.15+14.04.20140313-0ubuntu2 [08:41] seb128: because on touch we merged the functionality of signon-ui into online-accounts-ui, [08:41] pete-woods, it's installed by default ... maybe you got it uninstalled when you tried to install some touch component? [08:41] seb128: and we would have a conflict when installing the d-bus service file [08:42] mardy, how is that going to work for people who install unity8 on their desktop next to unity7? [08:42] seb128: I'm afraid it will break online accounts on unity7 :-( [08:42] seb128: could well be possible, I do have unity8 installed [08:42] mardy, we need to fix that [08:42] stgraber: ah, it should be bug 1300991, sorry. I just copied the changelog straight from Debian. I should have checked it. [08:42] bug 1300991 in auto-apt (Ubuntu Trusty) "auto-apt update and updatedb commands fail on 0.3.23" [Undecided,Triaged] https://launchpad.net/bugs/1300991 [08:43] stgraber: do you want to reject and I'll re-upload with a fixed changelog? [08:43] mardy, otherwise pete-woods is going to be the first of a long serie of unhappy users [08:43] seb128: I don't see an easy way to fix it... both packages want to install /usr/share/dbus-1/services/com.nokia.singlesignonui.service [08:44] @pilot out === udevbot changed the topic of #ubuntu-devel to: Utopic boot fixed in sysv-rc 2.88dsf-41ubuntu15, boot with init=/lib/systemd/systemd until then | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patc [08:44] oops [08:44] mardy, you could split that .service in its own binary and have both ui depending on it [08:44] seb128: maybe we could make the service file launch a shell script, that decides which binary to launch based on environment variables [08:44] is the service somehow linked to the frontend? [08:45] mardy, right, or you can do that check in the .service itself, we used to do that for notify-osd [08:45] Laney: yes, the service implementation is a UI component [08:46] * mardy goes and has a look at notify-osd [08:46] seb128: "used to do that", means you don't do that anymore? [08:47] seb128: found it in version 0.33, thanks [08:47] mardy, yw! [08:48] mardy, yeah, I think we dropped that logic, we just use notify-osd when installed now [08:48] seb128: OK, that sounds like a viable solution; I'll work on that [08:48] mardy, thanks [08:53] ekarlso, hi ? [08:55] @pilot in === udevbot changed the topic of #ubuntu-devel to: Utopic boot fixed in sysv-rc 2.88dsf-41ubuntu15, boot with init=/lib/systemd/systemd until then | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patc === pitti changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch pilots: pitti [08:58] seb128: how would you detect that we are running on unity8? I see "QT_QPA_PLATFORM=ubuntumirclient" in the env variables, would it be OK to use that? [08:59] Saviq, ^ do you know? === Tm_Tr is now known as Guest17709 [09:00] mardy, I guess that works, or you could just check for XDG_CURRENT_DESKTOP=Unity and assumes that's unity7 [09:01] why do you want to detect it? === timrc is now known as timrc-afk [09:02] mlankhorst: to know whether the D-Bus service should popup the desktop UI or the touch one [09:02] it's =Unity on touch too [09:03] Laney, seb128: I'll use the QT_QPA_PLATFORM then [09:05] mardy: You could check DESKTOP_SESSION is ubuntu-touch or unity8* [09:05] mardy: but can't you try to pop up the touch one, if that fails fall back to desktop one? [09:06] mardy: If you're using unity8 == touch, that's going to end in tears when unity8 is the default on the desktop too... [09:07] infinity, depends what you call "touch" [09:07] we want the new UI in unity8-desktop as well [09:07] mlankhorst: the problem is that the touch one will run on the desktop, but it can't be embedded in the unity-control-center (using XEMBED) [09:07] we'll just ship touchscreens with the images [09:07] * infinity mumbles something about convergence. [09:07] infinity, well, "touch" is going to be used on desktop as well [09:08] seb128: But not the same UI, obviously. Is it all screen-size/form-factor autodetecty yet? [09:10] infinity: the point is not about convergence; it's that we have two different implementations, for unity7 and unity8, and from the D-Bus .service file we need to decide which one to pop up [09:10] infinity, far from that ... [09:10] running Mangler in gdb, if it dies like it has been do I just run bt to give to you guys? [09:10] infinity: eventually, we'll use the unity8 one on all form factors [09:10] oops sorry wrong channel [09:10] infinity, but as i understood the lightning talk about it it should anyway be use-case driven ... based on available input/output devices [09:11] the QPA_PLATFORM thing seems like it might be an implementation detail which might not be reliable [09:11] that will only tell you you are running Mir [09:11] (or X11 or surfaceflinger) [09:12] wont tell you anything about what device you are on [09:12] infinity, well, we have a "new UI" and "legacy UI", ideally the legacy UI is going away, but we still need it for Unity7 because that doesn't have Mir, etc [09:12] tvoss: as my go-to C++ guy, do you have a recommendation for doing base64 encoding in C++? doing it with boost seems really unweildy [09:12] infinity, so that's not a case of detecting form factor, just a case of keeping something working for unity7 until our desktop has the techs needed to run the new UI [09:14] pete-woods: http://stackoverflow.com/questions/342409/how-do-i-base64-encode-decode-in-c [09:14] pete-woods: Might have a few decent pointers. [09:15] pete-woods: If you happen to already have openssl or glib in your dependency tree, both have base64 functions. [09:17] I was hoping to avoid implementing my own encoder, glib is sounding like the best option so far, as the C++ ones aren't in main [09:18] mardy: No, I wouldn't expect them to have access to it, and design-wise I think I'd prefer that they didn't assume that [09:19] cjwatson: OK, that's fine [09:19] pete-woods: Or just snag a copy of the coreutils one from the source or something. It's not lkike base64 is complicated, any mature codebase will have had a bug free implementation for ages that you can steal and run with if you want to avoid pulling in a whole library just for it. [09:20] ricotz: I've been holding off on switching on trusty builds because there's only a single builder per architecture at the moment and so it's easy for contention to get pretty bad; I'm hoping that I'll be able to land the livefs-in-LP work before we desperately need trusty image builds in preparation for 14.04.1 [09:21] infinity: part of the purpose of what I'm writing is to provide an example scope, I really don't want to say, hey you're going to have to implement your own base64 encoder just to do OAuth in your scope [09:22] pete-woods: Oh. Perhaps an oauth library that does all the heavy lifting is what's wanted here, if it's something more than one scope is likely to want. [09:23] infinity: I already have an OAuth lib doing the basic case, but this API also needs a header encoding in a specific way [09:23] Ahh, indeed, liboauth is in main. I guess it doesn't do the base64 stuff you need, though. [09:23] Oh, but it depends on libnss, which is also likely to have a base64 implementation hiding in it. [09:24] Cause pretty much every crypto library has to. [09:25] pete-woods: /usr/include/nss/base64.h from libnss3-dev looks promising. [09:26] pete-woods: (Assuming you're using liboauth anyway, you already have libnss3... But maybe you're using a different oauth lib) [09:26] mhall119: btw you're working with the SDK team right? [09:26] pete-woods: Oh, nssb64.h is more complete (same source) [09:27] infinity: cool, thanks, right now I'm happy to take just about any library in main that doesn't involve introducing a big lump of boilerplate code [09:28] pete-woods: Well, my usual M.O. there is to check your current dep tree and see if something in it can solve the problem. [09:28] pete-woods: So, if you're using liboauth, libnss is a slam dunk. If you have glib for some other reason, same argument. Etc. [09:29] pete-woods: But it's pretty hard to write something meant to talk to the intertubes that doesn't use NSS, OpenSSL, or GnuTLS, and all three should have base64 goop to abuse. [09:29] yep [09:34] thanks xnox [09:34] are you working on fixing the FTBFS? [09:34] I would like to upload in debian, just to pass the new queue [09:34] otherwise poedit won't be uploaded [09:35] LocutusOfBorg1: go ahead with uploading to Debian, but check if it builds there. [09:35] cjwatson, hi, thanks for the clarification, looking forward to them to be available [09:35] LocutusOfBorg1: i'm not working on resolving bugs in lucene++ at the moment, as the plan was to remove it from the archive, once mediascanner is dropped. [09:36] xnox, mmm and for poedit? [09:36] it needs lucene++ [09:36] LocutusOfBorg1: if it's reintroduced, that's fine. [09:37] sil2100, you there? [09:37] agreed xnox I understand [09:37] so I would like to know if sil2100 would like to maintain in debian too [09:37] Hi! [09:37] Hi sil! [09:38] I think you already got some mails to the poedit adopter [09:38] :) [09:38] do you mind uploading in debian? [09:40] LocutusOfBorg1: so, hm, I need to browse through my mailbox since I can't remember this well enough, but I could pick up maitaining the packaging for lucene++ in Debian if anything [09:40] If that's needed [09:43] yes, would be nice [09:43] just put the version on mentors and sync on ubuntu === TLemur is now known as Timur [09:43] you will simplify a LOT the packaging of the new poedit [09:43] sil2100, Timur is the person who wants to adopt poedit [09:44] LocutusOfBorg1: ok, will try doing that this week :) [09:46] wonderful :) [09:46] great thanks! === Guest17709 is now known as Tm_Tr [09:49] yes, thanks a lot [09:50] rbasak: Did you see the dpkg-divert idea for skype-translation that infinity mentioned yesterday? [09:59] GunnarHj: I saw it but haven't had a chance to read it yet. If infinity says it's reasonable though, that's good enough for me. [09:59] GunnarHj: if you do exactly what infinity wants and he says it's good then I'm happy to upload it :) [10:07] hum [10:07] does anyone see an issue with that mountall translation? [10:07] msgid "Checking disk %1$d of %2$d (%3$d%% complete)" [10:07] msgstr "Vérification du disque %1$d sur %2$d (avancement : %3$d%%)" [10:07] [10:07] I wonder why the % doesn't display in french on the plymouth screen [10:09] rbasak: Ok. I checked it out last night, and it seems to do the trick. Then I'll go on and make a new version and also addressing your questions on the bug report. Will ping you when done. :) [10:11] GunnarHj: great. Thanks! [10:12] rbasak: Thank _you_ for great sponsoring work! [10:12] seb128: hey, I've just made a merge request for the touchscreen issue, which I assigned to you (feel free to reassign). This is for 14.10. When we're done, I'll do the same for the SRU in 14.04: https://code.launchpad.net/~albertomilone/unity-settings-daemon/lp1287341-14.10/+merge/222011 [10:18] tseliot, thanks [10:19] yw === doko_ is now known as doko [10:27] mitya57: qtwebkit finally building at https://launchpad.net/~ci-train-ppa-service/+archive/landing-004/+packages - I just needed to update ppc64el and arm64 symbols. dbarth has still some apparmor change brewing that will get to the same silo in addition to the already approved webbrowser-app branch, hopefully it'll be ready soon. [10:29] Mirv: well,apparently i can't change apparmor :/ [10:30] Mirv: so it means i could switch to qtwebkit 5.2 for old webapps [10:30] dbarth: what needs changed? [10:30] Mirv: but i can't transparently migrate them to oxide [10:30] the 1.0 webapp policy group [10:31] this one prevents oxide from being used, to ensure only qtwebkit is [10:31] ah [10:31] so apparently no choice but to force (or wait for) eveyone to switch to 14.04 before i can turned down qtwebkit support [10:32] dbarth: can't as in won't be done? so then the only result is that we need slightly more testing and maybe some help to parse a list of apps not switched to 14.04 framework but using webkit [10:32] Mirv: so we can only get 1 of the 2 goals here: ie unblock qtwebkit 5.2, but i can't remove the dependency just yet (to help with the image size) [10:33] dbarth: are we not phasing out the 1.0 webapp policy group? [10:33] well, we probably needed a reason for somebody to work on deprecating the 13.10 framework anyway [10:33] qtwebkit 5.2 was tested to be quite good when Qt 5.2 landing was being made, so I don't expect huge problems unless some old webapp is using WebGL site [10:33] Mirv: jamie seemed to think that it was an interface change, so not acceptable for a framework meant to be all sealed by now [10:33] dbarth: ok [10:34] Hiyas all [10:35] dbarth: hrmmm, I was actually thinking more along the lines of, if its deprecated how bad would it be to add oxide permission to it. But I will defer to jdstrand [10:36] jjohansen: and jdstrand was not so keen on doing that [10:37] dbarth: right, I'll poke him in the morning so I can better understand his reasoning, thanks [10:38] jjohansen: i guess it's because it's not just changing one line in the webapp policy group (the one that says deny) [10:38] it's probably adding a whole lot in templates, to let the whole oxide process family be authorized [10:38] right, I expected it would be more than that [10:38] something that only happened when 1.1 was designed [10:38] ah [10:38] and the new webview policy group [10:40] cjwatson: yes, i'm happy to be that extra reason really [10:52] seb128: I want to rename signon-ui to signon-ui-x11, and make both signon-ui-x11 and u-s-s-o-a "Provides: signon-ui" [10:52] seb128: and both of them will depend on a new signon-ui-service package which installs the D-Bus service file [10:53] seb128: does this sound reasonable? (I have another question after this :-) ) [11:04] mardy, yes, sounds reasonable [11:05] mardy, be careful though, provides are not versioned, so if you have things depending on signon-ui (=> version) that's not going to work (you need an empty/dummy binary in that case) [11:07] seb128: actually, this is my next question: signon-ui-service replaces a file from signon-ui (<< 0.17) and u-s-s-o-a (<< something), but I'm not sure how to encode this information [11:07] seb128: for u-s-s-o-a I could add a Conflicts, I guess [11:08] mardy: https://wiki.debian.org/PackageTransition is a helpful reference for this sort of stuff, if that helps. [11:08] seb128: but for signon-ui, will dpkg be able to handle it correctly, since the newest version will be a virtual package (unversioned)? [11:09] AIUI, Breaks+Replaces is preferred over Conflicts where possible, as it's less constraining on upgrade ordering. [11:09] rbasak: that's useful, I'm reading it now [11:09] mardy, I was going to point the url rbasak just shared [11:09] rbasak: cool, I think that mine is case #5 === _salem is now known as salem_ === MacSlow is now known as MacSlow|lunch === NCommand` is now known as NCommander === salem_ is now known as _salem === NCommander is now known as Guest10479 [11:31] seb128: can I add you as a reviewer for the changes I'm about to propose about signon-ui and u-s-s-o-a? [11:32] hey all, do we know about Gnome apps in utopic? I know apps using headerbars have been rejected for trusty LTS, will this change for utopic? [11:32] mardy, sure [11:32] evfool, we don't know yet, larsu and Trevinho are working on making those work under Unity [11:32] seb128: done: https://code.launchpad.net/~mardy/signon-ui/signon-ui-service/+merge/222017 and https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/signon-ui-service/+merge/222016 [11:33] once GTK and Unity are improved, we need to revisit the impact on the usability [11:33] seb128: ok, thanks [11:33] evfool, it's fine to update things that are not the ubuntu-desktop, knowing that you are making some user experience miserable on the way === oSoMoN_ is now known as oSoMoN [11:33] but that's an upstream issue, not a lot we can do for those who care only about gnome-shell users [11:40] mardy, the changes look fine technically but there is an issue that u-s-s-o-a is in universe so you can't make signon-ui-x11 depends on a binary built from it, you are going to need to do it the other way around and build the service from signon-ui [11:41] seb128: uh, OK [11:47] evfool, it would be nice, if as an upstream, you would support non gnome-shell environments for your software ;-) [11:48] (just saw your comment on the bug) [11:49] seb128: I don't want to start philosophical discussions here, I run system monitor 3.13.1 on Unity, and I'm satisfied, so System Monitor supports non-gnome-shell environments [11:49] evfool, it's using GtkHeaderBar? Can you move/resize the window? [11:49] I can't here [11:49] not sure what is different in your session though [11:50] seb128: I'll have to check when I get home though, but I'm almost sure I would've noticed if I couldn't [11:50] because not having decoration/borders, not being able to resize or move the dialogs is the known state under several non shell environments, including Unity (which we are working on fixing) [11:51] seb128: I was only aware of some XFCE issues, which I don't understand, as I am also able to run System Monitor with headerbar under XFCE [11:51] evfool, the xfce issue is the inverse, you would likely get double decorations [11:51] the headerbar and a wm bar [11:52] seb128: about your remark on Conflicts/Replaces/Provides: I think that my case is very close to #5 here: https://wiki.debian.org/PackageTransition [11:52] evfool, like https://lh4.googleusercontent.com/-YlXpA1jR3O0/UpMsjN5c_OI/AAAAAAAAAXo/ZKPUsRLr-5s/w480-h500-k/xfcecalc.png [11:53] seb128: btw, I have spent quite a few hours trying to figure out a solution for a UI working both with and without a headerbar, but it turned out that I would have to duplicate lots of code [11:54] evfool, yeah, GNOME put developers in a tricky situation, basically you have different platforms there so you can't do well with one simple codebase [11:55] mardy, oh, so you keep an empty "signon-ui" binary as transitional? [11:56]