| mbiebl_ | jdstrand: there is a AppArmorProfile= stanza | 00:26 |
|---|---|---|
| mbiebl_ | http://www.freedesktop.org/software/systemd/man/systemd.exec.html | 00:26 |
| mbiebl_ | is that what you are looking for? | 00:26 |
| === mbiebl_ is now known as mbiebl | ||
| mbiebl | (v204 doesn't have that yet, though) | 00:26 |
| mbiebl | needs at least v211 iirc | 00:27 |
| mbiebl | actually, it's v210 | 00:27 |
| === broder_ is now known as broder | ||
| === _salem is now known as salem_ | ||
| === FlannelKing is now known as Flannel | ||
| === salem_ is now known as _salem | ||
| pitti | 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 |
| pitti | 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:55 |
| pitti | Good morning | 04:56 |
| RAOF | pitti: Good morning! | 05:00 |
| ScottK | pitti: Do all programs that we switched to use an upstart job need their sysvinit script restored? | 05:01 |
| RAOF | 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:01 |
| pitti | ScottK: at least all which are dependencies of other init.d scripts | 05:03 |
| ScottK | OK, but not leaf packages then. | 05:04 |
| pitti | ScottK: right; it often lowers the delta to Debian to put it back anyway, but it's not required | 05:04 |
| pitti | and of course it'll make things work under systemd | 05:04 |
| pitti | RAOF: yes, can do | 05:05 |
| ScottK | The package I'm worried about is already forked, so no rush. | 05:05 |
| RAOF | pitti: If you'd kindly run a arch-dependent only build of the tip of colord.git that'd be aces. | 05:15 |
| RAOF | 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:17 |
| pitti | RAOF: that should just be pwd; if you change directory in your test you could just save the original dir? | 05:18 |
| * RAOF goes to check the location of the logs. | 05:19 | |
| RAOF | Hm, no. | 05:22 |
| RAOF | 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:23 |
| pitti | hmm, no immediate idea; this should certainly work | 05:25 |
| pitti | RAOF: btw, why is this 'build needed' *and* you call make check again? | 05:25 |
| pitti | oh, the build-needed would also run ./configure | 05:25 |
| RAOF | pitti: Because make check isn't run during the build? | 05:26 |
| pitti | *nod* | 05:26 |
| pitti | 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 |
| RAOF | Oh. | 05:27 |
| RAOF | You know what? I should try --shell-fail and see where they are! | 05:28 |
| pitti | but the ones in jenkins succeed | 05:28 |
| RAOF | The ci.debian.org ones don't. | 05:28 |
| pitti | (I'm not sure whether automake's test runner also writes the logs on success) | 05:28 |
| pitti | See lib/colord/test-suite.log | 05:29 |
| pitti | yeah, it should indeed be just there | 05:29 |
| pitti | RAOF: build deps installing on the mips porter box, btw; this just takes rather long | 05:29 |
| RAOF | 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:30 |
| pitti | urgh | 05:31 |
| pitti | I should have started that in screen | 05:31 |
| RAOF | 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:31 | |
| RAOF | :) | 05:32 |
| === tsimpson_ is now known as tsimpson | ||
| * pitti NEWs ubuntu-app-launch to untangle the autopilot uninstallability | 05:42 | |
| pitti | RAOF: debuild started now | 05:54 |
| RAOF | With just binary-arch, right? | 05:55 |
| pitti | RAOF: dpkg-buildpackage -us -uc -B -j8 | 05:59 |
| RAOF | Sweet. | 05:59 |
| RAOF | Just making sure. Otherwise you get wait for the process that consumes gigabytes of memory and takes ages :) | 06:00 |
| pitti | ah, this box only has 2 GB | 06:00 |
| pitti | but 16 cores :) | 06:00 |
| richardus | 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:01 |
| richardus | i should add that debian also exhibits the ubuntu bug, i'm not completely crazy | 06:02 |
| RAOF | richardus: If you add (LP: #bugnumber) to the changelog it'll get automatically closed when the package is imported. | 06:02 |
| RAOF | Or when it's merged manually, if we've got Ubuntu-local changes to it. | 06:03 |
| Unit193 | xnox: The systemd beep seems to be related to brltty, when I purged that the beep sounded. | 06:04 |
| pitti | indeed, I don't have brltty installed | 06:05 |
| pitti | Unit193: where "sounded" means "stopped", or "it sounded differently"? | 06:05 |
| Unit193 | pitti: Sounded = the system made the beep. | 06:06 |
| pitti | 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 |
| pitti | Unit193: so you get this as well? | 06:06 |
| Unit193 | 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:07 |
| pitti | Unit193: so if you install brltty the beep goes away? that'd be a very interesting data point indeed | 06:08 |
| pitti | would be interesting to compare boot/syslogs with and without brltty, etc. | 06:08 |
| RAOF | Bah! Why does --shell-fail never actually spawn a shell on failure :( | 06:10 |
| richardus | ls | 06:10 |
| pitti | RAOF: it's certainly supposed to, I'm using it all the time; except for bug 1317078, are you using --output-dir? | 06:11 |
| ubottu | bug 1317078 in autopkgtest (Ubuntu) "--shell does not work with --output-dir" [Medium,Triaged] https://launchpad.net/bugs/1317078 | 06:11 |
| RAOF | pitti: Maybe it doesn't work with the lxc container method?L | 06:11 |
| pitti | adt-run: - - - - - - - - - - running shell - - - - - - - - - - | 06:13 |
| pitti | root@adt-virt-lxc-wpfpjv:/tmp/adt-virt-lxc.shared.mXhWW7/downtmp/ubtree0-build/real-tree# | 06:13 |
| pitti | RAOF: hm, works here; can you please file a bug with the exact command you are calling? | 06:13 |
| RAOF | pitti: Sure. | 06:13 |
| pitti | $ ./run-from-checkout --shell -B ~/ubuntu/tmp/testpkg// --- lxc -es adt-utopic | 06:14 |
| pitti | RAOF: I used that | 06:14 |
| pitti | RAOF: sorry, where ./run-from-checkout == adt-run | 06:14 |
| RAOF | Hm. You don't need root? | 06:14 |
| pitti | I'm aware of --output-dir messing things up (need a better way to find the real stdout/err with output redirection) | 06:14 |
| pitti | RAOF: lxc's -s switch calls lxc through sudo | 06:14 |
| RAOF | Ah. | 06:14 |
| pitti | $ sudo ./run-from-checkout --shell -B ~/ubuntu/tmp/testpkg// --- lxc -e adt-utopic | 06:15 |
| pitti | works as well, though | 06:15 |
| pitti | RAOF: does it have any error message, about /dev/stdout blabla not found, or similar? | 06:15 |
| pitti | you should at least get the "- - running shell" bit | 06:15 |
| RAOF | pitti: I'll try that command again and get some clean logs. | 06:15 |
| Unit193 | pitti: Nono, if I *purge* brltty, the system will beep because it's stopping the service before removal. | 06:21 |
| pitti | Unit193: do you also get it beeping when rebooting if you have brltty installed? | 06:22 |
| Unit193 | Yep. | 06:22 |
| pitti | Unit193: nice, that sounds exactly like bug 1316804 then | 06:24 |
| ubottu | bug 1316804 in systemd (Ubuntu) "loud pc-speaker like beep when rebooting under systemd" [Undecided,Confirmed] https://launchpad.net/bugs/1316804 | 06:24 |
| Unit193 | My point exactly. | 06:25 |
| pitti | 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:25 |
| pitti | brendand: could you try rebooting or purging with removing /lib/systemd/system/brltty.service ? | 06:26 |
| pitti | sorry, Unit193 ^ | 06:26 |
| pitti | Unit193: this might even be something semi-deliberate, like indicating to the blind user that brltty is starting/stopping/etc. | 06:26 |
| pitti | but certainly not supposed to happen on reboot | 06:26 |
| TheMuso | 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 |
| pitti | aah! | 06:27 |
| pitti | RUN_BRLTTY=no | 06:27 |
| pitti | we don't start it by default | 06:27 |
| TheMuso | No. | 06:27 |
| TheMuso | Scripts were written for the installer to enable it explicitly if a user requests it. | 06:27 |
| pitti | 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:27 |
| TheMuso | Longer term, brltty needs to become a user session service. | 06:28 |
| TheMuso | But thats a whole ball of wax. | 06:28 |
| Unit193 | pitti: Added brltty back, and service brltty stop does make the beep. | 06:29 |
| pitti | TheMuso: so in the short term, the systemd unit should probably read the /etc/default file? | 06:29 |
| pitti | Unit193: thanks for confirming | 06:30 |
| TheMuso | 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 |
| Unit193 | pitti: No problem! | 06:30 |
| TheMuso | pitti: i.e if we want to move away from /etc/default, now is as good a time to do so. | 06:30 |
| pitti | TheMuso: I mean, it is intended to not run brltty by default? | 06:30 |
| TheMuso | pitti: Correct, we do want to keep that behavior. | 06:30 |
| pitti | 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 |
| TheMuso | Debian runs it if brltty is installed, so this is an Ubuntu change which I am happy to keep. | 06:31 |
| TheMuso | pitti: I am happy to adopt whatever better method for systemd units there is. | 06:31 |
| pitti | TheMuso: the usual way is to enable/disable services using "systemctl enable" (or disable) | 06:32 |
| TheMuso | pitti: Ok, sounds clean enough. | 06:32 |
| pitti | TheMuso: I'm interested in why we install brltty by default but not enable it; most packages are enabled on installation | 06:32 |
| pitti | 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 |
| pitti | TheMuso: anyway, I'll adjust the unit file; we do the same in whoopsie | 06:33 |
| TheMuso | pitti: If the user has a USB display, brltty is also activated via udev. | 06:34 |
| TheMuso | 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 |
| pitti | it looks odd in systemctl status as brltty will appear as "failed" when disabled, but can't help that for now | 06:34 |
| pitti | TheMuso: ah, thanks for the heads-up | 06:34 |
| pitti | xnox: so, mystery solved for bug 1316804 :) | 06:35 |
| ubottu | bug 1316804 in brltty (Ubuntu) "loud pc-speaker like beep when rebooting under systemd" [Undecided,Triaged] https://launchpad.net/bugs/1316804 | 06:35 |
| TheMuso | pitti: Thanks. Long term brltty needs to be beaten into submission as a user session service. | 06:35 |
| TheMuso | Too much stuff still runs as root for blind/vision impared users. | 06:35 |
| TheMuso | And that needs to change. | 06:35 |
| pitti | TheMuso: *nod* until then we'll just need to live with the unit appearing as "failed" when it's disabled; mostly cosmetical | 06:35 |
| === smb` is now known as smb | ||
| TheMuso | 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 |
| TheMuso | 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. | 06:41 |
| pitti | 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:00 |
| dholbach | good morning | 07:05 |
| TheMuso | pitti: Ok thanks. | 07:06 |
| mardy | 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:07 |
| pitti | RAOF: so each ../../client/cd-create-profile takes some 20 minutes or so; I wish they'd parallelize :) | 07:08 |
| RAOF | 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 |
| pitti | ah, makes sense | 07:10 |
| RAOF | On the basis that eating ~20GiB of RAM isn't going to be particularly conducive to exploiting your cores :) | 07:11 |
| brendand_ | pitti, i myself have the problem with bltty | 07:13 |
| brendand_ | pitti, i was ignoring it so far | 07:13 |
| pitti | brendand_: oh, are you also already running with systemd? | 07:13 |
| brendand_ | pitti, at least the symptoms match xnox's | 07:14 |
| brendand_ | pitti, i am | 07:14 |
| pitti | brendand_: wow | 07:14 |
| pitti | 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:14 |
| pitti | brendand_: you are running it because you are interested, or still a leftover from last week's sysvinit debacle? | 07:15 |
| Unit193 | pitti: Netbook thinks it's a good idea to make a loud beep when you unplug it or plug it in. >_< | 07:15 |
| brendand_ | pitti, leftover - i guess i can remove it now? | 07:16 |
| pitti | brendand_: well, not remove in the package sense, but disable again if you want | 07:16 |
| brendand_ | pitti, yeah - i mean remove the init= from grub | 07:16 |
| pitti | yes | 07:16 |
| pitti | brendand_: make sure you are fully updated, though :) | 07:17 |
| brendand_ | pitti, yeah i thought of that :) | 07:17 |
| pitti | RAOF: OOI, are the color profiles arch dependent? | 07:23 |
| RAOF | 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:24 |
| pitti | RAOF: they are so small, it almost seems like an upstream release ought to ship them pre-generated, similarly to HTML documentation :) | 07:27 |
| RAOF | pitti: They get translations merged in at build time. Otherwise, yeah. | 07:27 |
| pitti | with appropriate .icc : .xml rules so that they are rebuilt on modifications | 07:27 |
| pitti | RAOF: ah, ok | 07:27 |
| pitti | they are just 4 KB, didn't look like they'd have much stuff in them | 07:28 |
| RAOF | 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:29 |
| pitti | 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:38 |
| LocutusOfBorg1 | xnox, you there? | 07:39 |
| LocutusOfBorg1 | may I know if this package is suitable for debian? https://launchpad.net/ubuntu/+source/mediascanner | 07:39 |
| LocutusOfBorg1 | also this one https://launchpad.net/ubuntu/+source/lucene++ | 07:40 |
| LocutusOfBorg1 | is needed in the new poedit upstream release | 07:40 |
| LocutusOfBorg1 | we might benefit from uploading directly in debian and then autosync, right? | 07:40 |
| === brendand_ is now known as brendand | ||
| ekarlso | apw: u around boss ? :) | 07:44 |
| dholbach | salut didrocks - ça va? | 07:55 |
| didrocks | dholbach: ça va bien, et toi ? | 07:55 |
| dholbach | didrocks, très bien, merci! :-) | 07:55 |
| dholbach | didrocks, t'as un petit peu de temps la prochaine semaine de parler un peu de "how contributions make it into Ubuntu"? :-) | 07:56 |
| lool | stgraber: Added SRU information to LP #1310715, thanks | 07:57 |
| ubottu | Launchpad bug 1310715 in ubuntu-touch-meta (Ubuntu Trusty) "Provide final 14.04 frameworks" [High,New] https://launchpad.net/bugs/1310715 | 07:57 |
| dholbach | 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:57 |
| didrocks | 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 |
| didrocks | dholbach: sil2100, robru are the ones leading this now | 07:59 |
| dholbach | ok cool - thanks didrocks :) | 07:59 |
| didrocks | yw ;) | 08:00 |
| dholbach | 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:00 |
| didrocks | 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:02 |
| ricotz | hello :), is there a reason why there are no trusty daily iso-builds? (like it is done for precise) | 08:03 |
| dholbach | didrocks, ok cool | 08:06 |
| mlankhorst | chrisccoulson: that would be me, but that bug seems hard :P | 08:17 |
| chrisccoulson | mlankhorst, yeah. I have absolute faith in you though :) | 08:19 |
| pete-woods | mardy: hi, was wondering if you'd heard anything regarding the Vimeo API bug? | 08:24 |
| mardy | pete-woods: yes, they acknowledge the bug, and said they'll fix it soon | 08:24 |
| pete-woods | mardy: cool, thanks :) | 08:24 |
| mardy | pete-woods: I'll forward you their email | 08:25 |
| pete-woods | cheers | 08:25 |
| mardy | pete-woods: done | 08:25 |
| xnox | 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:26 |
| dholbach | 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:30 |
| sil2100 | dholbach: hey! Let's have a chat in some moments :) | 08:32 |
| dholbach | sil2100, rock and roll :) | 08:33 |
| pete-woods | 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 |
| mardy | pete-woods: on the desktop? | 08:36 |
| pete-woods | mardy: yes | 08:37 |
| pete-woods | hmm, I don't seem to have signon-ui installed | 08:37 |
| mardy | pete-woods: yes, that's certainly the issue | 08:37 |
| pete-woods | mardy: bit strange that it's not installed by default | 08:38 |
| pete-woods | installing it makes all happy again, though :) | 08:39 |
| seb128 | pete-woods, what is not installed by default and where? | 08:39 |
| pete-woods | seb128: I just had to manually install signon-ui to get online accounts to work | 08:40 |
| mardy | pete-woods: the last ubuntu-system-settings-online-accounts version can't be installed at the same time as signon-ui | 08:40 |
| seb128 | pete-woods, desktop or touch? | 08:40 |
| pete-woods | this is on a pretty recent utopic desktop (last week) | 08:40 |
| seb128 | mardy, why not? | 08:41 |
| seb128 | pete-woods, http://cdimage.ubuntu.com/daily-live/current/utopic-desktop-i386.manifest | 08:41 |
| seb128 | signon-ui0.16+14.04.20140304.is.0.15+14.04.20140313-0ubuntu2 | 08:41 |
| mardy | seb128: because on touch we merged the functionality of signon-ui into online-accounts-ui, | 08:41 |
| seb128 | pete-woods, it's installed by default ... maybe you got it uninstalled when you tried to install some touch component? | 08:41 |
| mardy | seb128: and we would have a conflict when installing the d-bus service file | 08:41 |
| seb128 | mardy, how is that going to work for people who install unity8 on their desktop next to unity7? | 08:42 |
| mardy | seb128: I'm afraid it will break online accounts on unity7 :-( | 08:42 |
| pete-woods | seb128: could well be possible, I do have unity8 installed | 08:42 |
| seb128 | mardy, we need to fix that | 08:42 |
| rbasak | stgraber: ah, it should be bug 1300991, sorry. I just copied the changelog straight from Debian. I should have checked it. | 08:42 |
| ubottu | 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:42 |
| rbasak | stgraber: do you want to reject and I'll re-upload with a fixed changelog? | 08:43 |
| seb128 | mardy, otherwise pete-woods is going to be the first of a long serie of unhappy users | 08:43 |
| mardy | 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:43 |
| rbasak | @pilot out | 08:44 |
| === 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 | ||
| rbasak | oops | 08:44 |
| seb128 | mardy, you could split that .service in its own binary and have both ui depending on it | 08:44 |
| mardy | seb128: maybe we could make the service file launch a shell script, that decides which binary to launch based on environment variables | 08:44 |
| Laney | is the service somehow linked to the frontend? | 08:44 |
| seb128 | mardy, right, or you can do that check in the .service itself, we used to do that for notify-osd | 08:45 |
| mardy | Laney: yes, the service implementation is a UI component | 08:45 |
| * mardy goes and has a look at notify-osd | 08:46 | |
| mardy | seb128: "used to do that", means you don't do that anymore? | 08:46 |
| mardy | seb128: found it in version 0.33, thanks | 08:47 |
| seb128 | mardy, yw! | 08:47 |
| seb128 | mardy, yeah, I think we dropped that logic, we just use notify-osd when installed now | 08:48 |
| mardy | seb128: OK, that sounds like a viable solution; I'll work on that | 08:48 |
| seb128 | mardy, thanks | 08:48 |
| apw | ekarlso, hi ? | 08:53 |
| pitti | @pilot in | 08:55 |
| === 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 | ||
| mardy | 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:58 |
| seb128 | Saviq, ^ do you know? | 08:59 |
| === Tm_Tr is now known as Guest17709 | ||
| seb128 | mardy, I guess that works, or you could just check for XDG_CURRENT_DESKTOP=Unity and assumes that's unity7 | 09:00 |
| mlankhorst | why do you want to detect it? | 09:01 |
| === timrc is now known as timrc-afk | ||
| mardy | mlankhorst: to know whether the D-Bus service should popup the desktop UI or the touch one | 09:02 |
| Laney | it's =Unity on touch too | 09:02 |
| mardy | Laney, seb128: I'll use the QT_QPA_PLATFORM then | 09:03 |
| Laney | mardy: You could check DESKTOP_SESSION is ubuntu-touch or unity8* | 09:05 |
| mlankhorst | mardy: but can't you try to pop up the touch one, if that fails fall back to desktop one? | 09:05 |
| infinity | mardy: If you're using unity8 == touch, that's going to end in tears when unity8 is the default on the desktop too... | 09:06 |
| seb128 | infinity, depends what you call "touch" | 09:07 |
| seb128 | we want the new UI in unity8-desktop as well | 09:07 |
| mardy | 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 |
| ogra_ | we'll just ship touchscreens with the images | 09:07 |
| * infinity mumbles something about convergence. | 09:07 | |
| seb128 | infinity, well, "touch" is going to be used on desktop as well | 09:07 |
| infinity | seb128: But not the same UI, obviously. Is it all screen-size/form-factor autodetecty yet? | 09:08 |
| mardy | 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 |
| ogra_ | infinity, far from that ... | 09:10 |
| Fudge | running Mangler in gdb, if it dies like it has been do I just run bt to give to you guys? | 09:10 |
| mardy | infinity: eventually, we'll use the unity8 one on all form factors | 09:10 |
| Fudge | oops sorry wrong channel | 09:10 |
| ogra_ | infinity, but as i understood the lightning talk about it it should anyway be use-case driven ... based on available input/output devices | 09:10 |
| Laney | the QPA_PLATFORM thing seems like it might be an implementation detail which might not be reliable | 09:11 |
| ogra_ | that will only tell you you are running Mir | 09:11 |
| ogra_ | (or X11 or surfaceflinger) | 09:11 |
| ogra_ | wont tell you anything about what device you are on | 09:12 |
| seb128 | 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 |
| pete-woods | 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 |
| seb128 | 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:12 |
| infinity | pete-woods: http://stackoverflow.com/questions/342409/how-do-i-base64-encode-decode-in-c | 09:14 |
| infinity | pete-woods: Might have a few decent pointers. | 09:14 |
| infinity | pete-woods: If you happen to already have openssl or glib in your dependency tree, both have base64 functions. | 09:15 |
| pete-woods | 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:17 |
| cjwatson | 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:18 |
| mardy | cjwatson: OK, that's fine | 09:19 |
| infinity | 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:19 |
| cjwatson | 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:20 |
| pete-woods | 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:21 |
| infinity | 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:22 |
| pete-woods | 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 |
| infinity | Ahh, indeed, liboauth is in main. I guess it doesn't do the base64 stuff you need, though. | 09:23 |
| infinity | Oh, but it depends on libnss, which is also likely to have a base64 implementation hiding in it. | 09:23 |
| infinity | Cause pretty much every crypto library has to. | 09:24 |
| infinity | pete-woods: /usr/include/nss/base64.h from libnss3-dev looks promising. | 09:25 |
| infinity | pete-woods: (Assuming you're using liboauth anyway, you already have libnss3... But maybe you're using a different oauth lib) | 09:26 |
| shadeslayer | mhall119: btw you're working with the SDK team right? | 09:26 |
| infinity | pete-woods: Oh, nssb64.h is more complete (same source) | 09:26 |
| pete-woods | 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:27 |
| infinity | 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 |
| infinity | 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:28 |
| infinity | 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 |
| pete-woods | yep | 09:29 |
| LocutusOfBorg1 | thanks xnox | 09:34 |
| LocutusOfBorg1 | are you working on fixing the FTBFS? | 09:34 |
| LocutusOfBorg1 | I would like to upload in debian, just to pass the new queue | 09:34 |
| LocutusOfBorg1 | otherwise poedit won't be uploaded | 09:34 |
| xnox | LocutusOfBorg1: go ahead with uploading to Debian, but check if it builds there. | 09:35 |
| ricotz | cjwatson, hi, thanks for the clarification, looking forward to them to be available | 09:35 |
| xnox | 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:35 |
| LocutusOfBorg1 | xnox, mmm and for poedit? | 09:36 |
| LocutusOfBorg1 | it needs lucene++ | 09:36 |
| xnox | LocutusOfBorg1: if it's reintroduced, that's fine. | 09:36 |
| LocutusOfBorg1 | sil2100, you there? | 09:37 |
| LocutusOfBorg1 | agreed xnox I understand | 09:37 |
| LocutusOfBorg1 | so I would like to know if sil2100 would like to maintain in debian too | 09:37 |
| sil2100 | Hi! | 09:37 |
| LocutusOfBorg1 | Hi sil! | 09:37 |
| LocutusOfBorg1 | I think you already got some mails to the poedit adopter | 09:38 |
| LocutusOfBorg1 | :) | 09:38 |
| LocutusOfBorg1 | do you mind uploading in debian? | 09:38 |
| sil2100 | 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 |
| sil2100 | If that's needed | 09:40 |
| LocutusOfBorg1 | yes, would be nice | 09:43 |
| LocutusOfBorg1 | just put the version on mentors and sync on ubuntu | 09:43 |
| === TLemur is now known as Timur | ||
| LocutusOfBorg1 | you will simplify a LOT the packaging of the new poedit | 09:43 |
| LocutusOfBorg1 | sil2100, Timur is the person who wants to adopt poedit | 09:43 |
| sil2100 | LocutusOfBorg1: ok, will try doing that this week :) | 09:44 |
| LocutusOfBorg1 | wonderful :) | 09:46 |
| LocutusOfBorg1 | great thanks! | 09:46 |
| === Guest17709 is now known as Tm_Tr | ||
| Timur | yes, thanks a lot | 09:49 |
| GunnarHj | rbasak: Did you see the dpkg-divert idea for skype-translation that infinity mentioned yesterday? | 09:50 |
| rbasak | 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 |
| rbasak | GunnarHj: if you do exactly what infinity wants and he says it's good then I'm happy to upload it :) | 09:59 |
| seb128 | hum | 10:07 |
| seb128 | does anyone see an issue with that mountall translation? | 10:07 |
| seb128 | msgid "Checking disk %1$d of %2$d (%3$d%% complete)" | 10:07 |
| seb128 | msgstr "Vérification du disque %1$d sur %2$d (avancement : %3$d%%)" | 10:07 |
| seb128 | 10:07 | |
| seb128 | I wonder why the % doesn't display in french on the plymouth screen | 10:07 |
| GunnarHj | 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:09 |
| rbasak | GunnarHj: great. Thanks! | 10:11 |
| GunnarHj | rbasak: Thank _you_ for great sponsoring work! | 10:12 |
| tseliot | 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:12 |
| seb128 | tseliot, thanks | 10:18 |
| tseliot | yw | 10:19 |
| === doko_ is now known as doko | ||
| Mirv | 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:27 |
| dbarth | Mirv: well,apparently i can't change apparmor :/ | 10:29 |
| dbarth | Mirv: so it means i could switch to qtwebkit 5.2 for old webapps | 10:30 |
| jjohansen | dbarth: what needs changed? | 10:30 |
| dbarth | Mirv: but i can't transparently migrate them to oxide | 10:30 |
| dbarth | the 1.0 webapp policy group | 10:30 |
| dbarth | this one prevents oxide from being used, to ensure only qtwebkit is | 10:31 |
| jjohansen | ah | 10:31 |
| dbarth | so apparently no choice but to force (or wait for) eveyone to switch to 14.04 before i can turned down qtwebkit support | 10:31 |
| Mirv | 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 |
| dbarth | 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:32 |
| jjohansen | dbarth: are we not phasing out the 1.0 webapp policy group? | 10:33 |
| cjwatson | well, we probably needed a reason for somebody to work on deprecating the 13.10 framework anyway | 10:33 |
| Mirv | 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 |
| dbarth | 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 |
| Mirv | dbarth: ok | 10:33 |
| BluesKaj | Hiyas all | 10:34 |
| jjohansen | 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:35 |
| dbarth | jjohansen: and jdstrand was not so keen on doing that | 10:36 |
| jjohansen | dbarth: right, I'll poke him in the morning so I can better understand his reasoning, thanks | 10:37 |
| dbarth | 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 |
| dbarth | it's probably adding a whole lot in templates, to let the whole oxide process family be authorized | 10:38 |
| jjohansen | right, I expected it would be more than that | 10:38 |
| dbarth | something that only happened when 1.1 was designed | 10:38 |
| jjohansen | ah | 10:38 |
| dbarth | and the new webview policy group | 10:38 |
| dbarth | cjwatson: yes, i'm happy to be that extra reason really | 10:40 |
| mardy | 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 |
| mardy | seb128: and both of them will depend on a new signon-ui-service package which installs the D-Bus service file | 10:52 |
| mardy | seb128: does this sound reasonable? (I have another question after this :-) ) | 10:53 |
| seb128 | mardy, yes, sounds reasonable | 11:04 |
| seb128 | 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:05 |
| mardy | 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 |
| mardy | seb128: for u-s-s-o-a I could add a Conflicts, I guess | 11:07 |
| rbasak | mardy: https://wiki.debian.org/PackageTransition is a helpful reference for this sort of stuff, if that helps. | 11:08 |
| mardy | seb128: but for signon-ui, will dpkg be able to handle it correctly, since the newest version will be a virtual package (unversioned)? | 11:08 |
| rbasak | AIUI, Breaks+Replaces is preferred over Conflicts where possible, as it's less constraining on upgrade ordering. | 11:09 |
| mardy | rbasak: that's useful, I'm reading it now | 11:09 |
| seb128 | mardy, I was going to point the url rbasak just shared | 11:09 |
| mardy | rbasak: cool, I think that mine is case #5 | 11:09 |
| === _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 | ||
| mardy | 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:31 |
| evfool | 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 |
| seb128 | mardy, sure | 11:32 |
| seb128 | evfool, we don't know yet, larsu and Trevinho are working on making those work under Unity | 11:32 |
| mardy | 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:32 |
| seb128 | once GTK and Unity are improved, we need to revisit the impact on the usability | 11:33 |
| evfool | seb128: ok, thanks | 11:33 |
| seb128 | 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 | 11:33 |
| === oSoMoN_ is now known as oSoMoN | ||
| seb128 | but that's an upstream issue, not a lot we can do for those who care only about gnome-shell users | 11:33 |
| seb128 | 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:40 |
| mardy | seb128: uh, OK | 11:41 |
| seb128 | evfool, it would be nice, if as an upstream, you would support non gnome-shell environments for your software ;-) | 11:47 |
| seb128 | (just saw your comment on the bug) | 11:48 |
| evfool | 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 |
| seb128 | evfool, it's using GtkHeaderBar? Can you move/resize the window? | 11:49 |
| seb128 | I can't here | 11:49 |
| seb128 | not sure what is different in your session though | 11:49 |
| evfool | 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 |
| seb128 | 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:50 |
| evfool | 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 |
| seb128 | evfool, the xfce issue is the inverse, you would likely get double decorations | 11:51 |
| seb128 | the headerbar and a wm bar | 11:51 |
| mardy | 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 |
| seb128 | evfool, like https://lh4.googleusercontent.com/-YlXpA1jR3O0/UpMsjN5c_OI/AAAAAAAAAXo/ZKPUsRLr-5s/w480-h500-k/xfcecalc.png | 11:52 |
| evfool | 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:53 |
| seb128 | 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:54 |
| seb128 | mardy, oh, so you keep an empty "signon-ui" binary as transitional? | 11:55 |
| mardy | seb128: yes, because we have some packages depending on it, and I'll make both signon-ui-x11 and u-s-s-o-a provide "signon-ui" | 11:56 |
| seb128 | mardy, provides != transitional package | 11:57 |
| seb128 | transitional would be a binary listed in debian/control with no content but a Depends: new-binary | 11:57 |
| mardy | seb128: ah, no, then it's not a transitional package | 11:58 |
| mardy | seb128: I guess I confused transitional with virtual | 11:58 |
| seb128 | mardy, so you are not in case 5, use C,R,P then | 11:58 |
| mardy | seb128: OK, thanks | 11:58 |
| seb128 | yw | 11:58 |
| === _salem is now known as salem_ | ||
| evfool | seb128: yup, everyone has their ideas, GNOME had an idea, and the first implementation had some rough edges, but we've all been through this, I hope eventually GNOME and Ubuntu will be able to go down the road hand in hand, even with this convergence madness involved | 12:02 |
| seb128 | evfool, I doubt the GNOME solution is ever going to work great for other desktops, they are making design choices that are meant to integrate with their "OS" | 12:03 |
| xnox | evfool: cinnamon, mate, lxqt started in part due to GNOME coding against gnome-shell only. How to achieve working hand in hand? | 12:04 |
| seb128 | evfool, you can't really assume that GNOME UI = Ubuntu UI and that you can do well on both environment without at least runtime checks and tweaks | 12:04 |
| evfool | seb128: yes, that's true, runtime checks and tweaks would be fine for me, but last time I checked, it involved serious code duplication | 12:06 |
| evfool | and I wanted to avoid that | 12:07 |
| seb128 | well, you can't get your cake and eat too there... | 12:07 |
| seb128 | you have 3 choices | 12:07 |
| seb128 | 1- don't use GtkHeaderbar, and work everywhere (though being less integrated in the GNOME look) | 12:07 |
| seb128 | 2- use GtkHeaderBar and care only about gnome-shell users | 12:08 |
| seb128 | 3- duplicate code to support the different environments | 12:08 |
| mardy | seb128: I updated those two MPs | 12:09 |
| seb128 | mardy, looking | 12:09 |
| evfool | ok, if these are the only choices i choose 3, I don't like the first two, 1. because for me the headerbar is not only about the gnome look 2. because I'm also using ubuntu on several computers | 12:09 |
| evfool | seb128: thanks for the discussion, I'll take another look at supporting non-shell environments, and hopefully will manage to improve the situation (resulting in system monitor 3.xx.xx upload in the utopic archives) | 12:11 |
| seb128 | evfool, 3 is a good option, I think that's mostly where we are heading anyway | 12:11 |
| seb128 | evfool, thanks for looking at the issue, sorry that those design decisions from GNOME/us is making things more difficult for you as an app writer | 12:11 |
| seb128 | we are looking at making header bars working better under Unity | 12:12 |
| === MacSlow|lunch is now known as MacSlow | ||
| seb128 | but they are still going to feel inconsistant and different from others using the wm decorations | 12:12 |
| evfool | seb128: I saw the progress from the initial implementation (from only close button to supporting the buttons set in gsettings), so I feel like the situation is improving, and yes, the headerbar apps will look different compared to other apps, just like skype does, or acrobat, or eclipse, or firefox | 12:16 |
| seb128 | none of those look different from the menubar perspective atm | 12:16 |
| seb128 | but yeah, which is why I said earlier that it's up to the app writer to have their app looking different or not | 12:17 |
| seb128 | we are just blocking the ones in the default unity set atm | 12:17 |
| evfool | seb128: yes, the menubar is the same, but look at theming widget looks, etc. | 12:17 |
| seb128 | because we don't want inconsistency in our default installation | 12:17 |
| evfool | seb128: ok, I understand that | 12:17 |
| seb128 | where we can avoid it | 12:17 |
| seb128 | (like we need it for e.g firefox or libreoffice) | 12:17 |
| === psivaa is now known as psivaa-lunch | ||
| === Guest10479 is now known as NCommander | ||
| jdstrand | dbarth, jjohansen: the one line change isn't the issue per se. it is the 'webview' policy group that no 13.10 webapp currently has because it didn't exist at the time which all 14.04 and higher webapps have | 12:21 |
| === NCommander is now known as Guest44676 | ||
| === Guest44676 is now known as ncommander | ||
| === ncommander is now known as NCommander | ||
| jdstrand | dbarth, jjohansen: the webview policy group is actually fairly extensive. just adding the policy group to the policy isn't enough, because the 13.10 framework webapps won't already have it so would have to be adjusted anyway | 12:22 |
| jjohansen | okay | 12:23 |
| jdstrand | dbarth, jjohansen: I could technically add it to the ubuntu-webapp template, but then it is likely that an app running on an actual 13.10 device won't work. plus, I would need to update the ubuntu-sdk template for apps that use ubuntu webviews) | 12:24 |
| jdstrand | dbarth, jjohansen: this is extremely disruptive from a policy point of view, and one of the reasons why we have frameworks in the first place. if we are just going to retroactively fix everything going forward, there is little point in having a framework | 12:25 |
| jdstrand | dbarth, jjohansen: finally, apparmor-easyprof-ubuntu is currently backported into at least one (if not more ppas) for the sdk and these changes could be problematic there if people are using the ppa on a 13.10 system and testing the 13.10 framework | 12:27 |
| jdstrand | could this be done? yes, but it would be a distraction and throwaway work | 12:28 |
| jdstrand | (imo) | 12:28 |
| jdstrand | if we really want to continue supporting the 13.10 framework, then let's actually do it-- ship the qtwebkit 5.1 somewhere where the webapp container can find it. if not, obsolete the framework and get the framework definition off the device. the webapp authors will update their webapps so the webapps show up ion the store and on the device again | 12:31 |
| jdstrand | and as Colin pointed out, that is work that we need to figure out how to do anyway. IMHO it is wise to do it now when we can afford to make mistakes/learn things when there are no shipping phones | 12:32 |
| mardy | seb128: thanks a lot for the reviews! | 12:33 |
| seb128 | mardy, yw, thanks for the fixes! | 12:35 |
| shadeslayer | pitti: https://jenkins.qa.ubuntu.com/job/utopic-adt-kapptemplate/1/ARCH=amd64,label=adt/console fails just because no tests were found? | 12:36 |
| pitti | shadeslayer: right | 12:36 |
| shadeslayer | huh | 12:37 |
| pitti | shadeslayer: this usually indicates some packaging error (wrongly copy&paste'd XS-Testsuite, or typo in debian/tests/control, etc.) | 12:37 |
| pitti | we treat this as error to detect these | 12:37 |
| dbarth | jdstrand: ok, nw; i'll keep qtwebkit support for now | 12:37 |
| mlankhorst | chrisccoulson: good news, I know what's wrong with webapps, bad news, it's hard to fix | 12:37 |
| dbarth | jdstrand: the problem will solve itself since we don't accept 13.10 apps anymore | 12:37 |
| shadeslayer | pitti: ok | 12:38 |
| dbarth | mlankhorst: what's up with webapps? | 12:39 |
| mlankhorst | I'm guessing the different places that use opengl | 12:40 |
| mlankhorst | simultaneously | 12:40 |
| mlankhorst | I'll try something dumb first, maybe I'll get lucky | 12:44 |
| cjwatson | Noskcaj: expat sync: best to actually check the diff, as in this case the Debian maintainer said they'd applied the dh-autoreconf patch in the changelog but did not in fact do so. I'm fixing it up for you | 12:53 |
| cjwatson | dholbach: ^- cc as the sponsor | 12:53 |
| dholbach | cjwatson, urgh... sorry about that | 12:53 |
| cjwatson | have also reopened the Debian bug | 12:53 |
| dholbach | thanks a lot for taking care of all of this | 12:54 |
| cjwatson | np | 12:54 |
| mlankhorst | hm hack works | 12:59 |
| mlankhorst | by not calling flush in swapbuffers | 12:59 |
| mlankhorst | and doing something even more evil | 13:10 |
| nectarys_ | I'm trying to abitye myself with the linux environment (am a developper). what kind of distribution do you advice me to abitye myself with, please? | 13:11 |
| cjwatson | (abitye isn't a standard English word. Google suggests Haitian for "cope", which wouldn't quite fit but I think I know what you mean ...) | 13:13 |
| cjwatson | If you ask in an Ubuntu development channel then I think you can expect people to suggest that you use Ubuntu :-) | 13:13 |
| pitti | "appetite"? :) | 13:16 |
| brendand | Arch, arch, arch! | 13:16 |
| ogra_ | lol | 13:17 |
| brendand | cjwatson, 'familiar' is also suggested | 13:17 |
| brendand | cjwatson, which makes sense | 13:17 |
| brendand | almost | 13:18 |
| ogra_ | familiar was a nice distro :) | 13:18 |
| brendand | ogra_, not what i meant | 13:19 |
| ogra_ | might have become hard to find the matching hardware for it nowadays though :P | 13:19 |
| ogra_ | brendand, i know ;) | 13:19 |
| brendand | just googled it | 13:19 |
| brendand | interesting | 13:19 |
| brendand | ubuntu touch for 20 years ago :) | 13:19 |
| ogra_ | yeah :D | 13:20 |
| cjwatson | ah yes, familiarise would fit | 13:20 |
| nectarys_ | brendand, why Arch :p ? | 13:23 |
| brendand | nectarys_, because i'm being facetious | 13:23 |
| brendand | which is mostly why anyone suggests arch | 13:23 |
| === tedg is now known as ted | ||
| nectarys_ | brendand, doesn't it take too long to configure ? | 13:24 |
| brendand | nectarys_, yes! | 13:26 |
| === psivaa-lunch is now known as psivaa | ||
| brendand | nectarys_, ignore us all and just use ubuntu | 13:27 |
| === ted is now known as tedg | ||
| chrisccoulson | mlankhorst, yay \o/ ;) | 13:29 |
| mlankhorst | it has the nasty side effect of breaking other things that worked before, though.. | 13:31 |
| === vrruiz_ is now known as rvr | ||
| mlankhorst | hm i might be able to make things work, but it would require updating libdrm :/ | 13:36 |
| Laney | @pilot in | 13:41 |
| === udevbot 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 | Patch Pilots: Laney | ||
| seb128 | woot, between dholbach pitti and Laney the sponsoring queue is going to be empty tonight ;-) | 13:43 |
| * pitti ^5s dholbach | 13:43 | |
| pitti | but will have to stop soon :/ | 13:43 |
| * dholbach hugs Laney, rbasak, seb128 and pitti | 13:43 | |
| Laney | ha | 13:43 |
| dholbach | I just did a very few entries today :) | 13:43 |
| Laney | I'm not the fastest sponsor ever | 13:43 |
| pitti | but it just lost some 20 entries, I think that's a glitch | 13:44 |
| pitti | I've seen the sponsoring queue missing two dozen entries at times, and some minutes later they came back | 13:44 |
| pitti | last time I reloaded we had 65 | 13:44 |
| pitti | oh, and now it's indeed back to 63, nevermind | 13:44 |
| Laney | I'm looking at the grilo branches | 13:45 |
| === 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: Laney, pitti | ||
| * Laney nods Mirv | 13:46 | |
| * pitti fixes the duplicate patch pilot topic entry, seems I didn't get it quite right this morning (it got truncated) | 13:47 | |
| seb128 | xnox, hey, could you push https://code.launchpad.net/~xnox/unity-control-center/utopic/+merge/216962 manually to trunk? | 13:48 |
| === timrc-afk is now known as timrc | ||
| mlankhorst | Laney: hm didn't you file a bug about webapps too? | 13:48 |
| Laney | umm did I file it? | 13:49 |
| seb128 | what about those? | 13:50 |
| seb128 | oh, nouveau issue | 13:50 |
| Laney | yeah | 13:51 |
| Laney | mlankhorst: I think you told me it was https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1300411 | 13:51 |
| ubottu | Ubuntu bug 1300411 in xserver-xorg-video-nouveau (Ubuntu) "Xorg crashed with SIGSEGV in pushbuf_flush()" [Medium,New] | 13:51 |
| pitti | @pilot out | 13:54 |
| === udevbot 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: Laney | ||
| mlankhorst | Laney: ah right, there seems to be a webapps bug now, but the fix is not going to be fun :p | 13:55 |
| xnox | seb128: in-progress | 14:07 |
| xnox | seb128: done. | 14:11 |
| seb128 | xnox, thanks | 14:12 |
| === alexisb_out is now known as alexisb | ||
| mhall119 | shadeslayer: yes I work with the SDK guys, why? | 14:33 |
| shadeslayer | mhall119: I wanted to get an update on the Qt 5.3 status, but it was posted on the ML a few minutes ago, so it's all good :) | 14:34 |
| mhall119 | shadeslayer: great | 14:34 |
| rbasak | Do I need to run update-maintainer on an SRU with no Ubuntu changes (but with an ubuntu version number since it's an SRU)? | 14:35 |
| rbasak | It's a straight rebuild of a more recent version from Debian, since the only thing changed in sid is a fix for the bugs being SRUd | 14:35 |
| === gusnan_ is now known as gusnan | ||
| shadeslayer | rbasak: why not a sync then? | 14:37 |
| shadeslayer | unless that's not possible | 14:37 |
| === MacSlow_ is now known as MacSlow | ||
| rbasak | shadeslayer: I didn't think that's possible because the version is already published in Utopic, and we presumably want a rebuild for Trusty. | 14:38 |
| rbasak | Since publishing binaries in Trusty built on Utopic would probably not be a good idea (I'm guessing) | 14:39 |
| rbasak | So I've modified the changelog (and only the changelog). | 14:39 |
| mdeslaur | cjwatson: I'm stealing the chkrootkit merge from you | 14:55 |
| shadeslayer | rbasak: hm, I am unsure how that could be handled, best to ask someone in -release I guess | 15:02 |
| cjwatson | mdeslaur: ah, yeah, be my guest | 15:03 |
| cjwatson | rbasak: I don't personally think it's necessary to run update-maintainer, but wouldn't reject it if you did | 15:04 |
| cjwatson | And yeah, we generally wouldn't copy backwards like that | 15:04 |
| cjwatson | The only exceptions are when rebuilding is hard for some reason and we can be sure that the result doesn't depend on anything interesting from the host system - so the only case I'm aware of is shim/shim-signed | 15:05 |
| cjwatson | In that case not so much that rebuilding is hard but that it's expensive when the checksum changes | 15:05 |
| rbasak | cjwatson: OK, thanks! | 15:12 |
| rbasak | stgraber: auto-apt re-uploaded to trusty-proposed with the LP bug reference fixed. Sorry about that. | 15:15 |
| stgraber | rbasak: np | 15:16 |
| cjwatson | doko: hm, is it a bug for the compiler to pollute the built-in namespace with "#define bool bool"? | 15:36 |
| niemikorpi | what do you think about an idea of creating an own, chromium-based browser with npapi-support? | 15:37 |
| cjwatson | doko: that is, "gcc -xc -E -dD /dev/null | grep -w bool" returns non-empty on powerpc but empty on amd64 | 15:37 |
| cjwatson | doko: this is the root cause of the haskell-gio build failure on powerpc/ppc64el; I can work around it but am interested in whether it's a compiler bug | 15:38 |
| doko | cjwatson, from altivec.h: | 15:44 |
| doko | 'pixel' and 'bool' as context-sensitive AltiVec keywords (in | 15:44 |
| doko | non-AltiVec contexts, they revert to their original meanings, | 15:44 |
| doko | if any), so we do not need to define them as macros. */ | 15:44 |
| doko | #if !defined(__APPLE_ALTIVEC__) | 15:44 |
| doko | #define vector __vector | 15:44 |
| doko | #define pixel __pixel | 15:44 |
| doko | #define bool __bool | 15:44 |
| doko | #endif | 15:44 |
| doko | so looks like intent =) however that wouldn't explain why you see it on powerpc | 15:44 |
| seb128 | xnox, do you see anything wrong in ""Vérification du disque %1$d sur %2$d (avancement : %3$d%%)"" (that's a mountall translations for "Checking disk %1$d of %2$d (%3$d%% complete)") | 15:45 |
| cjwatson | doko: I'm seeing it defined to bool rather than __bool | 15:45 |
| cjwatson | doko: It looks like the effect of /usr/lib/gcc/powerpc64le-linux-gnu/4.8/include/stdbool.h, but I wouldn't expect that to be included without asking for it? | 15:46 |
| doko | if (TARGET_EXTRA_BUILTINS) | 15:46 |
| doko | { | 15:46 |
| doko | /* Define the AltiVec syntactic elements. */ | 15:46 |
| doko | builtin_define ("__vector=__attribute__((altivec(vector__)))"); | 15:46 |
| doko | builtin_define ("__pixel=__attribute__((altivec(pixel__))) unsigned short"); | 15:46 |
| doko | builtin_define ("__bool=__attribute__((altivec(bool__))) unsigned"); | 15:46 |
| doko | if (!flag_iso) | 15:46 |
| doko | { | 15:46 |
| doko | builtin_define ("vector=vector"); | 15:46 |
| doko | builtin_define ("pixel=pixel"); | 15:46 |
| doko | builtin_define ("bool=bool"); | 15:46 |
| doko | builtin_define ("_Bool=_Bool"); | 15:46 |
| doko | init_vector_keywords (); | 15:46 |
| doko | /* Enable context-sensitive macros. */ | 15:46 |
| cjwatson | Hmm, maybe not, __bool_true_false_are_defined isn't there | 15:46 |
| doko | cpp_get_callbacks (pfile)->macro_to_expand = rs6000_macro_to_expand; | 15:46 |
| doko | } | 15:46 |
| doko | } | 15:46 |
| xnox | !pastebin | 15:46 |
| ubottu | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 15:46 |
| xnox | seb128: seems resonable. Unless %%) is somehow parsed incorrectly whilst "%% " does the right thing | 15:48 |
| seb128 | xnox, let me try that, because the % part is missing in plymouth for some reason | 15:49 |
| doko | cjwatson, $ gcc -E -dM - </dev/null | grep bool doesn't show anything on powerpc | 15:50 |
| cjwatson | doko: oh, sorry, I'm testing on ppc64el after all | 15:52 |
| cjwatson | identical haskell-gio failure on powerpc though ... | 15:52 |
| doko | cjwatson, so yes, then I think this is expected. otoh, maybe we can raise it ... | 15:52 |
| cjwatson | doko: I could probably just use --std=c89 then | 15:53 |
| doko | yes | 15:53 |
| Laney | stgraber: https://code.launchpad.net/~rcj/ubuntu/precise/libdumbnet/sru/+merge/221919 could you confirm/deny that you asked for this? | 15:54 |
| stgraber | Laney: I can confirm but it's already been uploaded and is currently in precise-proposed | 15:54 |
| Laney | oh okay | 15:55 |
| Laney | let me get that merge proposal off the queue then ;) | 15:55 |
| cjwatson | or maybe there's some way I can glue in cpphs | 15:55 |
| doko | * Adjust watch file to new hackage layout | 15:57 |
| doko | ^^^ do you trust such packaging? ;-P | 15:57 |
| seb128 | xnox, no, adding a space doesn't fix it | 15:57 |
| cjwatson | what's wrong with that? | 15:57 |
| doko | "hackage" layout | 15:59 |
| cjwatson | doko: http://hackage.haskell.org/ | 15:59 |
| cjwatson | not a typo | 15:59 |
| doko | ahh | 15:59 |
| doko | cjwatson, on powerpc I get the define only, if I explicitly add -maltivec | 16:00 |
| cjwatson | doko: I think I'll just whack in --std=c89 for now and see if that fixes things across the board | 16:04 |
| doko | cjwatson, or does ghc turn on altivec by default? | 16:05 |
| cjwatson | er with one - | 16:05 |
| cjwatson | doko: checked, doesn't seem to | 16:05 |
| cjwatson | though who knows what lurks in the depths of that build system | 16:06 |
| doko | yes, like all -f and -m options | 16:06 |
| seb128 | xnox, so, it doesn't like the ":" in the string | 16:08 |
| cjwatson | oh for goodness' sake I can't pass in -std=c89 through the .cabal file. Will have to hold nose and use -Ubool I think | 16:11 |
| tseliot | seb128: shall I merge and upload the code myself now that you have approved it? | 16:14 |
| seb128 | tseliot, no, that's going through CI train, it's in https://launchpad.net/~ci-train-ppa-service/+archive/landing-014/ | 16:15 |
| tseliot | seb128: oh, nice, I had no idea that's how it works. Thanks | 16:16 |
| seb128 | tseliot, yw, thanks again for working on that! | 16:16 |
| tseliot | seb128: yw. BTW shall I do the same for the SRU for 14.04? | 16:17 |
| seb128 | tseliot, did you want some feedback from utopic first? | 16:18 |
| xnox | seb128: there is non-breaking space before ":" in your paste above (at least that's how it came through to me) | 16:19 |
| seb128 | xnox, of course, that's french :p | 16:19 |
| xnox | seb128: sounds very weird though, as ":" isn't a special character in gettext. | 16:19 |
| tseliot | seb128: not really, we have already done the testing on the limited use cases that we support. It was more of a matter of landing things in 14.10 first | 16:19 |
| seb128 | tseliot, ok, I can do the SRU upload as well | 16:20 |
| xnox | seb128: is the trailing ) always printed? e.g. to eliminate the case where the translated string is simply much longer than "C" translation. | 16:20 |
| tseliot | seb128: ok, I'll prepare the SRU then, thanks | 16:20 |
| seb128 | xnox, I did tweaks to the translations, like I changed it for "done %3$d%%" and it works "done : %3$d%%" and it stops working | 16:21 |
| xnox | *sigh* | 16:21 |
| seb128 | tseliot, don't bother, I'm going to go through the CI landing as well | 16:21 |
| seb128 | tseliot, but if you could make the bug SRU compliant that would be nice (impact, test case, regression potentiel) | 16:22 |
| tseliot | seb128: sure | 16:22 |
| seb128 | tseliot, thanks | 16:22 |
| tseliot | :) | 16:22 |
| dpm | pitti, could you enable the utopic langpack cron job? The export schedule in LP has now been updated | 16:31 |
| tseliot | seb128: ok, the description should be fine now. Thanks again | 16:40 |
| seb128 | tseliot, yw! | 16:40 |
| infinity | doko: Your binutils upload dropped my multiarch fix. | 17:02 |
| === seb128_ is now known as seb128 | ||
| nectarys_ | i'm trying to connect a open my usb via virtualbox where i've launched Windows 7, but I wasn't able to find how. Does anyone know how to deal with, please ? | 17:05 |
| Laney | @pilot out | 17:26 |
| === udevbot 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: | ||
| === josepht_ is now known as josepht | ||
| === timrc is now known as timrc-afk | ||
| === timrc-afk is now known as timrc | ||
| rbasak | schroot can't remove /var/lib/schroot/mount/<session>. Any ideas? | 18:30 |
| rbasak | Doing it by hand gives me "Device or resource busy", but I don't see it mounted, and lsof doesn't see anything inside it. | 18:31 |
| rbasak | This might have happened because I forgot about the session and updated the chroot underneath it | 18:31 |
| rbasak | Nothing in /proc/mounts that I can see. | 18:32 |
| === roadmr is now known as roadmr_afk | ||
| CodePulsar | Can I have two versions of Boost Libraries installed on the system? | 19:09 |
| CodePulsar | i.e. Boost 1.54 and 1.55 ? | 19:09 |
| CodePulsar | I see if I try to install 1.55 it tries to uninstall 1.54 and all the application that depend on it including Ubuntu SDK | 19:09 |
| === roadmr_afk is now known as roadmr | ||
| brendand | anyone hitting a similar problem to this? http://paste.ubuntu.com/7590314/ | 21:02 |
| brendand | luatex : Depends: texlive-binaries (>= 2014) but 2013.20130729.30972-2build4 is to be installed | 21:03 |
| brendand | is the gist of it | 21:03 |
| ScottK | brendand: Probably a stale mirror. | 21:09 |
| brendand | ScottK, i just have archive.ubuntu.com and gb.archive.ubuntu.com in my sources.list | 21:12 |
| ScottK | Dunno. The newer texlive-binaries is in uptopic. | 21:13 |
| ScottK | utopic even | 21:13 |
| ajmitch | at a glance, luatex was removed from utopic a couple of days ago | 21:14 |
| nottheoilrig | i just launched an ubuntu ec2 image and ran aptitude install git | 21:19 |
| nottheoilrig | Err http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ utopic/main git amd64 1:2.0.0-1 | 21:19 |
| nottheoilrig | 403 Forbidden | 21:19 |
| nottheoilrig | what am i doing wrong? | 21:20 |
| nottheoilrig | please let me know if theres a more appropriate irc channel for this | 21:20 |
| sladen | nottheoilrig: you're not doing anything wrong; that archive mirror appears to be currently down | 21:23 |
| sladen | nottheoilrig: you can edit /etc/apt/sources.list to select another mirror | 21:24 |
| nottheoilrig | okay thanks is there a web page with the status of the various ubuntu infrastructure? | 21:24 |
| nottheoilrig | like https://status.github.com/ | 21:25 |
| * sladen traies to find it in https://launchpad.net/ubuntu/+archivemirrors | 21:25 | |
| nottheoilrig | status.ubuntu.com is a thing... | 21:26 |
| mterry | Laney, you set bug 1325505 to won't fix? | 21:27 |
| ubottu | bug 1325505 in ubuntu-system-settings (Ubuntu) "[regression][#60] cannot change greeter's background" [Undecided,Won't fix] https://launchpad.net/bugs/1325505 | 21:27 |
| sladen | nottheoilrig: I've reported that one machine being 403 to the sysadmin's tracking system; There are several hundred more available though! | 21:37 |
| sladen | nottheoilrig: see https://launchpad.net/ubuntu/+archivemirrors | 21:37 |
| sladen | nottheoilrig: or just change to to plain 'archive.ubuntu.com' for the moment | 21:37 |
| sladen | nottheoilrig: status.ubuntu.com is actually for tracking bug process across the whole OS and application stack | 21:38 |
| nottheoilrig | sladen: awesome thanks did you find a webpage with the status of eg http://us-east-1.ec2.archive.ubuntu.com | 21:38 |
| sladen | nottheoilrig: https://launchpad.net/ubuntu/+archivemirrors | 21:39 |
| sladen | nottheoilrig: probably https://launchpad.net/ubuntu/+mirror/us.archive.ubuntu.com-archive | 21:39 |
| sladen | nottheoilrig: but I suspect that is served by several machines; one of which happens to be this one | 21:39 |
| sladen | nottheoilrig: it says (in general) "last checked 15 hours ago" | 21:40 |
| rbasak | sladen: #ubuntu-mirrors is the right place to ask this I think | 21:40 |
| rbasak | I don't see anything in that channel topic though | 21:40 |
| brendand | anyone running utopic can tell me what ' systemctl status cgmanager.service' returns for them? | 21:42 |
| stgraber | root@lantea:~# systemctl status cgmanager.service | 21:43 |
| stgraber | Failed to get D-Bus connection: No connection to service manager. | 21:43 |
| stgraber | brendand: which is the expected result since we haven't switched to systemd yet and systemd obviously isn't running on that system | 21:43 |
| brendand | stgraber, oh - but i am running systemd | 21:44 |
| brendand | stgraber, i tried switching back earlier today and it messed everything up | 21:44 |
| brendand | stgraber, like network-manager didn't start and lot's of other weirdness | 21:45 |
| stgraber | brendand: then you're pretty much on your own then, we don't support doing that yet (pitti is working on it but it's very much work in progress) | 21:45 |
| brendand | mterry, set it back to in progress. people should comment on status changes | 21:48 |
| mterry | brendand, yeah... I'll ask in bug for clarification too | 21:49 |
| === timrc is now known as timrc-afk | ||
| === timrc-afk is now known as timrc | ||
| Laney | I blame the gremlins | 22:07 |
| smoser | anyone know how | 22:23 |
| smoser | http://archive.ubuntu.com/ubuntu/pool/main/m/maas/maas_1.5.2+bzr2282.orig.tar.gz | 22:24 |
| smoser | differs from | 22:24 |
| smoser | https://launchpad.net/ubuntu/+archive/primary/+files/maas_1.5.2%2Bbzr2282.orig.tar.gz | 22:24 |
| smoser | (second is seen at https://launchpad.net/ubuntu/+source/maas) | 22:24 |
| smoser | ugh. | 22:25 |
| smoser | ugh. no it doesnt. ignore that | 22:27 |
| lifeless | smoser: full marks :) | 22:33 |
| === salem_ is now known as _salem | ||
| sarnold | xnox,pitti, this seems like one for you guys, even though it says 14.04: 1326412 | 22:46 |
| RAOF | pitti: Huh, I seem to have lost backscroll. How did mips go? | 22:48 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| xnox | sarnold: hey, what's up? | 22:51 |
| sarnold | xnox: bug 1326412 looks like it might be related to something you guys were working on in malta; I wanted to aim it your way in case you were working on a pile of these sorts of issues all at once :) | 22:53 |
| ubottu | bug 1326412 in ubuntu-release-upgrader (Ubuntu) "can't do dist-upgrade" [Undecided,New] https://launchpad.net/bugs/1326412 | 22:53 |
| acrilex | hello, I just created my PPA on launchpad, and the package fail to compile with deps errors. can someone help me plz? | 22:54 |
| acrilex | Here is the build log, it is long, but the most important should be at the end: https://launchpadlibrarian.net/176941630/buildlog.txt.gz | 22:55 |
| sarnold | acrilex: this line looks most important: dpkg-source: info: fuzz is not allowed when applying patches dpkg-source: info: if patch 'opengles' is correctly applied by quilt, use 'quilt refresh' to update it | 22:56 |
| xnox | sarnold: looking at the package i'd think it's mvo or bmurray. Oh, wait. nah you can't do that yet. | 22:56 |
| xnox | sarnold: we don't support a whole bunch of stuff when booted with systemd at the moment. One can't dist-upgrade, or even just install/upgrade a bunch of packages yet. | 22:57 |
| sarnold | xnox: ah :) | 22:57 |
| xnox | sarnold: hence all of us working on bringing systemd support flip between booting upstart & systemd at the moment (by tweaking init=/lib/systemd/systemd vs init=/sbin/init) | 22:57 |
| acrilex | do you think there is a fix I can apply to fix compile issue (this is launchpad buildbot, can't send him command) | 22:58 |
| xnox | sarnold: i've added a tag "systemd-boot" which is what we use to track everything. and will comment in a second. | 22:58 |
| sarnold | xnox: thanks! | 22:58 |
| acrilex | do you think there is a fix I can apply to fix compile issue (this is launchpad buildbot, can't send him command) | 22:58 |
| sarnold | acrilex: what does 'quilt pop -a ; quilt push -a' report in your local tree? | 22:58 |
| acrilex | wait 1 sec, doing it | 22:59 |
| acrilex | oh no! need to pull back project, it will take 1 minute | 23:00 |
| acrilex | Patch opengles does not exist | 23:04 |
| acrilex | who can I clean the patch from project and recreate it? | 23:05 |
| acrilex | how* | 23:05 |
| sarnold | acrilex: I don't know much about this end of things.. does 'bzr status' show anything unexpected? | 23:07 |
| acrilex | I will repull the original one and redo my job! will be easier | 23:08 |
| === timrc is now known as timrc-afk | ||
| xnox | wgrant: barry: in lazr.restfulclient's test-suite, i think it should be possible to still use wsgi_intercept, but instead of serving lazr.restful test-app, serve a WSCGIProxy.spawning app (aka shim). That shim would fork python2 interpreter, and server lazr.restful using python2. But it should allow running a full python3 test-suite in the lazr.restfulclient. | 23:28 |
| xnox | there are a few python3 compat things left unported in lazr.restulclient, so i'll tackle those first. | 23:28 |
| barry | xnox: what are still left unported? | 23:29 |
| xnox | and then work on the frankenstein (six) runner. | 23:29 |
| xnox | barry: in your branch: still a few "except Exception, e" & it uses oauth, instead of oauthlib. | 23:29 |
| xnox | barry: one can run a partial (non-lazr.restful dependant) test-suite under python3 and those things show up. | 23:30 |
| xnox | (oh and a few import statements compats) | 23:30 |
| xnox | I'll propose my work in progress branch to clean up those. | 23:30 |
| barry | xnox: sounds great! | 23:30 |
| xnox | Haven't done authlib port yet though. Should be easy (following your notes) | 23:30 |
| barry | yep | 23:31 |
| * barry -> dinner | 23:31 | |
| xnox | barry: the documentation on WSCGIProxy.spawn is sparse though. I hope it will work. | 23:31 |
| xnox | (should be more straightforward than cjwatson's mock C functions in python via reverse python-gi) | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
