| === superm1_ is now known as superm1 | ||
| === _salem is now known as salem_ | ||
| === timrc is now known as timrc-afk | ||
| === salem_ is now known as _salem | ||
| pitti | Good morning | 05:15 |
|---|---|---|
| RAOF | Aloha pitti! | 05:19 |
| pitti | hey RAOF, how are you? | 05:21 |
| RAOF | Within acceptable parameters :) | 05:22 |
| RAOF | Yourself? | 05:22 |
| * RAOF has recently learnt that <fn>+1 toggles the fans on his laptop into maximum-speed mode. | 05:22 | |
| sarnold | should they do that? :) | 05:23 |
| RAOF | It's apparently a secret firmware feature :) | 05:23 |
| RAOF | ie: It's deliberate, and it is just turning the fans on without increasing CPU load. | 05:24 |
| sarnold | nice! :) | 05:24 |
| RAOF | Huh. GTK links to libcolord1 it seems. | 05:25 |
| === work_alkisg is now known as alkisg | ||
| pitti | RAOF: I went to Taekwondo again after a 6 week break due to my wrist; I feel that everywhere now :) but quite fine, thanks | 05:29 |
| RAOF | Oooh :) | 05:29 |
| RAOF | Looks like it's time to prepare a libcolord transition. | 05:30 |
| === FJKong_afk is now known as FJKong | ||
| === alkisg is now known as work_alkisg | ||
| dholbach | good morning | 06:34 |
| Mirv | slangasek: hey. it seems your Debian merge of libsdl1.2 dropped the tearing fix patch (in other words, the 1.2.15-8ubuntu2 upload) that was in utopic and is proposed for trusty too. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/libsdl1.2/utopic/revision/48 | 06:43 |
| * mpt wonders why 100% CPU is being used by “init --user” | 07:13 | |
| mpt | I guess killing that process would be a bad idea | 07:22 |
| RAOF | That does seem likely. | 07:22 |
| mardy | cjwatson: hi! Do you remember what's the state of https://code.launchpad.net/~mardy/click/lp1245826/+merge/204674? Do you have some work already done, or is it better if I start re-implementing it on top of the latest trunk? | 07:23 |
| pitti | xnox, slangasek: I just mailed u-devel@ wrt. moving to insserv or not; comments appreciated | 07:42 |
| cjwatson | mardy: I have a fair amount of work done on translating it; sorry for not keeping you updated | 07:56 |
| cjwatson | mardy: I've been doing Launchpad work lately so put it on the shelf for a while, but I think you can still safely consider it on my plate | 07:56 |
| cjwatson | mardy: (I've basically done the translation, but I still need to sort out the handling of hook removals) | 07:59 |
| mardy | cjwatson: cool, thanks! | 08:01 |
| xnox | mpt: (a) it shouldn't (b) killing it should be fine, it would respawn (c) not sure how to get info as to why it's doing that. | 08:17 |
| caribou | xnox: I got a question for you if you're familiar with ubiquity | 08:19 |
| caribou | or to whoever else is | 08:19 |
| xnox | caribou: sure. | 08:19 |
| caribou | xnox: I got a reinstall issue over the weekend where the 'apt-clone' portion of the reinstall bailed out on me | 08:19 |
| caribou | xnox: let me dig the bug I opened | 08:20 |
| caribou | xnox: bug 1316032 | 08:20 |
| ubottu | bug 1316032 in ubiquity (Ubuntu Trusty) "ubiquity fails to complete automated upgrade with python traceback in _restore_package_selection_in_cache" [Undecided,New] https://launchpad.net/bugs/1316032 | 08:20 |
| caribou | this may not be the best room to address this though | 08:21 |
| caribou | xnox: I am tempted to re-run the apt-clone command after rebuilding the chroot | 08:21 |
| caribou | xnox: it might be a media problem, as this morning I was not able to reboot on the USB stick I used over the weekend | 08:22 |
| xnox | caribou: the useful bit would be to fetch and upload apt-clone generated tarball that it is trying to restore. It should be in the target filesystem. Let me check where it should be comming from. | 08:22 |
| caribou | xnox: I located this one | 08:23 |
| caribou | xnox: the system is usable btw, it just doesn't have all the user environments & such | 08:23 |
| xnox | caribou: right, please attach it to the bug report. (apt-clone-state-.*.tar.gz) | 08:23 |
| caribou | xnox: ok. Do you think that the apt-clone could be run on the running system itself, or do I need to reboot to install media & rebuild the chroot ? | 08:24 |
| xnox | caribou: in practice we do not recommend using ubiquity upgrade option. | 08:24 |
| xnox | caribou: i want the one from the current system as it is right now. It should have been kept around. | 08:25 |
| caribou | xnox: then it should be scrapped; having a documented option that is unstable is preaching for trouble IMHO | 08:25 |
| cjwatson | I don't like the option, but it's popular | 08:26 |
| caribou | xnox: ok, I'll let you know when I get all that done; nothing urgent | 08:26 |
| xnox | caribou: is there no /var/ubiquity-apt-clone/*.tar.gz ? | 08:26 |
| caribou | cjwatson: it worked for me on two other systems; which is why I'm suspecting that my USB key went bad. I just built another one | 08:26 |
| xnox | caribou: what did you upgrade from? ~stock precise? | 08:27 |
| caribou | xnox: yep | 08:27 |
| xnox | caribou: i'll test that and will check what's going on. | 08:27 |
| caribou | xnox: don't waste too much time on this | 08:28 |
| caribou | xnox: as I said, it worked flawlessly on two systems | 08:28 |
| xnox | pitti: i vaguely remember that we were still not using insserv & startpar on ubuntu due to shutdown not handled properly. But if that is the case, it would be RC in debian as well against upstart package. Thus we should migrate to it. slangasek might know more reasons. | 08:30 |
| pitti | xnox: ah, thanks; OOI, how is that related to upstart? | 08:35 |
| pitti | xnox: if e. g. the ordering in /etc/rc6.d/ was wrong, that woudl affect all sysvinit/systemd/upstart/openrc alike? | 08:35 |
| xnox | pitti: true... | 08:35 |
| xnox | yeah, upstart doesn't handle our shutdown, we simply leave upstart jobs running that don't have "stop on" condition and that's about it. | 08:39 |
| cjwatson | mapreri: done | 08:59 |
| === vrruiz_ is now known as rvr | ||
| lubko | hi | 10:07 |
| lubko | suppose I'm running ubuntu 12.10 lts and a package I need is not available for install. What's the proper way to get the package included in Ubuntu? Add to debian and wait? Is it possible to add a package for an already released distribution? | 10:08 |
| LocutusOfBorg1 | ubuntu 12.10 is NOT lts | 10:13 |
| LocutusOfBorg1 | anyway if you add it in debian is better for sure, it will be _automatically_ imported in ubuntu aswell | 10:14 |
| lubko | oh, then it's 12.4 maybe | 10:14 |
| LocutusOfBorg1 | but I don't think it can be backported to 12.04 | 10:14 |
| LocutusOfBorg1 | anyway ask to upload on debian | 10:14 |
| LocutusOfBorg1 | ask for a sync | 10:14 |
| LocutusOfBorg1 | file a backport bug and wait for sponsors-team | 10:14 |
| LocutusOfBorg1 | hint: the commands are "backportpackage" and "requestbackport" | 10:15 |
| LocutusOfBorg1 | unless the package is useful only in ubuntu | 10:15 |
| LocutusOfBorg1 | leaving, sorry | 10:15 |
| xnox | lubko: you can always create a PPA and make packages available from there. | 10:21 |
| darkxst | pitti, ping | 10:26 |
| === lubko is now known as lisca | ||
| pitti | darkxst: just ask :) (I'm busy, but I'll answer backscroll) | 10:56 |
| pitti | dholbach: yay, http://packaging.ubuntu.com/html/auto-pkg-test.html magically updated, thanks! announcement sent | 11:02 |
| * dholbach hugs pitti :) | 11:02 | |
| darkxst | pitti, wondering if Upower 0.99 likely to land this cycle, its pretty much a hard dependency for GNOME 3.12 | 11:04 |
| xnox | pitti: is this normal http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-libnih/5/ARCH=amd64,label=adt/artifact/results/log/*view*/ ? | 11:07 |
| pitti | darkxst: would certainly be nice, but it's a rather large transition (lots of rdepends, a lot of them probably need to be ported from upower to logind for suspend and friends) | 11:07 |
| xnox | pitti: that's from http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-libnih/ | 11:07 |
| pitti | xnox: the "can't parse dependency libdbus-1-dev:native (>= 1.4) | 11:07 |
| ogra_ | hmm, why do .local addresses not work anymore from my trusty laptop | 11:07 |
| pitti | xnox: ? not sure, I never saw ":native" | 11:08 |
| * ogra_ can reach them from all other machinnes in the network ... | 11:08 | |
| pitti | xnox: that's using Dpkg::Deps::deps_parse, i. e. libdpkg-perl | 11:08 |
| ogra_ | and it used to work during trusty dev cycle ... is there a known bug ? | 11:08 |
| pitti | I thought this was the official interface | 11:08 |
| pitti | ogra_: I did that just yesterday on utopic, worked fine; hmm | 11:09 |
| ogra_ | ogra@styx:~$ ping fhem.local | 11:09 |
| ogra_ | ping: unknown host fhem.local | 11:09 |
| ogra_ | ogra@anubis:~$ ping fhem.local | 11:09 |
| ogra_ | PING fhem.local (192.168.2.75) 56(84) bytes of data. | 11:09 |
| ogra_ | anubis is a precise desktop | 11:10 |
| ogra_ | styx is my lappie | 11:10 |
| ogra_ | i wonder if it is related to wlan vs wired or some such | 11:10 |
| darkxst | pitti, how many of the redepends actually use suspend and friends though, apart from g-s-d (already ported), u-s-d (can merge g-s-d patches), indicator-power? | 11:12 |
| === doko_ is now known as doko | ||
| pitti | darkxst: I don't know yet; I suppose things like xfce4-power-manager, mate-power-manager, kde-runtime might well do | 11:13 |
| pitti | darkxst: codesearch to the rescue :) (queries like http://ubuntu-codesearch.surgut.co.uk/search?q=UPower.Suspend) | 11:15 |
| pitti | darkxst: http://ubuntu-codesearch.surgut.co.uk/search?q=up_client_suspend as well | 11:17 |
| pitti | but it's hard to believe that this is everything, unless XFCE/KDE etc. were really good at porting :) | 11:17 |
| pitti | xfpm_power_sleep (power, "Suspend", FALSE); | 11:19 |
| pitti | right, we need to catch indirect calls like that, too | 11:19 |
| darkxst | pitti, yes hard to believe XFCE would have ported anything | 11:22 |
| === MacSlow is now known as MacSlow|lunch | ||
| seb128 | bluez5 is going to be another interesting one | 11:25 |
| seb128 | speaking of other desktops/porting and needed by new GNOME | 11:25 |
| darkxst | http://git.xfce.org/xfce/xfce4-power-manager/commit/?id=ae97be6f3500eea509d61c914e22c5355e7d57de | 11:26 |
| darkxst | bluez5 is less important, we can live without that | 11:26 |
| seb128 | the Debian gnome-pkg seemed to have flagged it as an important issue to update GNOME | 11:28 |
| seb128 | but if it's not that's good | 11:28 |
| pitti | darkxst: nice! | 11:29 |
| ScottK | For Kubuntu, we'll have upstream support for bluez5 and are getting bugged by upstream to move forward. | 11:29 |
| darkxst | right, it would be preferably to have bluez5, but we can ship GNOME 3.12 without it | 11:31 |
| apw | pitti, so do we yet have any way i can detect under adt why am i being run, ie on hows behalf. for my own upload, or an upload for another package | 11:31 |
| pitti | hey ScottK, how are you? | 11:31 |
| apw | s/hows/whos/ | 11:32 |
| pitti | ScottK: would you happen to know which KDE component is interfacing with upower (or perhaps logind already) to do suspend/resume/poweroff etc.? | 11:32 |
| pitti | apw: not "under" adt (that has no idea why you call it), but we have that information in the log files on the britney host (snakefruit) | 11:33 |
| pitti | apw: admittedly I don't have a good idea how to parse them, that's jibel's expertise mostly | 11:34 |
| xnox | pitti: looks like when resolving build-dependencies (e.g. those that can have :any, :<arch>, :native) one needs to pass "build_dep => 1" to deps_parse. How/where should I send the patch for that? | 11:34 |
| ScottK | pitti: Should be solid. | 11:35 |
| pitti | ScottK: thanks | 11:35 |
| pitti | xnox: ah; something like http://paste.ubuntu.com/7404029/ ? testing now | 11:36 |
| darkxst | pitti, seems mate is also working on porting i.e. http://git.mate-desktop.org/mate-power-manager/commit/?id=8f734c679de61292f0ae1bd9923fc67801ab041c | 11:36 |
| xnox | pitti: yeap. | 11:37 |
| pitti | xnox: would that break any binary deps? (sounds not, but are you aware of anything?) | 11:37 |
| pitti | Removing adt-satdep:amd64 because I can't find libdbus-1-dev:native:amd64 | 11:39 |
| pitti | xnox: so, it helps a bit, but not quite sufficient yet as apt still doesn't know about those; I suppose I need to do some extra filtering somewhere | 11:39 |
| RAOF | pitti: There's a new colord in collab-maint git (which doesn't want to be uploaded yet) that fails autopkgtest in my VM really strangely - it fails to build, but _only_ during the ADT test. | 11:39 |
| xnox | pitti: extra filtering also works, e.g. on launchpad ":*" is simply stripped from all names. | 11:39 |
| xnox | pitti: and since adt tests are non-multiarch and always run everything from a single arch, it's best to just do that. | 11:40 |
| RAOF | pitti: If I keep the VM around and log in, it builds fine. | 11:40 |
| pitti | RAOF: how does it fail? | 11:41 |
| pitti | meh, *just* when I thought I put out the last adt-run fire two new ones come along :) | 11:41 |
| RAOF | pitti: make fails to find a file to dist. But colord builds out-of-tree fine, I checked. | 11:42 |
| RAOF | Sorry I don't have the exact error handy. | 11:43 |
| pitti | xnox: hm, all that multi-arch business is actually why I'm using libdpkg-perl in the first place; I had expected reduce_arch => 1 to do that, or maybe there's yet another magic option for that? | 11:43 |
| xnox | pitti: use_arch => 0 ? | 11:44 |
| xnox | pitti: or maybe reduce_restrictions => 1 | 11:45 |
| pitti | xnox: no, I do want that | 11:45 |
| pitti | adt-run1: build dependencies: architecture resolved: autopoint, dbus (>= 1.4), debhelper (>= 9), dh-autoreconf, dpkg-dev (>= 1.16.1~), libc6-dev (>= 2.15~) | libc6.1-dev (>= 2.15~), libdbus-1-dev (>= 1.4), libdbus-1-dev:native (>= 1.4), libexpat1-dev (>= 2.0.0), libexpat1-dev:native (>= 2.0.0), pkg-config (>= 0.22) | 11:46 |
| pitti | xnox: ^ with reduce_restrictions => 1 | 11:46 |
| xnox | pitti: i guess i can remove needs-build tag and spell out the build-dependencies. | 11:46 |
| pitti | xnox: that doesn't do the same, BTW | 11:47 |
| pitti | xnox: so I guess s/:native// it is? | 11:47 |
| xnox | pitti: i'm not sure how but in the case where one is not cross-compiling this simply reduces the: libdbus-1-dev libdbus-1-dev:native to libdbus-1-dev | 11:47 |
| apw | pitti, it would be nice if we could have some kind of "RUNNING_FOR=x" sort of thing ... so we can not waste a load of time for the kernel when uploaded for itself | 11:47 |
| pitti | apw: that sort of thing would need to be done somewhere in the britney/adt interface though | 11:48 |
| pitti | apw: indeed; we knew about this wasted test when we came up with that simple criss-cross rebuild test | 11:49 |
| xnox | pitti: e.g. dpkg-checkbuilddeps does the right thing -> says nothing is needed, but when i pass "-ai386" it says libdbus-1-dev needs installing (that is libdbus-1-dev:i386) | 11:50 |
| pitti | xnox: crude, but works: http://paste.ubuntu.com/7404072/ | 11:51 |
| === debfx_ is now known as debfx | ||
| pitti | xnox: I'll see to come up with a test for that after lunch | 11:51 |
| xnox | pitti: yeah, that should work. | 11:53 |
| === _salem is now known as salem_ | ||
| mardy | pitti: sorry to bother you, but I think you might be able to help me with this build failure, as it's about debhelper and python3: https://launchpadlibrarian.net/174684030/buildlog_ubuntu-utopic-i386.uoa-integration-tests_0.2%2B14.10.20140506-0ubuntu1_FAILEDTOBUILD.txt.gz | 12:18 |
| mardy | pitti: I found that other packages in Debian had the same issue and fixed it like this: http://anonscm.debian.org/gitweb/?p=collab-maint/hitchhiker.git;a=commitdiff;h=ee7d2b40d3e66d2017498ee884a2c470b577182c | 12:18 |
| mardy | pitti: I have to say that I don't understand what this is all about, TBH; should I just copy that fix? It seems a bit dirty... | 12:19 |
| mardy | pitti: OK, I think that this is saying that overriding is the only solution ATM: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597105 | 12:29 |
| ubottu | Debian bug 597105 in debhelper "add support to build python3-* packages" [Wishlist,Open] | 12:29 |
| xnox | mardy: hm, you should use pybuild which is the right way to build python3/python2 packages. | 12:30 |
| xnox | mardy: see https://wiki.debian.org/Python/Pybuild | 12:31 |
| Saviq | xnox, Mirv, can't cross-build unity8 under utopic, could you have a look please: http://paste.ubuntu.com/7404297/ | 12:33 |
| mardy | xnox: thanks, I'll try that! | 12:33 |
| === dholbach_ is now known as dholbach | ||
| Saviq | hmm | 12:35 |
| Saviq | maybe it's my fault, trying in a clean chroot | 12:35 |
| Saviq | xnox, Mirv, unping for now | 12:35 |
| xnox | Saviq: somehow the package you build is not the package you install build-deps for. | 12:37 |
| Mirv | Saviq: irssi does not support 'unping', but it would be nice if it did ;) | 12:37 |
| Saviq | xnox, I think it's the Qt5 rename | 12:37 |
| xnox | Saviq: e.g. you removed ubuntu-settings-components and installed qtquick2. | 12:37 |
| xnox | Saviq: but you still say that you need ubuntu-settings-components. | 12:38 |
| xnox | Saviq: could be. | 12:38 |
| Saviq | xnox, ok, but that's a clean chroot now: http://paste.ubuntu.com/7404308/ | 12:38 |
| Saviq | Mirv, ↑↑ looks like this would require UITK to update its deps to the new names? | 12:38 |
| Mirv | Saviq: well the old names are transitional packages so there shouldn't be a reason for that to make difference? | 12:39 |
| Saviq | Mirv, maybe it's because of multi-arch though? | 12:39 |
| Mirv | Saviq: more like that one graphical effects "|" dependency in UITK is even older transitional thing and might of course confuse some package installer | 12:39 |
| Mirv | multi-arch sounds understandable | 12:39 |
| Saviq | Mirv, it tries to get arch:armhf, the transitionals are only arch:all | 12:40 |
| Mirv | Saviq: ah... | 12:40 |
| xnox | Mirv: transitional packages must be the same, e.g. arch:any and Multiarch:same | 12:40 |
| xnox | Mirv: if the package they point to is that. | 12:40 |
| xnox | Saviq: ^ | 12:41 |
| Saviq | bad Mirv! | 12:41 |
| Saviq | or whoever did the transitionals in debian ;) | 12:41 |
| Mirv | I just synced! :) | 12:41 |
| pitti | mardy: missing pyversions> apparently you are only building a py3 package, so you need to call py3versions (pyversions is for 2.x) | 12:42 |
| pitti | mardy: or, if you actually build py2 versions, you indeed need to b-dep on python-all, yes | 12:43 |
| pitti | mardy: looking at your package, it doesn't even build any python[3]-* package | 12:45 |
| pitti | mardy: so I don't think you actually want --with python2 | 12:45 |
| pitti | ^ that's the bit which needs pyversions (but only useful for building python modules) | 12:45 |
| pitti | xnox: btw, libnih's debian/tests/control's Depends: are entirely useless | 12:52 |
| pitti | xnox: "Depends:\nRestrictions: build-needed" shoudl suffice entirely | 12:52 |
| mardy | pitti: thanks, I'm now try using pybuild as suggested by xnox | 12:52 |
| pitti | mardy, xnox: ^ except that mardy isn't trying to build python[3]-* packages :) | 12:53 |
| pitti | so if anything, pybuild will make it more complicated | 12:53 |
| xnox | mardy: do you or do you not build python2 or python3 packages? | 12:54 |
| pitti | IMHO you shold drop the --with, and just do whatever you need to do (python3 setup.py install ..) in debian/rules explicitly, instead of relying on some magic which wasn't designed for this | 12:54 |
| mardy | pitti, xnox: ATM, the package is using python just to install some data files on the system; no python files are buing handled | 12:56 |
| pitti | mardy: right, hence my suggestion above; --with python2 or pybuild aren't really built for this, you'll run into some trouble | 12:56 |
| pitti | so better explicitly say what you need to do | 12:56 |
| mardy | pitti: but, there was no "--with" when that build failed. Probably debhelper was too smart and autodected that? | 12:57 |
| pitti | mardy: I apt-get source'd the current utopic pacakge, that does have it | 12:58 |
| mardy | pitti: oh, yes, but I removed that in the branch I'm currently building (https://code.launchpad.net/~mardy/uoa-integration-tests/python3/+merge/218283), though now I re-introduced it with the last commit | 13:01 |
| ogra_ | hmm, did pad.lv launchpad redirects stop working ? or is my new firefox broken ? | 13:05 |
| ogra_ | http://pad.lv/1308365 doesnt open for me | 13:05 |
| ubottu | Launchpad bug 1308365 in dialer-app "press-call-twice-to-redial doesn't work" [Undecided,Confirmed] | 13:05 |
| pitti | ogra_: yes, hangs here, too | 13:05 |
| ogra_ | k, i was about to blame FF :) | 13:06 |
| pitti | that works just as good or bad as version 28 here :) | 13:07 |
| pitti | it still greets me with the "OMGshoudln't have happened" page because it still doesn't know how to register to a non-archaic gnome session, but that bug is years old | 13:07 |
| pitti | otherwise I don't really understand all the fuss about "my menus are gone", they are all still there :) | 13:08 |
| pitti | xnox: ok, committed http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=be7814b30 (good thing I wrote a test, I was missing another spot to fix), rolled it out, and retried libnih | 13:11 |
| === MacSlow|lunch is now known as MacSlow | ||
| === smb` is now known as smb | ||
| pitti | xnox: crap, seems precise's libdpkg-perl is too old for this | 13:24 |
| pitti | xnox: ok, plan B: remove them before calling deps_parse().. | 13:26 |
| mapreri | pitti: Hi! with "you can ping the leads of these two derivatives to check" do you mean to email who seems to be the leader (admins of the lp teams?), don't you? | 13:28 |
| === oSoMoN_ is now known as oSoMoN | ||
| marga | The bug I encountered last month is back: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1302605 | 13:31 |
| ubottu | Launchpad bug 1302605 in eglibc (Ubuntu) "Calls to /libx32/ld-linux-x32.so.2 hang" [Undecided,Confirmed] | 13:31 |
| marga | infinity, could you please take a look? Let me know if you need any extra info | 13:32 |
| pitti | mapreri: they should be more or less identical yes, or at least know who to ask | 13:32 |
| mapreri | ok | 13:38 |
| pitti | xnox: ah, so it finally greenified \o/ you and you fancy dependencies.. :) | 13:50 |
| xnox | pitti: =)))))) | 13:52 |
| pitti | xnox: do you have an idea about the upstart failure? | 13:53 |
| xnox | pitti: didn't look yet, will check it. | 13:53 |
| pitti | wrong string value, expected 'init (upstart [0-9.][0-9.]*' got 'initctl: Name "com.ubuntu.Upstart" does not exist' | 13:53 |
| pitti | missing D-BUS or whatever? | 13:53 |
| xnox | pitti: that one is weird and has been seen intermittendly on the buildds, but does pass. | 13:55 |
| xnox | bug #1315767 | 13:56 |
| ubottu | bug 1315767 in upstart (Ubuntu) "intermitent test failure" [Undecided,New] https://launchpad.net/bugs/1315767 | 13:56 |
| pitti | xnox: at least that's the one that seems to consistently break i qemu | 14:06 |
| pitti | "in" | 14:06 |
| xnox | pitti: or just slow hardware is it seems to be the trend. | 14:07 |
| Elv1313 | Hello, any idea why https://errors.ubuntu.com/problem/96becd9a35ea3f1b2a5841dd058629ecf20c5673 is failing to retrace? It has been reported again yesterday and I really like to fix this, but I can't reproduce | 14:18 |
| pitti | superm1: uh, black screen! do we ship performant enough GL drivers for that? :-) | 14:30 |
| superm1 | pitti: :) | 14:30 |
| mapreri | superm1: :D | 14:31 |
| mapreri | (read a reply with a so short delay it's so pleasant!) | 14:32 |
| pitti | mapreri: so let's wait for a reply from studio, then we can (hopefully) dramatically simplify this | 14:33 |
| mapreri | pitti: yep. I'm deleting the rest of the old cruft... | 14:34 |
| mapreri | pitti: maybe you can remove this mp? https://code.launchpad.net/~gilir/xscreensaver/fix-129769/+merge/18043 | 14:35 |
| pitti | mapreri: with moving the screensavers back to the debian layout, we'll need some Breaks/Replaces: until the next LTS (16.04), but otherwise it should almost get back in sync | 14:35 |
| pitti | mapreri: I set it to "merged" according to the last comment | 14:35 |
| mapreri | pitti: umh... you right... let me think about the correct Breaks/Replaces | 14:36 |
| mapreri | pitti: yes, it's really merged | 14:36 |
| arges | RAOF: hi | 14:48 |
| bdmurray | mvo: could you have a look at bug 1309447 which failed verification? | 14:51 |
| ubottu | bug 1309447 in apt-clone (Ubuntu Trusty) "Unicode decode error during upgrade to 14.04 if sources.list contains non-ascii characters and locale is non-US" [High,In progress] https://launchpad.net/bugs/1309447 | 14:51 |
| mvo | bdmurray: aha, thanks | 14:52 |
| mvo | bdmurray: hrm, hrm, we probably need a .4 for this | 14:52 |
| === timrc-afk is now known as timrc | ||
| === roadmr is now known as roadmr_afk | ||
| mpt | cyphermox, how does NetworkManager decide how many bars to give a Wi-Fi network? What are the units of measurement? | 15:31 |
| cyphermox | IIRC <=25% one bar, >25% two bars, >50% three bars, >75% four bars | 15:33 |
| Elv1313 | Hello, there is no -dbg packages for sflphone-daemon, sflphone-gnome and sflphone-kde, is there any reason for that? What can I do to have these packages added to the repository? | 15:34 |
| cyphermox | mpt: scratch that, I'm wrong | 15:35 |
| mitya57 | Elv1313: Can you use ddebs.ubuntu.com? | 15:35 |
| mpt | cyphermox, I was going to say, I didn’t know there was a maximum value :) | 15:35 |
| mpt | (which percentage would imply0 | 15:35 |
| mpt | ) | 15:35 |
| cyphermox | there is | 15:35 |
| cyphermox | well | 15:35 |
| cyphermox | it's a function of SNR | 15:35 |
| mitya57 | Elv1313: i.e. download .ddebs for your architecture/version from http://ddebs.ubuntu.com/pool/universe/s/sflphone/, and dpkg -i them | 15:36 |
| mpt | cyphermox, Signal to Noise Ratio? | 15:36 |
| cyphermox | yes | 15:36 |
| mpt | ok, that’s all I need to know, thanks | 15:37 |
| cyphermox | so, >5% == nm-signal-25, >30% == nm-signal-50, >55% == nm-signal-75, >80% == nm-signal-100 | 15:37 |
| Elv1313 | mitya57: thanks, but I see other packages have -dbg directly in the main repository. I also have issues with errors.ubuntu.com where I have incomplete backtraces (without symbols), so there is something wrong somewhere... | 15:38 |
| mitya57 | Elv1313: Debian does not have .ddebs, so maintainers usually add debug packages manually. For sflphone it's not the case. | 15:39 |
| mpt | cyphermox, the reason I was asking was to figure out what the accessible label should be — whether it can be a percentage, or whether it has to be just “Weak”, “Moderate”, etc | 15:39 |
| mitya57 | Incomplete backtraces depend on whether retracer was lucky or not. | 15:39 |
| Elv1313 | mitya57: The maintainer (well, the one assigned by the sflphone developers to take care of take) happen to be myself, so what are the steps? | 15:40 |
| cyphermox | mpt: could still be weak, moderate | 15:40 |
| cyphermox | it's up to what you feel better conveys the message :) | 15:41 |
| mitya57 | Elv1313: No, in Debian maintainer of sflphone is not you :) | 15:41 |
| mpt | ok | 15:42 |
| mitya57 | Elv1313: In any case, https://wiki.debian.org/DebugPackage | 15:42 |
| Elv1313 | mitya57: I know that, but I also know that its part of my job to get things done ;) | 15:42 |
| xnox | mpt: the units are abitrary, whilst the power of the signal & noise is measured in dBm, the ratio is without units. Some devise "Arbitrary Strength Unit" but those are not consistent across GSM/3G/LTE/WiFi thus e.g. when people complained that iphone has low strength -> they released software update to "bump by one bar up" =) | 15:42 |
| mitya57 | Elv1313: In Ubuntu, you can just not care | 15:43 |
| Elv1313 | so in the end, it's still my problem to get the -dbg into the main repository | 15:43 |
| mpt | * The '''signal strength accessible label''' should be “(Very weak)”, “(Weak)”, “(Moderate)”, “(Strong)”, or “(Not in range)”. | 15:43 |
| mitya57 | Then that wiki page is for you | 15:43 |
| xnox | mpt: that sounds good. | 15:43 |
| Elv1313 | mitya57: ok, thanks | 15:44 |
| === roadmr_afk is now known as roadmr | ||
| === marcoceppi_ is now known as marcoceppi | ||
| * mpt wonders how screenreaders articulate the difference between labels with and without ellipses | 15:52 | |
| cyphermox | dot dot dot | 15:55 |
| cyphermox | I don't know :) | 15:55 |
| slangasek | Mirv: hmm, apparently a race condition while I was preparing the merge, sorry | 16:02 |
| slangasek | pitti: insserv is a thing we should do, but there's a lot of groundwork to do first | 16:02 |
| slangasek | xnox: the shutdown problems with insserv are Ubuntu-specific | 16:02 |
| xnox | slangasek: i remember you saying something like that. but i did not recall the fine details of they actually are. | 16:03 |
| slangasek | xnox: when Scott deployed upstart, he removed init scripts in the process rather than making them upstart-aware; this means that Ubuntu is missing a lot of the init script dependency information that insserv needs | 16:04 |
| slangasek | we obviously never removed init scripts in Debian :) | 16:05 |
| pitti | slangasek: you mean for scripts which came back later through syncs and merges? | 16:06 |
| xnox | slangasek: lovely. So we need to revert initscripts back into place, and modify them as needed to be apppriate for ubuntu..... | 16:06 |
| pitti | we still remove pretty much all of rcS.d/ from initscripts, but of course there are lots more sources putting stuff there | 16:07 |
| slangasek | pitti: sorry, I don't understand the question | 16:07 |
| slangasek | the fact that the initscripts *are* removed is the problem | 16:07 |
| xnox | pitti: is it normal that a get an aweful beep when i reboot with systemd? | 16:07 |
| slangasek | insserv gets the ordering wrong without them | 16:08 |
| pitti | slangasek: I didn't understand how you got from "we removed init.d scripts as we have upstart jobs for them" to "they are missing dep info" | 16:08 |
| pitti | slangasek: aah | 16:08 |
| slangasek | and it's more about rc{0,6} than rcS | 16:08 |
| pitti | slangasek: right, now I understand | 16:08 |
| slangasek | rcS is probably ok currently, but to get it back in sync with Debian again may introduce regressions with insserv along the way | 16:08 |
| xnox | slangasek: so if i run my init.d/init/systemd extractor against debian and compare the output, it should be evidant what's missing, no?! | 16:09 |
| pitti | slangasek: so upstart runs them in between or after the native and builtin jobs for shutdown, not before? | 16:09 |
| bdmurray | xnox: slangasek said you might be able to help with bug 1316302. | 16:09 |
| ubottu | bug 1316302 in android (Ubuntu) "ubuntu-emulator-runtime uses the same MAC address" [High,New] https://launchpad.net/bugs/1316302 | 16:09 |
| xnox | slangasek: and then sort through that as appropriate. | 16:09 |
| pitti | slangasek: I wouldn't like to reintroduce Debian's init.d scripts for rcS/rc0/6 TBH; we won't ever support running sysvinit in Ubuntu (I think?), and we don't really need them | 16:09 |
| pitti | xnox: beep> err, I hope not; I never heard a beep, but then again I'm not even sure if my laptop still has the equivalent of a PC speaker | 16:10 |
| slangasek | xnox: I suppose that should work, yes | 16:10 |
| pitti | slangasek: ok, thanks for the heads-up; so I guess for the initial merge I'll revert to our current update-rc.d and instead port the systemd script support manually? | 16:11 |
| slangasek | pitti: there are no upstart native and builtin "shutdown" jobs; and if you want to switch to insserv you must reintroduce the rc{0,6} init scripts so that insserv doesn't pooch people's filesystems on shutdown | 16:11 |
| slangasek | which initial merge? | 16:11 |
| pitti | slangasek: the one which I have on my hard disk and testing currently | 16:12 |
| xnox | slangasek: pitti is merging sysv-rc. | 16:12 |
| pitti | (^ which is sysvinit) | 16:12 |
| slangasek | hmm | 16:12 |
| xnox | right yeah. | 16:12 |
| slangasek | pitti: any chance you can post that for me to review before upload? | 16:12 |
| pitti | slangasek: I initially pondered just doing the update-rc.d bits for systemd, but then again, we should merge it every now and then, so I got to that question about insserv | 16:13 |
| slangasek | I am not confident in the sysvinit package in Debian | 16:13 |
| pitti | slangasek: yes, absolutely | 16:13 |
| xnox | bdmurray: so since it's all using qemu in the end it should be possible to override mac address. | 16:13 |
| pitti | slangasek: I was going to put it into a PPA with a call for testing and all that | 16:13 |
| slangasek | and I've held off merging it because things keep changing in Debian in Ubuntu-incompatible ways | 16:13 |
| pitti | (aside from the fact that currently $world rdepends on it, and any failed autopkgtest holds it in -proposed :) ) | 16:13 |
| xnox | bdmurray: however the device that emulator uses is a funny 3g-modem-not-really one. I'll look into randomizing it's MAC address. | 16:14 |
| bdmurray | xnox: that'd be great thanks | 16:14 |
| pitti | slangasek: ah, you did? ok; the insserv one seemed desirable to me in the long run to avoid slowly breaking compatibility with Debian syncs, and you already committed a lot of our delta there, so it shrunk quite a bit | 16:14 |
| pitti | slangasek: did> hold back the merge, I mean | 16:14 |
| slangasek | yes, I do want us to get to insserv | 16:15 |
| slangasek | we just have to sort out the init script problem first | 16:15 |
| shadeslayer | pitti: ping | 16:16 |
| shadeslayer | pitti: do autopkgtests get picked up automatically? i.e. if I add a test to kdelibs , https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/ will list it once it's processed? | 16:16 |
| pitti | shadeslayer: they do, yes; but it might take an hour or two until britney gets to it (at least it needs to get built and installable on all arches) | 16:18 |
| shadeslayer | pitti: roger | 16:23 |
| pitti | shadeslayer: when did you upload it? i. e. has it been some inordinately long time already? | 16:25 |
| pitti | one of these days I need to buy mvo a beer and figure out why we get these dreaded "hash sum mismatch"es on apt-get update so often :/ | 16:27 |
| pitti | (numpy and ubiquity tests restarted, FTR) | 16:28 |
| shadeslayer | pitti: no, just uploaded it like 15-20 minutes ago | 16:47 |
| shadeslayer | around the time I pinged you | 16:47 |
| shadeslayer | pitti: https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu2 | 16:47 |
| pitti | shadeslayer: what is debian/tests/acc doing? just checking that the command doesn't error? | 16:49 |
| shadeslayer | Description-en: debhelper addon to compare ABI compatibility of shared C/C++ library versions | 16:50 |
| pitti | aah | 16:50 |
| pitti | shadeslayer: OOI, how does "debian/rules build" know that it should test against the installed packages? | 16:50 |
| shadeslayer | pitti: no idea, tests come from debian, so I'd ask someone on #debian-qt-kde , I'm very new to autopkgtest | 16:51 |
| shadeslayer | still trying to understand bits and pieces | 16:51 |
| pitti | ok | 16:51 |
| * pitti waves good night, cu tomorrow | 16:51 | |
| shadeslayer | night :) | 16:51 |
| xnox | pitti: i have a merge of plymouth from debian, which should enable systemd units... but this is my first time playing with systemd. So far i've caused it to unmount filesystems not-clean on shutdown, not able to boot with dirty filesystems (one needs to switch to tty1 which triggers lightdm job somehow) and systemctl reboot fails from runlevel 0 | 16:56 |
| xnox | (as in it gets stuck on a cups job) | 16:56 |
| xnox | pitti: i think i should upload plymouth jobs/units.... | 16:56 |
| xnox | pitti: but overall it seems quite buggy at the moment =) | 16:56 |
| === blkperl_ is now known as blkperl | ||
| slangasek | Mirv: readded your change and uploaded; have you forwarded this change upstream / to Debian already? | 17:09 |
| === roadmr is now known as roadmr_afk | ||
| === bfiller is now known as bfiller_afk | ||
| === roadmr_afk is now known as roadmr | ||
| === bfiller is now known as bfiller-afk | ||
| xnox | slangasek: pitti: if init.d scripts are missing, is it ok to simply introduce systemd-unit and skip init.d script? | 18:59 |
| xnox | or i guess we do want inserrv support with upstart still?! | 19:00 |
| === Logan_ is now known as Guest54722 | ||
| === Logan__ is now known as Guest67468 | ||
| === Guest67468 is now known as Logan_ | ||
| xnox | zz-busybox generates symlinks, yet busybox hook removes them.... | 19:55 |
| slangasek | xnox: insserv support doesn't impact leaf services; we do need to sort out init.d scripts for anything in the rc{0,6} critical path (which may mostly be sysvinit itself) | 20:02 |
| xnox | slangasek: ack. i see a lot of packages that were not rebuild in ubuntu, that is init.d script is stipped instead of kept intact. | 20:02 |
| slangasek | well yes, because a straight rebuild would break it given that your lsb init-functions hook hasn't landed yet | 20:03 |
| xnox | true. | 20:03 |
| === timrc is now known as timrc-afk | ||
| slangasek | xnox: can you do something with your upstart-jobs branch to stop spamming upstart-devel? | 20:03 |
| xnox | slangasek: yes. | 20:03 |
| slangasek | thanks ;) | 20:03 |
| xnox | done. | 20:04 |
| xnox | bdmurray: so in android emulator it does accept shared-net-id parameter which sets the last two bytes of mac address. | 20:08 |
| xnox | bdmurray: snprintf(nic, sizeof nic, "nic,vlan=1,macaddr=52:54:00:12:34:%02x", shared_net_id); | 20:08 |
| xnox | bdmurray: would it be sufficient to randomize across those or do we want larger range? | 20:09 |
| xnox | bdmurray: hm, that would also randomise the IP of the emulator. | 20:12 |
| === bfiller-afk is now known as bfiller | ||
| === timrc-afk is now known as timrc | ||
| === salem_ is now known as _salem | ||
| stokachu | xnox: you around? | 21:20 |
| rsalveti | slangasek: these are the only remaining packages (new src pkgs) to get uploaded in order to have a working x86 emulator: https://launchpad.net/~rsalveti/+archive/touch-emulator-x86 | 22:10 |
| rsalveti | just created a build out of the archive + this ppa, and it worked fine | 22:11 |
| rsalveti | there's still one rendering bug, but that's probably mir related | 22:12 |
| rsalveti | as I got the same issue when I rebuilt the entire stack using the same src packages but forcing gles by default | 22:12 |
| rsalveti | let me upload them, but will need help to get them accepted | 22:15 |
| slangasek | rsalveti: great, happy to help with getting them accepted | 22:57 |
| RAOF | arges: Hello! Just about to reply to your mail. | 23:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!