| aeoril | sarnold I don't need sbuild or pbuilder if I can use vms though right? | 00:07 |
|---|---|---|
| cjwatson | VMs are way more cumbersome for this | 00:08 |
| aeoril | sarnold why? | 00:08 |
| sarnold | aeoril: to a point, yes, but it's sometimes nice to keep VMs clean so they can be easily re-used.. | 00:08 |
| aeoril | cjwatson why? | 00:08 |
| cjwatson | I mean, yes, you can arrange to bring up a clean VM from a base state every time and install just what you need to do the build | 00:08 |
| sarnold | aeoril: and once you get the build environment set up, it's always ready for further use :) | 00:08 |
| cjwatson | But sbuild automates all that and it's much faster | 00:08 |
| aeoril | sarnold cjwatson ok, that makes sense | 00:09 |
| cjwatson | And if you don't arrange to be starting from a clean state each time, it's not as reliable a test that you got everything right | 00:09 |
| aeoril | ok | 00:09 |
| aeoril | cjwatson sarnold The first thing I will need to do after setting up my build environment is build vim the same way it was built in the trusty package that was released with Ubuntu. How do I do that? I need to use the /debian/rules somehow I think - it has the correct rules to set up the make envirnonment | 00:12 |
| aeoril | cjwatson sarnold what I really need to do is learn how to build the upstream vim from its git source just like it was built under trusty so I can bisect correctly | 00:13 |
| aeoril | I have experimented with passing various command line parameters to ./configure but have not succeeded in reproducing the same build environment. I can reproduce the bug, but it is not reproduced in exactly the same way | 00:14 |
| aeoril | (I gleaned them from /debian/rules) | 00:15 |
| aeoril | Anyway, when I get back from dinner I will re-read the instructions for sbuild and try them out on a clean virtual machine until I get them right | 00:17 |
| aeoril | cjwatson sarnold note that I successfully reproced the bug using a certain command line I created from options in /debian/rules, but unfortunately the bug still happened even using the latest source code so it was bad in code that was in trusty and beyond vivid, so that was not usable. Also, the build was not identical by any means, but it was the first time I could reproduce the bug | 00:23 |
| aeoril | from the upstream source, so that may have some value in knowing | 00:23 |
| aeoril | s/reproced/reproduced/ | 00:23 |
| sarnold | aeoril: this is even harder to nail down than I expected.. | 00:24 |
| aeoril | sarnold yes, I really need to somehow figure out how to build it like they did in trusty - I think that seems to be key at this point. The bug is not cooperating. | 00:24 |
| aeoril | sarnold but, I was able to reproduce it from the upstream git source using an "screwed up variant" of the trusty build environment, so that gives some insight somehow | 00:25 |
| aeoril | sarnold maybe it points to the build environment as the source of the bug rather than the source code itself? | 00:26 |
| aeoril | vim source code* | 00:26 |
| sarnold | aeoril: that's a possibility, not easy to track down though :) | 00:26 |
| aeoril | sarnold by "build environment," I mean whatever was created by ./configure [command line ...] | 00:26 |
| aeoril | command line params* | 00:27 |
| aeoril | sarnold yes, I am beginning to realize that | 00:27 |
| tkamppeter | when does the Upstart -> systemd transition take place? Can I drop Upstart support in CUPS already in Vivid? | 00:27 |
| aeoril | sarnold we'll get 'er figured out though ... sooner or later ... :) | 00:27 |
| aeoril | sarnold I definitely need to get a proper build environment set up for this though using sbuild I guess | 00:29 |
| aeoril | (build environment here meaning more correctly the proper gcc, libraries, etc.) | 00:29 |
| aeoril | darkxst hey, I made some headway today, but it is going to be harder than thought | 00:32 |
| cjwatson | aeoril: Right, so for bisection sbuild is probably in fact a bit cumbersome to set up in full because you'd have to recreate full working packaging at each step, but I'd still at least use the schroot part of it for your builds. I suspect that you can get most of the way by just fishing out the appropriate configure options and any relevant environment variables from debian/rules. | 00:33 |
| cjwatson | tkamppeter: Part of a smooth transition is likely to require keeping upstart support past the transition (at least until the next LTS, I should think) so that upgrades can be smooth. | 00:33 |
| aeoril | cjwatson ok, cool - that was my first question - I fished out a portion of them already, but it was not quite correct. I will try to fish out the rest when I get finished with dinner. Would you be available to help me when I do to get all the options correct? | 00:34 |
| cjwatson | aeoril: Unlikely, sorry. It's late. Only awake because my eye's irritating me. | 00:35 |
| cjwatson | Also I'm really just doing drive-by Ubuntu development these days :) | 00:35 |
| aeoril | cjwatson ok, that is ok - thanks for the help anyway | 00:35 |
| darkxst | aeoril, good! | 00:37 |
| aeoril | darkxst I have reproduced the bug by passing a partial list of command line params to ./configure on the git source by fishing them out from /debian/rules. However, the same bug happened on the latest upstream with those same params. cjwatson suggests I fish out the rest of them (to paraphrase) so I and use them to bisect. Would you agree? | 00:40 |
| darkxst | aeoril, yes | 00:40 |
| aeoril | darkxst I could tell I did not build it exactly the same with --version because the gcc and ld command lines were not the same ... | 00:40 |
| aeoril | darkxst would you be available after I have dinner if I have trouble figuring out what I need from /debian/rules ? | 00:41 |
| aeoril | darkxst figuring out what I need to pass to ./configure in the upstream build from git? | 00:42 |
| darkxst | aeoril, should be around, but likely in and about a bit today | 00:43 |
| darkxst | aeoril, have you tried looking at the buildlogs? | 00:43 |
| aeoril | darkxst also, I am thinking it may be more of a build environment bug so I think the first thing I will do is diff /debian/rules between vivid and trusty ... that would be quick, hopefully | 00:44 |
| darkxst | pretty sure the exact configure command will show in the buildlogs | 00:44 |
| aeoril | darkxst oh, did not know about buildlogs - I will do that | 00:44 |
| aeoril | darkxst you mean just ./configure without any params? | 00:45 |
| aeoril | oh, sorry - misread - gotcha, will look at the logs - that would be wonderful! :) | 00:45 |
| darkxst | the actuall full configure command | 00:45 |
| aeoril | darkxst yes, misread - gotcha! Thanks1 I hope that is true! | 00:46 |
| darkxst | aeoril, and you probably need to set CFLAGS also, to get a build exactly the same | 00:47 |
| tkamppeter | cjwatson, OK, thanks. | 00:48 |
| aeoril | darkxst I was thinking about CFLAGS and there is another one, maybe like it ... do you mean actually set CFLAGS from the command line before running make? | 00:48 |
| aeoril | darkxst I saw CFLAGS in /debian/rules, IIRC | 00:48 |
| darkxst | aeoril, yes (before running configure though) | 00:49 |
| aeoril | darkxst oh, ok - yah, I would need to know what that is - hopefully from the logs??? | 00:49 |
| tkamppeter | slangasek, around? | 00:50 |
| darkxst | aeoril, should be | 00:50 |
| aeoril | darkxst ok, cool - thanks for all the help! Gotta go to dinner! | 00:50 |
| darkxst | aeoril, debian/rules is rather complicated, so the buildlogs are likely your best bet | 00:51 |
| aeoril | darkxst yes, ok - I will hope for the best on that ... | 00:52 |
| darkxst | aeoril, https://launchpadlibrarian.net/192193726/buildlog_ubuntu-vivid-amd64.vim_2%3A7.4.488-3ubuntu2_UPLOADING.txt.gz | 00:52 |
| aeoril | darkxst cool! Thanks! | 00:53 |
| darkxst | look for the lines with ./configure | 00:53 |
| aeoril | ok - what about trusty? | 00:53 |
| darkxst | you can probably just cut+paste that entire line | 00:53 |
| aeoril | yah, cool - I am leaving about as fast as you did the other night! | 00:53 |
| aeoril | lol | 00:53 |
| sarnold | darkxst: hah! that's so much easier than figuring out what debian/rules "would" execute. very nice. :) | 00:53 |
| darkxst | aeoril, got to vim page on launchpad and click through through the trusty packages | 00:53 |
| aeoril | ok, cool - thanks | 00:54 |
| aeoril | darkxst ok, so this: https://launchpadlibrarian.net/161446547/buildlog_ubuntu-trusty-amd64.vim_2%3A7.4.052-1ubuntu3_UPLOADING.txt.gz | 00:57 |
| aeoril | Yippeee! | 00:57 |
| aeoril | That also shows me v7-4-488 was vivid ... | 00:58 |
| aeoril | LEAVING!!! | 00:58 |
| ahoneybun | hey darkxst | 00:59 |
| darkxst | ahoneybun, hi | 01:00 |
| ahoneybun | balloons: it runs damn well | 01:01 |
| === jamesh_ is now known as jamesh | ||
| === salem_ is now known as _salem | ||
| aeoril | darkxst I found and used the entire ./configure command line along with the LDFLAGS and CFLAGS settings from the logs. The problem occured both on the standard trusty package and in the git upstream source I pulled a few days ago. I looked at the vivid logs on launchpad, and the ./configure command line is different. I tried it on trusty, but the version of GCC on trusty could not | 05:37 |
| aeoril | recognize one of the command line parameters given to it (gcc: error: unrecognized command line option '-fstack-protector-strong') | 05:37 |
| darkxst | aeoril, remove the unrecogonized flags | 05:39 |
| aeoril | darkxst I was going to try it on vivid (I already have a vm set up) to see if it would work | 05:39 |
| aeoril | darkxst then maybe try the trusty command line on vivid to see if it causes a failure. That would perhaps indicate a failure with the build, not the code? | 05:41 |
| darkxst | aeoril, things like -f should affect things to much | 05:42 |
| darkxst | alteast keep any -D's | 05:42 |
| darkxst | (^^ unless its some weird compiler bug, but I think that is unlikely at this stage) | 05:43 |
| aeoril | darkxst so you think I should try without the offending flag on trusty rather than worry about vivid right now? | 05:43 |
| darkxst | your using the command from vivid? | 05:43 |
| aeoril | darkxst yes, I tried the vivid command line from the vivid logs on my trusty machine - ./configure halted with the above error | 05:44 |
| darkxst | aeoril, yes just drop any flags that error | 05:44 |
| staylor | Anyone know what causes a package to refuse to be installed with :arch without attempting to remove the host architecture packages? For example attempting to install libgirepository-1.0-1:armhf on 14.04 causes apt to want to remove the host gir and dependent packages. I'm assuming it has something to do with the package not correctly using /usr/lib/TRIPLET/lib*.so and instead goes directly into /usr/lib/lib*.so yes? | 05:45 |
| aeoril | darkxst should I try real quick to run that command line on my vivid vm? | 05:45 |
| darkxst | aeoril, sure if you want | 05:45 |
| aeoril | darkxst I was thinking I could do that to verify it createst he same --version output as the /usr/bin/vi on vivid (it did so using the trusty command line on trusty) then try compiling the trusty source on vivid with the vivid command line to see if it failed or worked. If it works, I would think it points to a build environment bug not a code related bug ... | 05:49 |
| aeoril | anyway, I am going to bed. Good night | 05:51 |
| darkxst | night | 05:51 |
| mitya57 | pitti: On https://jenkins.qa.ubuntu.com/view/Vivid/view/AutoPkgTest/job/vivid-adt-yade/41/, both i386 and amd64 are successful, but the "global" build is marked as failed | 05:55 |
| mitya57 | Where can I see the reason for failure? | 05:56 |
| pitti | Good morning | 06:28 |
| pitti | mitya57: yeah, jenkins fail :( I had lots of fun with that yesterday already, I'll sort out the rest today (hopefully the queue has caught up) | 06:29 |
| darkxst | hey pitti | 06:29 |
| pitti | hey darkxst, how are you? | 06:32 |
| darkxst | pitti, good, but hiding from the heat again | 06:32 |
| mitya57 | pitti: jenkins says it's fixed now, thanks! | 07:07 |
| dholbach | good morning | 07:37 |
| === work_alkisg is now known as alkisg | ||
| LocutusOfBorg1 | hi all | 08:03 |
| yousry | Hi? | 08:03 |
| === kickinz1|afk is now known as kickinz1 | ||
| LocutusOfBorg1 | dholbach, hi, do you plan to look at the tcl/tk merges I did? | 08:06 |
| LocutusOfBorg1 | :) | 08:06 |
| dholbach | hi LocutusOfBorg1 - today I'm going to be busy with other stuff | 08:07 |
| dholbach | can anyone help LocutusOfBorg1 with the merges? | 08:07 |
| dholbach | it'd be great in any case if folks could help out with http://reqorts.qa.ubuntu.com/reports/sponsoring/ - we're up to 67 items in the queue! | 08:07 |
| LocutusOfBorg1 | no problem :) I also fixed a virtualbox 3d graphic bug, if somebody is interested bug 1351376 | 08:09 |
| ubottu | bug 1351376 in virtualbox (Ubuntu) "3d is not proper working inside a virtualbox guest" [Undecided,Confirmed] https://launchpad.net/bugs/1351376 | 08:09 |
| LocutusOfBorg1 | I didn't convert in a SRU format, I'm waiting for a prior feedback | 08:09 |
| infinity | pitti: Is the gmsh/i386 failure a testbet timeout? | 08:13 |
| infinity | pitti: I'm unclear on what it means when qemu is killed. | 08:13 |
| infinity | pitti: Ditto for lxc. | 08:15 |
| infinity | pitti: And kio | 08:16 |
| infinity | pitti: Or is that a log parser that checks the output and then kills qemu? | 08:17 |
| infinity | pitti: Ahh, I guess the latter in some cases. Not sure how I never noticed that's the last line of these logs. :P | 08:19 |
| dholbach | awe__, barry: Happy birthday! :) | 08:23 |
| alkisg | mvo: hi, did you check if the other 2 bug reports also need sru headers? Do you need help there? | 08:35 |
| mvo | alkisg: hi, sorry that we missed each other yesterday | 08:35 |
| mvo | alkisg: I looked at this yesterday and one bug is actually wrong in the changelog, so I need to reupload | 08:36 |
| alkisg | Ah, ok, do ping me if I can help anywhere :) | 08:36 |
| mvo | alkisg: but yeah, help much appreciated :) | 08:36 |
| mvo | alkisg: I will! | 08:36 |
| alkisg | pitti: could I also help with https://bugs.launchpad.net/gvfs/+bug/453605, e.g. do you want me to mention some specific test case etc? | 08:37 |
| ubottu | Launchpad bug 453605 in udisks2 (Ubuntu) "Make default mount umasks configurable" [Undecided,Confirmed] | 08:37 |
| alkisg | I believe it only involves changing the dmask numbers to 0022, nothing more... | 08:39 |
| alkisg | *err, removing dmask completely, sorry | 08:39 |
| pitti | re | 08:39 |
| pitti | infinity: yeah, we have a few tests which get stuck and then get killed after the timeout | 08:40 |
| pitti | infinity: it took until this morning for jenkins to catch up (and it broke yesterday, too) | 08:40 |
| pitti | infinity: I'll sort out the remaining blockers for glibc | 08:40 |
| pitti | infinity: there's no log parser; adt-run just kills the test after a timeout | 08:40 |
| pitti | alkisg: should be okay, still on my list; just been busy with other stuff so far, sorry | 08:41 |
| alkisg | np, thank you | 08:41 |
| pitti | infinity: and there's a bunch of KDEish things which are actual regressions (but not from glibc) | 08:42 |
| infinity | pitti: I already let glibc in after examining everything by hand. | 08:56 |
| pitti | infinity: ah, ok; I just overrode the failed test resultls for glibc | 08:56 |
| infinity | pitti: A bit late, it was already accepted. :P | 08:57 |
| pitti | infinity: OOI, how did you do this? | 09:04 |
| pitti | infinity: hopefully not in a way to let the regressing packages in (like lxc) | 09:04 |
| pitti | just glibc specific? | 09:04 |
| infinity | pitti: Just let in glibc. | 09:07 |
| infinity | pitti: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/899 | 09:08 |
| pitti | infinity: ah, neat | 09:08 |
| infinity | tumbleweed: Gah. Going through britney hints history. Don't force packages when they stop producing binaries on an arch! | 09:09 |
| infinity | tumbleweed: Either it's a bug that needs fixing, or we can just remove the binary on that arch in the release pocket and it'll slide in without forcing. | 09:10 |
| infinity | tumbleweed: Forcing is far too large a hammer, and lets us raise the uninstallable count, etc. Do not use. | 09:10 |
| infinity | tumbleweed: What you've created is a situation where the binaries are out of sync, which we don't want ever. | 09:11 |
| === vrruiz_ is now known as rvr | ||
| === work_alkisg1 is now known as alkisg | ||
| Mirv | what's happening on PPA:s.. an armhf build that had been running for 3h and about just finished, now reports it was started 6 mins ago :( | 10:05 |
| Mirv | argh | 10:06 |
| Mirv | or since those are archive builders, what's happening on those | 10:07 |
| Mirv | there was also one silent i386 "failed" build, no log | 10:07 |
| ogra_ | Mirv, cjwatson talked about a launchpad-buildd update yesterday ... not sure if that could be related | 10:09 |
| Mirv | maybe that's it then. | 10:14 |
| === Neo31` is now known as Neo31 | ||
| seb128 | wth libtool | 10:26 |
| seb128 | /bin/bash ../../libtool --mode=install /usr/bin/install -c libgbtgeoclue.la '/tmp/install/usr/lib/gnome-bluetooth/plugins/' | 10:27 |
| seb128 | libtool: install: error: cannot install `libgbtgeoclue.la' to a directory not ending in /usr/lib/gnome-bluetooth/plugins/ | 10:27 |
| seb128 | 10:27 | |
| darkxst | seb128, speaking of -bluetooth any progress on bluez5? | 10:27 |
| seb128 | darkxst, not much, the touch team still have an item to look at their kernel | 10:28 |
| seb128 | and larsu is going to pick up looking at indicator-bluetooth and unity-control-center | 10:28 |
| seb128 | since robert_ancell did start on that but let it half done | 10:28 |
| didrocks | darkxst: rsalveti is away until tomorrow, I plan to ping him back to get some updates on this (their team has an item for this iteration before feature freeze) | 10:29 |
| darkxst | seb128, still on target to land this cycle though? | 10:29 |
| diwic | PA 6.0 is not out in a stable release yet | 10:29 |
| seb128 | darkxst, it's not under my control so unsure about that | 10:29 |
| diwic | I was about to release it the other week but then a new discussion about the bluez 5 implementation came around | 10:30 |
| didrocks | diwic: but we'll push that version nevertheless, that's what we agreed at vUDS, right? (it's close to be RC) | 10:30 |
| darkxst | seb128, probably no one wants to control that mess, hence the delays getting it in I guess | 10:30 |
| diwic | didrocks, if you ask me, I think we could push 6.0rc3 as it is into vivid today - the further, the more wide-scale testing we get | 10:30 |
| seb128 | darkxst, well, in fact supervision has been going fine, it's just identified items that need work | 10:30 |
| didrocks | diwic: agreed, and some other distros are shipping it already it seems | 10:30 |
| seb128 | hopefully that happens before ff | 10:31 |
| diwic | didrocks, interesting, which ones? | 10:31 |
| didrocks | I guess I saw it on fedora 21 | 10:31 |
| didrocks | diwic: I need to recheck though | 10:31 |
| diwic | ok | 10:31 |
| seb128 | diwic, is the new pulse depending on the new bluez, or could we already push it? | 10:31 |
| diwic | seb128, PA 6.0 supports bluez 4 as well - that said, I think most testing has been done on bluez 5 because that's the new and shiny | 10:32 |
| diwic | seb128, but yes, I believe we could push it before the rest of bluez 5 goes in | 10:32 |
| seb128 | diwic, asked differently, what is blocking uploading pa 6 then? | 10:32 |
| darkxst | seb128, ok again probably out of the loop | 10:32 |
| diwic | seb128, IMO, nothing really. | 10:33 |
| seb128 | diwic, just do it then? ;-) | 10:33 |
| diwic | seb128, agreed. Just want to sync that up with Luke first | 10:34 |
| cjwatson | Mirv: The buildds will have been restarted this morning for upgrades, indeed. Sorry for the inconvenience. I'd asked that I be around for the non-virt upgrades but that apparently didn't happen | 10:35 |
| darkxst | seb128, my timezone is pretty whacko compared to all else except robert | 10:35 |
| seb128 | darkxst, yeah, I know | 10:36 |
| cjwatson | (When I'm around, I try to take care to schedule the upgrades around long-running builds) | 10:36 |
| seb128 | darkxst, in that case robert_ancell was the one that needed nudging, he started on porting the indicator and u-c-c, but he stopped and that was stalled work for a while | 10:36 |
| seb128 | darkxst, it has been handed over to larsu now though | 10:37 |
| darkxst | seb128, ok, maybe we could setup a short Ubuntu GNOME meeting each week? | 10:38 |
| seb128 | darkxst, up to Ubuntu GNOME to decide if you guys want a meeting I guess? | 10:39 |
| darkxst | seb128, Well I and Jackson can't attend the ubuntu-desktop meetings | 10:40 |
| seb128 | darkxst, you can read the log and comment the next day or on the list if you want | 10:41 |
| seb128 | but sure, having a small meeting in the european morning would work as well | 10:41 |
| darkxst | and seems pretty regularly left out of the loop | 10:41 |
| darkxst | seb128, logs fade away, meetings would probably be far easy easier | 10:44 |
| seb128 | what would be the goal of the meeting? | 10:44 |
| seb128 | you don't want to move the main ubuntu-desktop meeting right? | 10:44 |
| seb128 | but add a smaller one/with a different set of people? | 10:44 |
| darkxst | seb128, unless you want to move the ubuntu-desktop meeting ;) | 10:45 |
| seb128 | we don't | 10:45 |
| seb128 | we have U.S team members | 10:46 |
| seb128 | well, up to willcooke I guess | 10:46 |
| darkxst | seb128, mainly to keep us posted on things, mostly updates are not communicated back to our team, unless we are working on the packages | 10:46 |
| darkxst | bluez5, nm 0.9.10, etc | 10:47 |
| seb128 | well, you could as easily the log from the main meeting | 10:47 |
| seb128 | not sure what's the point to make people join another meeting to repeat the same info | 10:48 |
| seb128 | when you can browse through the log | 10:48 |
| === _salem is now known as salem_ | ||
| darkxst | seb128, likely because we may have different questions | 10:48 |
| seb128 | darkxst, you can ask question any day on #ubuntu-desktop though | 10:51 |
| seb128 | well, if you think a meeting would be useful just set up one | 10:51 |
| seb128 | I'm happy to join and we can see if it's turn out to be useful or not | 10:51 |
| seb128 | if it's not we can still dismiss | 10:51 |
| darkxst | seb128, ok I will check with the others | 11:03 |
| === alkisg is now known as work_alkisg | ||
| === oSoMoN_ is now known as oSoMoN | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === jpds is now known as Guest49936 | ||
| pitti | jamespage: hm, the nova autopkgtest regression appears to be real | 13:19 |
| jamespage | pitti, yeah - looking at that - probably eventlet related - I just bumped a new version in | 13:33 |
| jamespage | pitti, that may resolve itself with the kilo-2 release we're working on | 13:33 |
| pitti | jamespage: yes, that's what britney blames it on (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html) | 13:33 |
| willcooke | seb128, happy for there to be a Ubuntu Gnome meeting, but I would rather not move the Desktop Weekly, not least because my other meetings are around it and finding a new slot would be hard | 13:34 |
| === MacSlow|lunch is now known as MacSlow | ||
| === pgraner-afk is now known as pgraner | ||
| barry | dholbach: thanks! and awe__ hbd my 2-10 bruthah! | 14:27 |
| RichiH | as upstream and debian package maintainer, what's the best way to get https://bugs.launchpad.net/ubuntu/+source/vcsh/+bug/1352280 fixed? | 14:33 |
| ubottu | Launchpad bug 1352280 in vcsh (Ubuntu) "typo when setting default VCSH_HOOK_D" [Undecided,New] | 14:33 |
| cjwatson | RichiH: if you fix it in the next nine days or so in unstable it'll autosync into vivid. if you want to help fix it in stable releases too, that's https://wiki.ubuntu.com/StableReleaseUpdates | 14:34 |
| cjwatson | oh, I see it's already fixed in vivid? | 14:35 |
| cjwatson | (unstable) | 14:35 |
| cjwatson | so just the SRU page above then | 14:35 |
| RichiH | cjwatson: yah, it's been fixed for some time now | 14:38 |
| RichiH | SRU =~ backports? | 14:38 |
| rbasak | RichiH: no, it's a stable release update. For bugfixes, rather than feature backports. It'll end up in trusty-updates and users generally receive these updates automatically. | 14:40 |
| RichiH | ok, that seems to fall under "Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel)." | 14:40 |
| rbasak | RichiH: yeah - it should be fine to SRU that I think. See the Procedure section. I'll do step 4 for you now. | 14:40 |
| cjwatson | RichiH: analogous to stable updates in Debian | 14:41 |
| RichiH | cjwatson: yah; only simpler to get into | 14:42 |
| Saviq | cyphermox, hey, I still can't pair with my car (bug #1362694), can I get any debug info to help fixing that? | 15:04 |
| ubottu | Error: Launchpad bug 1362694 could not be found | 15:04 |
| Saviq | huh, bug private? | 15:04 |
| Saviq | bug #1362694 | 15:06 |
| ubottu | bug 1362694 in bluez (Ubuntu) "Can't pair with car kit (reverse mode)" [Undecided,New] https://launchpad.net/bugs/1362694 | 15:06 |
| Saviq | better | 15:06 |
| cyphermox | Saviq: just make sure to add /var/log/syslog (with debug logs from bluez if possible, that's done by adding -d to the command line for bluetoothd), and the logs from ubuntu-system-settings | 15:06 |
| Saviq | cyphermox, ok, I'll do that now | 15:07 |
| slangasek | tkamppeter: wasn't so much around, no. did you still need something from me? | 15:19 |
| seb128 | slangasek, hey | 15:32 |
| seb128 | slangasek, since you are around, I'm curious on what's the status of the systemd transition? | 15:32 |
| tkamppeter | slangasek, can you reject the CUPS package for the Trusty SRU of bug 1386241, so that the Trusty SRU of bug 1352809 can be done first? Thanks. | 15:34 |
| ubottu | bug 1386241 in system-config-printer (Ubuntu Trusty) "Add the full IPP Everywhere support from Utopic to Trusty" [High,Triaged] https://launchpad.net/bugs/1386241 | 15:34 |
| ubottu | bug 1352809 in cups (Ubuntu Utopic) "/usr/bin/lp on Trusty using -h option doesn't work as expected" [Medium,In progress] https://launchpad.net/bugs/1352809 | 15:34 |
| yousry | Hi | 15:35 |
| slangasek | seb128: hi! status should be all in the blueprint; the outstanding blockers that I'm aware of are console-setup+initramfs-tools merge and nfs-utils systemd support | 15:35 |
| slangasek | seb128: https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration | 15:35 |
| seb128 | slangasek, do you know if anyone is working on those? | 15:35 |
| seb128 | slangasek, nfs-utils seems assigned to you :-) | 15:36 |
| slangasek | seb128: I'm working on the first one, the second is in the "backlog" | 15:36 |
| seb128 | how is that work going? ;-) | 15:36 |
| slangasek | seb128: it will be done this week | 15:36 |
| seb128 | slangasek, great to read, thanks! | 15:36 |
| yousry | Is this the right place to ask a question about app-store submissions? | 15:40 |
| Mirv | cjwatson: arm64, powerpc and ppc64el builds aborted by itself now. and arm64 for the second time too. just FYI, I'm EOD. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+build/6963104 | 15:41 |
| Mirv | I got the previous package fully built, though, so mostly good | 15:41 |
| Mirv | but telling just in case it was thought any buildd upgrades were finished and working | 15:43 |
| Mirv | amd64, armhf and i386 seem to so far work | 15:43 |
| Mirv | wow, the queues are in tens of thousands of jobs | 15:44 |
| cjwatson | infinity: Are you upgrading the arm64 and ppc64el builders at the moment? | 15:44 |
| cjwatson | Mirv: There's a test rebuild in progress, hence the high job count. | 15:44 |
| Mirv | ok, right | 15:45 |
| cjwatson | infinity: If not, you might want to look into the above. All I can see is that buildd-manager got BUILDERFAIL from the slave. | 15:45 |
| cjwatson | But e.g. templar is apparently still up. | 15:45 |
| cjwatson | Mirv: All the test-rebuild build records are scored <0, so anything real will be dispatched first. | 15:46 |
| cjwatson | I wish I had a way to get the raw build slave log. OTOH that will become useless once everything's in scalingstack anyway ... | 15:47 |
| yousry | Can I upload a deb-package instead of a deb-src package to the app-store? It seems that your dpkg-shlibdeps script fails to recognize the -l (-ldirectory) option for packed libs. | 16:03 |
| ogra_ | yousry, no, the ubuntu archive only allows source packages | 16:03 |
| yousry | Is there a workaround for the missing -l option in dpkg-shlibdeps? I don't see another pssibility to indicate internal (packed) libraries? | 16:06 |
| pitti | yousry: I don't understand this; what should that option do and why is it missing? | 16:08 |
| Unit193 | Perhaps he should be looking into d/control deps line? | 16:08 |
| pitti | yousry: if your package has internal libs, they must not have shlibdeps; and if it has external libs they shoudl be in the proper search dirs? | 16:09 |
| pitti | besides, it does have an -l option | 16:09 |
| yousry | pitty, I got this feedback from the reviewer: dpkg-shlibdeps: unknown option `-ldebian/memorytheminorplanets/opt/memorytheminorplanets' but this option works on my system. | 16:10 |
| yousry | pitti, also I only reference systemlibs with shlibdeps | 16:16 |
| yousry | pitti, I just checked the script source-code. I found this option and cannot understand why the revierer got this error message. | 16:19 |
| pitti | yousry: I don't either; but why do you need shlibdeps in the first place? | 16:19 |
| === roadmr is now known as roadmr_afk | ||
| yousry | pitti, I followed the debian docs. I referenced vorbis, alut and some other libs. | 16:22 |
| cjwatson | infinity: Hm, might have been a network glitch. We got builderfail from most of 1SS at the same time. | 16:25 |
| rbasak | Minified JS without original source is still unacceptable in a source package and the source package must be repacked in this case, right? | 16:41 |
| rbasak | Also, is it a hard requirement to use libjs-jquery instead of an upstream shipped jquery? I can't find any reference to this to point someone to. Is there one, please? | 16:42 |
| pitti | rbasak: lintian complains about that | 16:43 |
| pitti | rbasak: depends on the license | 16:43 |
| rbasak | Ah, thanks. I see the tag description refers to policy "Convenience copioes of code". | 16:44 |
| pitti | rbasak: GPL and similar require including the preferred form of modification | 16:44 |
| rbasak | Which is a should, not a must. | 16:44 |
| pitti | rbasak: BSD and similar don't, for those you can ship any binary crap you like | 16:44 |
| pitti | it's not "nice" of course, but at least technically accepted by the license | 16:44 |
| rbasak | This is for jquery, which I think is BSD-alike. | 16:44 |
| rbasak | I just want to know what to require from a contributor before I upload. | 16:44 |
| pitti | code copies are generally frowned upon by archive admins regardless of the license | 16:45 |
| rbasak | Understood, and I can relay that. I was hoping for a hard policy requirement as it's easier for me to require it fixed then, but it does help that you confirmed it will be flagged - thanks. | 16:46 |
| === work_alkisg is now known as alkisg | ||
| tumbleweed | infinity: I *did* wonder what people would think :P (and was careful not to break anything, except requiring NBS cleanup). Next time I'll request archive-admin arch-specific removal | 16:57 |
| Odd_Bloke | Where is the ubuntu-core task used in http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/config#L361 defined? | 16:58 |
| pitti | tjaalton: btw, did anything come out of your investigation how to drop libopenvg1-mesa-dev from qtbase-opensource-src{,-gles}? | 16:59 |
| pitti | (or reintroducing openvg if Qt/KDE/touch wants it) | 16:59 |
| === roadmr_afk is now known as roadmr | ||
| tjaalton | pitti: no it's gone upstream, those pkgs just can't build against it anymore | 17:03 |
| tjaalton | did I not upload fixes? | 17:03 |
| pitti | apparently not :) | 17:04 |
| tjaalton | hrm | 17:04 |
| pitti | tjaalton: dropping the build deps should technically work (it's [!hurd]), configure detects its presence; I just don't know what kind of functionality this brings (or loses, rather) | 17:04 |
| === rickspencer3_ is now known as rickspencer3 | ||
| tjaalton | nothing should use it aiui, it's just extra | 17:05 |
| tjaalton | changelog didn't mention why it was enabled | 17:05 |
| tjaalton | other than upstream adding support for it | 17:05 |
| pitti | tjaalton: ah, good | 17:06 |
| tjaalton | svuorela from debian is aware of this too | 17:08 |
| tjaalton | so it should get fixed there soon, if not already | 17:08 |
| hallyn | arges: is systemd safe to assume to be installed on all systems? | 17:10 |
| hallyn | arges: oh, nm. i see you're checking for it | 17:10 |
| arges | hallyn: no. that's why I check for it; but i didn't want to dep on it | 17:10 |
| hallyn | hm, so what about dmidecode? | 17:11 |
| arges | hallyn: yea i'm not depping on that either... if that command fails though it just doesn't detect if we are on a VM | 17:12 |
| tjaalton | will systemd get enabled before FF, or can a pkg depend on it being pid 1? | 17:12 |
| arges | hallyn: well unless it catches it on dmesg | 17:12 |
| hallyn | tjaalton: that would be the systemd-sysv package; i'm only looking for systemd | 17:13 |
| hallyn | arges: well ubuntu-standard depends on dmidecode. is ubuntu-standard on all our flavors? | 17:14 |
| tjaalton | hallyn: yeah that was a general question :) | 17:14 |
| hallyn | (i agree it's "ok" if it's not installed the way you have it; jus ta bit fugly) | 17:14 |
| hallyn | tjaalton: i suspect it'll be after FF that it gets enabled by default | 17:15 |
| arges | hallyn: i mean... technically one could install ubuntu-minimal or other flavors... | 17:15 |
| hallyn | tjaalton: there are still a few blockers, including juju | 17:15 |
| arges | hallyn: so we could add another check for that command | 17:15 |
| tjaalton | and nfs-common | 17:15 |
| hallyn | right | 17:15 |
| tjaalton | it's the only blocker for syncing freeipa | 17:15 |
| hallyn | oh, the other thing, is VM_SEARCH##*$vm_string* a bash-ism or ok in dash? | 17:16 |
| arges | hallyn: i tested iwth /bin/sh, but I need to check if my env has bash set or not | 17:17 |
| cjwatson | hallyn: portable | 17:17 |
| hallyn | cool, thx | 17:18 |
| hallyn | heh actually it'd be saner for me to ask smoser to look at it than me to try to :) | 17:19 |
| hallyn | arges: yeah should be fine a sis; i'll take the patch as is now unless you are dying to make a change | 17:21 |
| arges | hallyn: no. I think it will work for now. let's let it bake into vivid for a bit before thinking about SRUs | 17:22 |
| rbasak | install: error writing ‘/tmp/adt-virt-lxc.shared.vo8ox3o3/downtmp/build.t2I/mysql-5.6-5.6.22/debian/tmp//usr/lib/mysql/libmysqld_pic.a’: No space left on device | 17:24 |
| hallyn | arges: ok, doing one more test build in ppa:ubuntu-virt/candidate (all tests passed this morning) then pushing to archive | 17:24 |
| rbasak | pitti: ^^ any chance I can get it to use something other than /tmp? TMPDIR? | 17:24 |
| rbasak | pitti: I'm not sure that /tmp is suitable for multi gigabytes of stuff. Current working directory would be better maybe here. Debatable I guess. | 17:25 |
| rbasak | In this case apparently 3.9G isn't enough. | 17:25 |
| rbasak | TMPDIR didn't seem to work. | 17:26 |
| rbasak | My mistake. TMPDIR does work if it exists. | 17:30 |
| slangasek | tkamppeter: bug #1352809, the package was already removed from trusty on Dec 12 per your request and this is documented in the bug... | 17:30 |
| ubottu | bug 1352809 in cups (Ubuntu Utopic) "/usr/bin/lp on Trusty using -h option doesn't work as expected" [Medium,In progress] https://launchpad.net/bugs/1352809 | 17:30 |
| slangasek | tkamppeter: sorry, I mean bug #1386241 | 17:30 |
| ubottu | bug 1386241 in system-config-printer (Ubuntu Trusty) "Add the full IPP Everywhere support from Utopic to Trusty" [High,Triaged] https://launchpad.net/bugs/1386241 | 17:30 |
| alexbligh1 | rbasak, any movement on https://bugs.launchpad.net/ubuntu/trusty/+source/apache2/+bug/1366174 ? Any chance of the fix getting merged for 14.04.2? | 17:33 |
| ubottu | Launchpad bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,Triaged] | 17:33 |
| rbasak | alexbligh1: I think I'll have time in the next few days, but with everything going smoothly I don't think it'll get through SRU verification in time to make 14.04.2, sorry. | 17:34 |
| rbasak | alexbligh1: I'm not sure it should matter that much though. Users would update apache2 from trusty-updates, no? | 17:35 |
| alexbligh1 | rbasak, well, the sooner the better. My concern is more that if 14.04.2 has other fixes in for apache2, my fixed version is going to get overwritten on customer sites. | 17:35 |
| alexbligh1 | rbasak, is there some way to find out if other stuff is queued? | 17:36 |
| rbasak | alexbligh1: https://launchpad.net/ubuntu/+source/apache2 will show you current status. | 17:36 |
| rbasak | alexbligh1: http://people.canonical.com/~ubuntu-archive/pending-sru.html shows you SRUs in flight. Normal updates will be on this page for at least seven days before landing in trusty-updates. | 17:37 |
| lamont | how many times are we planning to break upgrades for python-oslo packages? | 17:37 |
| smoser | hallyn, what did you need from me ? | 17:37 |
| rbasak | alexbligh1: security updates are probably your biggest risk, since they go through urgently, often without warning (responsible disclosure, etc) | 17:37 |
| smoser | lamont, 2 more. but thats it. :) | 17:37 |
| lamont | smoser: Lp | 17:37 |
| smoser | i'm happy to know that i'm not the only one using vivid and upgrading daily. | 17:38 |
| rbasak | alexbligh1: but that's outside the 14.04.2 and other point release milestones, really. The point releases are mainly about the installer, and what users get before they update. | 17:38 |
| alexbligh1 | rbasak, ok so the first one shows 2.4.7-1ubuntu4.1 is the latest version (as per packages.ubuntu). The second shows no SRUs pending for apache. So I just need to worry about security updates, and 14.04.2's release adds/removes nothing there? | 17:39 |
| hallyn | smoser: was going to ask you to look at https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1414153/+attachment/4315925/+files/lp1414153-vivid.debdiff , but i've gone ahead and taken it, so nm | 17:39 |
| ubottu | Launchpad bug 1414153 in qemu (Ubuntu) "qemu should not enable KSM on nested guests" [High,In progress] | 17:39 |
| hallyn | smoser: i've always been on the release distro; except i've been on crappy networks this cycle so couldn't afford the updates. so i'm on utopic :( i'll upgrade this afternoon | 17:40 |
| rbasak | alexbligh1: correct. 14.04.2 will only include what is already published in trusty-updates and trusty-security at the time the release is rolled. | 17:40 |
| smoser | hallyn, my comments there... | 17:40 |
| smoser | a. dmesg can't be relied upon for anything dude to buffer. | 17:41 |
| smoser | dmidecode is likely to be dropped (its not in snappy) in favor of /sys/class/dmi | 17:41 |
| smoser | VM_SEARCH##$vm_string* | 17:42 |
| smoser | probably doesnt need the last '*' . i think that can only mess things up. | 17:42 |
| hallyn | arges: ^ | 17:42 |
| smoser | and then the other thing, is that i would never bohter with full paths on checcking for executables. | 17:42 |
| smoser | (and i think doing '-f /usr/bin/systemd-detect-virt' is bad logic anyway, you'd want '-x') | 17:43 |
| alexbligh1 | smoser, hallyn - and whilst I look at this, why the need for sudo in a .postinst? (for my own interest) | 17:43 |
| hallyn | uh, none | 17:43 |
| smoser | that is odd, isnt it :) | 17:43 |
| arges | this is good feedback | 17:43 |
| hallyn | thanks gusy | 17:43 |
| hallyn | guys | 17:43 |
| * hallyn biab | 17:43 | |
| smoser | but my full path argument i think is probably not really valid. as i think lots of debian things hard code paths for whatever reason | 17:44 |
| smoser | (even though PATH is safe in an upstart script) | 17:44 |
| arges | smoser: so I can just remove the dmesg checking... but the biggest issue is that vm detection is just spotty.. so i'm trying a few things to get a reasonable idea if we're running in VM | 17:44 |
| smoser | yeah. i know. | 17:44 |
| === alkisg is now known as work_alkisg | ||
| smoser | i guess it doesn't hurt. | 17:45 |
| arges | smoser: i'll drop dmidecode to use /sys/class/dmi/* | 17:45 |
| arges | that seems like an easy fix | 17:45 |
| alexbligh1 | Also: sed -i 's/KSM_ENABLED=1/KSM_ENABLED=0/' /etc/default/qemu-kvm; | 17:45 |
| alexbligh1 | ^- isn't that going to mean if you upgrade qemu later, it's not going to upgrade the conffile? | 17:46 |
| smoser | yeah. | 17:46 |
| arges | alexbligh1: so this is the issue i have... | 17:46 |
| alexbligh1 | You might be better changing the init script to work this out rather than modify the /etc/default ... | 17:46 |
| smoser | right. | 17:46 |
| arges | i want to change the default /etc/default/qemu-kvm before the daemon restarts | 17:47 |
| smoser | i tihkn he's right. | 17:47 |
| smoser | change the init script (is there one ?) | 17:47 |
| smoser | to do the right thing. | 17:47 |
| arges | so if I change the upstart script, it just checks the /etc/default/qemu-kvm configuration | 17:47 |
| arges | to determine if KSM should be enabled or not | 17:47 |
| smoser | the rason being, if we built an image on bare metal and then ran the image in a vm, your logic is not used | 17:48 |
| smoser | and vice versa | 17:48 |
| arges | presumably a user could modify that on their own too | 17:48 |
| smoser | ie, fast path install takes a cloud image, built in a kvm vm | 17:48 |
| alexbligh1 | arges, what I'd suggest is override the value of KSM_ENABLED if you discover (in the init script / upstart script) you are on a VM. | 17:48 |
| smoser | and spits it to disk on a "real hardware" | 17:48 |
| smoser | and it'd have your bad value of off. when youd' want it on. | 17:48 |
| smoser | i agree with alexbligh1 | 17:49 |
| arges | alexbligh1: see that seemed bad to me... then what if a user actually wants KSM enabled in their nested VM? | 17:49 |
| smoser | not override it by runtime logic. | 17:49 |
| smoser | er.... | 17:49 |
| smoser | allow the user to turn it on or off or 'auto' | 17:49 |
| smoser | and default 'auto' | 17:49 |
| arges | is there a way i could modify etc/default/qemu-kvm _before_ it gets installed? | 17:49 |
| alexbligh1 | arges, OK, then add KSM_ENABLED_IN_VM=0 as a default in /etc/default/qemu-kvm, and if you find you are running in a VM, set KSM_ENABLED to KSM_ENABLED_IN_VM | 17:49 |
| alexbligh1 | arges, or just change the code that looks at KSM_ENABLED to look at KSM_ENABLED or KSM_ENABLED_IN_VM as appopriate | 17:50 |
| arges | hmm | 17:51 |
| arges | I think having KSM_ENABLED='auto' might make sense as smoser suggested. Then 'auto' is let the init script decide, otherwise respect the value set there | 17:51 |
| arges | it seems a bit 'cleaner' | 17:52 |
| tkamppeter | slangasek, but I do not succeed to upload the package of the new bug (which has the same release number). Should I simply bump the number by one? | 17:53 |
| alexbligh1 | arges, that also works. | 17:53 |
| arges | smoser: alexbligh1 thank you both for the feedback. I'll work on v2 today : ) | 17:53 |
| slangasek | tkamppeter: yes, you can't reuse a version number once it's been in the archive. | 18:01 |
| hallyn | smoser: will /sys/class/dmi be supported in precise's kernel? | 18:11 |
| tkamppeter | slangasek, thanks, I will re-upload with a new version number. | 18:24 |
| hallyn | arges: eta on your patch? < 3 hrs? | 18:47 |
| arges | hallyn: i could prioritize it | 18:48 |
| === kickinz1 is now known as kickinz1|afk | ||
| hallyn | arges: just trying to decide whether to push as is or wait for it | 18:53 |
| tkamppeter | caribou, I hace uploaded the Trusty SRU now, as cups 1.7.2-0ubuntu1.4. I had to bump the release number, as 1.3 was already used by another withdrawn SRU. | 18:56 |
| tkamppeter | slangasek, with bumped version number the upload worked. Thanks. | 18:57 |
| arges | hallyn: no don't push the version i have wait for v2 | 19:01 |
| hallyn | arges: ok (i could've pushe dit without your v1 :) but i'll wait, thx) | 19:06 |
| arges | hallyn: actually go ahead and push without my change, i'd rather not be hasty about this change | 19:07 |
| hallyn | arges: ok. | 19:20 |
| aeoril | darkxst sarnold cjwatson I am going to go ahead and make an sbuild environment on a new virtual machine at this point. I need to learn that skill anyway, and I think for this bug in particular it is important to have a build environment as close to that as was used in the release builds, which the docunentation says is one plus of sbuild | 19:38 |
| aeoril | I think it will also make my testing go faster once I have set it all up, and not be all gunky | 19:39 |
| sarnold | aeoril: feel free to make hte sbuild environment on your 'nice' machine in a permenant spot | 19:39 |
| aeoril | sarnold I am going to make a new virtual machine for it - it will become my "nice" machine. I assume I can use trusty and still build for other environments, like 14.10 and 15.04? | 19:41 |
| aeoril | that is the whole point, isn't it? | 19:41 |
| sarnold | aeoril: yeah, my trusty laptop does builds for lucid, precise, trusty, utopic, vivid, no trouble :) | 19:41 |
| aeoril | sarnold yes, that sounds great - I like the double entendre there "my trusty laptop ... " :) | 19:42 |
| sarnold | aeoril :D | 19:42 |
| robert_ancell | bdmurray, hey, the unity-greeter SRU is being held up due to "increased daily rate of errors". Looking at e.u.c the only significant errors I can see are https://errors.ubuntu.com/problem/5cb4c18c3fc57c4a33a0a31461bef0cc992a7f0b and https://errors.ubuntu.com/problem/7a0ce14fab00948fce6fe9a4f17cf9947b4d6fe1. I think these are existing problems that haven't increased since the update. Is there anything else I might have missed? | 19:42 |
| bdmurray | robert_ancell: that has started phasing again | 19:43 |
| robert_ancell | bdmurray, oh, thanks! | 19:43 |
| aeoril | sarnold I have an older PC running trusty - I can blow it away and make it my "nice" machine - would that be better than a vm for long-term development? It cannot support vms because it is older hardware, but I do not think I need to worry about that for an sbuild environment, do I? Also, not sure which is best to test on - older hardware on bare metal or newer hardware in vms ... I | 19:45 |
| aeoril | guess I could set up both, really, not either/or | 19:45 |
| sarnold | aeoril: depends how often you want to build things; I want it on my best build box because I build things often. | 19:45 |
| aeoril | sarnold I hope to do a lot of development for Ubuntu, so I would be building often. But, I must support my wife with my main unfortunately at this time so it is not available for an Ubuntu build environment (I cannot "play" with it except in vms) ... | 19:47 |
| RichiH | rbasak: just so i understand what you did in https://bugs.launchpad.net/ubuntu/+source/vcsh/+bug/1352280 : you simply pulled in a fixed version from another release? | 19:48 |
| ubottu | Launchpad bug 1352280 in vcsh (Ubuntu Trusty) "typo when setting default VCSH_HOOK_D" [Undecided,New] | 19:48 |
| aeoril | sarnold I will go ahead and learn sbuild on a vm on my main so I can easily work through making mistakes, then go ahead and worry about doing it on my regular trusty PC if/when I need to | 19:49 |
| sarnold | aeoril :) | 19:49 |
| === Spads_ is now known as Spads | ||
| aeoril | sarnold btw, vmware is fantastic ... | 19:57 |
| aeoril | sarnold pm? | 19:58 |
| sarnold | aeoril: sure | 19:59 |
| brendand | anyone seen Xorg crashing whenever chromium/chrome are launched? this is on vivid with the latest kernel. intel haswell graphics | 20:05 |
| === salem_ is now known as _salem | ||
| brendand | gah - habitual clicking on chromium... | 20:08 |
| sarnold | brendand: you didn't miss anything while you were gone | 20:11 |
| === roadmr is now known as roadmr_afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| ahoneybun | balloons: how often should I test the vivid next images? | 20:44 |
| balloons | ahoneybun, if you are interested in following along on a regular basis you have a couple options. You can use the lxc container and update it, or you can run vivid and install the packages (and update vivid) | 20:45 |
| balloons | ahoneybun, as far as how often, that depends on what you are after. If you want some larger changes between each test you'll need to wait longer ofc. | 20:46 |
| ahoneybun | balloons: I dont see any updates in the system settings | 20:46 |
| balloons | ahoneybun, right, you have to update it via https://wiki.ubuntu.com/Unity8inLXC#Maintaining_your_unity8_installation | 20:47 |
| ahoneybun | balloons: cool the main issues are touchpad and resizing but I imagine those are in the pipes already | 20:48 |
| === kickinz1 is now known as kickinz1|afk | ||
| balloons | ahoneybun, touchpad? | 20:51 |
| === rcj is now known as Guest25083 | ||
| ahoneybun | yea it was on a laptop balloons | 20:53 |
| ahoneybun | bbl | 20:54 |
| balloons | yes, I meant what issues? did you file a bug? | 20:54 |
| === kickinz1|afk is now known as kickinz1 | ||
| === roadmr_afk is now known as roadmr | ||
| === pgraner is now known as pgraner-afk | ||
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| arges | hallyn: ok v2 is posted bug 1414153 | 21:34 |
| ubottu | bug 1414153 in qemu (Ubuntu) "qemu should not enable KSM on nested guests" [High,In progress] https://launchpad.net/bugs/1414153 | 21:34 |
| hallyn | arges: ok, thx. i shoulda waited then :) will wait to look at it tomorrow | 21:36 |
| === kickinz1 is now known as kickinz1|afk | ||
| arges | hallyn: take your time. i'd rather not screw it up | 21:39 |
| rbasak | RichiH: no, I just updated the bug status to represent that it is fixed in Vivid, but not in Trusty. That's what I understood from what you said? | 22:01 |
| === bluesabre is now known as elty | ||
| === elty is now known as bluesabre | ||
| cjwatson | pitti: FYI Distribution should now be accurate in ddebs.txt: https://bugs.launchpad.net/launchpad-buildd/+bug/1348077 | 22:44 |
| ubottu | Launchpad bug 1348077 in launchpad-buildd "buildd slave config hardcodes --archive=ubuntu" [High,Fix released] | 22:44 |
| cjwatson | Probably too late to matter, but :) | 22:44 |
| rbasak | RichiH: you'll still need to follow the other steps in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure please. It's easier for you to do it since you know the package. | 22:46 |
| tkamppeter | I have a question about whether a package is in Main or in Universe. I is openjpeg. On https://launchpad.net/ubuntu/+source/openjpeg it says "Component: Main" but for the individual releases (for Vivid, Utopic, ...) it says Universe. What is correct? And if it is in Universe, what does the "Component: Main" at the top mean? | 23:55 |
| dobey | tkamppeter: apt-cache policy says universe on trusty | 23:56 |
| dobey | tkamppeter: maybe it's approved for main, but nothing ever seeded the binaries? | 23:57 |
| sarnold | tkamppeter: I believe 'rmadison -S openjpeg' is the best way to discover which binary packages are in main vs universe | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!